AMBA AXI · Module 19

AXI4-Stream Video Pipeline

Build a capture-process-display video pipeline with AXI4-Stream — the address-less streaming plane where data flows continuously: how pixels stream through processing stages, TLAST marks frame/line boundaries, TUSER carries start-of-frame, backpressure throttles the whole pipeline, and why streaming (not memory-mapped) AXI fits continuous dataflow.

The three previous case studies were all memory-mapped — they had addresses (CPU loads, DMA writes, CSR registers). A fourth, fundamentally different pattern has no addresses at all: AXI4-Stream, where data simply flows from producer to consumer continuously. The canonical example is a video pipeline: pixels stream from a camera (capture) through processing stages (filters, format conversion) to a display, in an unbroken flow where each pixel goes to "the next stage," not to an address. This chapter builds a capture→process→display pipeline to show the streaming plane — AXI4-Stream's TVALID/TREADY/TDATA/TLAST/TUSER carrying continuous dataflow, how frame/line structure is marked, and how backpressure throttles the whole chain — completing AXI's design-space tour with its address-less member.

1. The Streaming Pattern: Continuous Dataflow, No Addresses

AXI4-Stream carries a continuous flow of data from a producer to a consumer with no address — data goes to "whoever's downstream," not to a location. A video pipeline is the archetype: the camera produces a stream of pixels, each processing stage consumes the stream, transforms it, and produces a new stream, and the display consumes the final stream — a dataflow graph, not a memory map. The handshake is the familiar TVALID/TREADY (a beat transfers when both are high), and the payload is TDATA (the pixel/data), but there are no AW/AR/address channels — the stream is the channel. This is the right model when data flows in one direction continuously and position-in-the-stream, not address, defines where data goes.

Figure 1 — the streaming pattern: continuous dataflow with no addresses. AXI4-Stream carries data from producer to consumer as an unbroken flow — data goes to 'whoever's downstream', not to an address. A video pipeline is the archetype: camera → processing stages → display, a dataflow graph where each stage consumes a stream and produces a new one. The handshake is the familiar TVALID/TREADY (beat on both high) and the payload is TDATA, but there are NO address channels — the stream is the channel. Right when data flows one-way continuously and stream position, not address, defines routing.

2. Structuring the Stream: TLAST, TUSER, TKEEP

A raw stream is just bytes; video needs structure, and AXI4-Stream's sideband signals provide it. TLAST marks the end of a packet — in video, typically the end of a line (or frame), so the consumer knows where line/frame boundaries are. TUSER carries user-defined sideband, conventionally start-of-frame (the first pixel of a frame asserts a TUSER bit), so the pipeline can align to frame boundaries. TKEEP/TSTRB mark which bytes are valid (for partial/end transfers). Together these turn a flat pixel stream into a structured frames of lines of pixels — TUSER=start-of-frame at the first pixel, TLAST=end-of-line at each line's last pixel, TDATA=the pixels. This is exactly the video-over-AXI4-Stream convention.

Figure 2 — structuring a video stream with sideband signals. TLAST marks end-of-line (or end-of-frame) so the consumer knows line/frame boundaries. TUSER conventionally carries start-of-frame (the first pixel of a frame asserts a TUSER bit) for frame alignment. TKEEP/TSTRB mark valid bytes for partial transfers. Together they turn a flat pixel stream into structured frames-of-lines-of-pixels: TUSER=start-of-frame at the first pixel, TLAST=end-of-line at each line's last pixel, TDATA=the pixels — the standard video-over-AXI4-Stream convention.

3. Backpressure Throttles the Whole Pipeline

The defining behavior of a streaming pipeline is backpressure propagation. Because the stages are chained by TVALID/TREADY handshakes, if any stage can't accept data (drops TREADY — e.g. the display isn't ready, or a processing stage stalls), that backpressure propagates upstream: the stage feeding it stalls, then the stage before that, all the way back to the camera. The whole pipeline runs at the rate of its slowest consumer. This is why streaming designs need rate matching — FIFOs between stages to absorb rate mismatches and bursty processing — and why a real-time source (a camera that can't stall) must have enough downstream buffering, or it drops frames. Backpressure is the flow-control mechanism, and managing it is the central streaming design concern.

Figure 3 — backpressure throttles the whole streaming pipeline. The stages are chained by TVALID/TREADY, so if any stage drops TREADY (display not ready, a processing stage stalls), the backpressure propagates upstream stage by stage back to the camera — the whole pipeline runs at the rate of its slowest consumer. Streaming designs therefore need rate-matching FIFOs between stages to absorb mismatches and bursty processing, and a real-time source that can't stall (a camera) needs enough downstream buffering or it drops frames. Managing backpressure is the central streaming design concern.

4. Why Streaming, Not Memory-Mapped, and the Hybrid

AXI4-Stream fits video because the access pattern is continuous, one-directional dataflow where every pixel goes to the next stage in order — there's no random access, no addressing, no need for the read/write/response structure of memory-mapped AXI. Forcing video through memory-mapped AXI would mean addressing every pixel (pointless — they're sequential) and the overhead of address phases on a continuous flow. But real systems are often hybrid: a video pipeline streams pixels (AXI4-Stream) and is configured over AXI4-Lite (CSRs to set resolution, format, enable) and may write frames to memory via a DMA (full AXI) for buffering. So one video subsystem can use all three AXI variants — Stream for the pixel dataflow, Lite for control, full AXI for frame-buffer DMA — each for the traffic class it fits.

