AMBA AHB · Module 18

Bridge Deadlock

Finding and breaking a bridge deadlock — a circular wait where the bridge and the system get stuck waiting on each other, so nothing completes. A bridge holds its upstream side (wait states) while running the downstream transaction; deadlock arises when that holding closes a dependency cycle (master waits on the bridge -> bridge waits on the downstream -> downstream waits back on the master or a shared resource). The four classic conditions hold (mutual exclusion, hold-and-wait, no preemption, circular wait). It looks like a stuck HREADY but is a cycle, not a single stuck slave, so the stuck-HREADY method goes in circles. Diagnose by mapping what each party waits for and finding the cycle; break ONE edge — a timeout (abort with ERROR), an ordering rule, or buffering. A bus watchdog is the safety net.

This is the module's hardest debug: a bridge deadlock. A deadlock is a circular wait — the bridge and the rest of the system get stuck waiting on each other in a circle, so nothing completes. It looks like a stuck HREADY (18.1) — the bus is hung — but the cause is deeper: not a single stuck slave, but a dependency cycle. Recall (16.10) that a bridge holds its upstream side (wait states, HREADYOUT low) while it runs the downstream transaction. A deadlock arises when that holding forms a circular dependency that never resolves. The classic example: the upstream master is waiting for the bridge to complete its transfer; the bridge is waiting for the downstream peripheral to respond; but the downstream peripheral is waiting on something that depends on the upstream side — e.g. the same master needing to service the peripheral, or a shared resource the master holds. So the loop closes: master → bridge → downstream → master. Each party is correctly waiting, yet together they form a cycle with no progress. All four classic deadlock conditions hold: mutual exclusion (of the bus), hold-and-wait (the bridge holds upstream while waiting downstream), no preemption (transfers aren't preempted), and the circular wait itself. To find it, identify what each party is waiting for and look for the cycle. To break it, eliminate one edge: a timeout (abort with an error), ordering (so the dependency can't be circular), or buffering (so the bridge doesn't hold while waiting). (This is the debug methodology applied to a bridge-style FSM; the conceptual AHB-to-APB bridge is a separate subject.) This chapter builds the diagnosis.

1. What Is It?

A bridge deadlock is a circular wait through the bridge; debugging it means mapping the cycle and breaking one edge. Its parts:

A circular wait — the bridge and the system wait on each other in a circle (master → bridge → downstream → master), so nothing completes.
The bridge's hold-and-wait — the bridge holds its upstream side (wait states) while waiting on downstream; that holding closes the cycle.
The four conditions — mutual exclusion, hold-and-wait, no preemption, circular wait — all hold in a deadlock.
Diagnose + break — map what each party waits for, find the cycle; break one edge (timeout / ordering / buffering). A watchdog is the safety net.

Figure 1 — a bridge deadlock is a circular wait. The upstream MASTER is waiting for the bridge to complete; the BRIDGE is holding upstream and waiting downstream; the DOWNSTREAM is waiting on the master (or a shared resource the master holds). The arrows form a cycle: master waits on → bridge, bridge waits on → downstream, downstream waits on → master. Each party is correctly waiting, yet together they form a CYCLE with no progress. Break ONE edge: timeout / ordering / buffering.

So a bridge deadlock is a systemic failure — not a bug in one component, but a cycle of mutual waiting that spans the master, the bridge, and the downstream. The key to debugging it is recognizing it as a deadlock (a circular wait), not a stuck slave. A stuck HREADY (18.1) is one slave that won't complete; a deadlock is multiple parties each correctly waiting but collectively stuck. The bridge's role is central: its hold-and-wait behavior (holding upstream while waiting downstream — necessary for rate-matching — 16.10) is exactly the condition that closes a dependency cycle if the downstream depends back on the upstream. So the diagnosis is graph-like: map the wait-for relationships (who waits on whom), and look for a cycle. The fix is to break the cycle — remove one edge (one wait-for dependency) via a timeout, an ordering rule, or buffering. So a bridge deadlock is the circular-wait failure debugged by mapping the cycle and breaking an edge. So it's the hardest, most systemic AHB debug.

