AMBA AXI · Module 20

Common Mistakes Checklist

The recurring AXI mistakes to never make — across design, verification, debugging, integration, and interviews — distilled into one final checklist: the handshake deadlock, compliance-mistaken-for-correctness, the ordering-rule reversal, the unhandled corner, and the confident-wrong answer, with the single principle behind avoiding each.

This is the final chapter, and the most valuable list: the recurring AXI mistakes to never make. Across the whole curriculum — design, verification, debugging, integration, interviews — a small set of mistakes recur far more than any others, and avoiding just these prevents the majority of real AXI failures. This checklist gathers them: the handshake deadlock (VALID waiting on READY), mistaking compliance for correctness, reversing the ordering rule, the unhandled corner case, the unverified checks, the integration glue, and the confident-wrong interview answer. Each has appeared in its module's "misconceptions" callout; here they're consolidated as the one list to internalize. If you remember nothing else from the curriculum, remember not to make these — they're where AXI work most often goes wrong.

1. The Design Mistakes

The recurring design mistakes. #1 — VALID waits for READY (the deadlock rule): gating VALID (or its payload) combinationally on READY — the single most common fatal AXI RTL bug; drive VALID independently and hold it. Coupling reads and writes into one FSM, serializing the independent channels — keep them separate. Ignoring WSTRB byte-by-byte, clobbering neighbors on partial writes. Mis-timing LAST (not on beat LEN) or emitting more than one B per burst. Forgetting reset — VALIDs not low during reset, registers uninitialized. These are the design-checklist (20.1) failures; the deadlock rule is by far the most important — it's the mistake that, made once, hangs the bus.

Figure 1 — the recurring design mistakes. #1: VALID waits for READY (gating VALID/payload combinationally on READY — the single most common fatal RTL bug, deadlocks the bus). Coupling reads and writes into one FSM (serializing independent channels). Ignoring WSTRB byte-by-byte (clobbering neighbors). Mis-timing LAST (not on beat LEN) or emitting more than one B per burst. Forgetting reset (VALIDs not low, registers uninitialized). The deadlock rule is by far the most important — made once, it hangs the bus.

2. The Verification Mistakes

