Predictors

Scoreboards · Module 18 · Page 18.2

The Engineering Problem

The scoreboard compares the observed result against an independently computed expected (Module 18.1). But the scoreboard doesn't compute the expected — it receives it. Something has to produce the expected stream: take each input the DUT received, apply the DUT's intended function, and compute what the output should be. That something is the predictor. Building one raises real questions: where does it get its input (the stimulus? the input monitor?), what does it model (the intended input-to-output transformation), and — the hard part — what about state? A combinational DUT is a pure function (output depends only on input), and a predictor is easy. But most real DUTs are stateful — registers, memories, accumulators, pipelines — so the output depends on the input and the internal state, and the predictor must maintain the same state and update it exactly as the DUT intends. Get the state wrong and the predictor's expected is wrong — producing a flood of false mismatches that look like a DUT failure but are predictor bugs. The problem this chapter solves is producing the expected: the predictor that models the intended behavior to compute it.

A predictor is the component that computes the expected result by modeling the DUT's intended input-to-output transformation. It observes the input (subscribing to the input-side monitor, so it predicts for exactly what the DUT received), applies the model of intended behavior (a function for a combinational DUT; a state machine for a stateful one), and broadcasts the expected output transaction to the scoreboard — which compares it against the actual output (Module 18.1). It works in transactions, abstractly (TLM, Module 16) — independent of the DUT's implementation. The crucial complexity is state: a stateful predictor must maintain state that exactly mirrors the DUT's intended state — updating on every relevant input, resetting when the DUT resets — because the expected output depends on it, and a state divergence makes all subsequent predictions wrong. The predictor is the DUT's shadow: fed the same input, it computes what the output should be, in parallel, independently. This chapter is the predictor: its role and structure, the input-to-output model, the statefulness, and the state-divergence bug.

What is a predictor — the component that observes the input and computes the expected output by modeling the DUT's intended input-to-output transformation — and why must a stateful predictor maintain state that exactly mirrors the DUT's?

Motivation — why a predictor, and why state is hard

The predictor exists to produce the expected, and its difficulty is state. The reasons:

• The expected must be produced, transaction by transaction. The scoreboard needs an expected for each input — computed, not known. The predictor is the component that computes it, per input, automatically.
• It must model the intended input-to-output transformation. To predict the output, the predictor must embody the DUT's intended function — given an input (and state), what output should result. This is the specification, in executable form.
• It predicts from the actual observed input. The predictor predicts for exactly what the DUT received — so it observes the input (the input-side monitor), not the stimulus intent — because if the input was transformed in flight, the prediction must use the actual input.
• State is what makes it hard. A combinational DUT is a pure function — easy. But most DUTs are stateful: the output depends on the input and the internal state. The predictor must maintain the same state and update it exactly as the DUT intends — or its predictions drift.
• State divergence is silent and catastrophic. If the predictor's state diverges from the DUT's intended state (a missed update, an unhandled reset), every subsequent prediction is wrong — a flood of false mismatches that look like a DUT failure but are the predictor's fault.

The motivation, in one line: the scoreboard needs an expected per input, which must be computed by a predictor that models the DUT's intended input-to-output transformation — easy for a combinational DUT (a pure function) but hard for a stateful one, where the predictor must maintain state that exactly mirrors the DUT's, because a state divergence makes all later predictions wrong, a silent, catastrophic source of false mismatches.

Mental Model

Hold the predictor as the DUT's shadow — a parallel model fed the same input, computing what the output should be:

A predictor is the DUT's shadow: a parallel model that, fed the same input as the DUT, computes what the output should be — independently, in transactions, embodying the intended behavior. For a stateful DUT, the shadow must carry the same internal state and update it in lockstep, or it drifts away from what the DUT should be doing. Picture the DUT and, beside it, a shadow — a parallel model (the predictor) that receives the same inputs. As each input arrives, the shadow computes what the output should be — applying the intended function (the spec) — independently of what the real DUT actually produces. The scoreboard then compares the real DUT's output against the shadow's — match (DUT correct) or differ (a bug). For a combinational DUT — a pure function (output depends only on the current input) — the shadow is simple: apply the function to each input. But for a stateful DUT — one with registers, memory, accumulators (output depends on the input and the history) — the shadow must carry the same internal state and update it in lockstep with the DUT's intended updates: every input that changes the DUT's state must change the shadow's state the same way, and a reset of the DUT must reset the shadow. If the shadow's state ever drifts from the DUT's intended state — it misses an update, or fails to reset — then from that point, the shadow is computing for a different state, so every prediction is wrong, and the scoreboard flags mismatch after mismatch — blaming the DUT when the shadow is the one that wandered off. The shadow is only useful if it stays in lockstep — same input, same state, same updates — so its output is truly "what the DUT should produce."