Bridge deadlock = a CIRCULAR WAIT (master → bridge → downstream → master), not a stuck slave. The bridge's hold-and-wait (holds upstream while waiting downstream) closes the cycle. Diagnose by mapping what each party waits for and finding the cycle; break ONE edge (timeout / ordering / buffering)

A bridge deadlock in one frame: a circular wait — the bridge and the system get stuck waiting on each other in a circle, so nothing completes. It looks like a stuck HREADY (18.1 — the bus hangs) but the cause is a dependency cycle, not a single stuck slave. The bridge's role: it holds its upstream side (wait states, HREADYOUT low) while it runs the downstream transaction (the rate-matching of 16.10) — and that hold-and-wait is exactly what closes a cycle if the downstream depends back on the upstream. The classic cycle: the upstream master waits for the bridge to complete; the bridge waits for the downstream peripheral; the downstream waits on the master (the same master needing to service the peripheral, or a shared resource the master holds). So: master → bridge → downstream → master — a cycle where each party is correctly waiting but together they never progress. All four classic deadlock conditions hold: mutual exclusion (only one owner of the bus / resource), hold-and-wait (the bridge holds upstream while waiting downstream), no preemption (in-flight transfers aren't preempted), and the circular wait. To diagnose: map what each party is waiting for (the wait-for graph) and look for the cycle. To break it: eliminate one edge (one wait-for dependency) — (a) a timeout (the bridge/watchdog aborts the held upstream transfer with an ERROR after a bounded time → removes hold-and-wait by forcing progress); (b) ordering (impose a global acquisition order so the dependency can't be circular → removes the circular wait by construction); (c) buffering (a posted-write buffer/queue so the bridge doesn't hold upstream while downstream is in flight → removes hold-and-wait). A bus watchdog is the safety net (turning a missed deadlock into a recoverable fault). (The conceptual AHB-to-APB bridge is a separate subject; this is the deadlock-debug methodology applied to a bridge-style FSM.)

2. Why Does It Exist?

Bridge deadlocks exist because the bridge's hold-and-wait behavior (necessary for rate-matching) creates a resource dependency that, combined with a downstream-depends-on-upstream path, closes a cycle — and the four classic deadlock conditions (mutual exclusion, hold-and-wait, no preemption, circular wait) all hold, so the system locks up.

The the bridge holds-and-waits is the root: a bridge must hold its upstream side (wait states) while it runs the downstream transaction (it can't complete the upstream transfer until downstream is done — 16.10). This is hold-and-wait: the bridge holds a resource (the upstream bus, via the held transfer) while waiting for another (the downstream completion). Hold-and-wait is one of the four deadlock conditions. So the bridge's necessary behavior introduces a deadlock precondition. So bridge deadlocks exist because the bridge holds-and-waits. So it's an inherent risk. So the bridge enables the precondition.

The a dependency cycle closes drives the deadlock: hold-and-wait alone isn't a deadlock — it becomes one when the waited-for resource (downstream) depends back on the held resource (upstream). If the downstream needs something from the upstream master (which is blocked waiting on the bridge), the loop closes: master → bridge → downstream → master. So the deadlock exists because a cycle forms (the downstream-depends-on-upstream path plus the bridge's hold-and-wait). So it's a circular dependency. So the cycle closes the loop.