The recurring verification mistakes. Mistaking compliance for correctness — thinking a clean protocol checker means the design is verified; it proves legal traffic, not right behavior (you need a scoreboard). Skipping coverage closure — a clean check run on unexercised traffic proves nothing; confirm the scenarios were hit. Not verifying the checks themselves — trusting an unverified monitor (the scoreboard depends on it) or a vacuous assertion (one that can't fire). Skipping negative testing — never exercising the error paths, which fail in the field. These are the verification-checklist (20.2) failures; the deepest is compliance ≠ correctness, the mistake that lets wrong-but-legal designs pass.

Figure 2 — the recurring verification mistakes. Mistaking compliance for correctness (a clean checker proves legal traffic, not right behavior — need a scoreboard); skipping coverage closure (a clean run on unexercised traffic proves nothing); not verifying the checks themselves (trusting an unverified monitor or a vacuous assertion); skipping negative testing (error paths untested, failing in the field). The deepest is compliance ≠ correctness — the mistake that lets wrong-but-legal designs pass verification.

3. The Debugging and Ordering Mistakes

The recurring debugging and ordering mistakes. Reversing the ordering rule — thinking all responses (or different-ID) must be ordered; only same-ID is ordered, different-ID is free. Debugging the stuck signal instead of the root — a stuck channel's cause is usually elsewhere (the other side, or another channel); trace who-waits-on-whom. Confusing a deadlock with a stall — a deadlock is a permanent cycle with no root, not a long stall; find the cycle. Trusting internal consistency — a wrong LEN/SIZE or crossed ID is internally self-consistent; only comparison against intent catches it. No timeout instrumentation — leaving liveness failures as silent hangs. The waveform shows the canonical mistake: counting a stall as a beat.

The canonical mistake: counting a stall as a beat

7 cycles

Figure 3 — the canonical debugging mistake (and the ordering reversal). Counting a stall as a beat: VALID is held high but READY is low at one cycle (a stall, not a transfer), yet a careless reader counts it — getting the burst length wrong. Only the VALID && READY overlaps are beats. The related ordering mistake is reversing the rule (only same-ID is ordered, different-ID is free). Both stem from not reading the handshake precisely — count beats only at the handshake, and check IDs before judging ordering.

4. The Integration and Interview Mistakes, and the One Principle

The recurring integration mistakes: assuming verified blocks compose correctly (deadlock, starvation, glue emerge at the system level); a wrong address map (overlap, gap, unreachable); a missing CDC bridge across clock domains (intermittent corruption); mis-sequenced reset; no QoS for mixed traffic (starvation). And the recurring interview mistakes: the confident-wrong answer (the worst outcome), stating a myth fluently, rambling, and guessing instead of reasoning when unsure. Behind avoiding all of these is one principle: understand the why, then apply it systematically — the mistakes happen when you act without understanding (state a myth, gate VALID on READY) or understand without systematically applying (forget a corner, skip coverage). Understanding + operationalization is the whole defense.

Figure 4 — the integration and interview mistakes, and the one principle behind avoiding all of them. Integration: assuming verified blocks compose (deadlock/starvation/glue emerge at system level), wrong address map, missing CDC bridge, mis-sequenced reset, no QoS. Interview: confident-wrong answer (worst outcome), stating a myth, rambling, guessing when unsure. The one principle: understand the why, then apply it systematically — mistakes happen when you act without understanding (state a myth, gate VALID on READY) or understand without operationalizing (forget a corner, skip coverage). Understanding + operationalization is the whole defense.

5. Common Misconceptions

The meta-myths about mistakes

"Experienced engineers don't make these mistakes." They do — under deadline pressure, even experts gate a VALID on READY or skip a corner. That's why checklists exist: the mistakes are about omission and pressure, not ignorance, so a systematic process (not expertise alone) prevents them.
"There are too many AXI mistakes to track." A small set recur far more than the rest — the handshake deadlock, compliance-vs-correctness, the ordering reversal, the unhandled corner, the confident-wrong answer. Avoiding just these prevents most real failures; you don't need to track everything.
"The mistakes are unrelated." They share one root: acting without understanding (stating a myth, gating VALID on READY) or understanding without systematically applying (forgetting a corner, skipping coverage). The single defense — understand the why, then operationalize it — addresses all of them.
"Knowing the mistake is enough to avoid it." Knowing isn't avoiding — under pressure you forget. Avoiding requires operationalization: the design/verification/integration checklists and the interview revision, so the known mistakes are systematically excluded rather than left to memory.
"The deadlock rule and the others are equal." The VALID-not-on-READY deadlock rule is the single highest-impact item — it hangs the entire bus, and it's the most-probed interview question and most common fatal RTL bug. If you internalize one item, internalize that one.
"This is just a summary." It's the most actionable chapter — the consolidated list of what actually goes wrong, which is more valuable than any single topic because it's where the curriculum's understanding meets the reality of where engineers fail. Internalize this list and you avoid the majority of AXI failures.

6. Debugging Insight

🔍 Debugging insight — every real AXI failure maps to one of these recurring mistakes

When an AXI failure occurs anywhere in the flow, it almost always maps to one of the recurring mistakes — which is why this list is the master debug index:

Bus hangs. Almost always the deadlock rule (VALID on READY) or a system-level dependency cycle — check the handshake independence and the wait-for graph first.
Wrong-but-legal data/behavior escaped. Compliance mistaken for correctness — there was no scoreboard check against intent. Add the correctness layer.
Crossed/reordered transactions. The ordering-rule reversal or an ID-handling bug — confirm same-ID-ordered/different-ID-free and the ID matching.
Corrupted data, burst looks fine. A trusted-internal-consistency mistake — wrong WSTRB/LEN/SIZE that's self-consistent; only intent comparison catches it.
Works alone, fails in the system. An integration mistake — address map, CDC, reset, or QoS; check the glue and fabric.
Interview went wrong. A confident-wrong answer or a stated myth — the delivery/calibration mistakes.

The pattern: the recurring mistakes are the failure taxonomy — a hang → deadlock rule, wrong-legal-data → compliance≠correctness, reorder → ordering reversal, self-consistent corruption → trusted internal consistency, works-alone-fails-in-system → integration glue, bad interview → confident-wrong. So this checklist doubles as the top-level debug index: identify which recurring mistake the symptom matches, and you've localized the class. Avoiding the mistakes prevents the failures; recognizing them localizes the failures that slip through.

7. Verification Insight

✅ The capstone: internalize the recurring mistakes and the one principle, and the curriculum becomes practice

This final chapter is the curriculum's most actionable distillation: the small set of recurring mistakes that cause the majority of real AXI failures, across design, verification, debugging, integration, and interviews — and the single principle that avoids all of them. The mistakes: design — the VALID-on-READY deadlock (the #1 fatal bug), coupled read/write FSMs, ignored WSTRB, mis-timed LAST/extra B, forgotten reset; verification — compliance mistaken for correctness (the deepest), skipped coverage closure, unverified checks (vacuous assertions, untrusted monitor), skipped negative testing; debugging — the ordering-rule reversal, debugging the stuck signal not the root, deadlock-vs-stall confusion, trusting internal consistency over intent, no timeout instrumentation; integration — assuming verified blocks compose, address-map errors, missing CDC, mis-sequenced reset, no QoS; interview — the confident-wrong answer, stated myths, rambling, guessing instead of reasoning. The one principle behind avoiding every one: understand the why, then apply it systematically. The mistakes split into two failure modes — acting without understanding (stating a myth, gating VALID on READY, conflating compliance with correctness) and understanding without operationalizing (forgetting a corner, skipping coverage, assuming blocks compose) — and the defense is the conjunction: deep understanding (Modules 1–19) so you don't act on misconception, plus systematic operationalization (the checklists, Module 20) so the understanding is applied every time rather than left to memory under pressure. This is the synthesis of the entire curriculum: it built the understanding (why AXI works as it does), and the closing module operationalized it into checklists (so the understanding is reliably applied) — and this chapter names the mistakes that happen when either half is missing. The highest-impact single item remains the deadlock rule (VALID never on READY) — the most common fatal bug and most-probed question — but the meta-lesson is larger: the recurring mistakes are the failure taxonomy, so internalizing this list (and the understand-then-operationalize principle) is internalizing how to avoid the majority of AXI failures and how to localize the ones that slip through. With this, the curriculum's purpose is complete: from the first handshake to this final list, the goal was to build AXI understanding deep enough to use — to design, verify, debug, integrate, and articulate — and the recurring-mistakes checklist is the operational endpoint, the list that turns a course completed into a practice mastered. Remember the why, apply it systematically, never gate VALID on READY, never mistake compliance for correctness, never state a myth confidently — and you will avoid where AXI work most often goes wrong.

8. Interview Questions

9. Summary

The recurring AXI mistakes — a small set that cause the majority of real failures across design, verification, debugging, integration, and interviews — are the curriculum's most actionable distillation. Design: the VALID-on-READY deadlock (the #1 fatal bug — never gate VALID on READY), coupled read/write FSMs, ignored WSTRB, mis-timed LAST/extra B, forgotten reset. Verification: compliance mistaken for correctness (the deepest — a clean checker isn't verification), skipped coverage closure, unverified checks (vacuous assertions, untrusted monitor), skipped negative testing. Debugging: the ordering-rule reversal (only same-ID ordered), debugging the stuck signal not the root, deadlock-vs-stall confusion, trusting internal consistency over intent, no timeout instrumentation. Integration: assuming verified blocks compose, address-map errors, missing CDC, mis-sequenced reset, no QoS. Interview: the confident-wrong answer, stated myths, rambling, guessing instead of reasoning.

