AMBA AXI · Module 20

AXI Verification Checklist

A sign-off checklist for AXI protocol and functional verification — assertions for compliance, a monitor reconstructing transactions, a scoreboard for correctness against a reference, coverage closure, negative/error testing, and the self-verification of the checks themselves, confirmed before declaring an AXI block verified.

The design checklist (20.1) confirmed the RTL is built right; this one confirms it's proven right. The AXI verification checklist is the sign-off list you run before declaring a block verified — the concrete items that confirm the protocol compliance, functional correctness, coverage, and negative testing are all in place and passing. It operationalizes Module 16's layered model into a checklist, so "we verified it" means "we confirmed each verification item," not "the tests passed once." This chapter organizes the verification sign-off into categories — compliance (assertions), correctness (scoreboard), coverage, negative testing, and meta-verification (verifying the checks themselves) — each a small set of must-confirm items forming a repeatable verification sign-off pass.

1. Compliance: Assertions Present and Active

The first category confirms protocol compliance is checked. Confirm: a complete assertion set is bound to the interface (16.2), covering the handshake rules (VALID-stable-until-READY, VALID-not-on-READY/liveness), payload stability ($stable on every field while VALID held), and structural/encoding rules (legal BURST/SIZE/WRAP-length, reset behavior); and that the assertions are active during the run (not disabled, disable iff (!aresetn) correct). The check is twofold: the assertion set is complete (derived from the categorized rule catalog, one per rule per channel) and enabled (actually running and catching violations). Compliance assertions are the foundation — they prove the traffic is legal AXI.

Figure 1 — the compliance checklist: assertions present and active. Confirm a complete assertion set is bound (16.2) to the interface covering the handshake rules (VALID stable until READY, VALID-not-on-READY/liveness), payload stability ($stable per field while VALID held), and structural/encoding rules (legal BURST/SIZE/WRAP-length, reset). And confirm they're active during the run (enabled, disable-iff-reset correct). The check is twofold: complete (catalog-derived, one per rule per channel) and enabled (actually running). Compliance assertions prove the traffic is legal AXI.

2. Correctness: Monitor and Scoreboard

The second category confirms functional correctness is checked — because compliance isn't correctness (a compliant block can return wrong data). Confirm: a passive monitor reconstructs transactions from beats, matched by ID (16.3); a scoreboard checks the reconstructed transactions against an independent reference model (16.4) — data integrity (write-then-read, WSTRB-aware), per-ID ordering (same-ID in order, different-ID free), correct response codes, and end-of-test checks (no dropped transactions); and the reference model is spec-derived (not from the DUT). The check confirms the scoreboard exists, is fed by a verified monitor, and judges correctness against intent — turning "legal" into "correct."

Figure 2 — the correctness checklist: monitor and scoreboard. Confirm a passive monitor reconstructs transactions from beats by ID (16.3); a scoreboard checks them against an independent, spec-derived reference model (16.4) — data integrity (write-then-read, WSTRB-aware), per-ID ordering (same-ID in order, different-ID free), correct response codes, and end-of-test no-dropped-transaction checks. Compliance isn't correctness — a legal block can return wrong data — so the scoreboard against intent is what turns 'legal' into 'correct.' Confirm the monitor is itself verified, since the scoreboard trusts it.

3. Coverage and Negative Testing

The third category confirms completeness and error handling. Coverage (16.5): confirm functional coverage is defined (burst type/length/size, IDs, responses, WSTRB, timing/corners), crosses for the combinations that matter, illegal/unreachable bins excluded, and coverage closed (every meaningful bin hit or justified) — because a clean check run on unexercised traffic proves nothing. Negative testing (16.7): confirm error responses are provoked (SLVERR/DECERR) and the reference model predicts them, errors are injected (faulting slave, dropped responses) and the DUT's recovery is verified (state preserved, bus continues), and illegal traffic is driven in isolation to confirm the checker fires. Coverage proves the scenarios were exercised; negative testing proves error handling works.

Figure 3 — the coverage and negative-testing checklist. Coverage (16.5): functional coverpoints (burst/ID/response/WSTRB/timing) and crosses defined, illegal bins excluded, and coverage closed (every meaningful bin hit or justified) — a clean run on unexercised traffic proves nothing. Negative testing (16.7): error responses provoked (SLVERR/DECERR) and predicted by the model, errors injected (faulting slave, dropped responses) with recovery verified (state preserved, bus continues), and isolated illegal traffic confirming the checker fires. Coverage proves the scenarios occurred; negative testing proves error handling works.

