Scribd
Upload
30 views4 pages

APB RAL Integration Guide: Step-by-Step

This document provides a detailed step-by-step guide for integrating APB with RAL in a UVM project, emphasizing the importance of register specifications and the use of IP-XACT for generating UVM register models. It outlines the entire process from defining registers to connecting the RAL model with the APB sequencer, ensuring a seamless verification flow. The methodology is applicable to various protocols including APB, AXI-Lite, and PCIe CSR access, with the adapter being the only component that varies.

Uploaded by

Praveen Acharya
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
30 views4 pages

APB RAL Integration Guide: Step-by-Step

This document provides a detailed step-by-step guide for integrating APB with RAL in a UVM project, emphasizing the importance of register specifications and the use of IP-XACT for generating UVM register models. It outlines the entire process from defining registers to connecting the RAL model with the APB sequencer, ensuring a seamless verification flow. The methodology is applicable to various protocols including APB, AXI-Lite, and PCIe CSR access, with the adapter being the only component that varies.

Uploaded by

Praveen Acharya
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Complete APB RAL Integration – Detailed

Step-by-Step Explanation
This document explains EVERY step of a complete, working APB + RAL integration. It is written
assuming real UVM project usage (DMA / PCIe / AXI-Lite CSR verification). Each step explains
WHY it exists, WHAT it does, and HOW it connects to the next step.

Step 1: Register Specification (Source of Truth)

In any real project, registers are NOT discovered from RTL. They are defined first in a specification
(Excel, Word, or database). This specification is the single source of truth for RTL, firmware, and
verification.
For this example we define two registers:
CTRL @ 0x00
enable [0] RW
mode [2:1] RW

STATUS @ 0x04
done [0] RO

Step 2: IP-XACT ([Link])

IP-XACT is an IEEE standard XML format used to describe register maps in a tool-readable way.
Verification tools consume IP-XACT to automatically generate UVM register models.
Why IP-XACT is used in industry: - Single definition shared by RTL, firmware, and verification -
Eliminates manual register coding errors - Scales to thousands of registers
<register>
<name>CTRL</name>
<addressOffset>0x00</addressOffset>
<field>
<name>enable</name>
<bitOffset>0</bitOffset>
<bitWidth>1</bitWidth>
<access>read-write</access>
</field>
</register>

Step 3: Generate RAL Using uvm_reggen

uvm_reggen parses the IP-XACT file and generates SystemVerilog classes derived from uvm_reg
and uvm_reg_block.
Command:
uvm_reggen [Link] -o ral/

After this step, verification engineers NEVER manually write register classes.

Step 4: Generated RAL Directory


The output directory contains multiple SystemVerilog files. These files collectively represent the
register model.
ral/
■■■ apb_reg_pkg.sv <-- compile ONLY this file
■■■ apb_reg_block.sv
■■■ ctrl_reg.sv
■■■ status_reg.sv

The *_reg_pkg.sv file includes all other files and must be the only file compiled.

Step 5: APB Interface

The APB interface is the physical transport used to access registers in the DUT. RAL itself has no
knowledge of APB; it only knows about registers.
interface apb_if(input logic pclk);
logic presetn, psel, penable, pwrite;
logic [31:0] paddr, pwdata, prdata;
logic pready;
endinterface

Step 6: APB DUT (Register Implementation)

This module implements the actual hardware registers. RTL responds to APB reads and writes by
updating or returning register values.
The DUT does NOT know anything about RAL. It simply implements APB protocol correctly.
always_ff @(posedge pclk)
if(psel && penable && pwrite)
CTRL <= pwdata;

Step 7: APB Transaction (Sequence Item)

UVM sequences do not drive pins directly. They send high-level transaction objects to drivers.
The apb_tx object represents ONE APB transfer.
class apb_tx extends uvm_sequence_item;
rand bit write;
rand bit [31:0] addr, data;
endclass

Step 8: APB Driver

