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 Mirror Value

In the UVM Register Abstraction Layer (RAL), the mirror value represents the current known value of a hardware register stored inside the register model. It allows the verification environment to track the expected state of registers in the DUT without directly reading the hardware every time.

Desired Value vs Mirror Value

The UVM register model maintains two important variables for each register:

Variable Description
Desired Value Represents the value that the testbench wants to write to the hardware register. It acts as temporary storage until a transaction is performed.
Mirror Value Represents the register model’s current understanding of the value stored inside the hardware register.

Initial State

At the beginning of simulation, both the desired value and the mirror value typically start with their reset values (often zero). 


desired_value = reg.get();
mirror_value  = reg.get_mirrored_value();

Effect of the set() Method

The set() method updates only the desired value in the register model. It does not perform any transaction with the DUT. 


reg.set(17);

After calling set():

  • Desired value = 17
  • Mirror value = unchanged

Effect of the update() Method

The update() method performs a write transaction to the DUT using the desired value. 


reg.update(status);

However, the mirror value will only update if the register model can predict the result of the transaction.

The Role of Predictors

To keep the mirror value synchronized with the DUT, the register model must predict the value written to the hardware register. This prediction can be done using:

  • Explicit predictors
  • Bus predictors
  • Implicit prediction (auto predict)

Implicit Prediction with set_auto_predict()

If no predictor block is used, the register model cannot automatically update the mirror value after a transaction. To enable automatic prediction, the register map must enable auto prediction. 


default_map.set_auto_predict(1);

This enables implicit prediction so the register model updates the mirror value after a transaction such as update().

Example Behavior

Step Desired Value Mirror Value
Initial state 0 0
After set(17) 17 0
After update() without auto predict 17 0
After update() with auto predict enabled 17 17

Key Methods Related to Mirror Values

  • get() – returns the desired value
  • set() – updates the desired value
  • get_mirrored_value() – returns the mirror value
  • update() – writes the desired value to the DUT

Among these methods, only update() performs a transaction with the DUT. The other methods operate only on the register model variables.

Summary

The mirror value is a key concept in the UVM Register Abstraction Layer. It represents the register model’s understanding of the current hardware state. To keep the mirror value synchronized with the DUT, the verification environment must use predictors or enable implicit prediction using set_auto_predict(1).

Understanding the difference between desired and mirror values is essential when debugging register model behavior in UVM-based verification environments.