Figure 4 — why streaming fits video, and the hybrid system. AXI4-Stream fits because video is continuous one-directional dataflow with no random access — addressing every sequential pixel would be pointless overhead. But a real video subsystem is hybrid: it streams pixels (AXI4-Stream), is configured over AXI4-Lite (CSRs for resolution/format/enable), and may DMA frames to/from memory (full AXI) for buffering. One subsystem uses all three AXI variants — Stream for pixel dataflow, Lite for control, full AXI for frame-buffer DMA — each matched to its traffic class.

5. Common Misconceptions

Myths to unlearn

"AXI4-Stream is just AXI without some signals." It's a fundamentally different model — address-less continuous dataflow, not memory-mapped read/write. There are no AW/AR/B channels, no addresses, no reads vs. writes — just a one-directional flow with TVALID/TREADY/TDATA. The mental model is dataflow, not memory access.
"Streaming data needs addresses like memory-mapped AXI." No — in a stream, data goes to whoever's downstream, in order; position-in-the-stream defines routing, not an address. Addressing sequential pixels would be pointless overhead. The absence of addresses is the point.
"TLAST is like WLAST/RLAST for bursts." It marks packet boundaries in a continuous stream (e.g. end-of-line/frame in video), not the last beat of an addressed burst. A stream has no bursts; TLAST segments the flow into packets.
"Backpressure only affects the stalled stage." It propagates upstream through the whole chain — a stalled display backs up the processing stages back to the camera, so the pipeline runs at its slowest consumer. This propagation is the central streaming behavior, requiring FIFOs for rate matching.
"A video pipeline uses only AXI4-Stream." Real video subsystems are hybrid: AXI4-Stream for pixel dataflow, AXI4-Lite for configuration (CSRs), and full AXI (DMA) for frame buffering to memory. One subsystem commonly uses all three variants, each for its traffic class.
"A real-time source can always be stalled by backpressure." A camera producing pixels at a fixed rate can't stall — if downstream backpressure reaches it and there's no buffer, it drops frames/pixels. Real-time streaming requires enough downstream buffering (FIFOs) to absorb backpressure, or it loses data.

6. Debugging Insight

🔍 Debugging insight — streaming pipeline problems are backpressure, framing, or rate-matching

When a streaming video pipeline misbehaves, the cause clusters around flow control and framing:

Dropped frames / data loss. A real-time source (camera) hit backpressure with no buffer — trace the backpressure: which stage dropped TREADY, and does the upstream have enough FIFO to absorb it? Add/size rate-matching FIFOs, or speed up the bottleneck stage.
Whole pipeline runs slow. It's running at the slowest consumer — find the stage with the lowest sustained TREADY rate (the bottleneck) and either speed it up or buffer around it. Backpressure makes one slow stage throttle everything.
Frame/line misalignment (garbled image). TLAST/TUSER framing is wrong — TUSER start-of-frame on the wrong pixel, or TLAST end-of-line on the wrong pixel, so the consumer mis-segments the stream. Check the framing signals against the expected resolution.
First frame corrupt, rest fine (or vice versa). A start-of-frame (TUSER) synchronization issue — the pipeline didn't align to the frame boundary at startup. Check TUSER handling and pipeline reset/flush.
Partial-beat data wrong at line/frame ends. TKEEP/TSTRB not handled — the last beat of a line/frame may have fewer valid bytes. Check the byte-qualifier handling at boundaries.
Pipeline hangs. A TVALID/TREADY deadlock or a stage that never asserts TREADY — same handshake debugging as memory-mapped AXI (17.1), but on the stream channel.

The pattern: streaming bugs are predominantly backpressure/rate-matching (dropped frames, slow pipeline) and framing (TLAST/TUSER/TKEEP mis-marking → garbled/misaligned video), plus the universal handshake issues. Debug the flow control (FIFOs, the slowest stage) and the framing signals (start-of-frame, end-of-line) first — they're where streaming-specific bugs live.

7. Verification Insight

✅ System insight — the streaming plane completes AXI's design-space tour, and real systems are hybrid

