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 – Adapter Introduction

Converting Register Transactions into Bus Transactions

Why Do We Need an Adapter?

The UVM Register Model generates register transactions. However, the DUT understands only bus transactions.

Because of this difference, we need a translation layer that converts:

  • Register transactions → Bus transactions
  • Bus responses → Register transactions

This translation component is called the UVM RAL Adapter.

Primary Role of an Adapter

The adapter acts as a bridge between:

  • Register Model (RAL)
  • Bus Driver + DUT Interface

It ensures that data generated by the register model can be correctly applied to the DUT bus protocol (APB, AXI, or custom memory interface).

Typical RAL Transaction Flow

  1. Register sequence calls write() or read()
  2. UVM creates a uvm_reg_bus_op structure
  3. Adapter converts it to a bus transaction
  4. Sequencer → Driver → Interface → DUT
  5. Monitor captures response
  6. Predictor converts bus → reg transaction
  7. Mirror and desired values get updated

Read and Write in Reg Sequences

In a register sequence: 


// Write operation
reg_inst.write(status, data);

// Read operation
reg_inst.read(status, data);

Notice that we do not specify the address. The address map already knows each register’s offset.

uvm_reg_bus_op Structure

The register model internally uses the structure: 


uvm_reg_bus_op

It contains the following key members:

  • addr – Register address (64-bit)
  • data – Read/Write data (64-bit)
  • kind – UVM_READ or UVM_WRITE
  • status – UVM_IS_OK, UVM_NOT_OK, UVM_HAS_X

When we call read() or write(), these fields are automatically populated.

Two Core Adapter Methods

1️⃣ reg_to_bus()

Converts a register transaction into a bus transaction.

  • Used during WRITE
  • Used during READ request phase
  • Direction: RAL → DUT
2️⃣ bus_to_reg()

Converts a bus transaction back into a register transaction.

  • Used during READ response
  • Used by predictor
  • Direction: DUT → RAL

Complete Data Flow

Write Flow:

Reg Sequence → uvm_reg_bus_op → reg_to_bus() → Bus Transaction → Driver → Interface → DUT

Read Flow:

DUT → Monitor → Predictor → bus_to_reg() → Update Mirror Value

The adapter ensures both directions of communication remain synchronized.

Summary
  • RAL generates register transactions.
  • DUT understands bus transactions.
  • Adapter converts between the two.
  • reg_to_bus() → RAL to DUT.
  • bus_to_reg() → DUT to RAL.
  • uvm_reg_bus_op is the core internal structure.