Introduction
Introduction Get started Hello UVM example UVM Phases Part 1 UVM Phases Part 2 UVM Base Classes UVM Object and Core Methods UVM Components
Building a Testbench
UVM Transaction UVM Sequence UVM Sequencer UVM Driver UVM Monitor UVM Scoreboard UVM Agent UVM Environment UVM Test
Other Components
Coverage Collector
Execution Model
UVM Phases Objections
Communication
TLM Basics TLM Blocking Put Port TLM Non-Blocking Put Port TLM Blocking Peek Port Analysis Ports TLM FIFO
Configuration
UVM Factory UVM Config DB
Runtime Control
UVM Plusargs Seeds & Reproducibility Verbosity Control Debug Runtime Controls
Advanced
Virtual Sequences Virtual Sequencer
UVM RAL
Intro Abstraction Flexibility Comparison Coverage Minimum Requirements Learning Path Register Types First Implementation Register with 2 Fields Register with Reserved Bits Access Policies Part 1 Access Policies Part 2 Access Policies Part 3 Access Policies Part 4 Memory Modeling Register Block Adapter Introduction Adapter Methods Adapter Example Predictor Types Desired and Mirror Values Register Methods Desired Value Mirror Value

UVM RAL – The Power of Abstraction

Understanding how RAL simplifies register and memory verification

The Verification Challenge

Many DUTs consist of hundreds of registers and memory blocks. These registers cannot be written directly through simple input/output ports. Instead, they must be accessed through a bus protocol such as APB, AXI, or AHB.

As register count increases, maintaining address maps, sizes, and access policies becomes a complex and error-prone task.

Verification Without RAL

1️⃣ Manual Bus Transactions

The driver generates valid APB/AXI transactions to update registers.

  • Must track register addresses manually
  • Must track register sizes
  • Must track access policy (RO, RW, W1C)
  • Difficult to scale to 100+ registers

Tests become bus-centric instead of register-centric.

2️⃣ Interface Signal Mirroring (Not Recommended)

Add independent signals in the interface for each register: 


logic [31:0] reg1_signal;
  • Signal count increases with register count
  • Multiple components can modify signals
  • Bypasses real bus protocol
  • Cannot verify invalid transactions

Verification Using UVM RAL

UVM RAL introduces a register model inside the verification environment. Each register is represented as an object, typically using the same naming convention as the DUT.

The RAL model automatically maintains:

  • Register addresses
  • Field widths
  • Reset values
  • Access policies

Instead of manually generating bus transactions, the user interacts with registers using high-level methods: 


ral.reg1.write(status, data);
ral.reg1.read(status, data);

The RAL infrastructure automatically generates the required bus transactions and updates internal mirror values.

Why RAL Is a High-Level Abstraction

Without RAL
  • Engineer tracks address manually
  • Engineer tracks access type manually
  • Tests depend on bus implementation
  • High maintenance effort
With RAL
  • RAL model stores register metadata
  • Tests call read/write methods
  • Bus generation handled automatically
  • Cleaner and scalable verification

Typical RAL Architecture Flow

Register-centric interaction instead of bus-centric interaction

Test

↓

RAL Model

↓

Adapter

↓

Bus Driver

↓

DUT Registers

Senior Verification Insight

RAL provides the most value in medium and large SoCs where register count is high and manual tracking becomes error-prone. In very small IPs, the overhead of building a RAL model may not always be justified.