AMBA AXI · Module 3

Handshake Dependency & Deadlock Rules

The AXI dependency rules that prevent deadlock — VALID never waits for READY, and the cross-channel ordering (B after W, R after AR) that keeps the dependency graph acyclic.

Decoupled channels (2.4) and backpressure (3.3) give AXI its performance — and its capacity to deadlock, if the channels are allowed to wait on each other in a cycle. This chapter is the rule set that makes all that concurrency safe: the single-channel rule you met in 3.1 (VALID never waits for READY), now generalized to a cross-channel dependency graph. The whole trick is one idea — keep the dependency graph acyclic. AXI4's dependency rules are precisely the constraints that forbid a cycle, so a transaction can always make forward progress. Get a dependency direction wrong and you get a hang that no amount of waiting resolves. This is the Critical payoff of Module 3; grounded in AMBA AXI4 §A3.3.

1. Deadlock Is a Cycle of Waiting

Deadlock has one shape: a cycle of "I'll move after you move." If A waits for B and B waits for A, neither ever moves. On a handshake that's the cardinal-rule violation from 3.1 in its purest form — the source waits for READY and the destination waits for VALID, so neither signal ever asserts.

Figure 1 — deadlock is a dependency cycle. If the source won't assert VALID until it sees READY, and the destination won't assert READY until it sees VALID, each is waiting for the other to move first. The wait is circular, so neither ever fires — a permanent hang. Breaking the cycle (one side must not wait) is the whole game.

So the rule that prevents single-channel deadlock is exactly the cardinal rule: a source asserts VALID from its own data, never waiting for READY. That breaks the cycle — the source always moves first, so the destination's READY (which may wait for VALID) eventually fires. One non-waiting side is all it takes.

2. The Deadlock on a Waveform

A handshake deadlock has an unmistakable signature: both VALID and READY flat-low forever, with the transaction never completing.

Deadlock — VALID waits for READY (both flat low)

8 cycles

Figure 2 — the deadlock-dependency waveform. The source has data to send but waits for READY, so VALID never rises; the destination waits for VALID, so READY never rises. Both stay low for all time and no beat ever transfers. Flat-low-forever on both control signals is the textbook VALID-waits-for-READY deadlock.

Contrast this with backpressure (3.3), where VALID is high and READY is low (a legitimate stall that resolves when the destination is ready). Deadlock is both low and never resolving. Telling these two apart on a capture is a core skill: high-VALID/low-READY is flow control; low-VALID/low-READY-forever is a dependency bug.

3. From One Channel to Many

The single-channel rule generalizes. AXI has five channels, and they're allowed to depend on each other in specific directions — a master may legitimately wait for one thing before doing another. The danger is that these cross-channel waits could form a cycle across channels even if each channel individually obeys the cardinal rule. AXI4's dependency rules (§A3.3) are exactly the set of allowed dependencies chosen so that no cycle can form.

The rules come in two flavors:

"may depend on" (optional): a READY may wait for the corresponding VALID (the destination may wait to see an offer). These are the slave/master conveniences.
"must not depend on" (forbidden): a VALID must never wait for its READY — on any channel. This is the cardinal rule applied five times.
"must follow" (required ordering): some events must happen after others — the write response after the write data, the read data after the read address. These are mandatory orderings, not just allowances.

Put together, every dependency arrow points "forward" (a VALID enabling a READY, or an earlier event enabling a later one) and never backward into a VALID from its own READY — so the graph is a DAG, and a DAG cannot deadlock.

4. The AXI4 Dependency Graph

Here is the write path's dependency graph — the legal arrows. Read an arrow X → Y as "Y may be asserted depending on X" (Y is allowed to wait for X). The read path is the same shape with AR and R.

Figure 3 — the AXI4 write dependency graph (read is symmetric with AR/R). AWREADY may wait for AWVALID; WREADY may wait for WVALID; BVALID MUST follow the accepted write data (after WLAST); BREADY may wait for BVALID. Crucially, no arrow ever points from a READY back into its own VALID — every VALID is an independent source — so the graph is acyclic and cannot deadlock.

