AMBA AXI · Module 11

TVALID, TREADY & TDATA

The core AXI4-Stream signals — TVALID/TREADY handshake and TDATA payload. The four handshake states, the stability and no-retraction rules, full-rate throughput vs backpressure/starvation bubbles, and how it mirrors the AXI VALID/READY handshake.

AXI4-Stream's core is just three signals: TVALID, TREADY, and TDATA. The handshake is the same VALID/READY mechanism as memory-mapped AXI (Module 3) — a transfer happens on a clock edge when both TVALID and TREADY are high — now governing a one-way data pipe. This chapter details the stream handshake: the four states, the stability and no-retraction rules that keep data intact, and how full-rate throughput degrades into bubbles under backpressure or starvation. If you know the AXI handshake, this is that knowledge applied to the stream — but it's worth nailing precisely, because in a streaming protocol the handshake is essentially the whole thing.

1. The Three Signals

TVALID — driven by the source; asserted when the source has a valid data word on TDATA to transfer.
TREADY — driven by the sink; asserted when the sink can accept a word this cycle.
TDATA — the payload, driven by the source; the stream's actual content. Width is implementation-defined (typically a multiple of 8 bits).

A transfer occurs on the rising clock edge when both TVALID and TREADY are high — one TDATA word moves from source to sink. That's the entire core mechanism: the source offers data (TVALID), the sink accepts it (TREADY), and when they agree, a word flows.

Figure 1 — the four handshake states. Both high → transfer (a word moves). TVALID high, TREADY low → backpressure (source waits, data held). TVALID low, TREADY high → starvation (sink waits, no data). Both low → idle. A transfer happens only in the both-high state — identical to AXI's VALID/READY.

2. The Rules — Stability and No Retraction

The handshake carries the same correctness rules as AXI (Module 3), now on the stream:

No TVALID-on-TREADY dependency. The source must not wait to see TREADY before asserting TVALID — TVALID may not combinationally depend on TREADY. (The sink may wait for TVALID before TREADY, or assert TREADY early — "pre-ready.") This asymmetry prevents handshake deadlock.
Hold stable until accepted. Once the source asserts TVALID, it must keep TVALID high and hold TDATA (and all payload signals) stable until the transfer completes (the cycle TREADY is also high). No retracting the offer, no changing the data mid-offer.
No transfer without both. A word moves only when both are high on a clock edge. If TREADY is low, the source waits (holding data); if TVALID is low, the sink waits (no data to take).

Violating stability corrupts the stream (the sink may sample changing data); retracting TVALID before acceptance loses or duplicates a word. These are the identical pitfalls as the AXI handshake — the stream just has one such handshake instead of five channels' worth.

Figure 2 — the handshake rules. TVALID must not depend on TREADY (no deadlock); once TVALID is asserted, TDATA and TVALID must stay stable until TREADY completes the transfer (no retraction, no mid-offer data change). A word transfers only when both are high. These are the same VALID/READY rules as memory-mapped AXI.

3. On the Wire — Transfers and Bubbles

Data flows at full rate when both signals stay high; backpressure (TREADY low) or starvation (TVALID low) inserts bubbles:

stream-transfer — transfers with backpressure and starvation bubbles

8 cycles

Figure 3 — stream-transfer: TVALID/TREADY/TDATA flow. D0 transfers when both are high; then TREADY drops (backpressure) so D1 is held stable until TREADY returns and D1 transfers; then TVALID drops (starvation — no data) inserting a bubble; then D2 and D3 transfer back-to-back. A word moves only on a both-high cycle; bubbles are cycles where one side isn't ready.

4. Throughput — Full Rate and Bubbles

The throughput consequence is direct: when both TVALID and TREADY stay high every cycle, the stream moves one word per cycle — full rate, the maximum the link can carry. Any cycle where one side isn't ready is a bubble (no transfer):