The one principle behind avoiding all of them: understand the why, then apply it systematically. The mistakes split into acting without understanding (stating a myth, gating VALID on READY, conflating compliance with correctness) and understanding without operationalizing (forgetting a corner, skipping coverage, assuming blocks compose) — and the defense is the conjunction: deep understanding (Modules 1–19) so you don't act on misconception, plus systematic operationalization (the checklists, Module 20) so it's applied every time. This list doubles as the master debug index (the recurring mistakes are the failure taxonomy — a hang → deadlock rule, wrong-legal-data → compliance≠correctness, reorder → ordering reversal, self-consistent corruption → trusted internal consistency, works-alone-fails → integration glue). The highest-impact single item is the deadlock rule. This is the curriculum's telos made explicit: every module exists to prevent some of these mistakes, and mastery is not making them reliably under pressure — the conjunction of understanding and operationalization. From the first handshake to this final list, the curriculum built AXI understanding deep enough to use and operationalized it reliably enough to apply: that is mastery, and this checklist is its actionable endpoint.

10. The Curriculum, Complete

This is the final chapter of the AXI curriculum — 20 modules from the first VALID/READY handshake through the full protocol, interconnect, verification, debugging, real systems, and these closing checklists. You now have AXI understanding deep enough to design it, verify it, debug it, integrate it, and articulate it — and, with this chapter, the operational list to avoid where it most often goes wrong. Carry forward the one principle: understand the why, then apply it systematically.

Apply it: revisit the AMBA family overview to place AXI among its siblings (AHB, APB, ACE, CHI), build the AXI4-Lite slave and skid buffer for real, and run the design, verification, and integration checklists on your own AXI work.

Previous: 20.4 — AXI Interview Checklist. Related: 3.5 — Handshake Dependency & Deadlock Rules for the #1 mistake, 16.1 — The Protocol-Checker Mindset for compliance vs. correctness, and 18.8 — Tricky Misconceptions for the interview myths.