Reference Models: Choosing the Right Fidelity

Overview

A reference model computes expected outputs from observed stimulus using specification rules — not RTL structure. It sits upstream of the scoreboard's exp_imp stream and answers the question every checker must resolve: given what the DUT actually received, what response does the spec require? Choosing the right fidelity — algorithmic, transaction-level, or cycle-approximate — avoids over-engineering, prevents circular verification, and keeps maintenance proportional to verification value.

This topic walks through five focused lessons. Together they cover the check-pipeline role of reference models, a fidelity decision matrix, two common implementation styles (untimed transforms and transaction-level memory/protocol models), and the integration patterns that wire models into connect_phase alongside golden monitors and scoreboards.

Lesson index

1. Reference Model Role — predict pipeline, spec vs RTL, monitor-sampled inputs.

2. Fidelity Decision Matrix — algorithmic, transaction, cycle-approx, cycle-accurate.

3. Algorithmic Models — untimed data transforms (CRC, crypto, checksum).

4. Transaction-Level Models — memory state, protocol outcomes, predict().

5. Integration & Golden Paths — connect_phase wiring, golden VIP tradeoffs.

[CHECK] reference model fidelity overview

  FIDELITY          WHAT IT MODELS              WHEN TO USE
  ─────────────────────────────────────────────────────────────────
  Algorithmic       Result of computation       Data-path math (CRC, AES)
                    (no time, no protocol)      when ordering/latency N/A

  Transaction       Protocol + memory state     Bus slaves, SRAM models,
                    (no cycle delays)           register side-effects

  Cycle-approx      Credits, latency, QoS       Visible timing contracts
                    (event-driven, not pins)    (arbiter, retry, backpressure)

  Cycle-accurate    Pin-level timing            Rarely for scoreboard —
                    (clock-by-clock)            only when timing IS the target

[UVM] reference model in the check pipeline

  stimulus ──► DUT ──► [UVM] dut_mon.ap ──┬──► scb.act_imp  (ACTUAL)
                                          │
                                          └──► ref_model.req_imp
                                                    │
                                                    ▼ predict()
                                               ref_model.ap ──► scb.exp_imp (EXPECTED)
                                                    │
                                                    ▼
                                              [CHECK] scoreboard compare

When to use each fidelity level

• Algorithmic — pure data transforms where only the final value matters (Ethernet CRC, AES encrypt, checksum). Zero simulation time; unit-testable as package functions.

• Transaction-level — protocol-visible outcomes without cycle timing: memory read/write results, APB OKAY/SLVERR, AXI response codes. Use when the verification plan checks data and ordering at bus-transaction granularity.

• Cycle-approximate — when the spec defines credit limits, retry windows, or QoS priority that affect observable latency. Model events and counters, not RTL pipeline stages.

• Cycle-accurate — almost never for scoreboard expected streams. Reserve for dedicated timing verification or when pin-level protocol compliance is the primary goal.

Key takeaways

• Model the spec, not the micro-architecture.

• Start at the lowest fidelity that catches plan bugs; escalate only when missed bugs prove insufficient.

• Reference model feeds expected; DUT monitor feeds actual — never the driver.

Common pitfalls

• Matching RTL fidelity to RTL complexity — maintenance doubles with every micro-arch change.

• No reference model on a data-path block — scoreboard counts transactions but never checks values.

• Escalating to cycle-accurate because the RTL is complex — complexity is not a fidelity criterion.