Fidelity Decision Matrix

Four fidelity levels

Fidelity describes how much of the real system's behavior the reference model reproduces. Higher fidelity costs more development time, runs slower, and couples more tightly to implementation details. The goal is the minimum fidelity that catches the bugs in your verification plan — not the maximum fidelity the block could support.

[CHECK] fidelity decision matrix

  Level              Models                    Cost      Example blocks
  ────────────────────────────────────────────────────────────────────────
  Algorithmic        Transform result only     Low       CRC, AES, checksum,
                     (no time, no state)                 hash, parity

  Transaction-level  Protocol + memory state   Medium    APB slave, SRAM,
                     (no cycle delays)                   AXI reg file, DMA desc

  Cycle-approximate  Credits, latency, QoS      High      QoS arbiter, PCIe
                     (event counters, not pins)          retry, token bucket

  Cycle-accurate     Pin timing, clock edges   V.High    Rarely for scoreboard;
                                                         timing VIP / formal

[UVM] fidelity vs simulation cost

  Algorithmic:        write() completes in 0 time — no events scheduled
  Transaction-level:  write() completes in 0 time — associative array lookup
  Cycle-approximate:  may schedule delayed responses via fork/join or
                      uvm_tlm_time — still far cheaper than RTL
  Cycle-accurate:     competes with DUT sim speed — avoid in scoreboard path

When each level is the right choice

• Algorithmic — verification plan checks computed values only (CRC match, encrypted payload, checksum). No ordering, latency, or protocol state beyond the transform itself.

• Transaction-level — plan checks bus-visible data, memory contents, and response codes. Latency and credit behavior are out of scope or checked elsewhere.

• Cycle-approximate — plan includes features like 'response delayed until credit available' or 'low-priority traffic starved under load'. Model credits and scheduling rules, not gate-level timing.

• Cycle-accurate — pin-level setup/hold, clock-domain crossing metastability, or cycle-exact protocol state machines. Use dedicated VIP or formal, not scoreboard expected generation.

Escalation criteria

Start at the lowest fidelity. Escalate only when regression misses real bugs that higher fidelity would catch. Document the escalation decision in the verification plan so the team agrees on the tradeoff.

[CHECK] escalation decision tree

  Start: algorithmic or transaction-level (whichever fits the plan)

  Q: Did we miss bugs involving only data values or transaction ordering?
     → Stay at current level; fix the model logic, not the fidelity.

  Q: Did we miss bugs involving visible latency, credits, or QoS priority?
     → Escalate to cycle-approximate for those features only.

  Q: Did we miss bugs involving pin setup/hold or cycle-exact handshake?
     → Add dedicated timing check — do NOT mirror full RTL in scoreboard model.

  NEVER escalate because 'the RTL is complicated' — complexity ≠ fidelity need.

Worked example: Ethernet MAC CRC

CRC checking is purely algorithmic. The verification plan says: 'computed CRC on transmitted frame matches spec polynomial.' No latency, no credits — algorithmic model with crc32_spec() is sufficient. Escalating to transaction-level adds nothing unless the plan also checks frame ordering or inter-frame gap timing.

Worked example: QoS arbiter

Plan feature: 'high-priority traffic must not be delayed more than N cycles when credits are available.' Transaction-level model that returns data immediately cannot catch credit-starvation bugs. Escalate to cycle-approximate: model credit counters and priority scheduling rules from the spec, schedule delayed responses when credits are exhausted.

QoS model (cycle-approximate sketch):
  credits[port] -= 1 on grant
  credits[port] += refill_rate each event
  if (credits[port] == 0) schedule response after credit_refill_delay
  else respond immediately with spec data

Key takeaways

• Match fidelity to verification plan features — not to RTL complexity.

• Escalate on missed-bug evidence, not on designer intuition.

• Cycle-accurate models belong outside the scoreboard expected path.

Common pitfalls

• Building cycle-accurate model 'because the block is hard' — maintenance nightmare with no extra bug detection.

• Staying algorithmic when the plan checks credit contracts — silent pass on latency bugs.

• Mixing fidelity levels in one model without documenting which features use which — debug confusion.