UVM Register Abstraction Layer

The UVM Register Abstraction Layer (RAL) is a set of UVM base classes for modeling the registers and memories of a design. A test reads and writes registers through this model by name, and the model translates each access into transactions for whatever bus the design uses.

10 min read | Intermediate Level

What You'll Learn

• How registers, fields, register blocks and memory maps describe a design
• Which UVM classes model each of these: uvm_reg_field, uvm_reg, uvm_reg_block and uvm_reg_map
• How a register write travels from a sequence to the DUT through RAL
• Why RAL is preferred over writing bus transactions by hand

What are registers ?

Registers are storage elements in a hardware design that hold configuration settings, control information and status data. Software or firmware usually accesses them over a bus protocol such as AXI or APB, and programs them with specific values.

A register is commonly 32 bits wide and divided into several fields. Each field controls or reports one feature of the design, and can be configured by software independently of the others.

The figure above shows a single register, REG_CTL, with five functional fields. The remaining bits are reserved.

The design files may contain an RTL module that implements this register.

// RTL representation

module reg_block (...);
	wire [31:0]     reg_ctl;
	
	// Declare reg variables to store register field values
	reg             ctl_en;      // Enable for the module
	reg [2:0]       ctl_mode;    // Mode 
	reg             ctl_halt;    // Halt 
	reg             ctl_auto;    // Auto shutdown 
	reg [4:0]       ctl_speed;   // Speed control
	
	assign reg_ctl = {16'b0, ctl_speed, 5'b0, ctl_auto, ctl_halt, ctl_mode, ctl_en};
	
	// Logic for getting individual fields from the bus
	...
endmodule

The concatenation in the assign statement packs the fields from bit 31 down to bit 0, so it must match the bit offsets in the table exactly.

To model these registers with UVM RAL, you create a register model class hierarchy that mirrors the design. Each register becomes a class derived from uvm_reg, and each field inside it is an instance of uvm_reg_field.

What is a register block ?

A register block is a higher-level abstraction that groups the registers and memories of one design module. It keeps related registers together, which makes large designs with many registers easier to manage and verify.

Each register in a block sits at an offset from the start of the block. For example, REG_CTL is placed at offset 0x0 because it is the module's main control register. It occupies 32 bits, or 4 bytes, so the next register, REG_STAT, which holds the design's status flags, starts at 0x4.

A register block class is derived from the uvm_reg_block base class. The offsets of its registers are stored in an address map, an instance of uvm_reg_map, inside the block.

What is a memory map ?

A memory map is the arrangement of memories and memory-mapped peripheral registers within the address space of an SoC. It defines the address at which each component, such as a memory region, register or peripheral, can be reached by the processor and other bus masters.

A System-on-Chip (SoC) normally has one or more processor cores, DMA engines, bus interconnects and many peripheral modules. Each peripheral has its own register block, and all of them are laid out in the memory map. The processor reaches them through a peripheral bus such as APB or Wishbone, so each peripheral needs a base address where its register block starts.

Assume the register block described above belongs to a Timer module with a base address of 0xE7B3_0000. To access REG_CTL, the core sends a transaction to address 0xE7B3_0000, because REG_CTL has an offset of 0x0. To access REG_DMACTL, the core sends a transaction to 0xE7B3_0000 + 0xC = 0xE7B3_000C.

In RAL, the base address is given when the block's map is created, and the offsets when each register is added to it. The model then computes every absolute address for you.

What is Register Abstraction Layer ?

The purpose of the Register Abstraction Layer is to provide a structured, standard way to model and verify registers and memory-mapped structures in a design. Register verification includes testing different access scenarios, checking field values after reset, verifying side effects of register accesses, and more.

RAL defines base classes that, once extended for a design, abstract read and write operations to its registers and memories. Because sequences use register names instead of addresses and bus items, the same register sequences can be reused from block-level to subsystem and full-chip testbenches, typically with changes only to the model's configuration and bus connection.

The register model can be used in a UVM sequence to write to or read from a target register.

class my_sequence extends uvm_sequence;
	...

	regmodel 	m_regmodel;

	virtual task body();
		uvm_status_e 	status;     // Result of the access: UVM_IS_OK, UVM_NOT_OK, ...
		uvm_reg_data_t 	rdata;      // Value returned by read()

		// Get regmodel from config_db
		
		// Use register model handle to write into the DUT register
		m_regmodel.reg_ctl.write(status, 8'h3A);

		// Use register model handle to read from the DUT register
		m_regmodel.reg_ctl.read(status, rdata);
	endtask
endclass

In this sequence, write() sends the value 'h3A to REG_CTL. In binary, 'h3A is 0011_1010, so it sets En = 0, Mode = 101 (Balanced), Halt = 1 and Auto = 1. read() then returns the register's current value in rdata. After each call, status reports whether the bus access succeeded.

Behind the scenes, the register model looks up the address of REG_CTL in its map. An adapter converts the access into a bus item for the bus agent, which drives it to the DUT. A predictor watches the bus through the monitor and keeps the model's copy of each register up to date.

Why is RAL useful ?

Writing and reading registers without RAL is cumbersome. You have to create a uvm_sequence_item with the right address and data, and execute it on the bus agent for that specific protocol. Code like this cannot be reused as easily, and there is no record of the value each register should currently hold.

class write_sequence extends uvm_sequence;
	int 	m_addr;
	int 	m_wdata;

	...
	virtual task body();
		bus_item 	m_item;

		m_item = bus_item::type_id::create("my_item");
		start_item(m_item);
		m_item.randomize() with { 	wdata == m_wdata;
									write == 1;
									addr 	== m_addr; 
								};
		finish_item(m_item);
		
		...
	endtask
endclass

RAL improves on this in several ways:

• Access by name: sequences use reg_ctl.write() instead of addresses, so they survive changes in the address map and in the bus protocol
• Mirrored values: the model keeps a copy of what each register should contain, so a test can check the DUT against the model at any time
• Front-door and back-door access: a register can be accessed through the bus, or directly through the HDL path in zero simulation time
• Built-in sequences: UVM provides ready-made sequences such as uvm_reg_hw_reset_seq and uvm_reg_bit_bash_seq that check reset values and the access rights of every bit

Common Mistakes

virtual task body ();
  uvm_status_e   status;
  uvm_reg_data_t rdata;

  m_regmodel.reg_ctl.write (status, 32'h0000_5007);    // En=1, Mode=Auto Adjust, Speed=10
  if (status != UVM_IS_OK)
    `uvm_error ("REG", "REG_CTL write failed")

  m_regmodel.reg_ctl.read (status, rdata);             // Read back to confirm
  if (rdata != 32'h0000_5007)
    `uvm_error ("REG", $sformatf ("REG_CTL readback 0x%0h, expected 0x5007", rdata))
endtask