AMBA AXI · Module 16

AXI Scoreboards

Build an AXI scoreboard that checks data integrity and ordering by comparing the monitor's reconstructed transactions against a reference model — a memory model for write/read data, per-ID expected-response queues for ordering, and the predict-then-compare loop that turns protocol-legal traffic into a verdict on functional correctness.

Assertions prove the traffic is legal; the scoreboard proves the design does the right thing. Fed by the monitor's reconstructed transactions (16.3), a scoreboard maintains a reference model of expected behavior — most often a memory model — and for every transaction it predicts the correct result and compares it against what the DUT actually did. This is where data integrity (does a read return what was last written?) and ordering (do same-ID responses come back in order?) are actually checked — the compliance-vs-correctness split the mindset chapter (16.1) insisted on. This chapter builds the scoreboard: the predict-then-compare loop, the memory reference model, per-ID expected-response queues for ordering, and the end-of-test checks that catch the transactions that never completed.

1. Predict, Then Compare

A scoreboard's core is a two-step loop driven by the monitor's analysis export: predict the expected outcome of each transaction from a reference model, then compare the DUT's actual outcome against the prediction, flagging any mismatch. For a memory-mapped slave the reference is a model of memory: a write updates the model; a read is predicted by reading the model and compared against the returned data.

Figure 1 — the scoreboard's predict-then-compare loop. The monitor broadcasts reconstructed transactions to the scoreboard's analysis export. For each, the scoreboard consults its reference model to predict the expected result (write → update model; read → expected data from model), then compares the DUT's actual result against the prediction, producing pass or a flagged mismatch. The reference model is the scoreboard's notion of correct behavior.

2. The Memory Reference Model and Data-Integrity Check

