A scoreboard is the part of a testbench that decides whether the DUT was right. Everything else (sequences, drivers, monitors) exists to give it something to judge. This topic builds that judgement around the course's DMA bench, starting from dma_scoreboard and ending with the end-of-test audit that stops a test passing with work still owed.
Say where each side of a compare must come from, and why expected is built from observed input, never from the sequence.
Receive several streams in one scoreboard with uvm_analysis_imp_decl, and keep its write_* methods overridable.
Wire block scoreboards and an end-to-end checker into an env without reaching inside agents.
Choose in-order matching or a queue per ID, and defend the choice for AXI.
Account for traffic that is legally dropped, reordered, split or merged, and tell a lost item from a late one.
List what must be empty before a test passes, and put each check in the right phase.
Read a failing scoreboard's numbers and know which layer to open first.
Lesson | What it covers |
|---|---|
The scoreboard data flow: predict from observed inputs, compare against the observed output. The KEY write that fooled the model. | |
| |
| |
One expected queue, four outcomes, and choosing which fields the compare covers. | |
AXI-style responses: a queue per ID, repeated IDs, separate ID spaces. | |
What each failure pattern means, the XOR trick, and cascades after one lost word. | |
Drops, reorders, splits, merges, multicast, and latency checks that separate lost from late. | |
The checklist, check_phase versus phase_ready_to_end versus report_phase, and documented waivers. |