Beyond UVM Registers: Better, Faster, Smarter

The UVM Register package² has many features. These features include reading and writing register values, reading and writing register fields and register blocks. The register model keeps track of the expected value and can directly access the actual modeled register using "back-door access". Using the register model allows a testbench to be written that can check the behavior of registers and address maps.

Additionally, the register model can be constrained and randomized to provide stimulus or configurations. It can also be "covered" with functional coverage. These are the main operations of any register package; model the expected and actual values; check address mapping; generate random stimulus; allow direct access; support functional coverage.

The problem in the UVM Register package arises in the intricacies in the register layer source code. For uvm-1.1d, there are 26 files containing over 22,000 lines of source code. That represents 19% of the total number of files in the UVM, and 32% of the total number of lines of source code. Clearly the UVM Register package is a large part of the UVM.

In the next release, uvm-1.2, the percentages are reduced by increasing the files and lines in the overall UVM, but the absolute number of files is still 26, and the lines of source code is still over 22,000 for the UVM Register package. In the uvm1.1d User Guide, the description of the UVM Register layer is 26% of the number of pages.

The UVM Register package is a large part of the UVM, by file and line count. There are many detailed, complete tutorials, papers and discussions about UVM Registers, and their various capabilities. These include a detailed description of pros and cons to various quirky register implementation methods³; an interesting tutorial on register access routines and the register computing model⁴; various tutorials and UVM register scenarios^5,6; and discussions about field modeling^7,8.

A Google search for "UVM Registers" will yield many high-quality results discussing various UVM Register aspects. This community of support is excellent and a welcomed sight for new users. But one of the reasons that this community has grown so large, and so necessary is exactly the issue with the UVM Register package. It is big. It is complex. It is powerful.

Using a Register Package

Any verification team might use registers to answer the following questions. Any register modeling package should make getting these answers straightforward, transparent and easy.

• Can I read and write all my registers?
• Can I read and write all the addresses for all my registers on all interfaces allowed?
• Can I set all bits? Can I clear all bits? Can I read all bits?
• Do the registers function properly (including Quirky Registers)?
• Can I operate my DUT correctly when I load a set of registers (when I do a configuration) and press “go”?