The driver converts an apb_tx object into real pin toggles on the APB interface.
RAL never interacts with this driver directly. The driver only talks to the sequencer.
[Link] <= 1;
[Link] <= 1;

Step 9: RAL Adapter (Most Important Step)


The adapter is the bridge between the register world and the bus world.
RAL produces uvm_reg_bus_op objects. The adapter converts them into apb_tx transactions.
[Link] = [Link];
[Link] = [Link];
[Link] = ([Link] == UVM_WRITE);

Step 10: Register Model Build and Lock

The register model must be built exactly once during build_phase.


lock_model() prevents accidental modification of the register map at runtime.
[Link]();
regmodel.lock_model();
[Link]();

Step 11: Connecting RAL to APB Sequencer

This step connects the abstract register model to the concrete APB bus.
After this call, any [Link]() results in APB activity.
regmodel.default_map.set_sequencer(apb_sequencer, adapter);

Step 12: Using RAL in Sequences

Sequences operate ONLY on registers and fields.


They are protocol-independent and reusable.
[Link](status, 1);
[Link](status, done);

Step 13: Test and Top

The test creates the environment and starts sequences. The top module only connects DUT,
interface, and UVM.
Top module NEVER imports RAL.

Step 14: Mirror and Predict Concepts

RAL maintains a mirror copy of register values. Reads and writes automatically update the mirror.
predict() is used when register values change without a bus access (for example, status bits set by
hardware).

Step 15: Final Industry Flow Summary


Register Spec
↓
IP-XACT
↓
uvm_reggen
↓
Generated RAL
↓
Adapter
↓
APB / AXI
↓
DUT

This methodology is identical for APB, AXI-Lite, and PCIe CSR access. Only the adapter changes.

Common questions

Powered by AI

The sequence starts with defining registers in a specification, followed by creating an IP-XACT representation. This feeds into uvm_reggen to produce RAL classes. The adapter then connects these to the bus protocol (e.g., APB/AXI). Finally, connect the setup to the DUT, enabling a functional path for verification .

The RAL adapter converts abstract operations into concrete bus transactions (apb_tx), which the APB driver then translates into physical pin activity, ensuring register actions reflect correctly on the hardware, facilitating thorough unit testing .

The APB interface facilitates register data transport by providing a standard set of signals like 'pclk', 'psel', 'penable', 'pwrite', 'paddr', 'pwdata', and 'prdata'. These manage the selection, enabling, writing, and address signaling necessary for accessing and manipulating DUT registers .

The final step summary outlines a consistent methodology from register specification to DUT integration, demonstrating flexibility and scalability across different protocols. By changing only the adapter, this approach ensures reliable and standard verification processes are maintained across APB, AXI-Lite, and PCIe .

To connect a register model to an APB sequencer, you must set the default map of the register model to use the sequencer and adapter via regmodel.default_map.set_sequencer(apb_sequencer, adapter). This connection allows register-level operations to initiate corresponding APB bus transactions .

Mirroring in RAL involves maintaining a local copy of register states, mirroring changes from writes and reads. Prediction is used to update this mirror for register changes without bus access, such as status bits set by hardware, ensuring the mirror accurately reflects the real-time state of the system .

Building and locking the RAL model during the build_phase is crucial to prevent accidental runtime modifications. Locking ensures the register map's integrity, allowing only planned updates through appropriate sequences .

The RAL adapter is the bridge between the register world and the bus world. It converts uvm_reg_bus_op objects produced by RAL into apb_tx transactions suitable for the APB bus interface, enabling abstract register operations to result in actual bus activity .

IP-XACT is used because it provides a single definition shared by RTL, firmware, and verification, eliminating manual register coding errors and scaling efficiently to thousands of registers .

Sequences in the UVM environment abstract operations at the register level, interacting with registers and fields rather than bus protocols. This independence allows them to be reused across different verification environments that may use various communication protocols like APB, AXI, or PCIe .

You might also like