AMBA AXI · Module 20

AXI Design Checklist

A practical sign-off checklist for an AXI RTL block before review — the handshake rules, payload stability, burst/LAST correctness, WSTRB, response and ID handling, reset behavior, and the structural and timing concerns to confirm before declaring an AXI design done, organized into a repeatable pre-review pass.

The final module distills the whole curriculum into actionable checklists — the sign-off lists you actually run before review, interview, or tape-out. This first one is the AXI design checklist: the concrete items to confirm in an AXI RTL block before you declare it done and hand it to review. A checklist isn't a substitute for understanding (the prior modules built that) — it's the operationalization of understanding, so the things you know not to do are systematically verified rather than left to memory. This chapter organizes the design sign-off into categories — handshake, payload, burst/transaction, structural, and reset/timing — each a small set of must-confirm items, forming a repeatable pre-review pass that catches the classic RTL mistakes before someone else does.

1. Why a Checklist: Operationalizing Understanding

You've learned why AXI works the way it does; a checklist ensures you apply it every time. Under deadline pressure, even experienced engineers forget an item — a missed reset, a VALID gated on READY, an unhandled corner — and a checklist makes the review systematic: every block gets the same pass, so nothing slips through memory's gaps. The design checklist's job is to catch the classic RTL mistakes before review or simulation does, turning "I think it's right" into "I confirmed each item." It's the difference between relying on recall and relying on a process.

Figure 1 — why a design checklist: operationalizing understanding. The prior modules built the understanding (why AXI works as it does); the checklist ensures it's applied every time, systematically. Under deadline pressure, memory gaps let classic mistakes slip (a missed reset, VALID-on-READY, an unhandled corner); a checklist makes every block get the same pass, turning 'I think it's right' into 'I confirmed each item.' It's a process replacing reliance on recall — not a substitute for understanding, but its operationalization.

2. Handshake and Payload Stability

The first checklist category is the handshake and payload — the per-cycle protocol rules. Confirm: VALID never depends combinationally on READY (the deadlock rule — the single most important item); VALID stays asserted once raised until the handshake completes (never dropped before acceptance); payload is stable while VALID is held and not yet accepted (address, data, strobes, resp, last, id — none change mid-handshake); and READY may depend on VALID (legal) but is driven cleanly. These are the rules an assertion set checks (16.2), confirmed here at design time: a quick scan that VALID/payload come from registered or independent logic, not gated by the incoming READY.

Figure 2 — the handshake and payload-stability checklist items. Confirm: VALID never depends combinationally on READY (the deadlock rule, the most important item); VALID stays asserted until the handshake completes (not dropped before acceptance); payload stable while VALID held and unaccepted (address/data/strobes/resp/last/id unchanged mid-handshake); READY may depend on VALID (legal). These are the per-cycle protocol rules the assertion set (16.2) checks — confirmed at design time by scanning that VALID/payload are driven independently of incoming READY.

3. Burst, Transaction, and Encoding

The second category is burst and transaction correctness. Confirm: WLAST/RLAST on exactly the last beat (beat LEN, agreeing with the count); one B per write burst (aggregated, after the last beat); WSTRB honored byte-by-byte (write only strobed bytes, preserve neighbors); per-beat address generation correct for the burst type (INCR/WRAP/FIXED); no 4 KB-crossing bursts; legal encodings (no reserved AxBURST, AxSIZE ≤ bus width, legal WRAP lengths); response codes correct (OKAY/SLVERR/DECERR); and ID handling — same-ID in order, BID/RID match the request. These are the transaction-level rules the monitor/scoreboard check (16.3/16.4), confirmed at design time against the burst-handling logic.

Figure 3 — the burst, transaction, and encoding checklist items. Confirm: LAST on exactly the last beat (= count = LEN); one aggregated B per write burst; WSTRB honored byte-by-byte (neighbors preserved); per-beat address generation correct per burst type; no 4 KB-crossing bursts; legal encodings (no reserved BURST, SIZE ≤ bus, legal WRAP lengths); correct response codes; and ID handling (same-ID order, BID/RID match). These transaction-level rules (checked by monitor/scoreboard, 16.3/16.4) are confirmed at design time against the burst-handling logic.

