UVM RAL · Chapter 6 · Predictors

Auto vs Explicit Prediction

RAL keeps its mirror current in one of two modes, and this page covers both plus the single rule that keeps them from fighting. Auto prediction is implicit: the register model updates its own mirror as part of every frontdoor write and read. It is on by default and fine for a simple single-master testbench, but it only sees the accesses RAL originates. Explicit prediction connects a register predictor to the bus monitor and updates the mirror from all observed traffic, which is what multi-master and passive environments need. The rule is that these modes are alternatives, not additions: connecting an explicit predictor means turning auto prediction off. This page breaks a setup that leaves auto on with a predictor connected, so double prediction corrupts a write-one-to-clear register's mirror.

Foundation12 min readUVM RALAuto PredictExplicit PredictPredictorset_auto_predictMirror

Chapter 6 · Section 6.2 · Predictors

1. Why Should I Learn This?

The two prediction modes are the source of one of the most common and most confusing RAL bugs: connecting an explicit predictor for its multi-master capability while leaving auto prediction on, so every access is predicted twice. For idempotent fields (plain RW) the double update is harmless and hides, but for W1C, RC, counters, and any field whose update depends on its current value, applying the update twice corrupts the mirror in a way that looks like a modelling or DUT bug. Knowing that the two modes are alternatives — and that connecting a predictor means turning auto-predict off — is what keeps the mirror correct in exactly the realistic environments where you need explicit prediction.

Learning when to use each mode, and the disable-auto rule, is what lets you scale from a simple active testbench (auto is fine) to a multi-master or passive one (explicit, auto off) without silently double-predicting. It is the practical companion to 6.1's motivation.

2. Industry Story — the interrupt bit that cleared itself twice

A team upgrades a single-master environment to handle a second master, correctly adding a uvm_reg_predictor connected to the bus monitor (6.1). They test it, and RW registers are fine — but the INT_STATUS register, full of W1C interrupt bits, starts behaving strangely: clearing one interrupt seems to clear more than intended, and the mirror disagrees with the DUT in ways that make no sense.

The cause is double prediction. They connected the explicit predictor but never turned auto prediction off, so both modes are active. When RAL does a frontdoor write of 1 to clear a W1C bit, two things update the mirror: the register auto-predicts the clear as it drives (mirror bit → 0), and then the predictor observes that same write on the bus and predicts the W1C clear again. For a plain RW field, predicting the same write twice is idempotent — the value is the value — so those registers looked fine and hid the bug. But W1C (and RC, and counters) are not idempotent: applying the clear rule twice, or interacting a stale-then-observed update, drives the mirror to a state neither single prediction would, corrupting INT_STATUS's mirror. The fix is one line — set_auto_predict(0) on the map when the explicit predictor is connected — after which each access is predicted exactly once. The lesson: auto and explicit prediction are alternatives, not additions; connecting an explicit predictor requires turning auto prediction off, or every access is predicted twice, which is harmless for idempotent RW fields but corrupts W1C, RC, and counter mirrors.

3. Concept — the two modes and the exclusivity rule

RAL maintains the mirror in one of two modes:

Auto (implicit) prediction — the default. The register model updates its own mirror as part of each frontdoor operation: a write predicts the mirror from what it drove, a read refreshes it. On automatically; no extra components. Its limit is that it only sees accesses RAL originates — it cannot track another master or a passive scenario (6.1).
Explicit prediction. A uvm_reg_predictor connected to the bus monitor updates the mirror from all observed traffic (6.1), via bus2reg. Strictly more capable — it tracks every access on the bus, whoever drove it — which is why multi-master and passive environments use it.

