UVM Register Layer: The Structure

I don’t know about you, but I am looking forward to the day where we won’t even have to go to the doctor’s office for an exam. Instead, we will all have scanners in our homes that will transmit full digital models to our doctors who can then poke, prod, and examine us remotely.

This is essentially what the UVM register layer allows and does. The UVM register layer acts similarly by modeling and abstracting registers of a design. It attempts to mirror the design registers by creating a model in the verification testbench. By applying stimulus to the register model, the actual design registers will exhibit the changes applied by the stimulus.

The benefit of this approach comes from the high level of abstraction provided. The bus protocols for accessing registers can change from design to design, but any stimulus developed for verification of the registers doesn’t have to. This makes it easy to port code from one project to the next if the registers are the same. Taking a look at Fig. 1 provides a better understanding of what a register model implementation might look like with respect to the UVM environment.

Fig. 1 Taken from the UVM user guide, this image shows a register model relative to the rest of the verification environment

One thing that is interesting about Fig. 1 is the ‘Generator’ bubble. Modern designs have hundreds if not thousands of registers and tens of thousands of register fields. Manually trying to write SystemVerilog code to represent those thousands of registers and register fields would be a gruesome task. This is where generators come into play. A generator’s job is to take the register specifications of a design (usually in the form of a spreadsheet) and automatically ‘generate’ the equivalent register model in SystemVerilog code. In order to use generators or even understand their output, one should first have a good grasp of the UVM register layer.

So how exactly does the register layer work?

First, the register model is built using an organized hierarchical structure. The structure incorporates memory, registers, and address maps into address blocks. Ultimately the blocks communicate with an adapter and receive updates from a predictor, both of which interact with the rest of the verification environment. Once the structure is built, register access API are used to send signals to the DUT where a monitor will report back any information to the register model for the purposes of synchronization.

For the rest of this article, visit the Aldec Design and Verification Blog.

Tags: simulation, uvm, verification, verilog

Category: Functional Verification

This entry was posted on Wednesday, April 6th, 2016 at 2:56 pm. 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.