AMBA AXI · Module 17

Waveform-Based Debug Methodology

A single repeatable method for debugging any AXI waveform — classify the symptom (hang vs. wrong-data vs. wrong-response vs. wrong-routing), locate it in time and channel, reconstruct the transaction, compare against intent, and trace to root — integrating every specific technique of Module 17 into one disciplined flow.

Module 17 covered specific AXI bugs — stuck handshakes, missing LAST, wrong LEN/SIZE/WSTRB, response errors, ID mismatches, deadlocks. This final chapter ties them into one repeatable methodology so that, faced with any failing AXI waveform, you have a disciplined flow rather than ad-hoc staring. The method is a decision tree: classify the symptom, which routes you to the right technique; locate it in time and channel; reconstruct the transaction; compare against intent; and trace to root. Every specific chapter slots into one branch. The goal is to make debugging systematic — the same first questions every time, leading to the same kind of localized answer — turning AXI debugging from an art into a procedure you can apply, teach, and trust.

1. The Five-Step Method

Every AXI debug follows the same five steps, regardless of the bug. (1) Classify the symptom — is the bus hung, returning wrong data, returning a wrong response code, or delivering responses to the wrong transaction? (2) Locate — which channel, which cycle, which transaction? (3) Reconstruct — assemble the transaction(s) involved from the beats. (4) Compare against intent — what should have happened (reference model / spec)? (5) Trace to root — follow the discrepancy back to its cause. The classification in step 1 routes the rest: each symptom class points at a specific Module 17 technique.

Figure 1 — the five-step AXI debug method. (1) Classify the symptom — hang, wrong-data, wrong-response, or wrong-routing. (2) Locate it in channel/cycle/transaction. (3) Reconstruct the involved transaction(s) from beats. (4) Compare against intent (reference model/spec). (5) Trace the discrepancy to its root. The same flow applies to every AXI bug; step 1's classification routes you to the right specific technique from Module 17.

2. Step 1 — Classify the Symptom (The Routing Decision)

Classification is the highest-leverage step because it routes the entire investigation. Four symptom classes, each pointing at a Module 17 technique: Hang (the bus stops progressing) → stuck handshake (17.1), missing LAST (17.2), or deadlock (17.7), detected via timeouts (17.8). Wrong data (response OKAY, content corrupt) → wrong LEN/SIZE (17.3) or wrong WSTRB (17.4). Wrong response code (SLVERR/DECERR) → response-error tracing (17.5). Wrong routing (correct data, wrong transaction) → ID mismatch (17.6). Getting the class right sends you down the correct branch immediately; misclassifying wastes time in the wrong technique.

Figure 2 — the symptom-classification decision tree. Hang → stuck handshake (17.1) / missing LAST (17.2) / deadlock (17.7), found via timeouts (17.8). Wrong data with OKAY → wrong LEN/SIZE (17.3) / wrong WSTRB (17.4). Wrong response code → BRESP/RRESP error tracing (17.5). Wrong routing (right data, wrong transaction) → ID mismatch (17.6). The symptom class is the routing key; each branch is a specific Module 17 technique.

3. Steps 2–4 — Locate, Reconstruct, Compare

With the class chosen, locate the failure: timeouts (17.8) localize a hang to a channel/transaction; assertions (16.2) localize a protocol violation to a cycle; the scoreboard (16.4) localizes a data/response/ID mismatch to a transaction. Then reconstruct the involved transaction(s) from the beats (the monitor, 16.3, does this) so you reason in transactions, not raw signals. Then compare against intent — the reference model says what should have happened, and the discrepancy between observed and intended is the bug's signature. This is where the recurring lesson of Module 17 lands: many bugs are internally self-consistent, so only comparison against intent reveals them.

Figure 3 — locate, reconstruct, compare, powered by the verification infrastructure. Timeouts (17.8) and assertions (16.2) locate the failure in time/channel; the monitor (16.3) reconstructs the transaction from beats; the reference model/scoreboard (16.4) supplies intent and flags the observed-vs-intended discrepancy. The debugging method runs on the same instrumentation built in Module 16 — assertions, monitor, scoreboard, coverage, timeouts — which is why a well-instrumented environment makes debugging fast.

4. Step 5 — Trace to Root, by the Bug's Level of Structure