4. Structural, Reset, and Timing

The final category is structural, reset, and timing. Confirm: reset behavior — all VALIDs low during reset, registers initialized to reset values, clean exit from reset; channel independence — reads and writes (and address/data) proceed independently, no illegal coupling; outstanding/buffering sized correctly (no deadlock from undersized response paths, 15.7); CDC — any clock-domain crossing uses a proper async-FIFO bridge (14.2); width/parameters — derived values computed not passed (STRB_W = DATA_W/8), elaboration assertions for legal configs; and timing — VALID/READY paths registered where needed (skid buffers, 15.5) so the design closes timing. These structural items are where integration and timing bugs originate, confirmed before the block leaves your hands.

Figure 4 — the structural, reset, and timing checklist items. Confirm: reset behavior (VALIDs low during reset, registers initialized, clean exit); channel independence (reads/writes independent, no illegal coupling); outstanding/buffering sized to avoid deadlock (15.7); CDC via proper async-FIFO bridges (14.2); width/parameters (derived values computed, elaboration assertions for legal configs); and timing (VALID/READY paths registered via skid buffers where needed, 15.5). These structural items are where integration and timing bugs originate — confirmed before the block leaves your hands.

5. Common Misconceptions

Myths to unlearn

"A checklist replaces understanding." It operationalizes understanding, not replaces it — you need to know why each item matters (the prior modules) to apply it correctly and catch variations. The checklist ensures the understanding is applied systematically, every time, without relying on memory under pressure.
"If it simulates, it passed the checklist." The checklist catches things before and beyond simulation — structural issues (channel independence, parameter derivation), timing (registered paths), CDC, and reset behavior that a passing functional sim might not exercise. Run the checklist regardless of sim results.
"The handshake item is just one of many." The VALID-not-on-READY item is the single most important — it's the deadlock rule, the most common fatal RTL bug. Check it first and explicitly; the others matter, but this one ends the design if wrong.
"Reset behavior is trivial." Reset is a frequent bug source — VALIDs must be low during reset, registers initialized to reset values, and the exit clean. A block that comes out of reset in an undefined state fails in the system even if it simulates fine from a clean state.
"Burst correctness is only about LAST." It's WLAST/RLAST timing and one-B-per-burst, WSTRB byte handling, per-beat addressing, no 4 KB crossing, legal encodings, and ID handling — a whole category. LAST is one item among the burst/transaction set.
"The checklist is a one-time thing." Run it before every review (and re-run after changes), because edits reintroduce bugs — a refactor can re-add a VALID-on-READY path or break reset. The checklist is a repeatable pre-review pass, not a one-time gate.

6. Debugging Insight

🔍 Debugging insight — a failed review item maps to a checklist category and a curriculum module

When a review (or the checklist itself) flags a problem, the category localizes the fix and points to the module that explains it:

Handshake/deadlock issue. A VALID-on-READY path or a dropped VALID — the handshake category (Module 3, 17.1). Fix: drive VALID/payload independently of READY, hold until accepted.
Payload changed mid-handshake. The stability item — a register feeding the payload updates on the clock instead of the handshake (17.x). Fix: gate the payload register on the handshake.
Burst ends wrong (LAST/count/one-B). The burst/transaction category (7, 17.2/17.3). Fix: LAST on beat LEN, one aggregated B, correct per-beat addressing.
Data corruption (WSTRB). The WSTRB item — byte-strobe handling wrong (6.7, 17.4). Fix: write only strobed bytes, preserve neighbors.
Undefined state at startup. The reset item — VALIDs not low during reset or registers uninitialized (14.3). Fix: proper reset wiring and initialization.
Timing failure on a READY/VALID path. The timing item — an unregistered combinational handshake path (15.5). Fix: insert a skid buffer at the offending boundary.

The value: the checklist categories map one-to-one onto the curriculum modules and the bug taxonomies (Module 17), so a flagged item both tells you the fix and points to the chapter that explains why — the checklist is the operational index into the whole curriculum. A design that passes every category item is a design where the classic mistakes have been systematically excluded.

7. Verification Insight

✅ Sign-off insight — run the categorized checklist before every review, as the operational index into the curriculum

