Dear All,
I am back after a long time ! Here I would like to share my experience on coverage model in System Verilog..
I am back after a long time ! Here I would like to share my experience on coverage model in System Verilog..
There are different ways to define verification plans, I have worked with different organization where I have been involved in verification activities with different approaches. There are two main questions which each verification engineer needs to take care, which are “What to verify” and “How to verify”. I would try my level best to explain it in details with my experiences. Hope you enjoy this technical writeup.
Success of a verification relies heavily on the completeness and accurate implementation of a verification plan. A good verification plan contains resource usage and estimated schedule.There are different ways to define verification plans, such as a spreadsheet, a simple document or text file in some cases. It depends on company to company as way of following a process may be different.
What to verify and how to verify are the major two things which each verification engineer has to think before starting actual verification.
First of all engineer has to clearly defined features to verify in feature extraction phase. And then after defining what exactly need to be verified, engineer has to define how to verify them.
There are two approaches in current industries to make sure that verification is done using Assertions and Functional Coverage. You might have heard about the different methodologies like CDV, RVM, VMM, AVM, OVM and UVM etc... Methodologies are nothing but a flexibility for verification engineers. Using methodologies engineer can reuse and and utilize the power of base classes and the features in a different way. Its a beauty of each methodologies we have been using. I am not denying the that without methodologies we could not make sure on confidence of verification environment, we could. As we know now a days SoCs and ASICs are becoming complex and complex each day, verification engineers ending up with thousands of scenarios with complexity of environment, so in this case methodologies have helped us in utilizing the power of features and functionality of methodologies. I have worked on RVM, VMM and OVM too... I have realized that each methodologies have their own strong features and re-usability. Any way, I would try my best to come up with an detail writeup on methodologies ! Hope I should be able to come up soon :-)
As I have mentioned there are two approaches in current industries to make sure that verification is done. Those are 1. Assertions 2. Coverage. Thats where AIPs (Assertion IPs) and VIPs (Verification IPs) came in to picture.
1. Assertions :
Assertions are primarily used to validate the behavior of a design. ("Is it working correctly?") They may also be used to provide functional coverage information for a design ("How good is the test?"). Assertions can be checked dynamically by simulation, or statically by a separate property checker tool – i.e. a formal verification tool that proves whether or not a design meets its specification. Such tools may require certain assumptions about the design’s behavior to be specified. There are two types of Assertions:
Immediate Assertions:
Immediate assertions are procedural statements and are mainly used in simulation. An assertion is basically a statement that something must be true, similar to the if statement. The difference is that an if statement does not assert that an expression is true, it simply checks that it is true, e.g.:
Concurrent Assertions :
Concurrent assertions are used to check behaviour such as this. These are statements that assert that specified properties must be true.
2. Coverage Model :
2. Coverage Model :
As I have explaing above that SoCs and ASICs are becoming complex and complex each day ! The main concerns for industries are :
- How do they close verification ?
- How can they say , they are done ?
- How can they make sure they have stimulated each possibilities ?
All our current day methodologies have brought in the concept of re-usability of the agents such as BFM’s and monitors across projects. An engineer also creates a coverage model in order to provide the management with a picture of the verification activity status.
Using the strong constructs called covergroup, coverpoint, bins, cross coverage and class concept engineers are easily develops coverage model to generate functional covergare report after they run each simulation. Coverage reports gives us a lot of information in detail in pictorial view as well as in text formate too (based on the tools which you are using).
Its very important and individual should write functional coverage very accurately. I have mentioned some tips on writing functional coverage. Please read my article http://asicwithankit.blogspot.com/2010/03/dont-rely-on-illegalbins-for-checking.html (has been published by two most popular websites testbench.in and asicguru.com)
Hope you have enjoyed this article ! Please shoot me an email or post a comment if you have good thought on this point or you have any questions which you want to discuss.
Enjoy !
ASIC With Ankit
7 comments:
This is very good article.
How i verify major things which verification engineer has to thinks actual verification?
Asic Chip Design
This is very good article.
How i verify major things which verification engineer has to thinks actual verification?
Asic Chip Design
This is very good article.
How i verify major things which verification engineer has to thinks actual verification?
Asic Chip Design
Hi Mical,
Well, this question has very long answer but to short it down to one statement:
Verification engineer has to understand the specification in detail and he/she should write down the test scenarios to verify. So test plan should be solid to move forward with the test bench design.
Thanks,
Ankit
Hello,
I'm a beginner to formal verification. Can u help me writing a SVA for T-flip flop. Like defining the sequence, properties, assertion, etc.
It will be really helpful. Thank you
Hi Ankit ,
I have a basic query for coverage.
As we all know , Code coverage will exercise the written RTL code. Using code coverage analysis we can make sure we have covered all the written RTL logic. And we can add new tests for the missing holes in the code coverage if required.
Functional coverage is written by verification engineer based on the features he has identified from TestPlan. It might possible that if Verification Engineer miss to identify any scenario ,we might have functional coverage hole for that scenario.
Does that mean Functional Coverage might have holes at the end but Code Coverage will never left with holes ?
Hi Sam,
There are couple of things to understand for coverage (functional/code).
Your understanding is correct at some extend. code coverage is mostly to make sure design is covered or exercised during the simulation or not while functional coverage is to make sure the test scenarios that we have identified are exercised during the simulation regression or not.
Answer to your question is, if verification engineer misses the functionality in their test plan then you would mostly catch the holes during the code coverage review. Reason behind this is you have missed the functional scenario/test and never ran that particular functionality and as a result the respected piece of code in design will be un-touch and would show you as hole in your code coverage report.
Thanks,
Ankit
Post a Comment