AMBA AXI · Module 17

Stuck VALID / Stuck READY

Diagnose an AXI channel hung on VALID or READY — the two stuck signatures, the decisive question of which side is waiting on which, the combinational VALID-depends-on-READY deadlock, the cross-channel dependency hang, and the systematic waveform-reading method that localizes a stuck handshake to its root cause.

Module 17 turns from building and verifying to debugging — diagnosing the failures the previous modules surface. The most common AXI failure is a hung channel: a handshake that never completes, with VALID or READY stuck and traffic frozen. It's also the most misdiagnosed, because the symptom (one signal stuck high) rarely sits at the cause (often the other side, or another channel entirely). This chapter teaches the systematic diagnosis: read the two stuck signatures, ask the one decisive question — which side is waiting on which? — and trace it to the real root cause, whether a combinational VALID-on-READY loop, a producer that never asserts VALID, a consumer that never asserts READY, or a cross-channel dependency. Get the method right and a hung bus, the scariest-looking failure, becomes one of the fastest to localize.

1. The Two Stuck Signatures

A stuck handshake presents in one of two ways, and naming which you're looking at is the first step. Stuck-VALID: a channel's VALID is asserted and stays high forever — the producer has data but the consumer never accepts it (READY never comes). Stuck-READY-low (or never-VALID): READY is low or VALID never asserts — nothing is offered or nothing is accepted. The transfer condition VALID && READY never becomes true, so the channel is frozen.

Figure 1 — the two stuck signatures. Stuck-VALID: the producer holds VALID high but the consumer never asserts READY, so the offered beat is never accepted. Never-VALID / stuck-READY-low: VALID never asserts (nothing offered) or READY never asserts (nothing accepted). In both, VALID && READY never co-occur, so no beat transfers and the channel hangs. Identifying which signature you have is the first diagnostic step.

2. The Decisive Question: Who Waits on Whom?

The key to diagnosis is that AXI's handshake is asymmetric in dependency: READY is allowed to depend on VALID (a consumer may wait to see a request before asserting it can accept), but VALID must never depend combinationally on READY. So a stuck channel reduces to one question — which side is legitimately waiting, and which side has the bug?

Figure 2 — the decisive diagnostic question. Determine which side is waiting. If VALID is high and READY is low, the consumer is the suspect — why won't it accept? If VALID is low, the producer is the suspect — why won't it offer? The fatal case is a combinational loop: VALID waits for READY while READY waits for VALID, so neither moves. The legal dependency is READY-on-VALID; VALID-on-READY is the bug. Naming who waits on whom localizes the fault.

3. The Combinational-Loop Deadlock

The classic fatal bug is the combinational loop: the slave asserts READY only when it sees VALID (legal), and the master asserts VALID only when it sees READY (illegal). Each waits for the other in the same cycle and neither ever moves. The waveform signature is unmistakable — both signals sit low forever with valid intent on both sides.

Combinational VALID-on-READY deadlock

8 cycles

Figure 3 — the combinational VALID-on-READY deadlock. The master is (illegally) holding VALID low until it sees READY; the slave is (legally) holding READY low until it sees VALID. Both wait on the other in the same cycle, so VALID and READY stay low forever and no transfer occurs — a frozen channel with no progress from the first cycle. The signature is both signals stuck low with each side 'ready to go' but waiting. The fix is to drive VALID independently of READY.

This is why the rule from Chapter 3.5 exists: VALID (and its payload) must be driven independently of READY. When debugging, if both signals are stuck low and each side claims it's "ready," look for the combinational dependency — it's the most common deadlock and the assertion a_*_progress / formal independence check from 16.2 catches it.

4. The Cross-Channel Dependency Hang