The final step follows the discrepancy to its cause, and the kind of trace depends on the bug's level of structure — the unifying insight of Module 17. Signal-level bugs (stuck handshake) trace through the handshake dependency (who waits on whom, 17.1). Beat/burst-level bugs (LAST, LEN/SIZE, WSTRB) trace through the burst contract (cross-check against the declared and intended shape, 17.2–17.4). Transaction-level bugs (response codes) trace into the slave or decode (17.5). Inter-transaction (relational) bugs (ID mismatch) trace through transaction-matching (17.6). Global-dependency bugs (deadlock) trace through the wait-for graph and its cycles (17.7). The waveform — annotated with the located failure, the reconstructed transaction, and the intent comparison — is read at the bug's level.

Annotated waveform read at the bug's level

9 cycles

Figure 4 — tracing to root by the bug's level of structure (the unifying lens of Module 17). A signal-level bug traces through the handshake dependency; a beat/burst-level bug through the burst contract; a transaction-level bug into the slave/decode; a relational bug through transaction-matching; a global-dependency bug through the wait-for graph's cycles. The annotated waveform is read at the bug's level — which is why classifying the symptom (and thus the level) first is decisive: the level determines both the technique and how you read the waveform.

5. Common Misconceptions

Myths to unlearn

"Debugging AXI is ad-hoc waveform staring." It's a repeatable method: classify → locate → reconstruct → compare → trace. Staring without a method wastes time; the same first questions every time lead to a localized answer. The skill is the procedure, not intuition.
"Start by reading the waveform signal-by-signal." Start by classifying the symptom — that routes you to the right technique and the right level to read the waveform at. Reading signals before classifying means reading at the wrong level (e.g. staring at handshakes for an ID bug, which is relational).
"Each bug needs its own unrelated debugging trick." They're all branches of one method distinguished by symptom class and structural level. The specific techniques (17.1–17.8) are the branches; the five-step flow is the trunk. Learn the trunk and the branches follow.
"The waveform alone tells you the bug." The waveform shows what happened; many bugs are internally self-consistent, so you also need intent (the reference model) to see what should have happened. The discrepancy — not the waveform alone — is the bug.
"Debugging is separate from verification." Debugging runs on the verification infrastructure — assertions locate, the monitor reconstructs, the scoreboard compares, timeouts detect hangs. A well-instrumented environment (Module 16) makes debugging fast; a poorly-instrumented one makes it brutal. They're two views of the same machinery.
"You can skip identifying the level of structure." The bug's level (signal / beat / transaction / relational / global) determines both the technique and how you read the waveform. Misjudging the level sends you down the wrong branch — the classification's real job is to identify the level.

6. Debugging Insight

🔍 Debugging insight — run the method, and let the symptom class pick the branch

Apply the five steps in order, every time:

Classify first — never skip it. Hang? Wrong data (OKAY)? Wrong response code? Wrong routing (right data, wrong transaction)? This single question routes the whole investigation to the right technique and the right structural level. Resist diving into signals before classifying.
Locate with instrumentation, not eyes. For a hang, read the first timeout (17.8). For a protocol violation, read the fired assertion (16.2). For a data/response/ID mismatch, read the scoreboard's flag (16.4). The instrumentation names the channel/cycle/transaction — use it before manual waveform scanning.
Reconstruct the transaction. Use the monitor's view (16.3) to see the whole transaction (address, data, response, ID), not scattered beats. Most bugs are clearer at the transaction level.
Compare against intent. Pull the reference model's expectation and find the discrepancy. For self-consistent bugs (wrong LEN/SIZE, crossed ID, wrong-but-legal anything), this is the only step that reveals them — the waveform looks fine in isolation.
Trace at the bug's level. Signal → handshake dependency (17.1); burst → contract cross-check (17.2–17.4); response → slave/decode (17.5); relational → transaction-matching (17.6); global → wait-for graph (17.7). Read the waveform at that level.
Confirm the root, not the symptom. Verify the cause explains the discrepancy and that fixing it resolves the class (not just this trace) — and for hangs, that the cycle/stall can't re-form.

The method's power is that step 1 makes every later step deterministic: once you know the symptom class, the technique, the instrumentation to read, and the structural level are all determined. Debugging becomes "run the procedure," and the procedure is the same for every AXI bug.

7. Verification Insight

✅ Verification insight — one method, powered by instrumentation, organized by structural level

