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

The Desired Value in UVM RAL represents the value that the testbench intends a register to contain. This value exists only inside the register model and does not necessarily match the value inside the DUT hardware register.

Desired vs Mirror Value

In the UVM Register Abstraction Layer, every register field keeps track of two internal values:

  • Desired Value – The value the testbench wants the register to have.
  • Mirror Value – The last known value stored in the DUT register.

These values may be different until a transaction is performed to synchronize the register model with the DUT.

Methods Used with Desired Value

Method Description DUT Transaction
get() Returns the desired value stored in the register model No
set() Updates the desired value in the register model No
update() Writes the desired value to the DUT if it differs from the mirror value Yes

Example Sequence Using Desired Value

The following sequence from the example demonstrates how the desired value is accessed, modified, and finally written to the DUT register. 


class top_reg_seq extends uvm_sequence;

  `uvm_object_utils(top_reg_seq)

  top_reg_block regmodel;

  task body;

    uvm_status_e status;
    bit [7:0] rdata;

    // Read initial desired value
    rdata = regmodel.temp_reg_inst.get();
    `uvm_info("SEQ", $sformatf("Desired Value : %0d", rdata), UVM_NONE);

    // Update desired value in the register model
    regmodel.temp_reg_inst.set(8'h11);

    // Read desired value again
    rdata = regmodel.temp_reg_inst.get();
    `uvm_info("SEQ", $sformatf("Desired Value : %0d", rdata), UVM_NONE);

    // Synchronize register model with DUT
    regmodel.temp_reg_inst.update(status);

  endtask

endclass

Execution Flow of the Example

The sequence performs the following operations:

  1. The initial desired value is read using get(). At the start of simulation, this value is typically the reset value (0).
  2. The desired value is changed using set(8'h11). This modifies only the register model.
  3. The updated desired value is verified again using get().
  4. The update() method is called to synchronize the register model with the DUT.

What Happens During update()

Before performing a write operation, UVM compares the desired value and mirror value.

  • If desired ≠ mirror, a write transaction is generated.
  • If desired = mirror, no transaction is performed.

In the example, the desired value becomes 0x11, which is different from the mirror value, so a write transaction is issued to the DUT.

Driver Activity During the Write

Once update() triggers the register write, the transaction is translated by the register adapter and sent to the driver. The driver then performs the actual DUT write operation. 


if(tr.wr == 1'b1)
begin
   tif.din <= tr.din;
   @(posedge tif.clk);
   `uvm_info("DRV", $sformatf("Data Write -> Wdata : %0d",tif.din), UVM_NONE);
end

This confirms that the desired value stored in the register model is finally written into the DUT register.

Key Observations

  • The desired value exists only in the register model.
  • get() and set() operate only on the model.
  • No hardware access occurs until update() is called.
  • The update operation generates a write transaction only if the desired value differs from the mirror value.
  • After a successful write, the mirror value becomes equal to the desired value.
After the update transaction completes, both the desired value and the mirror value represent the same register state as the DUT.
Run This Example on EDA Playground