A subtler hang has nothing wrong with the stuck channel itself — it's frozen because another channel is blocked, and the protocol's dependency rules chain them. For example, a write B response can't be issued until the W data completes; if W is stuck (say its WREADY never comes because a downstream buffer is full), then B never comes either, and a naive look at the B channel sees "stuck" with the cause one or more channels away. Diagnosis must follow the dependency chain backward to the channel that's originally blocked.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Debug instrumentation: per-channel "stuck" detection with a timeout watchdog.
// Flags a channel whose VALID has been high without READY for too long.
always_ff @(posedge aclk) begin
  if (!aresetn) stuck_cnt <= 0;
  else if (awvalid && !awready) stuck_cnt <= stuck_cnt + 1;
  else                          stuck_cnt <= 0;
  if (stuck_cnt > STUCK_LIMIT)
    $error("AW stuck: VALID high, READY low for %0d cycles", stuck_cnt);
end
// Repeat per channel; the FIRST channel to trip points nearest the root cause.

The watchdog per channel is the practical tool: when a hang occurs, the channel whose stuck-timer trips first (or the one furthest back in the dependency chain) is nearest the root cause — the others are downstream victims waiting on it.

Viewed as a tiny state machine, a healthy handshake cycles WAIT → OFFER → TRANSFER; a hang is the machine stuck in OFFER, looping on itself because the completion condition never arrives:

Figure 4 — the handshake as a state machine, and where it gets stuck. WAIT (VALID low, nothing offered) advances to OFFER when the producer asserts VALID; OFFER advances to TRANSFER only when READY arrives (VALID && READY). A stuck-VALID hang is the machine trapped in OFFER, self-looping forever because READY never comes — whether due to legitimate-but-permanent backpressure, a combinational loop, or a cross-channel dependency. A never-VALID hang is the machine stuck in WAIT. Diagnosis identifies which state is stuck and why its exit condition never fires.

5. Common Misconceptions

Myths to unlearn

"The stuck signal is where the bug is." Usually not — a stuck VALID means the consumer isn't accepting, and a stuck downstream channel may be blocked by an upstream one. The stuck signal is the symptom; the cause is often on the other side or another channel.
"READY low is always a bug." No — READY low is legal backpressure; a consumer may legitimately not be ready. It's only a bug if it's permanently low when it should accept, or part of a combinational loop. Transient READY-low is normal.
"VALID waiting for READY is fine — it's symmetric." It is not symmetric: READY may depend on VALID, but VALID must never depend combinationally on READY. That asymmetry is the whole point — violating it creates the deadlock.
"A hung channel means that channel's logic is broken." It may be a cross-channel hang — the channel is frozen because another channel it depends on is blocked. Follow the dependency chain backward; the originally-blocked channel is the real fault.
"You can debug a hang by staring at one signal." You need the pair (VALID and READY) and often multiple channels, plus the question of who's waiting on whom. A single signal doesn't tell you whether it's a producer or consumer fault.
"If it's stuck, it's a functional bug in an FSM." Often it's the handshake dependency (combinational VALID-on-READY) or backpressure propagation (a full downstream buffer), not a state-machine logic error. Check the handshake structure before the FSM internals.

6. Debugging Insight

🔍 Debugging insight — the systematic method for a hung channel

Diagnose a stuck handshake in order:

Identify the signature. Is VALID high with READY low (stuck-VALID, consumer suspect), or is VALID never asserting (producer suspect), or both low (possible combinational loop)? Name it first.
Ask who waits on whom. VALID high + READY low → the consumer isn't accepting; investigate why its READY won't assert. VALID low → the producer isn't offering; investigate why. Both low with both "ready" → suspect the combinational loop.
Check the legal dependency direction. Confirm VALID is driven independently of READY. A combinational path READY → VALID is the classic deadlock — the structural/liveness assertion (16.2) pinpoints it.
Follow cross-channel dependencies backward. If the stuck channel depends on another (e.g. B waits on W, or a downstream buffer is full), trace to the channel that's originally blocked — per-channel stuck-watchdogs tell you which tripped first.
Look for backpressure source. A consumer's READY permanently low often means a full downstream buffer/FIFO (15.7) it feeds — the hang is rate/deadlock, not a handshake-logic bug. Check the buffer occupancy.
Confirm against the protocol checker. The handshake/liveness assertions (16.2) and the monitor (16.3) localize the stuck channel, cycle, and rule — let them point you before manual waveform staring.

