UVM / design verification

UVM Scoreboard Guide

A scoreboard answers the core end-to-end verification question: did the DUT produce the result the specification predicts? Good scoreboards are intentionally separate from drivers and timing details. They consume observed transactions, model expected behavior and report useful mismatches without becoming another copy of the RTL.

Core design rules

• Observe DUT behavior through monitors; the scoreboard should not peek into internal DUT state unless the verification plan explicitly requires it.
• Keep prediction/reference-model logic conceptually independent from the DUT implementation.
• Match transactions by ordering, ID, address or another architectural key appropriate to the protocol.
• Report expected and actual values plus enough context to reproduce the failure.

Implementation path

• Start with one analysis implementation and an in-order queue of expected results.
• Add separate input/output monitor streams when the DUT transforms transactions.
• Handle reset by clearing or invalidating outstanding expected transactions according to the specification.
• Add counters for compared, passed, failed and outstanding transactions so regressions are easy to audit.

Verification checklist

• Inject one deliberate DUT or testbench error and confirm the scoreboard produces a useful failure.
• Check reset while transactions are pending.
• Stress back-to-back traffic to ensure the checker is not accidentally relying on idle cycles.
• Use functional coverage alongside the scoreboard; passing comparisons alone do not prove the input space was exercised.

Useful RTL / verification pattern

function void write(txn t);
  expected = predict(t);
  // Compare later against the observed output transaction.
endfunction

Practice with executable problems

Turn it into a project