Reference Models

Scoreboards · Module 18 · Page 18.3

The Engineering Problem

The predictor produces the expected by applying a model of the intended behavior (Module 18.2). This chapter is that model — the reference model (the golden model): the executable embodiment of the spec that defines what correct is. Building one raises questions that determine the entire value of the checker. What does it model (the functional behavior — not the cycle-accurate micro-architecture)? How faithful must it be (its fidelity to the spec is the ceiling on what the scoreboard can catch — a gap in the model is a blind spot in verification)? How do you build it (SystemVerilog? C/C++ via DPI for a complex DUT?)? And — the subtle, critical one — where does it come from? It must come from the spec, independently — not from the RTL. If the reference model is a re-implementation of the RTL's algorithm, it replicates the RTL's bugs: the model and the DUT are wrong the same way, they agree, and the scoreboard passes — hiding the bug. The problem this chapter solves is building a faithful, independent reference model: the thing that defines correct for the entire checking effort.

A reference model is the executable, independent embodiment of the DUT's specification — the golden model that, given an input (and state), computes the correct output. It is abstracted: it models the functional/algorithmic behavior (what the output should be) — not the cycle-accurate micro-architecture (how the DUT computes it, with pipelines and internal timing) — which makes it simpler, faster, and independent of the DUT's implementation. Its fidelity to the spec is the defining property: the scoreboard can catch exactly the DUT deviations the model correctly captures — so a gap or error in the model is a blind spot (a missed bug) or a false alarm. It must be built independently from the spec — not a re-implementation of the RTL — or it replicates the implementation's bugs and the scoreboard passes them silently. For complex DUTs (codecs, processors, DSP), it's often written in C/C++ and called via DPI, reusing an existing software golden model. This chapter is the reference model: what it embodies, fidelity as the ceiling, functional abstraction, independence from the RTL, and DPI for complexity.

What is a reference model — the executable, independent embodiment of the spec that defines correct — and why is its fidelity the ceiling on what the scoreboard can catch, why must it be abstracted and independent of the RTL, and when is it written in C via DPI?

Motivation — why the reference model defines the verification

The reference model is not a detail — it defines what verification can do. The reasons:

• The reference model is the definition of correct. The scoreboard checks the DUT against the reference model. So the reference model is the standard — whatever it says is correct is what the check enforces. Its correctness is the foundation.
• Its fidelity is the ceiling on what's caught. A faithful model (correct per the spec) lets the scoreboard catch every DUT deviation. A model with a gap (doesn't model a feature) can't catch bugs there (a blind spot); a model with an error false-flags a correct DUT. Verification can't exceed the model's fidelity.
• It must be independent of the implementation. If the model is derived from the RTL (copies its algorithm), it shares the RTL's bugs — they're wrong the same way, agree, and the scoreboard passes. The model must come independently from the spec, so it disagrees with a buggy DUT.
• Abstraction makes it tractable and independent. Modeling the functional behavior (not the cycle-accurate micro-architecture) makes the model simpler, faster to write and run, and independent of the DUT's internal design (so it doesn't accidentally replicate the DUT's implementation choices — and bugs).
• Complex DUTs need a real software model. For a codec, processor, or DSP, the intended behavior is a substantial algorithm — often already implemented as a C/C++ software model (a spec frequently ships with one). DPI lets you call that existing golden model from the testbench.

The motivation, in one line: the reference model is the definition of correct the scoreboard enforces, so its fidelity to the spec is the ceiling on what verification can catch — which requires it to be faithful (or you have blind spots), abstracted to the functional level (tractable, independent), independent of the RTL (or it replicates the DUT's bugs), and — for complex DUTs — often a C/C++ golden model via DPI.

Mental Model

Hold the reference model as a golden ruler, made independently from the specification, that the DUT is measured against:

A reference model is a golden ruler: an authoritative standard, made independently from the specification, that the DUT is measured against. Its accuracy is the ceiling on what you can detect — a faithful ruler catches every deviation, a flawed ruler measures wrong — and a ruler copied from the very thing it measures is useless, because it would call any object 'correct'. Picture measuring a manufactured part (the DUT) against a reference ruler (the reference model). The ruler is the standard of correct — whatever it reads is taken as the truth, and the part is judged against it. Three things follow. First, the ruler's accuracy is the ceiling on what you can detect: if the ruler is accurate (a faithful embodiment of the intended dimensions — the spec), it catches every deviation of the part; if the ruler is off (a gap, a wrong marking), it measures wrong — it misses the part's real errors or flags a good part. You can't measure more accurately than your ruler. Second, the ruler must be made from the design intent, independently — from the blueprint (the spec), by a different process than the part. Third — the crucial trap — a ruler copied from the very part it measures is useless: if you make the ruler by tracing the part, then the part always matches the ruler (they're the same shape), so you'd call any part — including a defective one — correct. The ruler must be made independently of the part, from the intended dimensions, so that a defective part disagrees with it. A good metrology lab never derives its standard from the thing under test; it builds the standard from the specification, independently, so the comparison means something. The whole value of the ruler is its independent fidelity to the intended design.