So the predictor is the DUT's shadow: a parallel model, fed the same input, computing what the output should be via the intended function, independently. For a stateful DUT, the shadow must carry the same state and update it in lockstep — every state change mirrored, every reset honored — or it drifts, and all its predictions go wrong. The scoreboard compares the real DUT against the shadow; the shadow is trustworthy only while it stays in lockstep. Run the shadow on the same inputs, keep its state in lockstep, and its output is what the DUT should produce.

Visual Explanation — the predictor in the checking architecture

The defining picture is the checking architecture: the input monitor feeds the predictor, the predictor produces the expected, and the scoreboard compares it against the actual from the output monitor.

The figure shows the predictor's place in the checking architecture. The input monitor observes what the DUT received and sends it to the predictor. The predictor models the intended input-to-output transformation and computes the expected output, which it sends to the scoreboard. The output monitor observes what the DUT actually produced and sends that (the actual) to the scoreboard. The scoreboard compares expected against actual → the verdict. The crucial reading is the predictor's position: it sits between the input observation and the scoreboard's expected input — it is the source of the expected stream. The brand-colored predictor is the active producer of the expected; the success-colored scoreboard is the comparator. Note the two monitors: an input-side one (feeding the predictor) and an output-side one (feeding the scoreboard's actual) — the input monitor tells the predictor what to predict from, and the output monitor tells the scoreboard what the DUT did. This is the full checking pipeline: observe the input → predict the expected output (predictor) → observe the actual output (output monitor) → compare (scoreboard). The predictor is what makes the expected exist: without it, the scoreboard would have an actual but no expected to compare against (Module 18.1's gap). The diagram is the architecture of automated checking with the predictor in place: the predictor transforms the observed input into the expected output, feeding the expected side of the scoreboard, so the scoreboard can render the verdict — the predictor is the expected-producing engine of the checker.

RTL / Simulation Perspective — the predictor computes the expected

In code, the predictor receives input transactions (via an analysis subscriber), applies the model to compute the expected output, and broadcasts it. The code shows a stateful predictor.

class my_predictor extends uvm_subscriber #(in_txn);   // subscribes to the INPUT monitor's stream
  `uvm_component_utils(my_predictor)
  uvm_analysis_port #(out_txn) expected_ap;            // broadcasts the EXPECTED output to the scoreboard
  logic [31:0] accum;                                   // STATE: mirrors the DUT's intended state
 
  function void build_phase(uvm_phase phase); expected_ap = new("expected_ap", this); endfunction
 
  // reset the predictor's state when the DUT resets — or its state diverges (DebugLab)
  function void reset();  accum = 0;  endfunction
 
  // for EACH input, model the intended behavior and produce the expected output
  function void write(in_txn t);                        // called per input transaction
    out_txn e = out_txn::type_id::create("e");
    accum = accum + t.data;                              // UPDATE state exactly as the DUT intends
    e.result = accum;                                    // EXPECTED output = f(input, state)
    expected_ap.write(e);                                // broadcast the expected → scoreboard
  endfunction
endclass
// the predictor is the DUT's SHADOW: same input, same state updates → expected = what the DUT SHOULD do.

The code shows a stateful predictor. It subscribes to the input monitor's stream (uvm_subscriber #(in_txn) — so its write is called for each input the DUT received) and has an analysis port (expected_ap) to broadcast the expected output to the scoreboard. It maintains state (accum) that mirrors the DUT's intended state. For each input (write(in_txn t)): it updates the state exactly as the DUT intends (accum = accum + t.data), computes the expected output as a function of the input and state (e.result = accum), and broadcasts it (expected_ap.write(e)). The reset() method resets the state when the DUT resets — crucial, because without it the state diverges (the DebugLab). The shape to carry: a predictor subscribes to the input, applies the model of intended behavior (a function of the input and state), and broadcasts the expected output — and for a stateful DUT, it maintains and updates state in lockstep with the DUT's intended state (including reset). The closing comment captures the essence: the predictor is the DUT's shadow — same input, same state updates → the expected is what the DUT should do. The combinational case is the same code without the state (e.result = f(t) — no accum); the stateful case adds the state and its updates, which is where the complexity (and the bugs) live.

Verification Perspective — the predictor must mirror the DUT's state

For a stateful DUT, the predictor's correctness hinges on its state mirroring the DUT's intended state exactly. Seeing how state divergence breaks everything is seeing the core predictor challenge.

The figure shows the state-mirroring requirement that defines a stateful predictor. The predictor maintains its own copy of the state, updating it per input in lockstep with the DUT's intended updates, and resetting when the DUT resets. As long as the states match (the top path), the predictor's expected output is correct, and the scoreboard's comparison is meaningful. If the predictor's state diverges (the bottom path — a missed update or an unhandled reset), then from that point its expected is computed for the wrong state, so every prediction is wrong — a flood of false mismatches that blame the DUT. The verification insight is that a stateful predictor's state is a second DUT (a model of the DUT's state machine) that must track the real DUT's intended state at every step. This is why stateful prediction is hard: it's not enough to model the input-to-output function — you must model the entire state evolution, exactly, including the subtle parts (reset behavior, ordering of updates, which inputs do and don't change state). And the failure mode is brutal: a single divergence poisons all subsequent predictions (the state is cumulative — once wrong, it stays wrong), so a tiny state-modeling error produces a massive, ongoing failure. The warning-colored divergence path leads to all predictions wrong; the brand-colored lockstep state is what must be maintained. The figure is the core challenge of predictors: the predictor's state must mirror the DUT's intended state exactly, at every step — because the expected output depends on it, and a divergence doesn't cause one wrong prediction but all subsequent ones. Model the state, not just the function — and keep it in lockstep, or everything after the divergence is a lie.

Runtime / Execution Flow — predicting per input

At run time, the predictor runs a per-input loop: receive the input, update state, compute the expected output, broadcast it. The flow shows the loop.

The flow shows the predictor's per-input loop. Receive (step 1): the predictor receives the same input (from the input monitor) — exactly what the DUT received, transaction by transaction. Update state (step 2): for a stateful DUT, apply the intended state change (and reset the state on a reset event). Compute (step 3): apply the intended function — expected = f(input, updated state). Broadcast (step 4): send the expected output transaction; the scoreboard compares it against the actual. The runtime insight is that the predictor runs in lockstep with the DUT: for every input the DUT processes, the predictor processes the same input, updating its state and producing an expected output — so the predictor's expected stream parallels the DUT's actual stream, transaction for transaction. This lockstep is what makes the prediction valid: because the predictor sees the same inputs and maintains the same state, its output is what the DUT should produce for that exact sequence of inputs and state. The order of the steps matters for stateful DUTs: the state update (step 2) and the output computation (step 3) must match the DUT's intended semantics (does the output reflect the state before or after this input's update? — the predictor must match the DUT's convention). And the reset (in step 2) is critical: a reset event must reset the predictor's state, synchronously with the DUT's reset, or the state diverges (the DebugLab). The flow is the predictor operating as the DUT's shadow: same input, same state evolution, same output computation — per transaction, in lockstep — producing the expected stream that is "what the DUT should be doing," for the scoreboard to check against.

Waveform Perspective — the predictor's expected tracks the input

The predictor's operation is visible on a timeline: each input produces an expected output (accounting for state), and the scoreboard compares it against the DUT's actual. The waveform shows the predictor tracking a stateful computation.

The waveform shows the predictor operating as the DUT's shadow on a stateful computation. Each input (in_data) arrives; the predictor updates its state (pred_state, an accumulator) and computes the expected output (expected = the running accumulator). The DUT produces its actual output (dut_out). The scoreboard compares: at each output, expected equals actual (sb_match pulses), so the DUT is correct. The crucial reading is that the expected accounts for state — it's the accumulated sum (05, then 08, then 0A), not just the current input — which is why the predictor must track the DUT's state. The predictor's pred_state evolves (00 → 05 → 08 → 0A) in lockstep with the DUT's intended state, so its expected is what the DUT should produce for that accumulated state. The picture to carry is the state-aware prediction: the expected is not a function of the current input alone but of the input and the accumulated state, and the predictor's pred_state mirrors the DUT's. The counterfactual (the DebugLab) is visible too: if pred_state diverged (say, the predictor missed the 03 input, staying at 05), then expected would be wrong (07 instead of 0A) and every subsequent comparison would mismatch. Reading a predictor's waveform — does the predictor's state track the DUT's? does the expected (accounting for state) match the actual? — confirms the predictor is a faithful shadow. The state evolving in lockstep, the expected matching the actual at each step is the signature of a correct stateful predictor: it carries the same state, computes the same output, transaction by transaction — what the DUT should produce, checked against what it did.

DebugLab — the predictor whose state diverged and flooded false mismatches

✗ predictor does NOT handle the DUT's reset → state diverges → all later predictions wrong:
  function void write(in_txn t);
    accum = accum + t.data;   // keeps accumulating...
    e.result = accum;         // ...but the DUT was RESET (accum→0) and the predictor wasn't
  endfunction                  // predictor accum stays at the pre-reset value → every expected is OFF
  // from the reset onward: expected = (stale accum) + inputs;  actual = (0) + inputs  → MISMATCH flood
 
✓ predictor resets its state in lockstep with the DUT's reset:
  function void write_reset(reset_txn r);  accum = 0;  endfunction   // observe + handle the reset
  // OR subscribe to the reset event and zero the state, so predictor state == DUT intended state
  // now after reset: predictor accum = 0, matches the DUT → predictions correct again

Common Mistakes

• Not modeling the DUT's reset. A predictor that doesn't reset its state when the DUT resets diverges, flooding false mismatches from the reset onward.
• Missing a state-changing event. Any input that changes the DUT's state must change the predictor's state; a missed update drifts the prediction.
• Predicting from the stimulus intent, not the observed input. Predict from what the DUT actually received (the input monitor), so a modified-in-flight input is predicted correctly.
• Mismatching the state convention. If the DUT's output reflects the state before or after the update, the predictor must match that exactly.
• Treating a stateful DUT as combinational. A predictor without state for a stateful DUT predicts only from the current input and is wrong whenever history matters.
• Blaming the DUT for a flood of mismatches. A flood from a point with plausible observed values is usually predictor-state divergence, not a DUT bug.

Senior Design Review Notes

Interview Insights

Exercises

1. Place the predictor. Sketch the checking architecture and explain where the predictor sits and what feeds it.
2. Predict with state. For an accumulator DUT, write the predictor's per-input update and output computation.
3. Handle reset. Explain why a predictor must reset its state with the DUT, and what happens if it doesn't.
4. Diagnose the flood. Given mismatches flooding from a point with plausible observed values, name the likely cause and the fix.

Summary

• A predictor computes the expected result by modeling the DUT's intended input-to-output transformation: it observes the input (from the input monitor), applies the model (a function, or a state machine), and broadcasts the expected output to the scoreboard.
• It is the active producer of the expected side of the scoreboard's comparison, working in transactions and abstractly — the DUT's shadow, fed the same input, computing what the output should be in parallel and independently.
• It predicts from the observed input (what the DUT actually received), so a modified-in-flight input is predicted correctly — subscribing to the input-side monitor.
• The crucial complexity is state: a stateful predictor must maintain state that exactly mirrors the DUT's intended state — updating on every relevant input, resetting when the DUT resets — because a state divergence makes all subsequent predictions wrong (a flood of false mismatches).
• The durable rule of thumb: build the predictor as the DUT's shadow — observe the actual input, apply the intended input-to-output model, and broadcast the expected output — and for a stateful DUT, maintain state that mirrors the DUT's exactly (update on every relevant input, reset in lockstep with the DUT); a state divergence makes all later predictions wrong, a flood of false mismatches that look like a DUT failure but are a predictor bug, so when mismatches flood from a point with plausible observed values, suspect the predictor's state.

Next — Reference Models: the model of intended behavior the predictor draws on — the reference (golden) model: how to build one that faithfully captures the spec, the abstraction-level choices, the option of writing it in C/C++ via DPI for complex DUTs, and how the reference model's fidelity determines what the scoreboard can catch.