The AXI design checklist is the operationalization of everything the curriculum taught: it turns understanding into a repeatable pre-review pass that systematically confirms the classic RTL mistakes have been excluded, so nothing slips through memory's gaps under deadline pressure. It's organized into categories that map onto the curriculum: handshake/payload (Module 3 — VALID-not-on-READY as the top item, VALID held until accepted, payload stable), burst/transaction/encoding (Modules 6–9 — LAST timing, one B per burst, WSTRB, per-beat addressing, no 4 KB cross, legal encodings, responses, IDs), and structural/reset/timing (Modules 14–15 — reset behavior, channel independence, outstanding sizing, CDC bridges, parameter derivation, registered timing paths). Three disciplines make it effective: (1) Run it before every review and after every change — edits reintroduce bugs (a refactor can re-add a VALID-on-READY path or break reset), so the checklist is a repeatable gate, not a one-time pass. (2) Check the highest-impact items explicitly — the VALID-not-on-READY deadlock rule and reset behavior are the most common fatal mistakes, so confirm them deliberately, not in passing. (3) Treat the checklist as an index into the curriculum — each item maps to a module that explains why it matters and to a bug taxonomy (Module 17) for how it fails, so the checklist isn't rote: a flagged item points you to the understanding behind it. The checklist embodies the meta-lesson of the closing module: understanding must be operationalized to be reliable — knowing the AXI rules isn't enough if you don't systematically apply them, and a checklist is how expert knowledge becomes consistent practice. It's also how design quality scales: a team with a shared checklist produces uniformly correct AXI blocks regardless of who wrote them, because the checklist encodes the collective understanding. A design that passes this checklist — handshake, payload, burst/transaction, structural, reset, timing all confirmed — is one where the classic AXI mistakes have been excluded by process, which is exactly what review and sign-off require. Next, the verification checklist applies the same operationalization to proving an AXI design correct.

8. Interview Questions

9. Summary

The AXI design checklist operationalizes the curriculum's understanding into a repeatable pre-review pass that systematically confirms the classic RTL mistakes have been excluded — turning "I think it's right" into "I confirmed each item," so nothing slips through memory's gaps under deadline pressure. It's organized into three categories mapping onto the curriculum. Handshake/payload (Module 3): VALID never depends combinationally on READY (the deadlock rule — the single most important item), VALID held until accepted, payload stable while VALID is held, READY may legally depend on VALID. Burst/transaction/encoding (Modules 6–9): WLAST/RLAST on exactly beat LEN, one aggregated B per write burst, WSTRB byte-by-byte (neighbors preserved), per-beat addressing per burst type, no 4 KB crossing, legal encodings, correct responses, and ID handling. Structural/reset/timing (Modules 14–15): reset behavior (VALIDs low, registers initialized, clean exit), channel independence, deadlock-free outstanding/buffer sizing, CDC bridges, derived parameters with elaboration assertions, and registered timing paths.

The disciplines: run it before every review and after every change (edits reintroduce bugs — it's a repeatable gate, not a one-time pass); check the highest-impact items explicitly (VALID-not-on-READY and reset behavior are the most common fatal mistakes); and treat it as an index into the curriculum (each item maps to the module explaining why and the bug taxonomy in Module 17 for how it fails). A checklist is the right tool because AXI correctness is a many-independent-items problem prone to omission under pressure — it makes you consistent, not smarter, and scales quality across a team — with the limits that it operationalizes (not replaces) understanding, covers known not novel mistakes, complements verification, and demands honest checking. This is why the curriculum ends with checklists: they're the operational layer atop the understanding it built. Next, the verification checklist applies the same operationalization to proving an AXI design correct.

10. What Comes Next

You can now sign off a design; next, signing off its verification:

20.2 — AXI Verification Checklist (coming next) — the sign-off list for AXI protocol and functional verification: assertions, monitor, scoreboard, coverage, and negative testing, confirmed before declaring a block verified.

Previous: 19.7 — Debug & Trace Path. Related: 3.5 — Handshake Dependency & Deadlock Rules for the top handshake item, 16.2 — AXI Assertions (SVA) for the runtime checks of the same rules, and 15.1 — A Simple AXI4-Lite Slave for a design to run the checklist against.