The capstone lesson of Module 17 is that AXI debugging is a single repeatable method, not a collection of tricks — classify the symptom, locate, reconstruct, compare against intent, trace to root — and every specific technique (17.1–17.8) is a branch selected by the symptom class and the bug's structural level. Three principles make it work. (1) Classification routes everything — the symptom class (hang / wrong-data / wrong-response / wrong-routing) determines the technique, the instrumentation to read, and the structural level to read the waveform at; investing in getting step 1 right makes every later step deterministic, which is why a disciplined debugger always classifies before touching signals. (2) Debugging runs on the verification infrastructure (Module 16) — assertions locate protocol violations to a cycle, the monitor reconstructs transactions from beats, the scoreboard compares against intent and flags mismatches, and timeouts convert silent hangs into localized errors; a well-instrumented environment makes debugging fast because the locate/reconstruct/compare steps are already done by the infrastructure, while a poorly-instrumented one forces manual reconstruction from raw waveforms — so the best debugging investment is upstream, in instrumentation. (3) The structural-level lens organizes the whole module — every AXI bug lives at a level (signal, beat/burst, transaction, inter-transaction relationship, global dependency), the level determines both the technique and how the waveform is read, and the symptom classification's real job is to identify the level: a hang at the signal level (stuck handshake) vs. the global level (deadlock) are debugged completely differently despite both being "the bus stopped," and only classifying the level tells them apart. The recurring sub-lesson — the waveform shows what happened, but intent shows what should have, and many bugs are internally self-consistent (catchable only by comparison against intent) — is why the method always includes the compare-against-intent step and why the reference model is indispensable, not optional. The deliverable of this chapter, and of Module 17, is a mental procedure: faced with any failing AXI waveform, ask the same first question (what class of symptom?), let it route you to the level and technique, lean on the instrumentation to locate and reconstruct, compare against intent to find the discrepancy, and trace at the bug's level to the root — the same flow every time, producing a localized, explained, structurally-confirmed root cause. This completes Module 17 (AXI Debugging): from the specific bug taxonomies to the unified method that subsumes them, debugging is now a procedure you can apply consistently, teach to others, and trust to terminate in a real root cause rather than a guess. Next, Module 18 turns from doing the work to articulating it — interview mastery, where explaining this debugging method (and everything before it) clearly is itself the skill under test.

8. Interview Questions

9. Summary

AXI debugging is one repeatable five-step method, not a collection of tricks: classify the symptom, locate it, reconstruct the transaction, compare against intent, and trace to root. Classification (step 1) is decisive because it routes everything — the four symptom classes (hang → 17.1/17.2/17.7 via timeouts 17.8; wrong data → 17.3/17.4; wrong response code → 17.5; wrong routing → 17.6) each select a specific technique, the instrumentation to read, and the structural level to read the waveform at. The middle steps run on the Module 16 infrastructure: timeouts and assertions locate, the monitor reconstructs transactions from beats, and the scoreboard's reference model supplies intent and flags the observed-vs-intended discrepancy — so a well-instrumented environment makes debugging fast because locate/reconstruct/compare are already done.

The unifying lens is the bug's level of structure — signal, beat/burst, transaction, inter-transaction relationship, or global dependency — which determines both the detection technique and how the waveform is read, and which the symptom classification exists to identify (a signal-level hang and a global-level deadlock both look like "the bus stopped" but are debugged completely differently). The recurring sub-lesson is that the waveform shows what happened, intent shows what should have — many bugs are internally self-consistent and catchable only by comparison against intent. The deliverable is a mental procedure: same first question every time, routed by class and level, leaning on instrumentation, terminating in a localized, explained, structurally-confirmed root cause. This completes Module 17 (AXI Debugging) — from the specific bug taxonomies (17.1–17.8) to the unified method that subsumes them. Next, Module 18 turns from doing the work to articulating it: interview mastery, where explaining this method clearly is itself the skill under test.

10. What Comes Next

You can now debug any AXI waveform systematically; Module 18 turns to articulating it:

18.1 — Beginner Interview Questions (coming next) — the fundamentals interviewers always open with, where explaining AXI concepts (and debugging methods) clearly and correctly is the skill being assessed.

Previous: 17.8 — Timeout Debugging. Related: 17.1 — Stuck VALID / Stuck READY through 17.8 — Timeout Debugging for the specific techniques this method integrates, and 16.1 — The Protocol-Checker Mindset for the verification infrastructure debugging runs on.

Continue learning

Standards & specifications

Governing standard: Arm AMBA AXI Protocol Specification (IHI 0022)(opens Arm in a new tab)
Defines the AXI channels, handshake and ordering rules. RTL structure, interconnect topology and verification strategy are design choices this specification does not mandate.

This page also covers RTL structure, verification approach and debugging technique. Those are engineering practice built on the standard, not requirements the standard itself imposes.

Where this fits

Part of the AMBA AXI curriculum.