The exclusivity rule: use one, not both. When you connect an explicit predictor, you must turn auto prediction off on the map with set_auto_predict(0) (equivalently, the map's set_auto_predict(0) disables the register-self-update path). Otherwise both fire for every RAL access:

The register auto-predicts as it drives the frontdoor access.
The predictor observes that same access on the bus and predicts it again.

For an idempotent field (plain RW), predicting the same value twice is harmless — the value is the value — so the double update hides. For a non-idempotent field (W1C, W1S, RC, a counter, anything whose update depends on the current value), applying the update twice produces a state neither single prediction would, corrupting the mirror. Here is the decision and the rule:

Figure 1 — choosing a prediction mode, and the exclusivity rule. Single-master active testbench that only needs to track RAL's own accesses: auto (implicit) prediction is fine, leave it on. Multiple masters or passive monitoring (must track traffic RAL did not drive): use explicit prediction — connect a uvm_reg_predictor to the monitor AND turn auto-predict OFF (set_auto_predict(0)). The failure to avoid: predictor connected with auto-predict left ON means every RAL access is predicted twice, which corrupts non-idempotent fields (W1C/RC/counters).

4. Mental Model — two bookkeepers, and you must not hire both

Mental Model — one bookkeeper updates the ledger, and hiring a second means firing the first

Both prediction modes are bookkeepers keeping the mirror-ledger current; the rule is that exactly one keeps it, never two.

Auto prediction is a bookkeeper who updates the ledger by remembering what RAL did — every frontdoor access, they note the change. Explicit prediction is a bookkeeper who updates the ledger by watching every transaction on the bus — including ones RAL did not make. The watching bookkeeper is more thorough (they see the other masters too), which is why you promote to them for a busy, multi-party account. But if you keep both bookkeepers, they each record every RAL access, so every RAL transaction is entered twice. For an ordinary deposit (an idempotent RW write), a duplicate entry of 'balance is now 100' is harmless — the balance is 100 either way. But for an operation whose effect depends on the current state — 'clear this flag' (W1C), 'increment' (a counter), 'read-and-clear' (RC) — recording it twice applies it twice: the flag is cleared, then a second clear is applied to an already-changed state, and the ledger ends up somewhere neither single entry would put it. So promoting to the watching bookkeeper means firing the remembering one: connect the predictor and turn auto-predict off, so each access is booked exactly once.

Two habits:

Use one prediction mode. Auto for a simple active testbench; explicit (predictor + set_auto_predict(0)) for multi-master or passive.
Suspect double prediction when RW is fine but W1C/RC/counters are corrupt. The double update hides on idempotent fields and shows on non-idempotent ones.

5. Working Example — auto for simple, explicit-with-auto-off for multi-master

A simple single-master environment uses auto prediction — nothing to do, it is the default:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Single-master active testbench: auto prediction is on by default and sufficient.
reg_model.default_map.set_sequencer(apb_agent.sequencer, apb_adapter);
// No predictor; the register model self-updates the mirror on each frontdoor access.
cfg.write(s, 32'h13);   // auto-predicts the mirror as it drives — one update

A multi-master or passive environment uses explicit prediction and turns auto off:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Multi-master / passive: connect the predictor AND disable auto prediction.
reg_model.default_map.set_sequencer(apb_agent.sequencer, apb_adapter);
 
apb_predictor.map     = reg_model.default_map;
apb_predictor.adapter = apb_adapter;
apb_agent.monitor.ap.connect(apb_predictor.bus_in);      // explicit: mirror from observed traffic
 
reg_model.default_map.set_auto_predict(0);               // REQUIRED: turn OFF auto prediction
// Now each access updates the mirror EXACTLY ONCE — via the predictor observing the bus.

With auto off and the predictor on, a RAL write to a W1C bit is predicted once (by the predictor, observing the write), so the clear is applied a single time and the mirror is correct — and another master's write is also tracked (6.1). Leave set_auto_predict(0) out and that same W1C write is predicted twice, which is the next section.

6. Debugging Session — the predictor with auto-predict left on

Connecting an explicit predictor without turning auto prediction off predicts every access twice, corrupting non-idempotent (W1C/RC/counter) mirrors

DOUBLE PREDICTION

Buggy Code

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// The explicit predictor is connected, but auto prediction is NEVER turned off:
apb_predictor.map = reg_model.default_map;  apb_predictor.adapter = apb_adapter;
apb_agent.monitor.ap.connect(apb_predictor.bus_in);
// (missing) reg_model.default_map.set_auto_predict(0);   // auto-predict still ON
 
// A frontdoor write of 1 to a W1C interrupt bit is now predicted TWICE:
int_status.irq.write(s, 1);
//   (1) the register AUTO-predicts the W1C clear as it drives  -> mirror(irq) = 0
//   (2) the predictor OBSERVES the same write on the bus and predicts the clear AGAIN
//   For W1C/RC/counters, applying the update twice corrupts the mirror.

Symptom

Plain RW registers work perfectly, but registers with W1C, RC, or counter fields have mirrors that disagree with the DUT in ways that make no sense — clearing one interrupt appears to affect others, a counter's mirror is off by a factor, a read-clear seems to clear twice. Because RW is fine, the environment looks mostly correct and the bug seems specific to 'weird' registers, which points suspicion at their access-policy modelling or the RTL. The tell is that the corruption is confined to non-idempotent fields and appeared exactly when the explicit predictor was added.

Root Cause

Both prediction modes are active: the explicit predictor was connected, but auto prediction was never turned off, so every RAL frontdoor access updates the mirror twice — once by the register auto-predicting as it drives, and once by the predictor observing that same access on the bus. For an idempotent RW field, predicting the same value twice is harmless (the value is the value), which is why those registers are fine and hide the bug. For a non-idempotent field — W1C, W1S, RC, a counter — the update depends on the current state, so applying it twice produces a state neither single prediction would: a W1C clear applied to an already-cleared mirror, a counter incremented twice, a read-clear clearing a value that was already cleared. The mirror is corrupted precisely on the fields whose prediction is not idempotent, which is exactly the set that broke.

Fix

Turn auto prediction off when the explicit predictor is connected: reg_model.default_map.set_auto_predict(0); (as in Section 5), so each access is predicted exactly once — by the predictor observing the bus. Now the W1C clear is applied a single time and the mirror is correct, and the multi-master tracking the predictor provides still works. The rule the bug teaches: auto and explicit prediction are alternatives, not additions — connecting an explicit predictor requires set_auto_predict(0), or every access is predicted twice, which is harmless for idempotent RW fields but corrupts W1C, RC, and counter mirrors. When RW registers are fine but non-idempotent ones are corrupt after adding a predictor, you have double prediction: turn auto off.

7. Common Mistakes

Predictor connected with auto-predict left on. Every access is predicted twice; non-idempotent fields corrupt.
Assuming RW being fine means prediction is correct. Idempotent fields hide double prediction; check W1C/RC/counters.
Using auto prediction in a multi-master or passive environment. Auto sees only RAL's own accesses; you need explicit (6.1).
Turning auto off without connecting a predictor. Now nothing updates the mirror — the opposite failure.
Forgetting the predictor's map/adapter when going explicit. It needs both to reconstruct observed operations.

8. Industry Best Practices

Use exactly one prediction mode. Auto for a simple active testbench; explicit (predictor + set_auto_predict(0)) for multi-master or passive.
Pair every explicit predictor with set_auto_predict(0). Make it a fixed idiom so double prediction cannot slip in.
Test non-idempotent fields after any prediction change. W1C/RC/counters expose double (or missing) prediction that RW hides.
Never turn auto off without a predictor. Confirm the predictor is connected before disabling auto, or the mirror stops updating.
Document the environment's prediction mode. So a later change does not accidentally enable both.

9. Interview / Review Questions

10. Key Takeaways

Auto (implicit) prediction is the default: the register model updates its own mirror on each frontdoor access — simple, but it only sees the accesses RAL originates.
Explicit prediction uses a uvm_reg_predictor on the bus monitor to update the mirror from all observed traffic (6.1) — required for multi-master and passive environments.
The two are alternatives, not additions: connecting an explicit predictor requires set_auto_predict(0), or every RAL access is predicted twice.
Double prediction is harmless for idempotent RW fields (assignment) but corrupts W1C, RC, and counters (state-dependent updates applied twice) — the signature is RW fine, non-idempotent fields wrong after adding a predictor.
The half-failures are symmetric: predictor + auto-on double-predicts; auto-off + no predictor never predicts — so pair connecting a predictor with set_auto_predict(0) as one idiom.