Mirror & Predict: Desired, Mirrored, and Checking

Overview

RAL keeps two value views for each register field: desired (what software intends) and mirrored (what the model believes exists in DUT now). Most mirror failures are not random bugs; they are mismatches in how these two views are updated.

This topic turns mirror/predict into a deterministic workflow: understand value transitions, pick the right API method, wire predictor correctly, and debug drift using repeatable evidence.

Lessons in this topic

1. Desired vs Mirrored Theory — two-value model chart and state transitions.

2. set/update/write/read — method semantics table and practical code patterns.

3. uvm_reg_predictor Wiring — monitor -> predictor -> map signal path.

4. mirror(UVM_CHECK) Compare — compare lifecycle and pass/fail interpretation.

5. Auto Predict vs Explicit Predict — set_auto_predict decision matrix.

6. Mirror Drift Debug — checklist for false failures and triage sequence.

Two-value model and prediction pipeline

[RAL] and [UVM] mirror/predict data flow

  [TEST] set()/update()/write()/read()/mirror()
      │
      ├─ desired value (intent) ─────────────┐
      │                                      │
      └─ mirrored value (belief) ◄───────────┴─────────────┐
                                                             │
  [UVM] frontdoor write/read through map+adapter             │
      │                                                      │
      ▼                                                      │
  [BUS] sequencer -> driver -> DUT -> monitor ───────────────┤
      │                                                      │
      └─ analysis transaction -> uvm_reg_predictor --------->┘
                            bus2reg -> predict() -> mirror update

  Key rule:
    mirror(UVM_CHECK) is only meaningful when mirrored value is trustworthy.

[CHECK] failure classes this topic addresses

  1) False mismatch:
     mirror outdated because predictor missing or mis-modeled.

  2) Hidden bug:
     mirror silently auto-updated, masking missing monitor path.

  3) Method confusion:
     get() used where get_mirrored_value() was intended.

  4) Policy mismatch:
     W1C/RC/volatile modeled incorrectly, causing deterministic drift.

Key takeaways

• desired tracks intent; mirrored tracks believed DUT state.

• Method semantics and predictor wiring are coupled; treat them as one design decision.

• mirror(UVM_CHECK) is an integrity check on both DUT and model assumptions.

• Debugging mirror drift is fastest when done with a fixed checklist, not ad hoc prints.

Common pitfalls

• Assuming mirror failures always mean DUT bug; model plumbing is often the root cause.

• Using auto-predict by default in systems where external masters modify registers.

• Comparing desired value to DUT and calling it a mirror check.