The forbidden arrows are the ones you don't see: nothing points from AWREADY back to AWVALID, from WREADY to WVALID, from BREADY to BVALID, or (on the read side) from ARREADY/RREADY to their VALIDs. Each VALID is a graph source with no incoming dependency from its own READY. That's the acyclic guarantee, stated as a picture.

5. The Mandatory Orderings

Two arrows in that graph are not "may" but "must" — required orderings that hold every transaction together:

Write: B must follow W. The slave must not assert BVALID until it has accepted the write data — i.e., after the W-channel handshake of the last beat (WLAST). A response before the data is a protocol violation (and a correctness disaster: the master thinks the write landed when it didn't).
Read: R must follow AR. The slave must not assert RVALID until the address has been accepted (the AR handshake completed). You can't return read data for an address you haven't taken.

These orderings are causal — the answer can't precede the question — and they're the only "must follow" dependencies in the base protocol. (The slave may also wait for the write address before responding, but the hard rule is B-after-data.)

Figure 4 — the two mandatory orderings. A write's B response may be asserted only after the write data is accepted (through WLAST); a read's R data may be asserted only after the address is accepted (the AR handshake). The answer cannot precede the question — these causal orderings are required, not optional.

The dependency rules, as a set of guardrails:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — the AXI4 dependency rules (AMBA AXI4 §A3.3), as guardrails:
//  1. A SOURCE asserts VALID from its own data — NEVER waits for READY.   (no self-cycle)
//  2. A DESTINATION may assert READY before or after VALID.               (either is legal)
//  3. Write response: BVALID only AFTER the write data is accepted (WLAST). (B follows W)
//  4. Read data: RVALID only AFTER the AR handshake completes.             (R follows AR)
// Rule 1 broken on any channel, OR a dependency cycle across channels → DEADLOCK.

6. AXI3 vs AXI4 — A Relaxed Dependency

One historical note that's interview-relevant: AXI3 had a stricter write dependency — in effect, write data ordering was tied more tightly to the address. AXI4 relaxed it so the write data may arrive before, with, or after the write address (the decoupling from 2.4). This relaxation removed a dependency, which can only make the graph "more acyclic," never less — so it's safe. The lesson: AXI4's dependency set is the minimal one needed to prevent deadlock while maximizing decoupling; AXI3 was slightly more constrained. When bridging AXI3↔AXI4, this is one of the behaviours a converter must reconcile (Chapter 2.5).

7. How a Violation Deadlocks

Concretely, two ways to create a cycle and hang the bus:

Single-channel (the classic): a source codes VALID = f(READY) — awvalid <= awready, say. Now AWVALID waits for AWREADY, and a slave that (legally) waits for AWVALID before AWREADY completes the cycle. Both flat-low forever (Figure 2).
Cross-channel (the subtle one): a master that refuses to accept read data (RREADY low) until it finishes a write, while the thing blocking the write is downstream of that same master's read traffic — a loop through the system, not one channel. Interconnects and bridges are where these arise, because they couple channels that the base rules kept independent. The defense is the same: never let a VALID (or an "accept") wait on something that ultimately waits on it.

The rules in §4–5 guarantee the base protocol is deadlock-free; system-level deadlocks come from logic layered on top (a master/bridge that adds its own cross-channel dependency). So "AXI can't deadlock" is true of the protocol and false of careless integration — which is exactly why this chapter is Critical.

8. Common Misconceptions

Myths to unlearn

"AXI can't deadlock." The base protocol can't, because its dependency graph is acyclic. Integration logic (a master or bridge adding a cross-channel dependency) absolutely can. The rules protect the protocol, not your RTL.
"Backpressure and deadlock look the same." No. Backpressure is VALID high, READY low, and resolves. Deadlock is both low forever (or a cross-channel cycle) and never resolves. Different signatures, different causes.
"The slave can respond as soon as it has the address." For a write, BVALID must follow the accepted write data (WLAST), not just the address. Responding after only the address is a violation.
"Only VALID-waits-for-READY causes deadlock." That's the single-channel case. Cross-channel cycles (often through an interconnect/bridge) deadlock too, even when every individual channel obeys the cardinal rule.
"AXI3 and AXI4 have the same dependencies." AXI4 relaxed the write data/address dependency (data may precede address), which AXI3 constrained more tightly — a difference a bridge must handle.

9. Debugging Insight

🔍 Debugging insight — a hung bus is a cycle; find the back-edge

When the bus is hung (not slow — stopped), you're looking for a dependency cycle, and the method is systematic:

Confirm it's deadlock, not backpressure. Backpressure shows VALID high with READY low and eventually clears. Deadlock shows a channel stuck with no forward progress — classically both control signals low forever, or a set of channels each waiting.
On a stuck channel, check the source's VALID equation. If VALID is a function of READY (e.g., awvalid depends on awready), that's the single-channel cycle — the cardinal-rule violation. Fix: assert VALID from data readiness only.
If each channel is individually legal, look for a cross-channel cycle. Map what each blocked party is waiting for: master waiting on R before accepting more, slave waiting on something gated by that master, etc. Draw the wait-for arrows; a cycle is your deadlock. These live in masters, bridges, and interconnects that couple channels.
Use the mandatory orderings as checks. A BVALID that appeared before WLAST, or RVALID before the AR handshake, is an ordering violation — often the root of a downstream hang.

The mental model: deadlock = cycle in the wait-for graph. Find the back-edge (the dependency that shouldn't exist) and remove it.

10. Verification Insight

✅ Verification insight — assert the rules, and hunt cycles with timeouts

The dependency rules become a small, high-value assertion set, bound to every channel and transaction:

No VALID-waits-for-READY: structurally, each VALID must not be a combinational function of its READY (the cardinal rule, five times). Caught in review and by the deadlock symptom.
Ordering assertions: BVALID must not assert before the last W beat (WVALID && WREADY && WLAST) has been accepted; RVALID must not assert before the AR handshake. These directly encode the "must follow" rules.
Liveness / timeout: every asserted VALID must eventually meet READY, and every accepted request must eventually complete. A timeout firing is your deadlock detector — because a true deadlock never resolves, a bounded "this must complete within N cycles" assertion is what surfaces it in simulation (and a watchdog does the same in silicon).

Stimulus-wise, deadlocks hide in contention: many outstanding transactions, aggressive independent backpressure on every channel, and interconnect configurations that couple masters. Constrained-random traffic with per-channel ready-delay (3.3) plus these liveness timeouts is how you flush cross-channel cycles that directed tests never reach. Mechanics in Module 16.

11. Interview Questions

12. Summary

Deadlock is a cycle of waiting, and AXI prevents it by keeping the dependency graph acyclic. The foundation is the cardinal rule from 3.1 applied to every channel: a VALID must never wait for its READY — each VALID is an independent source, so some side always moves first. On top of that, AXI4 (§A3.3) defines which dependencies are allowed (a READY may wait for its VALID) and which are required (the mandatory orderings: B must follow the accepted write data, R must follow the accepted read address — the answer can't precede the question). Every arrow points forward; none feeds a READY back into its own VALID; the graph is a DAG and a DAG cannot deadlock.

Distinguish the failure from backpressure: backpressure is VALID high / READY low and resolves; deadlock is both low forever, or a cross-channel cycle, and never resolves. And remember the scope: the protocol is deadlock-free, but integration logic — masters, bridges, interconnects that couple channels — can add a back-edge and hang the system, which is why this is Critical. Debug a hang by finding the cycle in the wait-for graph and removing the illegal dependency; verify it with structural rule-assertions plus liveness timeouts. Next: the recurring handshake bugs that turn these rules into war stories.

13. What Comes Next

You have the rules that keep concurrency safe. Module 3 closes with the field guide to getting them wrong:

3.6 — Common Handshake Bugs (coming next) — the recurring handshake mistakes (dropped VALID, combinational READY loops, ordering violations) and how to spot each.

Previous: 3.4 — Handshake Throughput. For the broader protocol catalog, see the AMBA family overview doc.