Automation of the UVM Register Abstraction Layer

A recent blog post noted that today’s RTL design verification (DV) environments are very powerful and very complex. The SystemVerilog-based Universal Verification Methodology (UVM) standard provides most of the key building blocks for the simulation testbenches at the heart of the DV process. The previous post focused on correct-by-construction of UVM testbenches using the DVinsight™ smart editor from Agnisys. This post shows how other solutions from Agnisys can automate the generation of the UVM Register Abstraction Layer (RAL) that provides testbench access to the registers and memories in the design being verified.

The UVM uses object-oriented techniques to provide a set of base class libraries that can be extended for use across a wide range of DV projects. The UVM RAL provides a standard library of base classes and methods with a set of rules to reduce the effort required for register access from testbenches. The RAL classes are used to create a high-level, object-oriented model for memory-mapped registers and memories in the design under verification (DUV). The UVM RAL provides a high-level abstraction for reading and writing DUV registers using user-defined names. It provides a register test sequence library containing predefined test cases these can be used to verify the DUV registers and memories. The registers and memories can be accessed via the RTL design’s bus interface, or independently by calling read/write methods.

IDesignSpec™ from Agnisys automates the generation of the UVM register model environment, saving considerable time and effort over hand coding SystemVerilog. The model is built using the following abstractions:

• An instance of a register block is a register model, which may contain any number of registers, register files, memories, and other blocks
• Each register file contains any number of registers and other register files
• Each register contains any number of fields, which mirror the values of the corresponding elements in hardware
• For each element in a register model—field, register, register file, memory, or block—there is a class instance that abstracts the read and write operations on that element

The registers and memories can be defined using IP-XACT or a register definition language such as SystemRDL, and IDesignSpec can generate a UVM RAL model from these specifications. A simple, abstract input file can produce complex SystemVerilog code to define and instantiate the registers and memories.

For users who prefer graphical specification, Agnisys provides plug-ins to Microsoft Word, Microsoft Excel, and OpenOffice as well as the IDS-NG cross-platform GUI. Register specification becomes a simple matter of filling out entries in a form, with IDesignSpec doing the rest of the work.

To define a register, the user need only name it and describe its fields. Default values and access options (such as read/write or read-only) can also be specified. IDesignSpec generates a new class to define the register, extending the “uvm_reg” base class from the standard UVM library. The generated class builds the register from the fields specified by the user in the plug-in form and IDesignSpec instantiates it. If the user desires, the class can register itself with the UVM “factory” in the testbench environment. The UVM library register class does not include any built-in coverage model, but it provides the necessary application programming interface (API) to control instantiation and sampling of various coverage models. In the example below, the generated register class has a placeholder for a coverage model, but no actual model is defined.

To define a register group such as a register file, the user simply names it and specifies the registers that make up the group. IDesignSpec generates a new class, extending the “uvm_reg_file” base class, and instantiates it, possibly multiple times based on the “repeat” entry in the form.

Defining a memory is quite similar. The user fills out the form with the memory name, width and depth, offset, and default values. IDesignSpec generates a new memory class, extending the “uvm_mem” base class, and instantiates it.

These examples demonstrate the basic operation of UVM RAL automation, but there are many other capabilities of IDesignSpec. These include:

• Generation of register blocks and sub-blocks
• Support for multiple types of coverage models
• Support for cross-coverage, for example on two register fields
• Specification of custom coverage and constraints
• Generation of UVM callbacks for aliased registers
• Auto-mirroring to update the UVM register model when an RTL register is updated via the bus interface

More information on these and other advanced features is provided in a UVM RAL webinar, part of an extensive series covering a broad range of design and verification topics. DV engineers can register here at their convenience. More information on how IDesignSpec automates the UVM RAL flow can be found here. Many chip verification teams have saved weeks of manual SystemVerilog coding with this powerful and flexible automation approach. IDesignSpec should be in every UVM engineer’s bag of tricks.

Tags: IDesignSpec, IP-XACT, SystemVerilog, testbench, UVM

This entry was posted on Thursday, May 28th, 2020 at 6:03 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.