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

Desired and Mirror Values in the UVM Register Model

In the UVM Register Abstraction Layer (RAL), every register object stores several internal values that help the testbench track and control the state of registers inside the DUT. These values are automatically updated depending on the register operations that are executed.

A typical UVM register keeps track of four important internal variables:

  • Desired Value
  • Mirror Value
  • Reset Value
  • Randomized Value

In this section we focus on the two most important ones used during register transactions: Desired and Mirror.

Desired Value

The desired value represents the value that the testbench wants to place into the register during the next transaction with the DUT.

Instead of writing immediately to hardware, the testbench can first store the intended value inside the register model. Later, a transaction such as update() or write() will send that value to the DUT.

You can think of the desired value as the planned value for the next register write operation.

Example:


reg_model.ctrl_reg.set(32'h2);

Here the register model stores the value 2 as the desired value, but the DUT register has not been modified yet.

Mirror Value

The mirror value represents the value that the register model currently believes exists inside the DUT register.

After each register transaction, such as a read or write, the mirror value is updated to reflect the latest known state of the hardware register.

In simple terms, the mirror value is the testbench’s local copy of the register value.

Desired vs Mirror

Concept Description
Desired The value we want the register to have in the next transaction.
Mirror The value the register model believes is currently stored in the DUT.

Example Scenario

Assume no transactions have been performed yet with the DUT.

Variable Value
Desired 0
Mirror 0

Now the testbench sets a desired value: 


reg_model.ctrl_reg.set(2);

After calling this method:

Variable Value
Desired 2
Mirror 0

The desired value changed, but the DUT register is still the same because no transaction has occurred yet.

Writing the Value to the DUT

To actually send the desired value to the DUT register, the testbench can call the update() method. 


reg_model.ctrl_reg.update(status);

After this write operation is completed:

Variable Value
Desired 2
Mirror 2

Now both values match because the transaction updated the hardware register.

Key Points

  • The desired value stores the value the testbench plans to write to a register.
  • The mirror value stores the value that the register model believes currently exists in the DUT.
  • The mirror value is updated automatically after register transactions.
  • These mechanisms allow the register model to track hardware state without constantly accessing the DUT.

Summary

The desired and mirror values play an important role in the UVM register model. The desired value represents the value that will be written in a future transaction, while the mirror value keeps track of the current known value of the hardware register.

Together, they allow the register model to maintain an accurate software representation of the DUT registers and simplify register verification.