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 – Memory Modeling

Understanding how to implement memory using UVM RAL.

Registers vs Memory

So far, we have learned how to implement registers in the verification environment, including defining multiple fields, mapping them to a parent register, and specifying properties like LSB position and field size.

Registers are more complex because:

  • They may contain multiple fields
  • Each field must be configured separately
  • LSB position and field size must be specified
  • Field access policies must be defined

Memory modeling is simpler in comparison.

What Defines a Memory?

To fully describe a memory in UVM RAL, only three main parameters are required:

  • Number of memory locations
  • Data width (size of each location)
  • Base address (added later in reg_block)

Because of this, memory implementation is much more straightforward than register implementation.

Using uvm_mem

Memory in UVM RAL is implemented by extending the uvm_mem base class.

The constructor of uvm_mem requires: 


super.new(
   name,              // Instance name
   size,              // Number of memory locations
   n_bits,            // Width of each location
   access,            // Access policy
   has_coverage       // Functional coverage option
);
Access Policy
  • RW → Used for RAM (read and write allowed)
  • RO → Used for ROM (read-only memory)

Unlike registers, memory does not require field configuration.

Example Implementations

Memory 1
  • 16 locations
  • 8-bit per location
  • RW access

class dut_mem1 extends uvm_mem;

  `uvm_object_utils(dut_mem1)

  function new(string name = "dut_mem1");
    super.new(name, 16, 8, "RW", UVM_NO_COVERAGE);
  endfunction

endclass
Memory 2
  • 1024 locations
  • 16-bit per location
  • RW access

class dut_mem2 extends uvm_mem;

  `uvm_object_utils(dut_mem2)

  function new(string name = "dut_mem2");
    super.new(name, 1024, 16, "RW", UVM_NO_COVERAGE);
  endfunction

endclass
Memory 3
  • 2048 locations
  • 32-bit per location
  • RW access

class dut_mem3 extends uvm_mem;

  `uvm_object_utils(dut_mem3)

  function new(string name = "dut_mem3");
    super.new(name, 2048, 32, "RW", UVM_NO_COVERAGE);
  endfunction

endclass
Important Note

The base address of the memory is not specified here. It is defined later when the memory is added inside a uvm_reg_block.

Summary
  • Memory modeling is simpler than register modeling.
  • No fields or LSB mapping required.
  • Key parameters: number of locations, data width, base address.
  • Use uvm_mem to implement memory.
  • RW is commonly used for RAM, RO for ROM.