The unifying method: signature → who-waits-on-whom → dependency direction → backward through channels → backpressure source. The stuck signal is the symptom; this chain leads to the cause, which is frequently a different signal, side, or channel than the one that looks stuck.

7. Verification Insight

✅ Verification insight — instrument for liveness, and let assertions catch the deadlock the moment it happens

A stuck handshake is fundamentally a liveness failure — "something that should eventually happen never does" — and the verification discipline is to make liveness failures visible and localized rather than appearing as a simulation that simply hangs. Three measures. (1) Per-channel stuck-watchdogs — instrument each channel with a timeout that fires if VALID is held without READY (or a request is outstanding) for more than a threshold, so a hang becomes an error with a channel name and cycle instead of a silent freeze; the channel whose watchdog trips first is nearest the root cause, and the others are downstream victims. (2) The handshake/liveness assertions from 16.2 — the VALID-stable-until-READY checks plus the eventually-accepted liveness property catch the stuck condition the moment it violates the protocol, and the combinational-independence (VALID ⊥ READY) is best proven formally, since formal will produce a minimal deadlock counterexample rather than relying on simulation happening to hit it. (3) Follow the dependency model — because hangs propagate across channels (a blocked W freezes B; a full buffer freezes its producer), the debug must trace backward along the protocol's dependency chain and the design's backpressure paths to the originally-blocked point, which the per-channel watchdogs and the monitor's transaction view support. The decisive diagnostic principle — who is waiting on whom — maps directly onto the protocol's dependency asymmetry: READY-on-VALID is legal, VALID-on-READY is the bug, and cross-channel waits follow the spec's ordering dependencies. The highest-leverage habit is to never let a hang manifest as "the sim stopped" — always have watchdogs and liveness assertions so a stuck handshake announces which channel, which side, which cycle, turning the scariest-looking failure (a frozen bus) into one of the most localizable. This sets up the rest of Module 17: most AXI debugging is reading the handshake and the dependency chain, and a stuck channel is the canonical case. Next, we diagnose a burst that hangs for a related but distinct reason — a missing WLAST/RLAST.

8. Interview Questions

9. Summary

A stuck AXI handshake — the most common and most misdiagnosed failure — presents in two signatures: stuck-VALID (VALID high, READY never comes → suspect the consumer) and never-VALID / stuck-READY-low (nothing offered or accepted → suspect the producer), with the transfer condition VALID && READY never satisfied. Diagnosis hinges on the decisive question — who waits on whom — answered by the protocol's dependency asymmetry: READY may legally depend on VALID, but VALID must never depend combinationally on READY. The classic fatal bug is the combinational loop (master holds VALID until READY, slave holds READY until VALID — both stuck low forever), fixed by driving VALID independently. A subtler cross-channel hang freezes a channel because another it depends on is blocked (e.g. B waits on a stuck W, which waits on a full buffer), requiring you to trace the dependency chain backward to the originally-blocked point.

The systematic method: signature → who-waits-on-whom → dependency direction → backward through channels → backpressure source. Because a stuck handshake is a liveness failure (a silent freeze with no error event), the discipline is to make it visible and localized with per-channel stuck-watchdogs (the first to trip is nearest the root) and the liveness/independence assertions from 16.2 (with combinational independence proven formally). The protocol's dependency graph turns a single blockage into a system-wide hang, so the real skill is finding the root of the dependency graph and checking for cycles — the stuck signals are mostly propagation. Next, we diagnose a related burst hang with a distinct cause: a missing WLAST/RLAST.

10. What Comes Next

You can now diagnose a hung handshake; next, a burst that hangs for a different reason:

17.2 — Missing LAST (coming next) — diagnosing a burst that never asserts WLAST/RLAST, so the burst never ends and the response never comes — a hang with a beat-count root cause rather than a handshake one.

Previous: 16.9 — Using AXI VIP. Related: 3.5 — Handshake Dependency & Deadlock Rules for the dependency asymmetry this diagnosis rests on, 3.3 — Backpressure & Stalls for legal vs. stuck READY, and 16.2 — AXI Assertions (SVA) for the liveness assertions that catch a hang.