4. Meta-Verification and Sign-Off

The final category is the one most often skipped: verifying the checks themselves. Confirm: the assertions are non-vacuous (cover property on antecedents — each assertion was actually exercised, not vacuously passing) and sound (injected violations confirm each fires — 16.2); the monitor is verified against known traffic (the scoreboard trusts it, so a monitor bug masquerades as a DUT failure — 16.3); and the coverage model is complete (mapped to the rule catalog and the spec, not just a number). The sign-off is then: assertions complete/active/non-vacuous, scoreboard passing with an independent model, coverage closed, negative tests passing, and the checks themselves verified. Only then is the block genuinely verified — not just "the tests passed."

Figure 4 — meta-verification (the often-skipped category) and sign-off. Verify the checks themselves: assertions non-vacuous (cover property on antecedents — actually exercised) and sound (injected violations each fire); the monitor verified against known traffic (the scoreboard trusts it, so a monitor bug looks like a DUT failure); and the coverage model complete (mapped to the rule catalog/spec, not just a number). Sign-off = assertions complete/active/non-vacuous + scoreboard passing with an independent model + coverage closed + negative tests passing + the checks themselves verified. Only then is the block genuinely verified, not just 'tests passed.'

5. Common Misconceptions

Myths to unlearn

"The tests passed, so it's verified." "Verified" means the checklist is satisfied — assertions complete/active/non-vacuous, scoreboard passing against an independent model, coverage closed, negative tests passing, and the checks themselves verified. A passing run with weak/incomplete checks or no coverage closure isn't verification.
"Assertions are enough." Assertions prove compliance (legal traffic), not correctness (right behavior). The checklist requires a scoreboard against an independent reference too — a compliant block can return wrong data, which only the scoreboard catches.
"Coverage is optional / a separate concern." Coverage closure is a required sign-off item — without it, a clean check run proves only that no check fired on the (possibly trivial) traffic exercised, not that the meaningful scenarios were tested. Checks + coverage are both mandatory.
"Negative testing is nice-to-have." Error handling is a required category — provoke SLVERR/DECERR, inject faults, and verify recovery (state preserved, bus continues). A block unverified for errors will fail in the field exactly when something already went wrong.
"You don't verify the checks themselves." The most-skipped item, and a real gap: an assertion that never fires might be vacuous (mis-written, can't fail), and the scoreboard trusts an unverified monitor. Confirm non-vacuity (antecedent coverage), soundness (injected violations), and a verified monitor — or the checks give false confidence.
"A VIP means it's verified." A VIP provides the compliance layer (assertions + coverage); it does not verify your design's functional correctness — you still need your scoreboard and coverage closure. "All VIP checks pass" is a compliance baseline, not sign-off.

6. Debugging Insight

🔍 Debugging insight — a verification gap maps to a missing checklist category

When a bug escapes verification (found late, or in the field), it maps to a skipped checklist category — diagnosing which tells you what to add:

A protocol violation escaped. A missing or vacuous assertion — the compliance category. Add the assertion (catalog-derived) and confirm it's non-vacuous (antecedent coverage) and sound (injected violation fires).
Wrong-but-legal data escaped. No scoreboard check for it, or the reference model was wrong/DUT-derived — the correctness category. Add/fix the scoreboard against an independent model.
A corner case was never tested. A coverage hole — the completeness category. Add the coverpoint, close the coverage (refine stimulus to hit it), so the gap is visible and filled.
An error scenario failed in the field. No negative test for it — the error-handling category. Provoke/inject the error and verify recovery.
The scoreboard reported false failures (or missed real ones). The monitor wasn't verified — meta-verification. Validate the monitor against known traffic first.
An assertion "passed" but the scenario never occurred. A vacuous assertion — meta-verification. Add antecedent coverage to confirm each assertion is exercised.

The value: an escaped bug is evidence of a missing checklist item, so the post-mortem fix is to add the item (and the corresponding check) so that class of bug can't escape again — the checklist grows from escapes (bug-driven verification). A complete checklist is one where every escape has been converted into a new sign-off item, closing that gap permanently.

7. Verification Insight

✅ Sign-off insight — 'verified' means the checklist is satisfied, including verifying the checks themselves

The AXI verification checklist operationalizes Module 16 into a sign-off pass, and its core message is that "verified" is a defined state, not a feeling — it means the checklist is satisfied across all categories, not that the tests happened to pass. The categories: compliance (a complete, active, catalog-derived assertion set proving legal traffic — 16.2), correctness (a scoreboard against an independent, spec-derived reference proving the design does the right thing, fed by a verified monitor — 16.3/16.4), coverage (functional coverage defined and closed, so the meaningful scenarios were exercised — 16.5), negative testing (errors provoked and injected, recovery verified — 16.7), and the often-skipped meta-verification (the checks themselves verified: assertions non-vacuous and sound, the monitor verified, the coverage model complete). Three principles: (1) Compliance ≠ correctness ≠ completeness — you need all three (assertions for legal, scoreboard for right, coverage for exercised), and the checklist requires each separately because each catches a class the others can't. (2) Verify the checks themselves — the most-skipped and most-dangerous gap: an unverified monitor makes every scoreboard verdict suspect, a vacuous assertion gives false confidence, and an incomplete coverage model hides untested behavior, so the checklist explicitly includes meta-verification (antecedent coverage, injected violations, monitor validation, catalog-mapped coverage). (3) The checklist grows from escapes — every bug that escapes verification is evidence of a missing item, so the post-mortem adds the item and the check, making the checklist a living artifact that closes gaps permanently (bug-driven verification). The deeper point, echoing the design checklist (20.1): verification, like design, must be operationalized — "we tested it" is unreliable without a systematic sign-off confirming the checks are complete, correct, exercised, and themselves verified. A block that passes this checklist — compliance proven, correctness judged against an independent model, coverage closed, errors handled, and the checks validated — is genuinely verified in the sense that matters: not "the tests passed," but "we have systematic evidence the design is correct and we'd catch it if it weren't." That distinction — between a passing run and a satisfied checklist — is what separates real verification sign-off from false confidence, and it's why the closing module makes verification a checklist. Next, the integration checklist applies the same operationalization to wiring AXI into a system.

8. Interview Questions

9. Summary

The AXI verification checklist operationalizes Module 16 into a sign-off pass, encoding that "verified" is a defined state, not a feeling — the checklist satisfied across all categories, not just "the tests passed." Five categories: compliance (a complete, active, catalog-derived assertion set proving legal traffic — 16.2); correctness (a passive monitor reconstructing transactions and a scoreboard checking them against an independent, spec-derived reference — data integrity, per-ID ordering, responses, end-of-test no-dropped checks — 16.3/16.4); coverage (functional coverpoints and crosses defined, illegal bins excluded, and closed — 16.5); negative testing (errors provoked and predicted, faults injected with recovery verified — 16.7); and the often-skipped meta-verification (the checks themselves verified: assertions non-vacuous via antecedent coverage and sound via injected violations, the monitor verified, the coverage model complete).

The disciplines: compliance ≠ correctness ≠ completeness (all three required, each catching a class the others can't); verify the checks themselves (the most-skipped, most-dangerous gap — an unverified monitor makes every verdict suspect, a vacuous assertion gives false confidence); and the checklist grows from escapes (every escaped bug is a missing item → add the check and the gate, bug-driven verification). The meta-lesson, echoing the design checklist: verification must be operationalized — "we tested it" is unreliable without systematic evidence the checks are complete, correct, exercised, and themselves verified, and confidence is only as good as the checks that produce it. A block that passes this checklist has systematic, self-validated evidence it's correct — the genuine meaning of verified, distinct from a passing-but-hollow run. Next, the integration checklist applies the same operationalization to wiring AXI into a system.

10. What Comes Next

You can now sign off verification; next, signing off integration:

20.3 — AXI Integration Checklist (coming next) — the sign-off list for wiring AXI into an interconnect/SoC: address map, clocks/resets, interrupts, the data path, and the bring-up that integration requires.

Previous: 20.1 — AXI Design Checklist. Related: 16.1 — The Protocol-Checker Mindset for the catalog the assertions derive from, 16.4 — AXI Scoreboards for the correctness layer, and 16.5 — AXI Functional Coverage for coverage closure.