Handshake Dependency & Deadlock Rules

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.

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.

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.

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 and AW. The slave must not assert BVALID until it has accepted the write data — the W-channel handshake of the last beat (WLAST) — and until it has accepted the write address, the AW handshake. Both are "must wait" dependencies in §A3.3.1, not just the data one. A response before either is a protocol violation, and a correctness disaster: the master believes the write landed when it did not.
• 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 "must follow" dependencies of the base protocol.

The dependency rules, as a set of guardrails:

// 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 AW handshake AND the accepted
//     final write-data beat (WLAST).                            (B follows AW and 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

9. Debugging Insight

10. Verification Insight

11. The Rules as Executable Checks

The section above says "the dependency rules become a small, high-value assertion set." Here it is, written out. These four checks are the mandatory orderings of §A3.3.1 in SVA — and nothing else, because the single-channel VALID/READY mechanics already have their own executable proof in 3.1 — the VALID/READY handshake. This page's job is the cross-channel half.

The ordering rules are counting rules, so the checker counts. Each channel's completed handshakes are tallied, and a response is legal only if the transaction it answers has already been fully requested.

// ─────────────────────────────────────────────────────────────────────────
//  AXI4 cross-channel dependency checks (AMBA AXI4 §A3.3.1).
//  Bind to a master/slave/interconnect port:
//     bind axi_slave axi_dependency_checks u_dep (.*);
// ─────────────────────────────────────────────────────────────────────────
module axi_dependency_checks (
  input logic aclk, aresetn,
  input logic awvalid, awready,
  input logic wvalid,  wready, wlast,
  input logic bvalid,  bready,
  input logic arvalid, arready,
  input logic rvalid,  rready, rlast
);
 
  // ── Completed-handshake tallies, one per transaction-level event ───────
  int unsigned aw_seen, w_seen, b_seen, ar_seen, r_seen;
 
  always_ff @(posedge aclk or negedge aresetn) begin
    if (!aresetn) begin
      aw_seen <= 0;  w_seen <= 0;  b_seen <= 0;  ar_seen <= 0;  r_seen <= 0;
    end else begin
      if (awvalid && awready)            aw_seen <= aw_seen + 1;  // addresses taken
      if (wvalid  && wready && wlast)    w_seen  <= w_seen  + 1;  // writes fully delivered
      if (bvalid  && bready)             b_seen  <= b_seen  + 1;  // responses retired
      if (arvalid && arready)            ar_seen <= ar_seen + 1;  // read addrs taken
      if (rvalid  && rready && rlast)    r_seen  <= r_seen  + 1;  // reads retired
    end
  end
 
  // The registered counters are exactly the right reference, and it is worth
  // seeing why rather than reaching for a combinational "including this cycle"
  // total. A concurrent assertion samples in the Preponed region, so at the
  // edge where the slave accepts WLAST, `w_seen` is still the OLD count — the
  // increment lands after that edge. The earliest the slave can then drive
  // BVALID is the following cycle, which samples the incremented count and
  // passes. A response asserted any earlier samples the old count and fails.
  // So the registered form already permits the fastest legal response and
  // rejects everything ahead of it; adding current-cycle terms would only
  // widen the check into accepting a response that genuinely preceded its data.
 
  // ── Rule: B must follow the accepted final write-data beat ─────────────
  //  While BVALID is high the slave is offering response number b_seen
  //  (0-indexed). That write must already have delivered its WLAST, so the
  //  count of completed write payloads must exceed the responses retired.
  a_b_after_wlast:
  assert property (@(posedge aclk) disable iff (!aresetn)
      bvalid |-> (b_seen < w_seen))
    else $error("[%0t] BVALID asserted for a write whose WLAST has not been accepted (b_seen=%0d w_seen=%0d)",
                $time, b_seen, w_seen);
 
  // ── Rule: B must ALSO follow the accepted write address ────────────────
  //  The half of the rule that gets dropped. AXI4 decouples AW from W, so a
  //  slave can hold WLAST while AWVALID has never arrived; without this check
  //  it may respond to a transaction it cannot have identified.
  a_b_after_awaddr:
  assert property (@(posedge aclk) disable iff (!aresetn)
      bvalid |-> (b_seen < aw_seen))
    else $error("[%0t] BVALID asserted for a write whose address has not been accepted (b_seen=%0d aw_seen=%0d)",
                $time, b_seen, aw_seen);
 
  // ── Rule: R must follow the accepted read address ──────────────────────
  a_r_after_araddr:
  assert property (@(posedge aclk) disable iff (!aresetn)
      rvalid |-> (r_seen < ar_seen))
    else $error("[%0t] RVALID asserted for a read whose address has not been accepted (r_seen=%0d ar_seen=%0d)",
                $time, r_seen, ar_seen);
 
  // ── The covers that make the passes mean something ─────────────────────
  //  Each assertion above is an implication. On a quiet bus every attempt
  //  passes vacuously, so a clean run proves nothing without these.
  c_write_response_seen: cover property (@(posedge aclk) disable iff (!aresetn)
      bvalid && bready);
  c_read_data_seen:      cover property (@(posedge aclk) disable iff (!aresetn)
      rvalid && rready && rlast);
  c_wlast_before_awaddr: cover property (@(posedge aclk) disable iff (!aresetn)
      (w_seen > aw_seen));   // the AXI4 decoupling actually exercised
 
endmodule

What each check means, and what a failure means.

The last cover, c_wlast_before_awaddr, is the one reviewers forget. It fires only when write data genuinely arrives ahead of its address, which is exactly the AXI4 relaxation described in §6. If it never fires, the regression has not exercised the decoupling, and a_b_after_awaddr has never been in a position to catch anything.

