UVM RAL Model

A UVM RAL model consists of multiple hierarchical blocks that represent the design’s register architecture. The key components of a UVM RAL model include:

1. uvm_reg (Register)

The uvm_reg class represents a single hardware register. It encapsulates details like:

  • The number of bits in the register (width).
  • The default reset value.
  • The access type (read-only, write-only, read-write, etc.).
  • Register fields (bit-level breakdown).

Registers provide built-in operations such as write(), read(), and mirror() to interact with the DUT.

2. uvm_reg_field (Register Field)

Each register contains one or more fields, represented by the uvm_reg_field class. A register field defines:

  • The bit range it occupies within the register.
  • The access policy (e.g., read-only, write-only, volatile).
  • Reset behavior and constraints.

Register fields allow fine-grained access to specific bits within a register.

3. uvm_mem (Memory)

The uvm_mem class represents memory elements in the design. It models blocks of storage (RAM, ROM, FIFOs, etc.) that can be read and written like registers but are typically larger in size.

Memory can be accessed using functions similar to register operations, such as write(), read(), and mirror().

4. uvm_reg_block (Register Block)

A uvm_reg_block represents a collection of registers and memories grouped together as a logical unit. It serves as the top-level container for registers and provides the following functionality:

  • Defines address maps for registers and memories.
  • Facilitates hierarchical organization (e.g., sub-blocks within larger blocks).
  • Connects registers to the DUT through an adapter.

Each register block corresponds to a specific module or subsystem in the DUT.

5. uvm_reg_map (Register Map)

A uvm_reg_map provides a mapping between logical register addresses and the DUT’s physical address space. It handles:

  • Address offsets for registers and memories.
  • Bus interface properties (e.g., byte-lane, endianness).
  • Conversions between high-level register accesses and low-level transactions.

The register map is essential for interfacing the UVM RAL model with the DUT’s bus protocol.

6. uvm_reg_adapter (Adapter)

The uvm_reg_adapter bridges the UVM RAL model and the DUT’s bus interface. It converts register operations into corresponding UVM sequence transactions that the bus driver understands.

For example, if the DUT uses an APB interface, the adapter translates RAL read/write requests into APB bus transactions.

7. uvm_reg_predictor (Predictor)

The uvm_reg_predictor is responsible for mirroring register values in the UVM testbench. It updates expected register values based on read/write operations, ensuring that the verification environment keeps track of the DUT’s register states correctly.

This component is crucial for self-checking testbenches, as it allows automatic comparison of expected and actual values.

How UVM RAL Works in a Testbench

The UVM RAL model is integrated into a testbench as follows:

  1. Model Creation: The register model is generated using either a script (from a register specification) or manually coded in UVM.
  2. Register Block Instantiation: The uvm_reg_block and associated registers are instantiated in the environment.
  3. Address Map Definition: The uvm_reg_map links the model’s logical registers to physical addresses in the DUT.
  4. Adapter Connection: The uvm_reg_adapter connects the model to the UVM driver, enabling register transactions.
  5. Test Execution: The test sequences use high-level register API functions (write(), read(), mirror(), etc.) to interact with the DUT registers.
  6. Checking and Debugging: The uvm_reg_predictor maintains expected values, and scoreboard comparisons help identify mismatches.
Previous
Next