So the reference model is a golden ruler made independently from the spec: it is the authoritative standard of correct, against which the DUT is measured; its fidelity to the spec is the ceiling on what you can detect (a faithful ruler catches every deviation; a flawed one measures wrong); and it must be made independently of the DUT — from the spec, not the RTL — because a ruler copied from the part would call any part correct (it replicates the part's defects). Build the standard from the design intent, independently — never trace it from the thing you're measuring.

Visual Explanation — the reference model defines correct, from the spec

The defining picture is the origin and role: the reference model is built from the spec independently and defines correct, which the predictor/scoreboard use to judge the DUT.

The figure shows the reference model's origin and role. The specification (the intended behavior) is the source. The reference model is built from it, independently of the RTL — embodying the spec as executable code. It defines what correct is — the predictor applies it to compute the expected, and the scoreboard checks the DUT against that expected. The RTL (DUT) is also built from the spec, but by a different path (a different team, a different discipline — design vs verification). The crucial reading is the two independent realizations of the same spec: the brand-colored reference model and the default RTL are both derived from the warning-colored spec, but independently — so they don't share implementation choices (or bugs). Because they're independent, a DUT deviation from the spec makes the DUT disagree with the reference (which is faithful to the spec), and the scoreboard catches it. The success-colored "definition of correct" and "scoreboard" show the model's role: it is the standard, and the check is DUT vs standard. The independence is structural and essential: if the reference model were built from the RTL (the dashed path that must not exist), it would share the RTL's bugs, and the check would pass them. The diagram is the epistemology of checking: two independent realizations of the spec (reference model and DUT), cross-checked — the reference trusted (it's simpler, abstract, carefully built from the spec), the DUT under test; and the independence of the two paths from the spec is what makes a disagreement reveal a DUT bug. Build the reference from the spec, by a path independent of the RTL, so the two realizations can disagree.

RTL / Simulation Perspective — building the reference model (SV and C/DPI)

In code, the reference model can be SystemVerilog (for simpler behavior) or a C/C++ golden model via DPI (for complex algorithms). The code shows both, and the abstraction.

// === SYSTEMVERILOG reference model: the intended FUNCTION, abstractly (not cycle-accurate) ===
class alu_ref_model;
  // models WHAT the output should be — from the SPEC — not HOW the RTL pipelines it
  function bit [31:0] compute(bit [31:0] a, b, op_e op);
    case (op)
      ADD: return a + b;          // the spec's intended result — independent of the RTL's adder design
      SUB: return a - b;
      MUL: return a * b;          // no pipeline stages, no internal timing — just the function
      // ... full spec coverage: every operation, every corner (overflow, flags) the scoreboard checks
    endcase
  endfunction
endclass
 
// === C/C++ GOLDEN MODEL via DPI: reuse an existing software model for a COMPLEX DUT ===
import "DPI-C" function void codec_ref_encode(input byte unsigned in[], output byte unsigned out[]);
//   the C reference (often shipped WITH the spec) computes the expected; the predictor calls it:
class codec_predictor extends uvm_subscriber #(frame_txn);
  function void write(frame_txn t);
    out_txn e = out_txn::type_id::create("e");
    codec_ref_encode(t.payload, e.encoded);   // ← call the C golden model for the expected output
    expected_ap.write(e);
  endfunction
endclass
// ✗ NEVER build the reference by copying the RTL's algorithm → it replicates the RTL's bugs (DebugLab).

The code shows the two main implementation paths. The SystemVerilog reference model (alu_ref_model) models the intended function — from the spec — abstractly: compute returns the spec's result for each operation (ADD: a + b, etc.) without the RTL's pipeline stages or internal timing — what the output should be, not how the RTL computes it. Its fidelity is full spec coverage (every operation, every corner — overflow, flags — the scoreboard checks). The C/C++ golden model via DPI is for complex DUTs: import "DPI-C" brings in a C reference (codec_ref_encode — often shipped with the spec), and the predictor calls it (codec_ref_encode(t.payload, e.encoded)) to compute the expected output — reusing the existing software golden model rather than re-writing a complex algorithm in SystemVerilog. The closing ✗ comment marks the cardinal rule: never build the reference by copying the RTL's algorithm — it replicates the RTL's bugs (the DebugLab). The shape to carry: a reference model is the intended function, made executable — in SystemVerilog for simpler DUTs (the function, abstractly, from the spec) or via DPI-C for complex ones (reusing a C golden model) — and it models what the output should be (functional), not the DUT's micro-architecture (cycle-accurate), built from the spec, never from the RTL. The abstraction (functional, not cycle-accurate) and the independence (from the spec, not the RTL) are the two defining properties; the implementation language (SV vs C) is a practical choice driven by the model's complexity.