12. Safety, Liveness, and Performance — Three Different Claims

A deadlock is the absence of progress, and no assertion of the kind written above can detect it: every one of them is a safety property, and a hung bus never does anything wrong — it simply never does anything. Catching a hang needs a different kind of claim, and conflating the three is how pages like this one start stating things about AXI that AXI does not say.

The three claims, kept apart:

Encoded, they look different too: safety is unbounded SVA, bounded liveness is SVA with a finite ##[0:N] window, and performance is coverage and statistics rather than an assertion at all.

True liveness — "READY eventually asserts," with no bound — is unfalsifiable in a finite simulation: you can never observe "eventually." What simulation can do is bound it, and a bounded-liveness assertion is exactly a watchdog:

// ─────────────────────────────────────────────────────────────────────────
//  Bounded-liveness watchdog. MAX_STALL is chosen from the SYSTEM's latency
//  budget — the deepest legitimate backpressure the integration can produce
//  under worst-case contention — with margin. It is NOT an AXI requirement,
//  and a firing watchdog is a finding to investigate, not a protocol verdict.
// ─────────────────────────────────────────────────────────────────────────
module axi_liveness_watchdog #(
  parameter int MAX_STALL = 1024
) (
  input logic aclk, aresetn,
  input logic awvalid, awready,
  input logic wvalid,  wready,
  input logic bvalid,  bready,
  input logic arvalid, arready,
  input logic rvalid,  rready
);
 
  // Once a source asserts VALID it must hold it until READY (the stability
  // rule from 3.1), so "the VALID that rose at cycle N is still waiting at
  // cycle N+k" is simply VALID still being high. The property therefore only
  // has to ask whether READY showed up inside the window.
  property p_no_indefinite_stall(logic valid, logic ready);
    @(posedge aclk) disable iff (!aresetn)
      $rose(valid) |-> ##[0:MAX_STALL] ready;
  endproperty
 
  // ##[0:MAX_STALL], not ##[1:MAX_STALL]: a destination may already be
  // asserting READY in the cycle VALID rises — a legal zero-stall transfer.
  // A window starting at 1 would demand a SECOND READY and fail every
  // full-throughput handshake on the bus.
 
  w_aw_progress: assert property (p_no_indefinite_stall(awvalid, awready))
    else $error("[%0t] AW stalled beyond %0d cycles — suspect a dependency cycle", $time, MAX_STALL);
  w_w_progress:  assert property (p_no_indefinite_stall(wvalid,  wready))
    else $error("[%0t] W stalled beyond %0d cycles — suspect a dependency cycle",  $time, MAX_STALL);
  w_b_progress:  assert property (p_no_indefinite_stall(bvalid,  bready))
    else $error("[%0t] B stalled beyond %0d cycles — suspect a dependency cycle",  $time, MAX_STALL);
  w_ar_progress: assert property (p_no_indefinite_stall(arvalid, arready))
    else $error("[%0t] AR stalled beyond %0d cycles — suspect a dependency cycle", $time, MAX_STALL);
  w_r_progress:  assert property (p_no_indefinite_stall(rvalid,  rready))
    else $error("[%0t] R stalled beyond %0d cycles — suspect a dependency cycle",  $time, MAX_STALL);
 
endmodule

Note what the watchdog does not claim. It does not say the stall was illegal; it says the stall exceeded the bound this system was designed to tolerate, which is a statement about your integration. That is still exactly what you want, because a genuine deadlock exceeds every bound — a true cycle of waiting never resolves, so any finite MAX_STALL catches it. The bound's only real job is to be large enough that legitimate contention never trips it.

13. Debugging Lab — A Cross-Channel Deadlock, End to End

  DMA         is not asserting RREADY   because its read-data buffer is full
  DMA buffer  is not draining           because the DMA drains it by writing to DDR
  DMA write   is not progressing        because AWVALID is not being accepted
  Interconnect is not asserting AWREADY because its write-issue slot is held
  write slot  is held                   because an earlier write is awaiting its B
  that B      is not returning          because the slave's response path is behind
  the slave   is behind                 because it is stalled on ... the DMA's reads

14. Interview Questions

15. 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.

17. Where This Is Specified

The dependency rules on this page are normative text in the Arm AMBA AXI Protocol Specification, §A3.3 — Dependencies between channel handshake signals — with the per-channel "must wait" / "may wait" list in §A3.3.1 and the handshake rules themselves in §A3.2. Arm publishes the specification on its AMBA AXI documentation page; it is the source to check before writing any dependency assertion, because §A3.3.1 is a short list in which the difference between must and may carries the entire deadlock-freedom argument — and it is the list from which "B follows W" is routinely quoted with the AW half missing.

One thing to confirm in the specification rather than take from any tutorial: there is no clause bounding how long a READY may remain low. Its absence is what makes every watchdog in §12 a policy rather than a protocol check, and searching for the rule and not finding it is a more durable way to learn that than being told.

The SVA used above is IEEE Std 1800 (SystemVerilog), clause 16 — see concurrent assertions for the sampling and implication semantics these checks rely on, and for why each one is paired with a cover.

Related lessons. The single-channel mechanics this page builds on are in 3.1 — VALID/READY handshake; the channel set in five channels and independent channels; the legitimate stall it must be distinguished from in backpressure and stalls. For the write-side ordering rule in detail see write ordering and WLAST; for the depth parameter that makes cross-channel cycles reachable, outstanding verification; and for the hands-on hunt, debugging deadlock and timeout debug.

16. 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.