Part 8 · Checking & Coverage · Intermediate

Integration: Scoreboard, Golden Monitor, Spec Rules

connect_phase wiring, golden VIP vs algorithmic model, and spec fidelity documentation.

Wiring ref model to scoreboard

Integration happens in connect_phase: analysis ports from the DUT monitor feed both the reference model (for expected generation) and the scoreboard (for actual comparison). The reference model's analysis port feeds the scoreboard's exp_imp. This canonical pattern works for algorithmic, transaction-level, and cycle-approximate models — only the model internals change.

diagram
[UVM] full connect_phase wiring diagram

  build_phase:
    dut_agt   = bus_agent::type_id::create("dut_agt", this);
    scb       = bus_scoreboard::type_id::create("scb", this);
    ref_model = mem_ref_model::type_id::create("ref_model", this);

  connect_phase:
    ┌─────────────────────────────────────────────────────────────┐
    │  dut_agt.mon.ap                                             │
    │       │                                                     │
    │       ├──────────────────────► ref_model.req_imp            │
    │       │                              │                      │
    │       │                              ▼ predict / write    │
    │       │                         ref_model.ap                │
    │       │                              │                      │
    │       │                              ▼                      │
    │       │                         scb.exp_imp  (EXPECTED)     │
    │       │                                                     │
    │       └──────────────────────► scb.act_imp  (ACTUAL)        │
    │                                      │                      │
    │                                      ▼                      │
    │                                 compare()                   │
    └─────────────────────────────────────────────────────────────┘

  Filter RESPONSE in write_act; feed REQUEST to ref_model (or filter in write).
systemverilog
class block_env extends uvm_env;
  `uvm_component_utils(block_env)
  bus_agent      dut_agt;
  bus_scoreboard scb;
  mem_ref_model  ref_model;

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    dut_agt   = bus_agent::type_id::create("dut_agt", this);
    scb       = bus_scoreboard::type_id::create("scb", this);
    ref_model = mem_ref_model::type_id::create("ref_model", this);
  endfunction

  function void connect_phase(uvm_phase phase);
    super.connect_phase(phase);
    // Monitor → ref model (REQUEST stream)
    dut_agt.mon.ap.connect(ref_model.req_imp);
    // Ref model → scoreboard expected
    ref_model.ap.connect(scb.exp_imp);
    // Monitor → scoreboard actual (filter RESPONSE in write_act)
    dut_agt.mon.ap.connect(scb.act_imp);
  endfunction
endclass
  • dut_agt.mon.ap connects to both ref_model.req_imp and scb.act_imp.

  • ref_model.ap connects exclusively to scb.exp_imp — never to act_imp.

  • Filter transaction kind in write_act (RESPONSE only) and optionally in ref_model write (REQUEST only).

  • Never connect driver, sequencer, or seq_item_port to scoreboard or ref model.


Golden monitor vs algorithmic model

An alternative to writing a reference model is a golden-path monitor : a second agent monitoring a known-good implementation — C model, trusted behavioral RTL, or commercial VIP acting as DUT. The golden monitor's analysis port feeds scb.exp_imp directly, bypassing a custom predict function.

diagram
[CHECK] golden vs algorithmic tradeoff

  Criterion              Algorithmic model       Golden monitor / VIP
  ─────────────────────────────────────────────────────────────────────
  Spec clarity           Math well-defined       Protocol complex, VIP exists
                         (CRC, AES, checksum)

  Independence           Fully independent       RISK: circular if golden IS DUT RTL
  from DUT RTL           from DUT structure

  Development cost       Low (package fn)        Low if VIP licensed; high if C model port
  Maintenance            Spec ECO only           VIP rev + C model sync

  Simulation speed       Fastest (0-time)        C model slower; VIP moderate
  Fidelity control       You choose level        VIP fidelity fixed by vendor
  Unit testability       Excellent (package)     C model tests separate from UVM

  Out-of-order support   You implement ID        VIP may handle natively
  in scoreboard          in model output

  Best for               Data-path transforms    Standard protocols (PCIe, USB)
                         Custom memory maps      when VIP scoreboard exists
diagram
[UVM] golden-path wiring (alternative to ref model)

  ref_agt.mon.ap ──► scb.exp_imp   (EXPECTED from golden DUT)
  dut_agt.mon.ap ──► scb.act_imp   (ACTUAL from DUT under test)

  // No ref_model in this path — golden agent replaces predict()

When to prefer each approach

  • Algorithmic model — spec math is documented (CRC polynomial, AES S-box), custom block with no commercial VIP, team wants full control over fidelity and unit tests.

  • Golden monitor — standard protocol with mature VIP (AXI, PCIe), C reference model already exists from design team, protocol rules too complex to reimplement quickly.

  • Hybrid — golden VIP for protocol compliance, algorithmic model for data-path transform inside the DUT (e.g., VIP checks AXI handshake, ref model checks encryption output).


Spec fidelity rules and documentation

Every reference model carries documented assumptions that must align with the verification plan. Undocumented defaults — unmapped address returns 0, SLVERR vs OKAY on decode miss — cause false passes or false failures when RTL and model disagree on edge cases.

Required documentation

  1. Assumptions: unmapped addr → OKAY with 0 data, or SLVERR — match spec section reference.

  2. Version model with spec rev — track ECOs in model changelog alongside RTL changelog.

  3. Unit-test predict() / package functions before env integration — known vectors from spec appendix.

  4. Model visible behavior only — not internal pipeline stages, credit refill rates, unless plan requires cycle-approximate.

  5. Fidelity level recorded in verification plan — algorithmic, transaction, or cycle-approximate per feature.

  6. Scoreboard pairing strategy documented — FIFO for in-order, ID map for AXI/PCIe out-of-order.

diagram
[CHECK] integration checklist before regression

  □ ref_model.req_imp ◄── dut_mon.ap (not driver)
  □ ref_model.ap ──► scb.exp_imp
  □ dut_mon.ap ──► scb.act_imp (RESPONSE filter in write_act)
  □ predict() unit tests pass with spec vectors
  □ Fidelity assumptions documented in verification plan
  □ check_phase drains unmatched expected on scoreboard
  □ Golden path (if used) is NOT same RTL as DUT

Key takeaways

  • ref_model.ap → scb.exp_imp; dut_mon.ap → scb.act_imp — canonical connect_phase pattern.

  • Prefer independent algorithmic models when spec math is well-defined.

  • Golden VIP saves protocol effort but risks circular verification if golden equals DUT.

  • Document every model assumption — undocumented defaults become debug time sinks.

Common pitfalls

  • Cycle-accurate model mirroring RTL in scoreboard path — maintenance nightmare, no extra value.

  • No model on data-path — scoreboard counts transactions but never compares payload values.

  • Golden agent instantiated from same RTL as DUT — correlated bugs pass both paths.

  • Connecting ref_model.ap to act_imp — expected and actual streams collide.