Backpressure bubble (TREADY low) — the sink can't keep up (its buffer is full, or it's busy). The source holds its data and stalls.
Starvation bubble (TVALID low) — the source has no data (it's waiting on its own upstream). The sink waits idle.

So a stream's sustained throughput equals the slower of the producer's data-supply rate and the consumer's accept rate — exactly like a pipe limited by its narrowest point. To hit full rate, both sides must sustain a word every cycle; buffering (FIFOs) between stages smooths bursty producers/consumers so a momentary stall on one side doesn't bubble the whole pipeline. This is the streaming form of the same throughput reasoning as AXI's handshake and outstanding-transaction discussions — but here it's purely about keeping both handshake signals high.

Figure 4 — throughput. Both signals high every cycle = full rate (one word/cycle). A TREADY-low cycle is a backpressure bubble (sink can't keep up); a TVALID-low cycle is a starvation bubble (source has no data). Sustained throughput equals the slower side; FIFOs between stages absorb momentary stalls to keep the pipe full.

5. Common Misconceptions

Myths to unlearn

"The source should wait for TREADY before asserting TVALID." No — TVALID must not depend on TREADY (deadlock risk). The source asserts TVALID when it has data, regardless of TREADY.
"TDATA can change while TVALID is held." No — once TVALID is asserted, TDATA (and all payload) must stay stable until the transfer completes. Changing it corrupts the stream.
"A word transfers when TVALID goes high." Only when both TVALID and TREADY are high on a clock edge. TVALID alone is just an offer.
"The sink can't assert TREADY before there's data." It can — TREADY may be asserted early ("pre-ready"); the transfer simply waits for TVALID. Only the reverse dependency is forbidden.
"Bubbles mean something is broken." Bubbles are normal flow control — backpressure (sink busy) or starvation (source waiting). They reduce throughput but aren't errors; the handshake is working as intended.
"This handshake is different from AXI's." It's the same VALID/READY mechanism and rules — the stream just has one handshake (per direction) instead of five channels.

6. Debugging Insight

🔍 Debugging insight — stream handshake bugs are deadlock, corruption, and bubbles

The core stream signals fail in the same ways as the AXI handshake:

Stream completely stuck (deadlock)? Likely a TVALID-on-TREADY dependency — the source waits for TREADY while the sink waits for TVALID, a circular wait. The source must drive TVALID independently of TREADY. Check the source's TVALID logic for a combinational path from TREADY.
Data words corrupted or wrong? A stability violation — TDATA changed while TVALID was held (before TREADY), so the sink sampled the wrong value, or TVALID was retracted mid-offer. Confirm the source holds data stable until accepted.
Words lost or duplicated? A handshake-counting error — something registered a transfer when both weren't high, or missed one. The transfer condition is strictly TVALID && TREADY on the clock edge.
Throughput below full rate? Bubbles — measure where TVALID or TREADY is low. TREADY low → sink can't keep up (add buffering or speed the sink); TVALID low → source starved (the upstream is the bottleneck). This is performance, not a correctness bug.

The triage is identical to AXI handshake debug (Module 3): stuck → TVALID/TREADY dependency; corruption → stability; lost/dup → transfer-condition error; slow → bubbles. The difference is it's the whole protocol here, so handshake correctness is paramount.

7. Verification Insight

✅ Verification insight — handshake compliance and data integrity under all flow patterns

Stream handshake verification asserts the VALID/READY rules and checks data integrity under every flow pattern. Compliance: TVALID does not depend on TREADY (no deadlock); TDATA and TVALID are stable once asserted until the transfer completes; a transfer is counted only when both are high. Data integrity: a scoreboard that's an ordered FIFO — every TDATA word the source sent arrives at the sink, in order, uncorrupted, none lost or duplicated.

Coverage must exercise the flow patterns that create bubbles: continuous full-rate transfer (both high every cycle), backpressure (sink deasserting TREADY at varied points, including mid-stream and for multiple cycles), starvation (source gapping TVALID), and combinations (alternating, random stalls on both sides). The highest-value tests are the random backpressure/starvation interleavings — stalling each side at adversarial points and confirming no word is lost, duplicated, or corrupted and the stream stays in order. This is the stream analog of AXI handshake verification, and since the stream protocol is essentially this handshake plus payload, getting it airtight under all flow conditions is most of stream verification. Framing (TLAST), byte qualifiers, and routing add their own checks in the next chapters.

8. Interview Questions

9. Summary

The AXI4-Stream core is TVALID (source has data), TREADY (sink can accept), and TDATA (the payload) — a transfer happens when both TVALID and TREADY are high on a clock edge, the same VALID/READY mechanism as memory-mapped AXI (Module 3). The four states are transfer (both high), backpressure (TREADY low), starvation (TVALID low), and idle (both low). The correctness rules are identical to AXI: TVALID must not depend on TREADY (deadlock avoidance), and once asserted the source must hold TVALID and TDATA stable until accepted (no retraction, no mid-offer change). Violations cause deadlock or stream corruption.

Throughput is one word per cycle when both stay high; any cycle where one side isn't ready is a bubble (backpressure or starvation), so sustained rate equals the slower side — and FIFOs/skid buffers between stages absorb momentary mismatches to keep a pipeline full. Because the stream protocol is essentially this handshake plus payload, getting it airtight under all flow patterns (full rate, backpressure, starvation, random interleavings) is most of stream verification, and the debug taxonomy mirrors AXI's handshake exactly (stuck→dependency, corruption→stability, lost/dup→transfer-condition, slow→bubbles). Next: TLAST — how a stream is framed into packets.

10. What Comes Next

You've got the core handshake; next, framing the stream:

11.3 — TLAST & Packet Boundaries (coming next) — how TLAST marks the end of a packet/frame, structuring an otherwise-continuous stream.
11.4 — TKEEP & TSTRB (coming soon) — byte qualifiers for partial and position bytes.

Previous: 11.1 — The AXI4-Stream Mental Model. Related: Valid/Ready Handshake — the memory-mapped handshake this mirrors. For the broader protocol catalog, see the AMBA family overview doc.