The video pipeline is the streaming plane — the fourth and final point in AXI's design-space tour (after latency-critical CPU data, throughput-critical DMA data, and control CSR access) — and it's fundamentally different: address-less continuous dataflow rather than memory-mapped access. AXI4-Stream fits because video is a one-directional flow where every pixel goes to the next stage in order, so there's no random access, no addressing, and none of memory-mapped AXI's read/write/response/burst machinery — just TVALID/TREADY flow control and TDATA, with sideband (TLAST for line/frame boundaries, TUSER for start-of-frame, TKEEP/TSTRB for valid bytes) structuring the flat stream into frames-of-lines-of-pixels. The central design concern is backpressure: chained TVALID/TREADY stages propagate a stall upstream, so the pipeline runs at its slowest consumer, which means streaming designs live or die by rate matching (FIFOs between stages) and, for real-time sources that can't stall (cameras), sufficient downstream buffering or they drop frames. The system-level capstone lesson, drawing all four case studies together: a real subsystem is hybrid — the same video pipeline streams pixels over AXI4-Stream, is configured over AXI4-Lite (CSRs for resolution/format/enable), and DMAs frames to/from memory over full AXI (frame buffering) — so one subsystem uses all three AXI variants, each matched to its traffic class. This is the unifying insight of the case-study module: AXI is a family, and real systems compose its members — full AXI for bulk memory-mapped data (tuned for latency or throughput), AXI4-Lite for control, AXI4-Stream for continuous dataflow — and the architect's job is choosing the right variant and configuration for each traffic class and composing them into a coherent system. The four paths span the space: memory-mapped latency-critical (CPU), memory-mapped throughput-critical (DMA), memory-mapped control (CSR/Lite), and streaming dataflow (video/Stream) — covering the dimensions of addressed-vs-streaming, data-vs-control, and latency-vs-throughput that characterize on-chip traffic. For verification, the streaming plane needs backpressure-storm testing (stall every stage at every point, confirm no data loss with adequate buffering, confirm the pipeline resumes), framing verification (TLAST/TUSER/TKEEP correct at every line/frame boundary), and rate-mismatch scenarios (fast source/slow sink and vice versa) — complementing the memory-mapped paths' burst/outstanding/ordering tests. Understanding all four paths means understanding AXI not as a protocol but as a family of right-sized protocols for the spectrum of on-chip communication, which is the synthesis the whole curriculum builds toward and the case studies make concrete. Next, we scale up to the interconnect itself: how AXI bridges into a Network-on-Chip at system scale.

8. Interview Questions

9. Summary

AXI4-Stream is the streaming plane — the fourth and final point in AXI's design-space tour — and it's fundamentally different from the three memory-mapped paths: address-less continuous dataflow where data flows from producer to consumer with no addresses, only the TVALID/TREADY handshake and TDATA payload. A video pipeline (capture→process→display) is the archetype: pixels stream stage to stage as a dataflow graph, structured by sideband signals — TLAST for line/frame boundaries, TUSER for start-of-frame, TKEEP/TSTRB for valid bytes — turning a flat stream into frames-of-lines-of-pixels. The defining behavior is backpressure propagation: chained handshakes mean a stall ripples upstream, so the pipeline runs at its slowest consumer, requiring rate-matching FIFOs between stages and, for un-stallable real-time sources (cameras), sufficient downstream buffering or it drops frames.

Streaming fits video because the traffic is continuous one-directional dataflow with no random access — addressing sequential pixels would be pointless overhead. But real systems are hybrid: a video subsystem streams pixels (AXI4-Stream), is configured over AXI4-Lite (CSRs), and DMAs frames to memory over full AXI — using all three variants, each for its traffic class (often with async FIFOs for the clock-domain crossings). This is the capstone lesson of the case-study module: the four paths span the dimensions of on-chip traffic (addressed-vs-streaming, data-vs-control, latency-vs-throughput), revealing AXI as a family of right-sized protocols that real systems compose. The architect's job is to classify each subsystem's traffic, choose the right variant/configuration, and compose them on the interconnect with appropriate arbitration — the system-architecture understanding the whole curriculum builds toward. Next, we scale up to how AXI bridges into a Network-on-Chip at system scale.

10. What Comes Next

You've toured AXI's four traffic patterns; next, scaling the interconnect:

19.5 — NoC / Interconnect Use (coming next) — how AXI bridges into a Network-on-Chip at scale, where many masters and slaves connect through a packet-switched fabric rather than a simple crossbar.

Previous: 19.3 — AXI4-Lite CSR Access. Related: 11.1 — The AXI4-Stream Mental Model for the streaming paradigm, 11.3 — TLAST & Packet Boundaries for the framing, and 11.6 — Stream Backpressure for the flow control.