Verification Perspective — fidelity is the ceiling on what's caught

The reference model's fidelity to the spec determines what the scoreboard can catch — it is the ceiling on verification. Seeing how a gap or error in the model limits the check is seeing why fidelity is paramount.

The figure shows fidelity as the ceiling — how the model's correctness and completeness bound what the scoreboard can catch. A faithful model (correct and complete per the spec) gives full correctness coverage — the scoreboard catches every DUT deviation (the brand → success path). A model gap (a feature not modeled) creates a blind spot: bugs in that area are never caught, because there's no expected to compare against — the scoreboard is silent where the model is empty. A model error (modeled wrong) creates a false alarm: a correct DUT is flagged (the model says wrong when the DUT is right). The verification insight is that the model defines, and limits, what correctness checking can find: the scoreboard can catch exactly the deviations the model correctly captures — no more. So a gap in the model is a gap in verification (a silent blind spot — worse than a visible hole, because you don't know it's unchecked), and an error in the model is a false failure (noise that wastes debug time and erodes trust). The warning-colored gap and error are the two ways fidelity falls short. This is why the reference model is the highest-leverage artifact in the checker: improving the model's fidelity directly raises the ceiling on what verification finds, and any model deficiency directly limits it. The practical consequence: the reference model deserves the same rigor as the DUT — it must be reviewed against the spec, covered (every feature modeled), and validated (it must agree with a known-good DUT and catch injected bugs). The figure is the stakes of the reference model: it's not a helper but the standard — whatever it can't model, verification can't check, and whatever it gets wrong, verification gets wrong — so its fidelity to the spec is literally the ceiling on what the entire checking effort can catch.

Runtime / Execution Flow — building a faithful, independent reference model

Building a reference model is a disciplined process: derive it from the spec (independently), abstract to the functional level, cover every feature, and validate it. The flow shows the steps.

