neha@arrowdevices.com
New member
You certainly can’t improve something unless you measure it. So, how do you know if the functionality of your design has been verified completely? One metric that helps answer this question is coverage. Coverage is a guide for directing verification completeness by identifying covered and uncovered portions of the design.
Coverage can be broadly classified into two categories - Functional and Code coverage. Functional coverage complements Code coverage to handle the exponential increase in complexity and state space of the designs. Functional coverage gets interesting when two or more cover-points are crossed, leading to a variety of possibilities covering interesting combinations of important parameters.
Most of the today’s well-designed constrained random environments will easily take you to around 60 to 70 % of the functional coverage. So, how do you take it from here to get to the magic figure of 100% functional coverage?
The answer lies in following the few steps outlined below. Also added as a ready reckoner, is a flowchart that summarizes these steps.
Step 1: Remove redundant bins
It’s advisable that while developing the coverage, you pay attention to redundant bins. Redundant bins tend to escape and show up as coverage holes. To avoid this, identify cover groups and crosses with the highest uncovered bins in coverage reports. Crosses and cover points with undefined bins are the usual culprits leading to redundant bins. Make use of ‘ignore_bins’ or define the valid cover-bins for cover points instead of letting tools do the auto binning.
Step 2: Run more simulation cycles within the test
Increase the number of stimuli, or the duration of the test. Continue this process till coverage shows some proportional improvement to increase in stimuli. Beyond a point, increase in stimuli count or duration will not yield increase in coverage. This is optimal point for the machine run time, and highest coverage a particular constrained random test can provide.
Step 3: Increase seed count
Increase the seed count for those constrained random tests that are not providing the desired coverage. Continue to increase the seed count till a substantial improvement in the coverage is seen. Beyond a point, increase in seed count will not yield increase in coverage. This is optimal point for the machine run time, and highest coverage a particular constrained random test can provide.
Step 4: Tune the constraints
If the coverage level has plateaued in spite of all the above, it’s time to tune the constraints. Relax or tighten the constraints to target uncovered areas. Depending in need, add more constrained random tests. You can also increase stimuli and seed count after tuning the constraints.
Step 5: Write new directed tests
Once you are out of all the above options and still the coverage has not reached 100 % mark, then you either need to improve the test bench infra, or start writing new directed tests. Directed tests should be used only for highly corner cases that make up the remaining 2-3 % of the coverage.
Attached flow chart provides a ready reckoner of ways suggested above in the form of algorithm. Verification engineers are strongly recommended to take a print out of this flow chart and attach in their cubes for quick reference.
Once the above improvements have been implemented, and the functional coverage reaches 100%, does it mean that the JOB IS DONE?
The answer is…no! 100 % coverage is a necessary, but not a sufficient condition for calling the job done.
This is because, if 100% coverage is accompanied by a high bug rate, it shows insufficient or wrong coverage. You need to do some further work to improve the coverage plan and capture untouched parts of the design and to expose more bugs if present. Hence, one must ensure that the bug rate is tending towards zero, along with 100% coverage to declare the job done.
by Gunjan Gupta
<script src="//platform.linkedin.com/in.js" type="text/javascript">
lang: en_US
</script>
<script type="IN/Share" data-counter="right"></script>
Coverage can be broadly classified into two categories - Functional and Code coverage. Functional coverage complements Code coverage to handle the exponential increase in complexity and state space of the designs. Functional coverage gets interesting when two or more cover-points are crossed, leading to a variety of possibilities covering interesting combinations of important parameters.
Most of the today’s well-designed constrained random environments will easily take you to around 60 to 70 % of the functional coverage. So, how do you take it from here to get to the magic figure of 100% functional coverage?
The answer lies in following the few steps outlined below. Also added as a ready reckoner, is a flowchart that summarizes these steps.
Step 1: Remove redundant bins
It’s advisable that while developing the coverage, you pay attention to redundant bins. Redundant bins tend to escape and show up as coverage holes. To avoid this, identify cover groups and crosses with the highest uncovered bins in coverage reports. Crosses and cover points with undefined bins are the usual culprits leading to redundant bins. Make use of ‘ignore_bins’ or define the valid cover-bins for cover points instead of letting tools do the auto binning.
Step 2: Run more simulation cycles within the test
Increase the number of stimuli, or the duration of the test. Continue this process till coverage shows some proportional improvement to increase in stimuli. Beyond a point, increase in stimuli count or duration will not yield increase in coverage. This is optimal point for the machine run time, and highest coverage a particular constrained random test can provide.
Step 3: Increase seed count
Increase the seed count for those constrained random tests that are not providing the desired coverage. Continue to increase the seed count till a substantial improvement in the coverage is seen. Beyond a point, increase in seed count will not yield increase in coverage. This is optimal point for the machine run time, and highest coverage a particular constrained random test can provide.
Step 4: Tune the constraints
If the coverage level has plateaued in spite of all the above, it’s time to tune the constraints. Relax or tighten the constraints to target uncovered areas. Depending in need, add more constrained random tests. You can also increase stimuli and seed count after tuning the constraints.
Step 5: Write new directed tests
Once you are out of all the above options and still the coverage has not reached 100 % mark, then you either need to improve the test bench infra, or start writing new directed tests. Directed tests should be used only for highly corner cases that make up the remaining 2-3 % of the coverage.
Attached flow chart provides a ready reckoner of ways suggested above in the form of algorithm. Verification engineers are strongly recommended to take a print out of this flow chart and attach in their cubes for quick reference.
Once the above improvements have been implemented, and the functional coverage reaches 100%, does it mean that the JOB IS DONE?
The answer is…no! 100 % coverage is a necessary, but not a sufficient condition for calling the job done.
This is because, if 100% coverage is accompanied by a high bug rate, it shows insufficient or wrong coverage. You need to do some further work to improve the coverage plan and capture untouched parts of the design and to expose more bugs if present. Hence, one must ensure that the bug rate is tending towards zero, along with 100% coverage to declare the job done.
by Gunjan Gupta
<script src="//platform.linkedin.com/in.js" type="text/javascript">
lang: en_US
</script>
<script type="IN/Share" data-counter="right"></script>
Last edited by a moderator:
