AMBA AXI · Module 3

The VALID/READY Handshake

The single transfer contract every AXI channel uses — VALID, READY, transfer on both-high, the stability rule, and the cardinal rule that VALID must never wait for READY.

There is exactly one transfer mechanism in AXI, and every channel on every memory-mapped variant uses it: the VALID/READY handshake. Learn it once — truly, precisely — and you know how AW, W, B, AR, and R all move data; the channels differ only in their payload. This chapter nails the contract: the source asserts VALID when it has something to send, the destination asserts READY when it can take it, and a single beat transfers on the clock edge where both are high. Then come the two rules that separate engineers who use AXI from those who only recognise it — the stability rule and the cardinal rule that VALID must never wait for READY. The deadlock dependency graph across channels is Module 3.5; here we make the single-channel contract exact.

1. One Handshake, Every Channel

Every AXI channel is a one-directional pipe with two control signals and a payload:

VALID — driven by the source (the side sending information on this channel). It means "the payload is valid right now; take it."
READY — driven by the destination (the receiving side). It means "I can accept a payload this cycle."
The payload — the channel's actual content (an address on AW/AR, data on W/R, a response on B).

A transfer — one beat — happens on the rising clock edge where VALID and READY are both high. That's the entire mechanism. It is identical on all five channels; only who is the source changes (the manager sources AW/W/AR; the subordinate sources B/R) and what the payload is. Internalise this once and four-fifths of "learning AXI signals" is already done.

Figure 1 — the handshake as three states. From IDLE, the source asserts VALID when it has data and then holds it; while READY is low it stays asserted (waiting); on the edge where VALID and READY are both high, one beat TRANSFERS — then back to IDLE, or straight to the next beat. Every AXI channel runs this same cycle.

2. The Transfer Condition

Say it as a single line, because everything else builds on it:

A beat transfers on the rising clock edge where VALID && READY are both asserted.

Not when VALID rises. Not when READY rises. On the edge where both are simultaneously high. If VALID is high but READY is low, nothing transfers — the source is offering, the destination isn't taking. If READY is high but VALID is low, nothing transfers — the destination is willing, the source has nothing. Only the coincidence of both high moves a beat. (Exactly when in the cycle this is sampled — the rising-edge timing — is Chapter 3.2's focus; here, the logical condition is what matters.)

3. The Stability Rule

The contract has a crucial obligation on the source: once you assert VALID, you must keep it asserted — and keep the payload stable — until the transfer happens. You cannot offer a beat, then change your mind or change the data before the destination has taken it.

Concretely: if a source raises VALID with address A, and the destination's READY is low for three cycles, the source must hold VALID high and keep the address at A for all three cycles, until the cycle where READY is finally high and the beat transfers. Dropping VALID early, or mutating the payload mid-wait, breaks the contract and corrupts or loses the transfer.

This is what makes the handshake robust: the destination can take its time, confident the offered payload won't vanish or mutate underneath it.

In RTL, correct source behaviour is short — and the wrong version is the classic bug:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — correct source: VALID comes from having data, never from READY.
assign valid = have_data;              // ✅ assert when I have something to send
// hold `valid` AND the payload stable until the beat moves:
wire transfer = valid && ready;        // one beat moves on this edge
 
// ❌ WRONG — VALID must never be a function of READY:
// assign valid = ready;               // can deadlock (see §6) and breaks the contract

4. A Normal Transfer

The clean case: the destination is ready, so beats move back-to-back, one per cycle.

Normal transfer — both high, one beat per cycle

6 cycles

Figure 2 — a normal transfer. VALID and READY are both high across cycles 1–3, so a beat (D0, D1, D2) transfers on each of those edges — full throughput, one beat per cycle, no waiting. This is the handshake at its best: both sides agree every cycle.

5. A Stalled Transfer

Now the destination isn't ready immediately. The source asserts VALID with D0 and holds it stable while READY is low; the beat transfers only when READY finally rises.

Stalled transfer — VALID held stable until READY rises

7 cycles

Figure 3 — a stalled transfer. The source asserts VALID with D0 at cycle 1, but READY is low until cycle 4. The source must hold VALID high and keep data = D0 stable across the whole stall; the single beat transfers only at cycle 4, where both are finally high. The held-stable VALID and payload through the wait is the stability rule in action.

The destination holding READY low to delay a transfer is backpressure — the universal flow-control mechanism — and it's the subject of Chapter 3.3. The point here is narrower: whatever the destination does, the source's job during a stall is to hold steady.

6. The Cardinal Rule — VALID Must Not Wait for READY

Now the rule that prevents the single most common AXI hang. The two sides are not symmetric:

The destination's READY may depend on VALID. It's legal for a destination to wait until it sees VALID before asserting READY (e.g., "I'll only signal ready when there's actually something to take").
The source's VALID must never depend on READY. A source must assert VALID based only on its own data being available — never "I'll assert VALID once I see READY."

The reason is deadlock. If the source waits for READY before asserting VALID, and the destination waits for VALID before asserting READY, then neither ever fires — both sides wait forever for the other to move first. By forbidding the source from waiting, AXI guarantees at least one side always makes the first move, so the handshake can always complete.

Figure 4 — the asymmetry that prevents deadlock. READY is allowed to depend on VALID (the destination may wait to see an offer). VALID is forbidden from depending on READY (the source must offer from its own data). If both waited for the other, neither would ever assert — a permanent hang. The single banned dependency is what keeps the handshake alive.

