- Published: Friday, 31 August 2012 22:08
- a methodology
- based on SystemVerilog (SV) but not limited to it
- a set of SV classes to support the methodology
- Predictability : benchmarks can easily be defined
- Proven / Complete : used by many companies in many projects
- Independent / Open : not linked to a tool vendor
- Existing : do not re-invent the wheel
- Ease of maintenance : because standard and based on SV
- Reuse / Scalable : through verification components but also test cases
- Interoperable : verification assets can be reused (eVC)
SystemVerilogUVM is primarily based on the SystemVerilog language but is not limited to it. SystemVerilog has numerous advantages as a language, amongst which:
- It is a standardized language
- Tool / vendor independent (now built-in in all major tools)
- Easy to learn (it is a superset of Verilog)
- Object oriented with extra data types compared to Verilog
- It supports Constraint Random Generation
- Assertion Based Verification to check the design + Scoreboard to check output data
- Coverage Driven Verification (functional coverage)
- It provides easy backdoor accesses
- DPI to other languages (more efficient than PLI of Verilog)
Building a CDV environmentThe following picture depicts a classical Coverage Driven Verification.
Starting from a design specification or a features list, a test plan and verification plan are created (eventually, the verification plan is the features list). The DUT (Design Under Test) interfaces are exercised by verification components (the blue box). Some passive monitors can be plugged on the other interfaces. The monitored data are checked by scoreboards and functional coverage is covered. Radomization is used in the test generation and finally reports are automatically generated based on coverage information and verification plan.
This is for the decorum. Let's now have a look to the flow.
What is the flow?
The first focus must be on the Verification Plan that defines what to test. The items of the plan are translated into coverage points, in a language understandable by the simulator. Then a first version of the verification environment is developped. It is the framework defining how the DUT is exercised. Start with a few highly random test cases and analyze the coverage. The analysis should reveal the coverage holes that can be targeted by adjusting the constraints and adding new test cases. We can already see how important the Verification Plan is: it must be broad but detailed enough.
At this point, the coverage model can be enlarged in order to explore new combinations and if necessary, possibly go back to the verification plan.
- Next >>