Ask a bunch of engineers about the Universal Verification Methodology (UVM) and you’ll hear two distinct sets of responses, sometimes from the same people. Most verification engineers agree that UVM was a huge leap in testbench sophistication and a boon for system-on-chip (SoC) and intellectual property (IP) development. It brought object-oriented programming (OOP), constrained-random stimulus generation, reusable verification IP (VIP), testbench automation, functional coverage, and assertions to mainstream verification users. It was developed as a standard, first by Accellera and then by the IEEE, encouraging a wide range of electronic design automation (EDA) vendors and tools to support it. UVM’s impact on the industry cannot be overestimated.

Along with this praise, you’ll hear numerous reservations about UVM. Some are based on technical preferences, such as arguments that the methodology relies too much on SystemVerilog macros or that it doesn’t have enough support for aspect-oriented programming (AOP). UVM doesn’t do much to automate the manual effort of translating designer intent into verification code. UVM also has limitations on “vertical” VIP reuse from block to subsystem to SoC, which was one of the motivations for the development of the Portable Stimulus Standard (PSS). But the most common complaint you’ll hear is that UVM is difficult to learn and therefore challenging to deploy across a large verification team. Qualified UVM experts are hard to find and expensive to hire because they’re in such high demand. Even experienced UVM verification engineers say that it’s hard to remember all the details of the standard and time-consuming to develop testbenches and tests.

At Agnisys, we heard these comments from our users all the time, and early in our product development effort we strove to automate the verification process as well as the design process. We started by automatically generating the register-transfer-level (RTL) design code for IP/SoC registers from an executable specification, and we quickly realized that we could do a lot to help the functional verification process as well. We could generate the UVM testbenches, and the test sequences, needed to verify the registers. We found that some users wanted to be able to execute custom programming sequences, so we added the ability to specify them in an executable format and translate them into UVM testbench sequences. Today, we support custom checks in the testbenches as well, also generated from executable specifications.

In addition to the registers themselves, we also generate wrapper modules to facilitate read and write access. We provide support for access via numerous standard buses, including AXI, AHB, APB, and Avalon. In response to user demand, we added support for many special types of registers, along with appropriate UVM sequences to verify their functionality. We saw an increasing interest in using assertions both for formal verification and for providing checks in the UVM testbenches, so we also automatically generate SystemVerilog Assertions (SVA) for the registers. Our users asked us to provide RTL for standard interfaces and functions, so we introduced our library of customizable and configurable IP blocks. We generate UVM testbenches, tests, and assertions to verify the IP. The figure below does a nice job of showing all the verification-related components that we provide, every one of which replaces considerable manual effort and schedule time.

It would take a big white paper, or perhaps even a small book, to describe everything in this diagram and how we automate the process of developing it. For now, here’s a short summary of the design and UVM components that we generate automatically from executable specifications:

• Register RTL Block: RTL hardware design, which may contain any number of registers, register files, memories, and other blocks
• Register Model: testbench model for an instance of a register block, where every register in the model corresponds to an actual hardware register in the IP or SoC design
• Model Updater: mirrors the hardware register values in the Register Model by using the Tapper Interface to get values and generate write events
• Tapper Interface: obtains required values from the register design
• Component Interface: hardware interface between user-defined logic and the outside world
• Signal Interface Driver: predefined library containing SystemVerilog tasks that can be used to drive arbitrary pulses on interfaces
• Complete UVM Testbench: bus agents, drivers, adaptors, sequencers, and sequences, as well as the Makefiles for all major simulators
• Register Sequences: positive and negative tests for register and field access plus test sequences for memories and special registers such as alias, shadow, FIFO, and more
• Custom Sequences: programming and test sequences for registers or VIP generated from user specifications
• Custom Checkers: checkers generated from user specifications, including waiting for testbench or design events, access to the Tapper Interface and the Component Interface, callbacks, fork-join parallelism, and conditional checks
• Coverage Collector: coverage points for registers and memories, including cross coverage

We should also note that design specifications change many times over the course of an IP or SoC project, and manually keeping a UVM testbench and tests updated and synchronized with the design is a huge challenge. Everything that we generate can be re-generated at the push of a button, reaping time and resource savings again and again. We generate C/C++ code for embedded programming and high-quality documentation as well. With this high level of automation, a project needs far fewer UVM experts. Verification engineers new to UVM can learn from our generated code and even the experts shorten their schedules because they do less manual work.

In this post, we’ve only scratched the surface of the UVM automation capabilities in our IDS-NG™ solution. To find out more, we recommend watching our recent webinar “A Complete Automated UVM-Based Verification System” by registering here. We also invite you to visit us in our booth at the Design Automation Conference (DAC) in San Francisco in July. We’re excited to show you all the great things we can do to make your IP and SoC design and verification faster, easier, and better.

Anupam Bakshi