Hold this as a one-line guardrail: a source asserts VALID from its own readiness; a destination may key READY off VALID; never the reverse. The full cross-channel dependency graph (which VALID/READY pairs may legally depend on which, across AW/W/B/AR/R) builds on exactly this and is Chapter 3.5.

7. Why One Contract Is So Powerful

It's worth pausing on the design elegance, because it explains why AXI is learnable at all. By making every channel use the identical handshake:

You learn it once. Understand VALID/READY here and you can read transfers on any channel of any memory-mapped AXI variant — the payload changes, the handshake doesn't.
Backpressure is universal. Every channel can be throttled the same way (destination lowers READY), so flow control composes across the whole interconnect.
The building blocks are reusable. Skid buffers, FIFOs, and pipeline registers built around VALID/READY work on any channel (Module 15) — and the same monitor/assertion ideas verify any channel (Module 16).

The handshake is the atom. Decoupling (Chapter 2.4) is what you get by running five of these atoms independently; everything else in the protocol is payload and rules layered on top.

8. Common Misconceptions

Myths to unlearn

"A beat transfers when VALID rises." No — it transfers on the edge where both VALID and READY are high. VALID alone moves nothing.
"The source can drop VALID if it changes its mind." No — once VALID is asserted it must stay high, with the payload stable, until the transfer completes. That's the stability rule.
"VALID and READY are symmetric." They are not. READY may depend on VALID; VALID must never depend on READY. The asymmetry is deliberate and prevents deadlock.
"Waiting for READY before asserting VALID is just cautious." It's the bug — if the destination is also waiting for VALID, you deadlock. The source must assert from its own data readiness.
"Different channels have different handshakes." Every AXI channel uses the same VALID/READY handshake. Only the source/destination roles and the payload differ.

9. Debugging Insight

🔍 Debugging insight — read the two signals and you know who's blocking

A stalled or hung channel is diagnosed by looking at just VALID and READY, and the four combinations each mean something exact:

VALID high, READY low (persisting): the destination isn't accepting — a busy/backpressuring or mis-coded receiver. The source is doing its job (offering, holding stable); look downstream.
READY high, VALID low (persisting): the source has nothing to send — it never produced the data, or its VALID-generation logic is wrong. Look upstream.
Both low forever: the deadlock of §6 — almost always a source that waits for READY (so VALID never rises) while the destination waits for VALID (so READY never rises). Check the source's VALID equation: if it references READY, that's the bug.
Payload changing while VALID is high before transfer: a stability-rule violation — the source is mutating data mid-offer, which corrupts the beat.

So "the channel is stuck" becomes a precise question — which signal is missing, and is VALID illegally a function of READY? — answerable from two wires.

10. Verification Insight

✅ Verification insight — the handshake is mostly assertions, and they're reusable

Because the contract is small and exact, most of it is checked with a handful of protocol assertions that apply to every channel — write them once, bind them everywhere:

Stability: while VALID is high and the beat hasn't transferred (VALID && !READY), the payload must not change, and VALID must not drop.
No VALID-waits-for-READY: structurally, the source's VALID must not be a combinational function of READY (caught in review and by deadlock/timeout checks).
Liveness: an asserted VALID must eventually see READY (and vice versa) — a transfer must not be deferred forever; a timeout assertion flags a hang.

Stimulus-side, the lever is independent READY-delay models per channel: randomly stall the destination (drop READY) to exercise the stability rule and backpressure paths, and randomly delay the source's VALID. A testbench that always keeps READY high never tests the stall behaviour where real bugs live. These assertions and ready-delay agents are the backbone of AXI VIP — built on this one contract, reused across all channels (Module 16).

11. Interview Questions

12. Summary

Every AXI channel moves data with one contract: the source asserts VALID when its payload is valid, the destination asserts READY when it can accept, and a beat transfers on the rising clock edge where both are high. Two rules make it robust. The stability rule: once VALID is asserted, the source holds VALID and the payload steady until the transfer completes — no withdrawing, no mutating. The cardinal rule: VALID must never depend on READY (though READY may depend on VALID), because a mutual wait deadlocks — this single banned dependency keeps the handshake alive.

Read a channel by its two control signals: VALID high with READY low means the destination is blocking; the reverse means the source has nothing; both low forever is the VALID-waits-for-READY deadlock; payload changing under a held VALID is a stability violation. Verify it with a small, reusable set of stability, independence, and liveness assertions plus per-channel READY-delay stimulus. Because this one handshake is identical on AW, W, B, AR, and R, mastering it here is most of "knowing AXI signals." Next we sharpen the timing of the transfer itself — exactly when, on the clock edge, the beat is considered to have moved.

13. What Comes Next

You have the contract. Module 3 now refines it — the precise transfer instant, then backpressure, throughput, and the cross-channel dependency rules:

3.2 — The Transfer Event (coming next) — exactly when a beat transfers (VALID && READY sampled on the rising edge) and why the sampling instant matters.
3.3 — Backpressure & Stalls (coming soon) — how READY de-assertion throttles a channel and propagates upstream.

Previous: 2.5 — AXI4 vs AXI3 vs AXI4-Lite vs AXI4-Stream. For the broader protocol catalog, see the AMBA family overview doc.