The flow shows the disciplined build of a faithful, independent reference model. Derive (step 1): build it from the specification, independently of the RTL — not by copying the RTL's algorithm — so it doesn't share the RTL's bugs (the DebugLab). Abstract (step 2): model what the output should be (the functional behavior), not the cycle-accurate micro-architecture — making it simpler, faster, and independent of the DUT's internal design. Cover (step 3): model every feature the scoreboard checks (every operation, every corner), so there are no blind spots (gaps). Validate (step 4): confirm it agrees with a known-good DUT (so it's not false-flagging) and catches injected bugs (so it's actually checking) — proof it's faithful. The runtime insight is that the reference model is built and validated with the same rigor as the DUT — because it's the standard. Each step guards a failure mode: derive-independently guards the replicated-bug trap (step 1 → DebugLab); abstract guards tractability and independence (step 2); cover guards blind spots (step 3 → Figure 2's gap); validate guards both false alarms (agrees with good DUT) and blind spots (catches injected bugs) (step 4). The implementation choice — SystemVerilog or C/C++ via DPI — is driven by the model's complexity (step alongside, not a separate concern). This is why a reference model is not a quick helper but a first-class deliverable: its fidelity is the ceiling on verification (Figure 2), so it must be derived right (independent), abstracted right (functional), covered (no gaps), and validated (agrees + catches) — a process that produces a trustworthy standard of correct. The flow is the recipe for the golden model: from the spec, independently; functional, not cycle-accurate; complete; and validated — so it can be trusted as the definition of correct the entire check rests on.

Waveform Perspective — functional abstraction: the model computes what, not how

The reference model's abstraction is visible on a timeline: the DUT takes many cycles (pipeline, micro-architecture) to produce an output, while the reference model computes the same output value functionally — they agree on the data, abstracting the how. The waveform shows the level difference.

The waveform shows the reference model's functional abstraction. The DUT takes several cycles to compute the result: the input (in=12) enters its pipeline (stages S1, S2, S3 on dut_pipe), and the actual output (dut_out=24 — say a doubling) appears a few cycles later, after the micro-architecture's stages. The reference model computes the same result value functionally — ref_out=24 — modeling what the output should be, not the cycle-accurate pipeline. The scoreboard compares the data (dut_out == ref_out → sb_match). The crucial reading is the level difference: the DUT's dut_pipe shows the micro-architecture (the multi-cycle pipeline — how the result is computed), while the reference's ref_out shows just the result value (what the result should be) — available immediately, functionally, without modeling the stages. The reference abstracts the how (the multi-cycle pipeline) and models only the what (the result value 24) — which is why it's simpler (no pipeline to model) and independent of the DUT's micro-architecture (it doesn't care how the DUT computes 24, only that the result should be 24). The picture to carry is that the reference model lives at a higher abstraction level than the DUT: the DUT is cycle-accurate RTL (stages, timing); the reference is functional (the result). They meet at the data — dut_out == ref_out — which is what the scoreboard checks. Reading this — does the DUT's eventual output match the reference's functional result? — confirms the DUT computes the right value (regardless of how its pipeline got there). The DUT's multi-cycle pipeline vs the reference's functional result, agreeing on the data is the signature of functional abstraction: the reference models what, the DUT implements how, and the check is did the how produce the right what — which is exactly the level at which correctness (as opposed to micro-architecture) is defined.

DebugLab — the reference model that shared the DUT's bug

✗ reference model DERIVED FROM THE RTL (replicates the RTL's bug → they agree → bug hidden):
  // RTL rounds a corner case toward zero (WRONG per spec, which says round-to-nearest)
  // reference model was written by COPYING the RTL's rounding logic (round toward zero)
  // → ref and DUT BOTH round toward zero → they AGREE → scoreboard PASSES → spec violation HIDDEN
  // the model shares the DUT's implementation bug, so it can't catch it
 
✓ reference model derived INDEPENDENTLY FROM THE SPEC (disagrees with the buggy DUT → caught):
  // reference model implements round-to-nearest PER THE SPEC (independent of how the RTL does it)
  // → DUT rounds toward zero (bug), ref rounds to nearest (correct) → they DIFFER → MISMATCH → caught
  // independence from the RTL is what lets the model catch the RTL's implementation bugs

Common Mistakes

• Deriving the reference model from the RTL. It replicates the RTL's bugs; build it independently from the spec, ideally by a different path.
• A gap in the model. A feature not modeled is a silent blind spot — bugs there are never caught; cover every feature the scoreboard checks.
• An error in the model. A wrongly-modeled behavior false-flags a correct DUT; validate the model against a known-good DUT.
• Modeling cycle-accurate micro-architecture. The reference should model the functional behavior (what), not the pipeline (how); cycle-accuracy makes it complex and couples it to the implementation.
• Treating the model as a quick helper. The reference model's fidelity is the ceiling on verification; it deserves first-class rigor, review, and validation.
• Not validating with injected bugs. A model that isn't proven to catch deliberate spec violations may share the DUT's behavior or have blind spots.

Senior Design Review Notes

Interview Insights

Exercises

1. State the ceiling. Explain why the reference model's fidelity is the ceiling on what the scoreboard can catch, with an example of a gap and an error.
2. Choose the abstraction. For a pipelined multiplier, explain what the reference model should and shouldn't model.
3. Spot the replicated bug. Given a reference model copied from the RTL, explain why a shared bug escapes and how to fix it.
4. Decide SV vs DPI. For a simple adder and a video codec, choose the reference model's implementation and justify.

Summary

• A reference model (golden model) is the executable, independent embodiment of the DUT's specification — it computes the correct output and is the definition of correct the scoreboard enforces.
• Its fidelity to the spec is the ceiling on what the scoreboard can catch: a faithful model catches every deviation; a gap is a silent blind spot (missed bug); an error is a false alarm (a correct DUT flagged) — verification can't exceed the model's fidelity.
• It is abstracted to the functional level — modeling what the output should be, not the cycle-accurate micro-architecture (how) — which makes it simpler, faster, and independent of the DUT's implementation.
• It must be independent of the RTL — derived from the spec, not a re-implementation of the RTL — or it replicates the RTL's bugs (model and DUT wrong the same way agree → the scoreboard passes the bug silently); for complex DUTs, often a C/C++ golden model via DPI.
• The durable rule of thumb: build the reference model as a faithful, independent embodiment of the spec — derived from the specification (not the RTL), abstracted to the functional level (what, not how), covering every feature, and validated to agree with a known-good DUT and catch injected spec violations — because its fidelity is the ceiling on what verification can catch, and a model copied from the RTL replicates the RTL's bugs and hides them.

Next — Data Checking: with the expected in hand, the scoreboard performs the comparison — data checking: how it pairs each observed transaction with its expected, compares the fields, reports a precise mismatch (got vs expected, which field), and the patterns for robust, debuggable comparison of transaction data.