AMBA AXI · Module 3

The Transfer Event

Exactly when an AXI beat transfers — VALID && READY sampled on the rising ACLK edge — and why that single instant governs sampling, beat-counting, and off-by-one bugs.

The last chapter said a beat moves when VALID and READY are both high. This one pins down the word when to a single instant: the beat transfers on the rising ACLK edge where both are high — not during the cycle, not when either signal rises, but at the edge. That precision sounds pedantic until you realize it governs three practical things: where a monitor must sample the payload, how you count beats, and the off-by-one bugs that come from looking one cycle too early or too late. Getting the transfer event exact is what turns "I understand the handshake" into "I can read, count, and check it correctly."

1. The Transfer Is an Edge Event

AXI is synchronous: every channel is timed to a shared clock, ACLK, and signals are meaningful at the rising edge. So the transfer condition from Chapter 3.1 — VALID && READY — is evaluated at each rising ACLK edge:

A beat transfers on a rising ACLK edge if, and only if, VALID and READY are both high at that edge.

The transfer is therefore a discrete event, not a stretch of time. It happens, atomically, at one edge. Before that edge the beat hasn't moved; after it, the beat has moved and is committed. There is no "halfway transferred." This is the instant the destination captures the payload and the source is free to move on.

The transfer event — only edges where both are high

6 cycles

Figure 1 — the transfer event marked precisely. VALID is high from cycle 1, but READY is low at the cycle-1 edge, so nothing transfers there. At the cycle-2 edge both are high → D0 transfers (captured at that edge). At cycle 3 both are high again → D1 transfers. The transfer is the edge, not the cycle: same VALID, but only the edges where READY is also high move a beat.

2. What Happens At the Transfer Edge

The transfer edge is where two things happen at once, atomically:

The destination captures the payload. Whatever value is on the channel at that edge is the beat — that and only that. (The stability rule from 3.1 is what guarantees the value at the edge is the value the source intended.)
The source is released. Having seen the transfer, the source may present the next beat on the following cycle, or drop VALID if it has nothing more.

So the edge is a clean baton-pass: one beat is committed to the destination, and the channel is ready to carry the next. Nothing is pending across the boundary — which is exactly why a beat is the indivisible unit from Chapter 1.6.

Figure 2 — the atomic update at the transfer edge. On the rising edge where VALID and READY are both high, the destination captures this beat's payload and, simultaneously, the source is freed to advance to the next beat (or deassert VALID). One edge, two committed effects — no in-between state.

3. Sampled at the Edge, Not Over the Cycle

A consequence engineers must internalize: what matters is the signal value at the rising edge, not what it did between edges. AXI is edge-sampled. If READY is high for most of a cycle but low at the edge, no transfer occurs. If a glitch briefly raised VALID mid-cycle but it's low at the edge, nothing transfers. The combinational behaviour between edges is irrelevant to the protocol; only the sampled-at-the-edge values count.

This is why you never reason about AXI transfers by "how long was the signal high?" You reason edge by edge: at this edge, were both high? Each qualifying edge = exactly one beat. Hold both high for four cycles and you get four beats (one per edge), not one long transfer — the beat count equals the number of qualifying edges.

4. The Transfer Event Is How You Count Beats

Because each qualifying edge is exactly one beat, the number of transfer events is the number of beats moved — which ties straight back to the beat-vs-cycle distinction of Chapter 1.6. Cycles where the handshake doesn't complete are bubbles; they tick the clock but produce no transfer event.

Beats = transfer events, not cycles

7 cycles

Figure 3 — counting beats by transfer events. Over six cycles, VALID and READY are both high at only three edges (cycles 1, 2, and 5) — so three beats transferred, despite more cycles elapsing. Cycle 3–4 is a stall (READY low): the clock ticks, no transfer event, no beat. Count the marked edges, not the cycles.

Notice D2 is held stable across the cycle-3/4 stall (the stability rule) and finally transfers at cycle 5 — three transfer events, three beats, over six cycles. A monitor that counted cycles would report six; counting transfer events reports the correct three.

5. Why the Exact Instant Matters — Sampling Discipline

Here's where the precision earns its keep. To capture a beat correctly — in RTL, in a monitor, in an assertion — you must sample the payload at the transfer edge, and the off-by-one failures are unforgiving:

Sample one cycle early (before the transfer edge) and you read a value that wasn't accepted yet — possibly stale, possibly a beat that never transfers.
Sample at the transfer edge (VALID && READY) and you capture exactly the beat that moved. Correct.
Sample one cycle late and the source may have already advanced to the next beat — you capture beat N+1's data and attribute it to beat N.

In RTL the rule is simply "qualify your capture with the handshake," and it's one line:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — capture the payload AT the transfer event, never before/after.
always_ff @(posedge aclk) begin
  if (valid && ready)        // the transfer event: both high at this edge
    captured <= payload;     // commit exactly the beat that moved
end

Figure 4 — sampling discipline. Capturing one cycle early reads a beat that hasn't transferred (stale); capturing one cycle late reads the next beat (the source already advanced); capturing at the transfer edge (VALID && READY) captures exactly the beat that moved. Off-by-one in either direction corrupts which beat you think you saw.

This single discipline — sample on the transfer event — is behind a huge fraction of "my data is shifted by one beat" bugs in both RTL and testbenches.

6. One Clock, Edge-Aligned

Two framing facts that the edge-event view rests on. First, a standard AXI interface is synchronous to a single clock, ACLK — all five channels share it, so "the rising edge" is unambiguous. (Crossing between two clocks is a clock-domain-crossing problem handled by bridges — Module 14 — not by the base handshake.) Second, because the transfer is edge-sampled, the usual setup/hold discipline applies: VALID, READY, and the payload must be stable around the edge for the sample to be valid — which is automatic in well-formed synchronous RTL and is exactly what the stability rule enforces at the protocol level. You don't need timing analysis to use AXI, but knowing the transfer is an edge sample is why stability and a clean clock matter.

7. Common Misconceptions

Myths to unlearn

"The transfer happens during the cycle while both are high." It happens at the rising edge where both are high — a discrete event, not a span. Edge-sampled, not level-measured.
"Holding VALID and READY high longer transfers more of one beat." No — each qualifying edge is exactly one beat. Four cycles both-high = four beats, not one bigger transfer.
"A glitch that briefly raises a signal can cause a transfer." Only the value at the rising edge matters; mid-cycle behaviour is irrelevant to the protocol. (Glitches are a timing/electrical concern, not a transfer.)
"You can sample the data whenever during the transaction." You must sample at the transfer edge (VALID && READY). One cycle early = stale; one cycle late = the next beat. This is the classic off-by-one.
"Counting cycles tells me how many beats moved." No — count transfer events. Stall cycles tick the clock but move no beat.

8. Debugging Insight

🔍 Debugging insight — line your cursor up on the transfer edges

When data looks wrong on a capture, the first move is to find the transfer edges — the rising edges where both VALID and READY are high — and read the payload only there. Most "wrong data" reports dissolve once you do this:

Data looks shifted by one beat? You (or the RTL) sampled one edge off. Re-read the payload exactly at each VALID && READY edge; the values almost always line up. This is the single most common waveform-reading mistake.
"It transferred N beats but I expected M"? Count the qualifying edges, not the cycles the signals were high. Stalls (qualifying condition false at the edge) don't count; a long both-high stretch counts once per edge.
An RTL block captures stale or duplicated data? Check that its capture is gated by valid && ready, not by valid alone (captures too early/repeatedly) or by a delayed strobe (captures late). The fix is to qualify the capture with the transfer event.

The habit — mark the transfer edges first, then read — is what separates engineers who can debug an AXI waveform from those who guess.

9. Verification Insight

✅ Verification insight — sample on the transfer event, in the right region

A monitor's correctness hinges on this instant: it must record each beat on the transfer event (VALID && READY at the clock edge), because that's the one moment the beat is real. Sampling on VALID alone records beats that may never transfer (the destination wasn't ready); sampling on a delayed strobe records the wrong beat. Reconstructing a transaction (Chapters 2.2/2.3) is exactly "collect the payload on each transfer event until LAST."

There's also a SystemVerilog timing subtlety this motivates: testbench sampling must occur in a well-defined scheduling region (conventionally, monitors sample in the clocking-block / NBA region) so the monitor reads the settled edge values, not mid-delta-cycle intermediates — otherwise a monitor and the DUT can disagree on a beat that "passed." Concurrent assertions are written against the same edge so they evaluate the handshake at the sampling point. The takeaway for now: the transfer event is the sampling point for monitors, scoreboards, and assertions alike — get the instant right and the data lines up; get it wrong and you chase phantom mismatches. Mechanics in Module 16.

10. Interview Questions

11. Summary

An AXI beat transfers at a single, discrete instant: the rising ACLK edge where VALID and READY are both high. It is an edge event, not a span — at that edge the destination captures the payload and the source is freed to advance, atomically and with nothing left pending. Because the protocol is edge-sampled, only the values at the edge matter (mid-cycle behaviour is irrelevant), and each qualifying edge is exactly one beat — so the number of beats moved is the number of transfer events, never the number of cycles.

That precision is practical, not academic. It dictates sampling discipline: capture the payload at the transfer edge — one cycle early reads a stale/never-transferred beat, one cycle late reads the next beat, and either is the classic one-beat shift that haunts RTL and testbenches. So in RTL gate captures with valid && ready; in a monitor record on the transfer event in the right sampling region; when debugging, mark the transfer edges first and read the payload only there. Nail the instant and beats line up; miss it and you chase phantom off-by-one mismatches. Next: what happens when the destination deliberately withholds READY — backpressure.

12. What Comes Next

You can pinpoint the transfer. Module 3 now uses that to study flow control and performance:

3.3 — Backpressure & Stalls (coming next) — how a destination de-asserting READY stalls a channel and propagates upstream.
3.4 — Handshake Throughput (coming soon) — connecting back-to-back transfer events to sustained throughput and bubbles.

Previous: 3.1 — The VALID/READY Handshake. For the broader protocol catalog, see the AMBA family overview doc.