Hi,
I have this question since long time. At the end of verification cycle, we perform code coverage analysis. At times we may need to waive few of the coverage types due to several reasons. Say for ex: signals that are tied to a hard coded value will reduce the toggle coverage, few combinations of FEC will not be valid due to DUT limitation etc.
We collect all this information in a waiver file through GUI.
Now if the DUT gets modified, these waivers will not be valid and that depends on the extent of modification, DUT is undergone.
During this situation, do I need to create new waivers? Can old waivers be re-used by making minimal modifications to get the updated code coverage numbers for the new RTL?
Kindly share your thoughts.
Regards,
Naveen
The are a number of ways to input code coverage wavers, and doing it through the GUI is usually file/linenumber based. There are also way of excluding coverage directly in the source that is less sensitive to modifications.
This is going to fall into the realm of tool specific details and it is best to contact your vendor directly for the best practices.
In reply to dave_59:
I agree with you, Dave.
But my question was more on the maintenance of these waivers so that I can re-use them with minimal modifications.
I will get in touch with vendor for this.
In general, is code coverage analysis performed again for any RTL updates once verification is officially complete?
Do you feel it is important? Please share your opinion.
In reply to naveensv:
How do you know if your verification is officially complete if you have not run code coverage? Code coverage is supposed to tell you the areas of RTL code that have not been exercised, and if it has not been exercised, it can not have been verified.
I agree it can be tedious to keep updating coverage exclusion files every time the design changes, so you need to strike a balance in using code coverage to help you find areas of the design that need more verification. And there is no reason to run code coverage until you have passing verification tests. So you should schedule periodic code coverage runs among your regression runs. Perhaps monthly, then transition to weekly. It really depends on the overall project timeline, the performance cost of turning on code coverage, and the total number of exclusions your project needs to manage.
In reply to dave_59:
Let’s consider different versions of RTL, say v1 and v2. I verified v1 RTL, analysed code coverage and closed officially.
Now v2 got released few months later with more features added and at the end of the verification of v2, I may need to analyse the code coverage. I re-use the tests developed for v1 but it wont be possible to re-use the waivers.
In reply to naveensv:
Not sure if your last comment is a question or a statement.
If you add more features to RTL v2, then you will need to add more tests for the verification of RTL v2 regardless of if you use the same verification tests from v1.
You might be able to use all, some or none of the code coverage waivers. It is difficult to give a generic answer to this.
In reply to dave_59:
That was a statement, Dave.
But as you said, it depends on the extent of modifications that V2 RTL has undergone. If the modifications are less, then probably I can re-use the waivers and if they are more then it will be very difficult.
Thanks for your valuable inputs.