For a memory or register slave, the reference model is an associative array indexed by address. A write transaction updates the model byte-by-byte under WSTRB (so the model mirrors the slave's strobe behavior); a read transaction is checked by comparing each returned beat against the model's current contents at that beat's address.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

class axi_scoreboard extends uvm_component;
  byte mem [axi_addr_t];                         // reference memory model
 
  // Write: update the model exactly as the slave should (WSTRB-masked)
  function void on_write(axi_txn t);
    axi_addr_t a = t.addr;
    foreach (t.data[beat]) begin
      for (int b = 0; b < BYTES; b++)
        if (t.strb[beat][b]) mem[a + beat*BYTES + b] = t.data[beat][b*8 +: 8];
    end
  endfunction
 
  // Read: predict from the model, compare against the DUT's returned data
  function void on_read(axi_txn t);
    axi_addr_t a = t.addr;
    foreach (t.data[beat]) begin
      for (int b = 0; b < BYTES; b++) begin
        byte exp = mem.exists(a + beat*BYTES + b) ? mem[a + beat*BYTES + b] : 8'hXX;
        byte got = t.data[beat][b*8 +: 8];
        if (mem.exists(a + beat*BYTES + b) && exp !== got)
          `uvm_error("SB", $sformatf("Read mismatch @%0h: exp %0h got %0h",
                                     a+beat*BYTES+b, exp, got))
      end
    end
  endfunction
endclass

The byte-level, WSTRB-aware update is what makes the data-integrity check trustworthy: a read after a partial-word write must return the merged result, and the model only gets that right if it applies strobes exactly as the slave does.

Figure 2 — data integrity via the memory model. A write transaction updates the reference memory byte-by-byte under WSTRB (mirroring the slave). A later read to overlapping addresses is predicted from the model and compared against the DUT's returned beats. A write-then-read to the same address is the canonical data-integrity check; matching means the slave stored and returned the data correctly.

3. Ordering Checks with Per-ID Queues

Data integrity is only half the job; the scoreboard also checks ordering. AXI's rule is that responses for the same ID must return in the order their requests were issued, while different IDs may complete in any order. The scoreboard models this with per-ID queues: when a request is observed it's pushed onto that ID's expected queue; when a response arrives it must match the head of the corresponding ID's queue (in-order), but no ordering is enforced across different IDs.

Figure 3 — ordering via per-ID expected queues. Each transaction ID has its own FIFO of outstanding requests. A response must match the head of its ID's queue — enforcing same-ID in-order completion — while different IDs' queues are independent, allowing different-ID responses in any order. A response that doesn't match its ID's head (or matches the wrong ID) is an ordering violation.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Per-ID expected-response queues
axi_txn exp_q [int][$];                  // exp_q[id] is a queue of outstanding txns
 
function void on_request(axi_txn t);     // push when request observed
  exp_q[t.id].push_back(t);
endfunction
 
function void on_response(axi_txn r);    // must match head of its ID's queue
  if (exp_q[r.id].size() == 0)
    `uvm_error("SB", $sformatf("Response for id %0d with no outstanding request", r.id))
  else begin
    axi_txn expected = exp_q[r.id].pop_front();   // in-order within ID
    if (r.addr !== expected.addr)
      `uvm_error("SB", $sformatf("Out-of-order/mismatched response for id %0d", r.id))
  end
endfunction

4. End-of-Test Checks: The Transactions That Never Came

A scoreboard must also check what didn't happen. At end of test, any non-empty per-ID queue means a request was issued but never got its response — a dropped or hung transaction the per-transaction checks can't catch (they only fire when a response arrives). The check_phase sweeps every queue and errors on leftovers.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

function void check_phase(uvm_phase phase);
  foreach (exp_q[id])
    if (exp_q[id].size() != 0)
      `uvm_error("SB", $sformatf("%0d transactions for id %0d never completed",
                                 exp_q[id].size(), id))
endfunction

Figure 4 — end-of-test completeness check. During the run, per-ID queues fill on requests and drain on responses. At check_phase, any queue that is not empty represents a transaction that was issued but never completed — a dropped or hung response. This catches the failure mode that per-transaction comparison cannot, because a missing response simply never triggers a compare. A clean scoreboard ends with every queue empty.

5. Common Misconceptions

Myths to unlearn

"A protocol checker already verifies the data." No — assertions verify legality (handshake, stability, encoding), not correctness. A slave can return perfectly legal but wrong data; only a scoreboard comparing against a reference catches that. Compliance ≠ correctness.
"The reference model can ignore WSTRB." It must apply byte strobes exactly as the slave does, or a read after a partial-word write will mismatch the model even when the slave is correct. The model has to mirror the slave's byte-level semantics.
"Checking each response is enough." Per-response checks only fire when a response arrives — they can't catch a response that never comes. The end-of-test sweep of non-empty per-ID queues is what catches dropped/hung transactions, and omitting it leaves a major failure mode unchecked.
"Enforce a global response order." AXI only requires same-ID in-order completion; different IDs may complete in any order. A scoreboard that enforces global ordering will produce false failures on legal out-of-order different-ID traffic. Model ordering per ID.
"The scoreboard can read the DUT's internal state to predict." The reference model must be independent of the DUT — derived from the spec, not the implementation. A model that peeks at design internals can't detect the design's own mistakes; it would agree with the bug.
"A scoreboard replaces coverage." The scoreboard checks correctness when a scenario occurs; coverage measures whether the scenarios occurred. A passing scoreboard on weak stimulus proves little — you need coverage (16.5) to know the interesting cases were exercised.

6. Debugging Insight

🔍 Debugging insight — a scoreboard error names the address, ID, and expected-vs-actual

A well-built scoreboard error is highly specific; read it before suspecting the design:

"Read mismatch @addr: exp X got Y." A data-integrity failure. But first confirm the model is right: was the prior write applied with the correct WSTRB? Is the model byte-indexed correctly? A model bug shows as a mismatch even when the DUT is correct — check the write that should have set that address.
"Out-of-order/mismatched response for id N." An ordering failure — a same-ID response didn't match its queue head. Confirm the monitor reconstructed the IDs correctly (16.3), then look at the DUT's per-ID response ordering.
"Response for id N with no outstanding request." Either the DUT emitted a spurious response, or the monitor missed/mis-IDed the request. Check the request side of the queue first.
"M transactions for id N never completed" (at end). Dropped or hung responses — the DUT didn't respond, or the monitor never saw the response. Cross-check against assertions: a liveness/handshake assertion may have also fired.
False mismatches everywhere. Usually the reference model diverged from the spec (wrong WSTRB handling, wrong address arithmetic, wrong reset value), not the DUT. Validate the model against a trivial directed write-read first.

Because a scoreboard error reports the address/ID and expected-vs-actual, debugging is concrete — but the first discipline is always to rule out the model (and the monitor feeding it) before concluding the DUT is wrong, since a mismatch is symmetric: it only says model and DUT disagree, not which is right.

7. Verification Insight

✅ Verification insight — an independent reference model, per-ID ordering, and end-of-test completeness

The scoreboard is where functional correctness is decided, so its trustworthiness rests on three things. (1) An independent reference model — the model must encode spec behavior, derived independently of the DUT (not from the RTL or by peeking at internals), so it can genuinely disagree with a buggy design; for a memory/register slave it mirrors the byte-level, WSTRB-aware, access-type semantics (RW/RO/W1C from Module 10), and for richer DUTs it's a transaction-level functional model. A common, powerful realization is the UVM register model (RAL), which auto-predicts register semantics. (2) Correct ordering semantics — model AXI ordering as per-ID in-order, cross-ID free using per-ID queues; enforcing global order causes false failures, while ignoring per-ID order misses real reordering bugs. (3) End-of-test completeness — sweep all queues in check_phase so dropped/hung transactions (which per-response checks can't see) are caught; a test that "passes" with outstanding transactions left in the queues is hiding a bug. Beyond these, the scoreboard pairs with the other layers: assertions (16.2) cover the signal-local legality the scoreboard doesn't, the monitor (16.3) must be verified first since the scoreboard trusts its reconstruction, and coverage (16.5) must confirm the data-integrity and ordering scenarios were actually exercised (a scoreboard that never sees a write-then-read to the same address proves nothing about data integrity). The decisive tests are write-then-read to the same address (with every WSTRB pattern) for integrity, interleaved multi-ID traffic with out-of-order completion for ordering, and a deliberately dropped response to confirm the end-of-test check fires. With an independent model, per-ID ordering, and completeness checking — all fed by a verified monitor and complemented by assertions and coverage — the scoreboard turns protocol-legal traffic into a sound verdict on whether the design is actually correct.

8. Interview Questions

9. Summary

An AXI scoreboard decides functional correctness, complementing the assertions that decide compliance. Fed by the monitor's reconstructed transactions, it runs a predict-then-compare loop against an independent reference model: for a memory/register slave, a write updates the model byte-by-byte under WSTRB, and a read is predicted from the model and compared against the DUT's returned data — making write-then-read to the same address the canonical data-integrity check (and requiring the model to mirror the slave's byte-level semantics exactly). Ordering is checked with per-ID queues that enforce AXI's rule — same-ID responses in request order, different-ID responses in any order — where a response must match the head of its ID's queue. End-of-test checks sweep the queues so dropped or hung transactions (which per-response comparison can't see) are caught as leftover entries.

The scoreboard's soundness rests on an independent model (spec-derived, never peeking at the DUT — often a RAL), per-ID ordering semantics (not global), and completeness checking at end of test. It sits in a layered stack: assertions for signal-local legality, the (separately verified) monitor for transaction reconstruction, the scoreboard for correctness/ordering, and coverage to confirm the scenarios were exercised — together answering the four distinct verification questions. A mismatch is symmetric (model and DUT disagree), so debugging always rules out the model first. Next, we measure whether the traffic actually exercised the bursts, IDs, responses, and corners that make these checks meaningful — functional coverage.

10. What Comes Next

You can now judge correctness; next we measure whether the right scenarios were tested:

16.5 — AXI Functional Coverage (coming next) — defining coverage for burst types/lengths, IDs, responses, and protocol corners, so a clean scoreboard run is backed by evidence the interesting cases were exercised.

Previous: 16.3 — AXI Monitors. Related: 8.3 — Same-ID Ordering and 8.4 — Different-ID Ordering for the ordering model the scoreboard enforces, and 10.5 — AXI4-Lite Verification Checklist for the register-model (RAL) reference.