The all four conditions hold is the formalization: a deadlock requires all four of mutual exclusion (the bus/resource is exclusive), hold-and-wait (a party holds while waiting), no preemption (held resources can't be forcibly taken), and circular wait (the cycle). In the bridge case, all four hold: the bus is exclusive, the bridge holds-and-waits, transfers aren't preempted, and the cycle exists. So the system deadlocks. So bridge deadlocks exist because: the bridge's hold-and-wait (necessary for rate-matching) is a deadlock precondition (the why); a downstream-depends-on-upstream path closes a cycle (the circular dependency); and all four deadlock conditions hold (the formal deadlock — the lock-up). So a bridge deadlock is the circular-wait failure that arises when the bridge's hold-and-wait meets a downstream-depends-on-upstream dependency — debugged by mapping the wait-for cycle and broken by removing one edge (one of the four conditions). So this chapter teaches the cycle-mapping diagnosis. So map the cycle and break a condition.

3. Mental Model

Model debugging a bridge deadlock as untangling a gridlocked intersection where each driver is blocked by the next, in a circle — nobody can move because everybody is waiting for the car ahead, and the car ahead is (eventually) waiting for them. To debug, you map who is blocked by whom and look for the circle. To fix, you break the circle at one point: a traffic cop forces one car to back out (a timeout — abort), a rule that says "always yield in this direction" prevents the circle forming (ordering), or a wider road / turn lane lets a car proceed without blocking (buffering). You don't fix every car — you break the cycle at one edge.

A four-way intersection (the system) in gridlock (deadlock). Each car (the master, the bridge, the downstream) has entered the intersection and is now blocked by the car ahead — and crucially, the blocking forms a circle: car A is blocked by car B, B by C, and C is blocked back by A. Nobody can move, because everybody is waiting for the car ahead, and the chain loops back. This is a deadlock: each car is correctly waiting (it can't move into an occupied space — mutual exclusion; it holds its spot while waiting — hold-and-wait; nobody will back out voluntarily — no preemption), yet together they form a circular wait. The naive reaction — "which car is broken?" — is wrong: no car is broken; the configuration is deadlocked. To debug, you map who is blocked by whom — A waits on B, B waits on C, C waits on A — and see the circle. To fix, you break the circle at one point — you don't need to fix every car. Three ways: a traffic cop (a timeout/watchdog) forces one car to back out (abort the held transfer with an error — removing hold-and-wait); a traffic rule ("always yield to the right" — ordering) prevents the circle from forming in the first place (you can't create a circular wait if everyone acquires in the same order); or a wider road with a turn lane (buffering) lets a car proceed without blocking the next (the bridge completes upstream into a buffer and drains downstream independently — removing hold-and-wait). Each fix removes one edge of the cycle. The cop is the safety net — even if you miss the cycle, the cop eventually clears it (a watchdog turning a permanent gridlock into a recoverable one).

This captures bridge-deadlock debug: the gridlocked intersection = the deadlocked system; each car blocked by the next in a circle = the circular wait (master → bridge → downstream → master); no car being broken = no single component being buggy (it's the configuration); mapping who is blocked by whom = mapping the wait-for graph; seeing the circle = finding the cycle; the traffic cop forcing one car out = a timeout/watchdog aborting the held transfer; the always-yield rule = an ordering rule preventing the cycle; the turn lane letting a car proceed = buffering removing hold-and-wait; breaking the circle at one point = removing one edge; the cop as safety net = the watchdog. Map who is blocked by whom, find the circle, and break it at one edge.

Watch a bridge deadlock on the waveform — the permanent stall and the cycle:

Bridge deadlock: a circular-wait permanent stall

4 cycles

Figure 2 — a bridge deadlock: a permanent stall that looks like a stuck HREADY but is a cycle. The upstream HREADY is stuck low forever (the master is held by the bridge). On a stuck-HREADY trace (18.1) you'd decode the address to the bridge and find its HREADYOUT low — but here, going further, the bridge's downstream side is ALSO stuck waiting (the downstream PREADY never asserts), and the downstream is waiting on the master (which is held). The 'who waits on whom' row maps the cycle: master→bridge, bridge→downstream, downstream→master. Unlike a simple stuck HREADY (one slave's logic), there's no single stuck component — it's a circular wait. The fix isn't 'unstick one slave' but 'break one edge of the cycle' (timeout / ordering / buffering).

The model's lesson: map who is blocked by whom, find the circle, and break it at one edge. In the waveform, the permanent stall looks like a stuck HREADY — but tracing further reveals the bridge's downstream is also stuck, and the downstream waits back on the master: a cycle (master → bridge → downstream → master). It's a deadlock, not a single stuck slave — fixed by breaking one edge, not unsticking one component.

4. Real Hardware Perspective

In debug, you recognize the deadlock (a stall with no single stuck component), map the wait-for graph (who waits on whom across the master, bridge, and downstream), find the cycle, and break one edge (timeout / ordering / buffering) — with a watchdog as the safety net.

The recognize the deadlock (not a stuck slave): on the waveform, you start like a stuck HREADY (18.1) — trace the upstream HREADY to the bridge. But unlike a stuck slave, going further — to the bridge's downstream side — shows it's also stuck waiting (not its own logic stuck, but waiting on the downstream). And the downstream is waiting on the master. So there's no single stuck component — each is waiting on the next. This is the recognition: a deadlock (circular wait), not a stuck slave. So in debug, recognize the cycle, not a single stuck component. So that's the key recognition. So it's a deadlock, not a hang.

Figure 3 — breaking the deadlock by removing one edge of the circular wait. 1) Timeout: the bridge / bus watchdog ABORTS the held upstream transfer with an ERROR after a bounded time → removes hold-and-wait (forces progress). 2) Ordering: impose a global acquisition order so the dependency CAN'T be circular (downstream never depends back on a blocked master) → removes the circular-wait condition by construction. 3) Buffering: a posted-write buffer / queue so the bridge does NOT hold upstream while downstream is in flight; the upstream completes into the buffer and the downstream drains independently → removes hold-and-wait. Find the cycle → identify what each party waits for → break exactly ONE edge. A bus watchdog is the safety net — turns a missed deadlock into a recoverable fault.

The map the wait-for graph and find the cycle: map the wait-for relationships — for each party (master, bridge, downstream, any shared resource), what is it waiting for? The master waits on the bridge (its transfer to complete); the bridge waits on the downstream (the peripheral's response); the downstream waits on... — here's the critical step — what does the downstream depend on? If it depends back on the master (the master must service it, or release a shared resource the master holds), the cycle closes. So you trace the dependency all the way around and find the cycle. So in debug, map the wait-for graph. So it's cycle-finding. So that localizes the deadlock.

The break one edge + watchdog: with the cycle mapped, break one edge (remove one of the four conditions — usually hold-and-wait or circular wait): (1) Timeout — the bridge (or a bus watchdog) aborts the held upstream transfer with an ERROR after a bounded time (removing hold-and-wait — the master is released); (2) Ordering — redesign so the downstream never depends back on a blocked master (a global acquisition order — removing the circular wait by construction); (3) Buffering — give the bridge a posted-write buffer/queue so it completes upstream immediately (into the buffer) and drains downstream independently (removing hold-and-wait — the bridge doesn't hold while waiting). And always add a bus watchdog as the safety net — even if a deadlock is missed in design, the watchdog detects the prolonged stall and triggers recovery (turning a permanent hang into a recoverable fault — 18.1). So in debug, a bridge deadlock is recognize (a stall with no single stuck component) → map the wait-for graph → find the cycle → break one edge (timeout/ordering/buffering) + watchdog. So in debug, map the cycle and break an edge. So that's the method.

5. System Architecture Perspective

At the system level, a bridge deadlock is a system-integration failure (it arises from the interaction of correctly-designed components, not a single bug) — making it hard to find (no single culprit) and a prevention-by-design problem (the four conditions, posted writes, ordering rules) — and it's why a bus watchdog is essential (the safety net for the un-found deadlock).

The system-integration failure: a bridge deadlock is an emergent property of the system's structure — it arises from the interaction of the master, bridge, and downstream (each correctly designed) forming a cycle. So it's a system-integration failure, not a component bug. So at the system level, it's emergent — no single component is wrong; the composition is. So it's hard to attribute. So integration creates it.

The hard to find, prevent by design: because there's no single culprit, a deadlock is hard to find by component-level debug (each component passes in isolation). So the primary defense is prevention by design: avoid the four conditions (especially hold-and-wait via posted writes/buffering, and circular wait via ordering rules) at design time, and verify with deadlock-detection (a formal check for cycles, or stress tests that create the dependency). So at the system level, deadlocks are prevented by design (not found after). So it's a design-time concern. So prevent, don't chase.

The the watchdog as essential safety net: because deadlocks are hard to find (some may escape to silicon), a bus watchdog is essential — it detects the prolonged stall (a HREADY low beyond a threshold — 18.1) and triggers recovery (an error/reset), turning a permanent system freeze into a recoverable fault. So the watchdog is the system-level safety net for the un-found deadlock. So at the system level, a bridge deadlock is a system-integration failure (emergent from correctly-designed components forming a cycle — no single culprit, hard to find), prevented by design (avoiding the four conditions — posted writes/buffering, ordering rules — at design time, verified by deadlock-detection), with a bus watchdog as the essential safety net (recovering the un-found deadlock — a permanent freeze → a recoverable fault). So a bridge deadlock is the hardest class of bug — emergent, systemic, no single culprit — making design-time prevention (break a condition) and a runtime watchdog (the safety net) the two-layer defense, and the cycle-mapping the diagnostic skill. So design out the cycle, and guard with a watchdog. So deadlock is the systemic frontier.

6. Engineering Tradeoffs

Debugging a bridge deadlock embodies the recognize-the-cycle, map-the-wait-for-graph, break-one-edge approach.

Recognize a deadlock vs chase a stuck slave. Recognizing a circular wait (no single stuck component) directs you to map the cycle; chasing a single stuck slave (the stuck-HREADY method) fails (each component is correctly waiting). Recognize the cycle.
Map the wait-for graph vs guess. Mapping what each party waits for (and finding the cycle) localizes the deadlock; guessing misses the circular structure. Map the graph.
Break one edge vs fix every component. Breaking one edge (removing one condition) resolves the deadlock; fixing every component is futile (none is broken). Break one edge.
Timeout vs ordering vs buffering. Timeout is simple (abort after a bound) but aborts a transfer; ordering prevents the cycle but constrains design; buffering removes hold-and-wait but adds a buffer. Choose by the design; always add a watchdog.

The throughline: a bridge deadlock is a circular wait — the master, bridge, and downstream wait on each other in a circle (master → bridge → downstream → master), so nothing completes. It looks like a stuck HREADY but is a dependency cycle, not a single stuck slave. The bridge's hold-and-wait (holding upstream while waiting downstream — necessary for rate-matching, 16.10) closes the cycle when the downstream depends back on the upstream. All four classic conditions hold (mutual exclusion, hold-and-wait, no preemption, circular wait). Diagnose by mapping what each party waits for and finding the cycle; break one edge — timeout (abort with ERROR — removes hold-and-wait), ordering (no circular dependency — removes circular wait), or buffering (don't hold while waiting — removes hold-and-wait). It's a system-integration failure (emergent, no single culprit), prevented by design, with a bus watchdog as the essential safety net.

A deadlock is NOT a stuck slave — there's no single buggy component; each party is CORRECTLY waiting, but they form a CYCLE. So DON'T chase one stuck slave (the stuck-HREADY method fails). Map what each party waits for, find the cycle, and break ONE edge (timeout/ordering/buffering). And ALWAYS have a watchdog — it's the safety net for the deadlock you didn't find

The defining mistake with a bridge deadlock is treating it like a stuck HREADY — chasing a single stuck slave — when it's a circular wait with no single culprit. The recognition is the hard part: (1) It's not a stuck slave — it's a cycle. A stuck HREADY (18.1) is one slave whose HREADYOUT is stuck due to its own logic (a hung FSM, a never-true condition). A deadlock is different: each party (master, bridge, downstream) is correctly waiting — none has a bug — but they form a cycle where each waits on the next. So the stuck-HREADY method (decode the address → that slave → why is its HREADYOUT stuck) fails: you trace to the bridge, find its HREADYOUT low — but not because its logic is stuck; because it's correctly waiting on the downstream. You trace to the downstream, find it waiting — on the master. You trace to the master, find it waiting — on the bridge. Round and round: no single stuck component. So you must recognize this is a deadlock (a cycle), not keep chasing a single stuck slave (which doesn't exist). (2) Map the wait-for graph and find the cycle. Once recognized, map what each party waits for (the wait-for graph) and find the cycle: master → bridge → downstream → master (and what the downstream-to-master edge is — usually a shared resource the master holds, or the master needing to service the peripheral while it's blocked). The cycle is the deadlock. (3) Break ONE edge — don't fix every component. Since no component is broken, you don't fix the components — you break the cycle by removing one edge (one of the four conditions): a timeout (abort the held transfer → removes hold-and-wait), an ordering rule (so the downstream can't depend back → removes circular wait), or buffering (the bridge doesn't hold while waiting → removes hold-and-wait). One edge breaks the whole cycle. (4) Always have a watchdog. Deadlocks are hard to find (some escape to silicon), so a bus watchdog (18.1) is the essential safety net — it detects the prolonged stall and recovers (turning a permanent freeze into a recoverable fault). Never ship a multi-cycle-holding bridge without a watchdog. The unifying discipline: recognize the cycle (not a stuck slave), map the wait-for graph, break one edge, and guard with a watchdog. The tell of a mis-debug: endlessly chasing a single stuck component that's actually correctly waiting (going in circles — literally following the deadlock cycle). (See Stuck HREADY for the contrast, and Bridge FSM (RTL) for the bridge's hold-and-wait.)

7. Industry Example

Debug a bridge deadlock between a CPU, a bridge, and a peripheral that needs CPU service.

A system hangs intermittently. A CPU accesses a peripheral through a bridge; the hang involves the bridge.

The symptom (looks like a stuck HREADY). The system freezes; the CPU's upstream HREADY is stuck low. You start the stuck-HREADY method (18.1): decode the address → the bridge; the bridge's HREADYOUT is low.
But it's not a stuck slave. Going further: the bridge's HREADYOUT is low because it's waiting on the downstream peripheral (not its own logic stuck). You trace to the peripheral: it's waiting too — for the CPU to service an interrupt (the peripheral won't complete the access until the CPU handles a pending condition). But the CPU is blocked (held by the bridge on this very access) — so it can't service the interrupt. Cycle: CPU → bridge → peripheral → CPU.
Map the cycle. The wait-for graph: CPU waits on the bridge (its access to complete); bridge waits on the peripheral (the downstream response); peripheral waits on the CPU (to service the interrupt / release a condition). The cycle is the deadlock — each correctly waiting.
Break one edge. Three options: (timeout) the bridge aborts the held access with an ERROR after a bound — the CPU is released, services the interrupt, and the peripheral progresses; (ordering) redesign so the peripheral doesn't require CPU service to complete a bus access (decouple them); (buffering) make the access a posted write — the bridge completes it immediately (into a buffer), releasing the CPU, and drains it to the peripheral independently. You choose the timeout (simplest) plus a posted-write path for writes.
The watchdog. You also add a bus watchdog (18.1): if HREADY stays low beyond a bound, it recovers — the safety net for any deadlock that escapes design.

The example shows the recognition and the method: the hang looked like a stuck HREADY, but tracing further revealed a cycle (CPU → bridge → peripheral → CPU) with no single stuck component; mapping the wait-for graph found it; breaking one edge (timeout / posted write) resolved it; and a watchdog guards the rest. This is how you debug the hardest bug — a deadlock. This is the cycle broken.

8. Common Mistakes

Bridge-deadlock debugging misconceptions

"It's a stuck slave — find the broken component." No — a deadlock has no single broken component; each party is correctly waiting. It's a cycle. Map the wait-for graph.
"Keep tracing the stuck HREADY to the one bad slave." No — you'll go in circles (literally the deadlock cycle). Recognize it's a deadlock and map the cycle.
"Fix every waiting component." No — none is broken. Break one edge of the cycle (remove one of the four conditions). One edge breaks the whole cycle.
"A timeout masks the bug." A timeout (abort with ERROR) is a legitimate fix (removes hold-and-wait) — and a needed safety net. (It's only "masking" if you ignore the underlying cycle; ideally also fix by ordering/buffering.)
"No watchdog needed if the design is correct." No — deadlocks are hard to find; a watchdog is the essential safety net for the deadlock you missed. Always have one.
"Deadlocks only happen with bad components." No — they're emergent from correctly-designed components forming a cycle (a system-integration failure). Prevent by design (break a condition).

9. Interview Insight

Bridge deadlock is an expert debug interview topic — the it's-a-cycle-not-a-stuck-slave recognition, the wait-for-graph mapping, and the break-one-edge + watchdog discipline are the signals.

Figure 4 — a strong answer in one card: a deadlock is a circular wait (master → bridge → downstream → master), not a stuck slave; the bridge's hold-and-wait (holds upstream while running downstream) closes the cycle; diagnose by mapping what each party waits for and finding the cycle (looks like a stuck HREADY but is a cycle); break ONE edge — timeout (abort with ERROR), ordering, or buffering; a watchdog is the safety net. The senior point: map what each party waits for, find the cycle, and break exactly one edge.

The answer that lands gives the cycle recognition and the break-one-edge fix: "A bridge deadlock is a circular wait — the master, the bridge, and the downstream get stuck waiting on each other in a circle, so nothing completes. It looks like a stuck HREADY — the bus is hung — but the cause is different: not a single stuck slave, but a dependency cycle. The bridge holds its upstream side with wait states while it runs the downstream transaction — that's necessary for rate-matching — and that hold-and-wait closes a cycle if the downstream depends back on the upstream. The classic case: the master is waiting for the bridge to complete; the bridge is waiting for the downstream peripheral; but the peripheral is waiting on the master — maybe it needs the master to service an interrupt, or release a shared resource the master holds. So master to bridge to downstream to master — a cycle where each party is correctly waiting but together they never progress. All four classic deadlock conditions hold: mutual exclusion, hold-and-wait, no preemption, and circular wait. The key debugging insight is recognizing it's a deadlock, not a stuck slave. If I use the stuck-HREADY method — decode the address, find the bridge, check why its HREADYOUT is stuck — I'd find it's not stuck because of its own logic; it's correctly waiting on the downstream. And the downstream is waiting on the master. There's no single broken component; if I keep chasing, I go in circles — literally following the deadlock cycle. So I recognize it's a deadlock and map the wait-for graph: what is each party waiting for, and is there a cycle. Then I break one edge — I don't fix every component, because none is broken. Three ways: a timeout, where the bridge or a watchdog aborts the held transfer with an error after a bound, removing hold-and-wait; ordering, redesigning so the downstream can't depend back on a blocked master, removing the circular wait; or buffering, a posted-write buffer so the bridge completes upstream immediately and drains downstream independently, removing hold-and-wait. One edge breaks the whole cycle. And I always have a bus watchdog as the safety net, because deadlocks are hard to find and some escape to silicon — the watchdog turns a permanent freeze into a recoverable fault." The cycle recognition, the wait-for-graph mapping, and the break-one-edge + watchdog discipline are the senior signals.

🔍 The discriminator: a deadlock is a CIRCULAR WAIT (no single stuck component) — recognize it's NOT a stuck slave (the stuck-HREADY method goes in circles); map the wait-for graph, find the cycle; break ONE edge (timeout/ordering/buffering) — don't fix every component; ALWAYS have a watchdog safety net

The discriminator on a bridge deadlock is whether you recognize it's a circular wait (not a stuck slave) and break one edge (not fix every component). A weak answer says "the bus is hung at the bridge, I'd debug the bridge." A solid answer adds that the bridge is waiting on the downstream. But the senior answer recognizes the deadlock: there's no single stuck component — each party (master, bridge, downstream) is correctly waiting, but they form a cycle (master → bridge → downstream → master). The standout insight is why the stuck-HREADY method fails: if you chase the single stuck slave (decode → that slave → why its HREADYOUT is stuck), you find it's not stuck due to its own logic — it's correctly waiting on the next party — so you go in circles (literally following the deadlock cycle). So you must recognize it's a deadlock and map the wait-for graph (what each party waits for) to find the cycle. The bridge's role is the signal: its hold-and-wait (holding upstream while waiting downstream — necessary for rate-matching, 16.10) is exactly the condition that closes the cycle when the downstream depends back on the upstream. And the four classic conditions (mutual exclusion, hold-and-wait, no preemption, circular wait) — all holding — formalize it. The break-one-edge discipline is the fix signal: you don't fix the components (none is broken) — you break the cycle by removing one edge (one condition): timeout (abort → removes hold-and-wait), ordering (removes circular wait), or buffering (removes hold-and-wait). And the watchdog is the essential safety net (deadlocks are hard to find; some escape — the watchdog recovers them). The framing that impresses: a bridge deadlock is a system-integration failure — emergent from correctly-designed components forming a cycle, no single culprit, hard to find — so the primary defense is prevention by design (break a condition) and the runtime safety net is a watchdog. A candidate who recognizes the cycle (not a stuck slave), maps the wait-for graph, breaks one edge, and insists on a watchdog demonstrates expert-level system-debug maturity — handling the hardest, most emergent class of bug.

10. Practice Challenge

Build and reason from debugging a bridge deadlock.

The circular wait. Describe a bridge deadlock as a circular wait (master → bridge → downstream → master) and how the bridge's hold-and-wait closes the cycle.
Vs stuck HREADY. Explain why a deadlock is not a stuck slave and why the stuck-HREADY method fails (goes in circles).
Read the waveform. From Figure 2, explain how the permanent stall is recognized as a cycle (not a single stuck component).
Break one edge. Describe the three fixes (timeout / ordering / buffering) and which deadlock condition each removes.
The watchdog. Explain why a bus watchdog is essential even after design fixes.

11. Key Takeaways

A bridge deadlock is a circular wait — the master, bridge, and downstream wait on each other in a circle (master → bridge → downstream → master), so nothing completes. It's not a single stuck slave.
The bridge's hold-and-wait closes the cycle — the bridge holds upstream (wait states) while waiting downstream (necessary for rate-matching — 16.10); the cycle closes when the downstream depends back on the upstream.
All four conditions hold — mutual exclusion, hold-and-wait, no preemption, circular wait. Removing any one breaks the deadlock.
The stuck-HREADY method fails — chasing a single stuck slave goes in circles (each party is correctly waiting). Recognize the cycle, map the wait-for graph, and find the cycle.
Break one edge — timeout (abort with ERROR → removes hold-and-wait), ordering (no circular dependency → removes circular wait), or buffering (don't hold while waiting → removes hold-and-wait). Don't fix every component (none is broken).
Always have a watchdog — deadlocks are emergent and hard to find (some escape to silicon); a bus watchdog is the essential safety net (permanent freeze → recoverable fault). It's a system-integration failure — prevent by design, guard at runtime.

12. What Comes Next

You now can debug the hardest AHB bug — a deadlock. The final chapter generalizes the debugging skills into a repeatable method:

Waveform-Based Debug Methodology (next) — a repeatable method for debugging any AHB waveform, unifying all the failure modes of this module.

To revisit the contrast with a single stuck slave, see Stuck HREADY; for the bridge's hold-and-wait, see Bridge FSM (RTL); for the watchdog/assertion safety net, see AHB Assertions (SVA).