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 – Access Policies (Part 1)

Understanding how access types control register modeling behavior in UVM.

Why Access Policies Matter

When we configure a uvm_reg_field, we provide nine parameters. One of the most important parameters is the access type.

UVM RAL supports 25 different access policies. In this series, we will explore them one by one to understand their behavior.

Access Policy Inside configure()

The configure() function is used to replicate the exact properties of a DUT register inside the verification environment.

The access policy parameter defines how the register model behaves during read and write operations. 


field.configure(
   parent,
   size,
   lsb_pos,
   "ACCESS_TYPE",   // Access Policy
   volatile,
   reset,
   has_reset,
   is_rand,
   individually_accessible
);

Desired Value vs Mirror Value

Each register in UVM RAL internally maintains two important variables:

  • Desired Value
  • Mirror Value

These variables help the verification environment keep track of the register’s state.

What happens during a Write?

When we write to a register, both desired and mirror values are updated to reflect the new expected state.

What happens during a Read?

When we read from the DUT register, the mirrored value is updated to match the actual hardware state.

The reason we maintain two separate values will become clearer in later examples.

Important Clarification

Access policy does NOT change the behavior of the hardware register.

The behavior of a hardware register during read/write operations is completely defined by the RTL.

The verification environment cannot modify RTL behavior. It can only send stimulus and analyze the response.

So What Does Access Policy Control?

Access policy determines how the desired and mirror values are updated inside the UVM register model when a read or write operation is performed.

In simple terms:

  • It defines how the register model reacts
  • It does NOT change the DUT
  • It ensures correct modeling of hardware behavior

As we explore specific access types in the next section, this concept will become much clearer.

Summary
  • Access policy is one of the 9 parameters in configure().
  • UVM supports 25 different access types.
  • Each register maintains a desired value and a mirror value.
  • Access policy defines how these values update during read/write.
  • Access policy does NOT change RTL behavior.