Register Modeling: Exploring Fields, Registers and Address Maps

The UVM is widely used for verification purposes. It suffers from the perception that it is hard. It is only hard when getting started. Re-using old, simple, well-written UVM testbenches can make UVM adoption go more smoothly. There are many free places to get examples and learn about the UVM.

The UVM also benefits by being a standard that other people know. These other people are resources to hire or consult with. Or even a place to get a job. This UVM ecosystem gets stronger every year with trainers, generators, free code, books and consultants. Stimulus generation with UVM using random constraints and checking using functional coverage is the state-of-the-art for productivity and tape-out success.

The UVM has many pieces. One of the most interesting pieces is a register modeling piece. It models registers, fields, address maps and many related objects.

The UVM Register documentation is well developed with examples in UVM 1.1d and UVM 1.2. This paper will refer to APIs and use models from the UVM, but the code development is started from a clean sheet of paper. This development discusses modeling strategies and various techniques. It is not meant as a replacement for the UVM register package, but as an exploration of modeling that can be applied to registers, fields, address maps and other constructs completely unrelated to registers.

This is a conversation about encouraging writing models and using those models to improve verification productivity

Modeling Philosophy

Hardware verification is already hard enough. Productivity tools should be small, transparent, and easy to read and debug.

This paper will create a model of registers, fields, and address maps.

A register models ‘bits’ in the device-under-test. A register can be accessed using ‘addresses’. The bits of a register can be collected and called fields. A register write or read treats the whole register as one and does not access single bits or single fields alone. A register in the device-under-test exists in one “hierarchy”.

In the testbench, each device-under-test register is “shadowed” by a single register. The testbench register and the device-under-test register are pairs. They are normally in sync. At certain times they may become out of sync. Out of sync is either an error (mismatch) or is a period of time where the two simply haven’t caught up with each other.

A register has a name and a backdoor name. It has a reset value and most importantly a value. Additionally, it has a table of address maps that it belongs to. It is “in” those address maps. See Figure 1.

An address map is much simpler. It has a name, and a table which maps a register handle and an address together. Things that can be said about the relationship between registers and address maps:

1. A register can be referenced from many address maps.
2. A register can have multiple addresses.