In February, we will celebrate the tenth anniversary of Accellera approving the first version of the Universal Verification Methodology (UVM). It’s no exaggeration to say that UVM changed the world of semiconductor verification. It wasn’t the first verification methodology and not even the first to use SystemVerilog, but it was developed and supported by all major electronic design automation (EDA) vendors. Users confidently craft testbenches with the UVM building-block library and guidelines, assured that simulators and tools will handle them effectively.
UVM focused on the diverse set of constructs and powerful capabilities available in SystemVerilog on the specific task of building a reusable verification environment. Object-oriented programming (OOP) support meant that users could extend the building blocks without modifying them. Adherence to the guidelines made verification components reusable “horizontally” across projects and even across companies. Passive components such as monitors and coverage collectors, and even some active interface models, could be reused “vertically” from block to subsystem to system.
Above all, UVM brought automation to testbenches. Verification engineers no longer had to hand-write tests for every feature in the design. They can establish an environment where sequencers autonomously generate an unlimited array of tests, varying in length and content extensively. It takes time and a fair amount of expertise to set up a UVM environment. Since it eliminates a huge amount of manual testing and provides better verification coverage, the up-front investment is worth it.
It is interesting to ask whether the creation and maintenance of a UVM testbench can be automated to reduce the initial effort, minimize the impact of specification changes, and deliver even more value to the verification team. Unfortunately, no solution can magically transform a natural-language specification into a complete verification environment. However, it turns out that there are many parts of a UVM chip testbench that can be automatically generated from executable specifications. The IDS-Verify™ solution from Agnisys provides these capabilities today.
Given our history of register automation at Agnisys, of course, IDS-Verify™ provides a great solution in this domain. Users can specify their registers in any of a wide variety of formats, including IP-XACT, SystemRDL, Microsoft Word and Excel plug-ins, or our customized editor. IDS-Verify™ generates essential testbench components for verifying registers, incorporating them into full-chip verification, and ensuring synchronization as RTL register values evolve.
Based on the register specification, IDS-Verify™ generates the complete UVM testbench: bus agents, drivers, adaptors, sequencers, and sequences, as well as the makefiles to build the testbench and run tests using all major simulators. These tests provide 100% functional coverage “out of the box” with register-focused cover groups. Test types include positive and negative (such as ensuring that a read-only register cannot be written), indirect register access, and lock/unlock register sequences. Additional sequences are generated for special types such as shadow, alias, and interrupt registers.
IDS-Verify™ provides built-in support for numerous standard buses, including ARM® AXI-Full, AXI-Lite, AHB, AHB-Lite, APB, and Avalon. Users are not limited to these choices; they can also define proprietary buses. The sequence specification format in Excel or Python is exceptionally flexible to accommodate many different types of control flow. Among other attributes, users can specify:
- Abstract register read/writes with automatic read-modify-write
- Waiting on time, field values, or signal events
- Access to the Component Interface to drive or sample values
- Hierarchical sequences
- Parallelism using fork-join constructs
- Looping and conditional constructs such as if-else, for, and while
- Randomization and constraints
Users have the flexibility to define commercial protocol verification IP (VIP) components in the testbench and incorporate sequence specifications from their VIP vendors. Vendors or users can follow a similar process to specify custom functional checkers in Excel or Python. Many of the same specification features used for sequences are available for checkers. In addition, users can access callbacks and SystemVerilog interfaces, trigger events on the buses or within the RTL, and specify assertions to check for functional correctness.
Registers can be volatile, and in that case, their values need to be updated in the verification register model. To handle this, IDS-Verify™ has a built-in Model Updater that executes “auto mirroring” whenever a hardware event occurs on a UVM register field.
The automatic coverage generation process directly leverages the information contained in the register specification. For each field in each register, there is a look-up table (LUT) showing the defined values and their meaning. IDS-Verify™ generates a SystemVerilog cover for each register, a cover-point for each field, and bins for the different values. This ensures that the generated register tests exercise all meaningful field values while not artificially lowering coverage metrics due to unspecified values. In addition, IDS-Verify™ supports cross-coverage between multiple field-level coverpoints.
IDS-Verify™ gives a big boost to verification productivity, but it benefits other teams as well. It keeps all teams in sync with a common specification. IDS-Verify™ generates C/C++ header files for the registers, providing value to the programmers writing drivers and other software that interfaces with the hardware. The generated documentation for registers, sequences, and checkers can be used by the technical writers developing user manuals and online documentation.
Perhaps the biggest value of IDS-Verify™ is automatic updates. The register specification changes many times throughout every chip project to reflect product refinement, feature changes, and impact from the implementation process. Modifying registers, whether by addition, deletion, or field redefinition, may necessitate updates to testbench sequences, checkers, coverage codes, software header files, and documentation. With IDS-Verify™, the user simply tweaks the specification and pushes a button to regenerate the output files. All project teams receive consistent updates at the same time.
To learn much more about IDS-Verify™, including a detailed example, please view our recent webinar.
