Functional Coverage Guidelines for Implementers:
Functional coverage and code coverage both are contributing highly on sign off criteria for verification. Implementers have to make sure that their test plan and test environment is intelligent enough to satisfy the code/functional coverage closure. Code coverage is generated by tool with the help of the simulations generated by the test environment. So test environment should be random and intelligent enough to make sure design is covered as a part of code coverage and designer should be in agreement while code coverage review. There should be valid comments with reason for all exclusions for code coverage w.r.t to design specification. Functional coverage should be written in such a way that it should be able to capture all identified functionality while defining the test plan. Coverage and assertions are very important entity in the verification process and there are few guidelines that would help in verification process.
Few guidelines while working with functional coverage
- Your test plan should be based on the functionality you want to verify w.r.t to specification
- You should have a coverage matrix with the list of cover point details w.r.t to your test plan scenario and there should be a link of traceability between test scenario and cover point.
- Environment should have control mechanism for enabling or disabling coverage and assertions for better controllability in your environment
- Don’t enable functional coverage at the beginning of the verification to avoid simulation overhead in the starting phase of verification
- During the initial time of the verification bug ratio is typically higher, as you move forward to the verification bug ratio would start to drop. Here is the time when you should enable coverage and start analyzing it
- Functional coverage plan needs to be updated as verification progresses
- As your knowledge of the design and corner case understanding increases, you should keep updating your functional coverage plan
- Make effective use of cover group “trigger” and sampling mechanism.
- Follow meaningful names of cover group and cover points. This will help when you in debug process
- Coverage should not be captured on failing simulations. Make sure to gather coverage for only passing simulation. If few tests are not passing in regression first make sure to fix those issues before coming to a conclusion on coverage achievement
- If your tests are keep exercising the same logic in design, start developing the new tests for uncovered coverage part of coverage (coverage holes)
Very nicely written, especially the last section where you talk about few guidelines. Will help in understanding for new engineers.
Thank You Ashith. Appreciate your efforts to read and learn.
you are explanation is good sir………….
how to write a functional coverage for full adder is a snippet question
can u help me
Hi Sowjanya,
I implemented coverage for PIPE example you can take a reference of that and try to implement for FULL adder in a similar way then you can understand better.
Reference: https://theartofverification.com/how-to-build-uvm-environment-part-4/
Thank you
You should have a coverage matrix with the list of cover point details w.r.t to your test plan scenario and there should be a link of traceability between test scenario and cover point.
//whats coverage matrix and hows the link coded?
Hi Arun,
Coverage matrix and that link do not code it’s mentioned while creating Coverage Plan.
Thank you