AMBA AXI · Module 11

DMA, Video & Network Use Cases

AXI4-Stream in real systems — the MM-to-stream DMA bridge, video pipelines (SOF/EOL framing), and network packet processing (TLAST/TKEEP/TDEST). How every stream signal maps to a concrete role across three canonical pipelines.

This chapter closes Module 11 by grounding everything — TDATA, TLAST, TKEEP, TUSER, TID/TDEST, and backpressure — in three canonical use cases: DMA (bridging memory-mapped and streaming), video (pixel pipelines), and network (packet processing). These are where AXI4-Stream actually lives, and seeing each signal play its real role makes the whole module concrete. The unifying theme: every "T" signal maps to a tangible job, and real systems combine all three AXI flavors — memory-mapped for storage, stream for dataflow, AXI4-Lite for control.

1. DMA — Bridging Memory-Mapped and Stream

The most fundamental use case is the DMA that bridges memory-mapped AXI and AXI4-Stream. Two directions:

MM-to-Stream (MM2S / "read" DMA): reads data from memory over full AXI4 (addressed, bursting), and emits it as an AXI4-Stream into a downstream block (e.g., an accelerator). It converts addressed memory data into a flow.
Stream-to-MM (S2MM / "write" DMA): receives an AXI4-Stream and writes it to memory over full AXI4. It uses TLAST to know a packet is complete — finalizing a buffer, recording the length, advancing a descriptor, raising an interrupt.

This is the MM-edges, stream-middle pattern (Chapter 11.1): memory-mapped AXI4 at the memory endpoints (where addressing and bursts are needed), AXI4-Stream through the compute (where data just flows), and AXI4-Lite for the DMA's control registers. The DMA is the glue that converts between the addressed and streaming worlds.

Figure 1 — the DMA bridge. An MM2S DMA reads memory over full AXI4 (addressed, bursting) and emits an AXI4-Stream into an accelerator; the accelerator streams results to an S2MM DMA that writes them back to memory over AXI4, using TLAST to delimit buffers. AXI4-Lite carries the DMAs' control registers. Memory-mapped edges, streaming middle.

2. Video — Pixel Pipelines

In a video pipeline, pixels stream through processing stages (scaler, color-space converter, on-screen display, etc.), and the stream signals carry the frame structure:

TDATA = the pixel data (one or more pixels per beat).
TLAST = end-of-line (EOL) — marks the last pixel of each scanline (each line is a packet).
TUSER[0] = start-of-frame (SOF) — asserted on the first pixel of each frame (the standard AXI4-Stream Video convention), framing the stream into frames.
Backpressure (TREADY) throttles the pipeline; FIFOs / frame buffers decouple stages, and a real-time camera source needs buffering to absorb downstream stalls (Chapter 11.6) or frames are torn/dropped.

So a video frame is a sequence of lines (each TLAST-delimited), with SOF on TUSER marking the frame's start. Downstream stages use SOF+EOL to track position within the frame. This combination — TDATA/TLAST/TUSER for framing plus TREADY flow control — is the canonical streaming-video design.

Figure 2 — a video pixel pipeline. Pixels stream from a camera through processing stages (scaler, color converter, OSD) to a display. TDATA carries pixels, TLAST marks end-of-line, TUSER[0] marks start-of-frame, and TREADY backpressure plus FIFOs/frame buffers pace the pipeline. The real-time camera needs buffering to absorb downstream stalls.

3. Network — Packet Processing

In network/packet processing, Ethernet frames flow through parsers, classifiers, and switches:

TDATA = the frame bytes.
TLAST = end-of-frame — frames are variable-length packets, delimited by TLAST (no length field).
TKEEP = the partial last beat — since frame length rarely divides the bus width, TKEEP marks the valid bytes of the final beat, giving the exact frame length (Chapter 11.4).
TDEST/TID = routing — a stream switch routes whole frames by TDEST to the right processor/queue (CPU, offload engine), with TID identifying the source port (Chapter 11.5).
TUSER = per-frame status — e.g., a CRC-error or classification-result flag.

So a frame is a TLAST-delimited, TKEEP-sized packet, routed by TDEST, tagged by TID, with status on TUSER. This exercises essentially every stream signal — which is why networking is the showcase use case for AXI4-Stream's full feature set.

Figure 3 — a network packet pipeline. An Ethernet MAC presents frames as AXI4-Stream (TLAST=end-of-frame, TKEEP sizing the partial last beat, TUSER carrying CRC/status); a switch routes whole frames by TDEST (with TID identifying the source) to a CPU queue or offload engine. Networking exercises nearly every stream signal.

4. Every Signal Maps to a Role

The throughline across all three use cases: each stream signal has a concrete real-world job.

Signal	Role	Example
`TDATA`	the payload	samples / pixels / frame bytes
`TVALID`/`TREADY`	flow control	pace producer/consumer, backpressure
`TLAST`	unit boundary	packet / line (EOL) / frame
`TKEEP`	partial last beat	variable frame length
`TUSER`	sideband	SOF (video), CRC/status (network)
`TID`/`TDEST`	identify / route	source port / destination queue

And every real system layers the three AXI flavors: memory-mapped AXI4 for addressed storage (DMA endpoints, frame buffers), AXI4-Stream for dataflow (the compute/processing pipeline), and AXI4-Lite for control (configuration/status registers). Recognizing which flavor fits which part — and which stream signal carries which structure — is the practical payoff of the whole AXI curriculum so far.

Figure 4 — signals to roles, and the three-flavor system. Each stream signal has a concrete job (TDATA payload, TLAST boundary, TKEEP length, TUSER sideband, TID/TDEST routing, TVALID/TREADY flow). Real systems combine memory-mapped AXI4 (storage), AXI4-Stream (dataflow), and AXI4-Lite (control) — the canonical SoC structure.

5. Common Misconceptions

Myths to unlearn

"A DMA is purely memory-mapped or purely streaming." A stream DMA bridges both — memory-mapped AXI4 on the memory side, AXI4-Stream on the compute side. That bridging is its whole purpose.
"Video framing uses TLAST alone." Video uses TLAST for end-of-line and TUSER[0] for start-of-frame — two markers for the two boundary levels (line and frame). TLAST alone only delimits lines.
"Network frames have a length field on the stream." No — frame length comes from TLAST (end-of-frame) plus TKEEP (valid bytes of the partial last beat). There's no length field; you count to TLAST and size by TKEEP.
"A stream switch can split a packet across destinations." No — it routes a whole packet to one TDEST until TLAST (Chapter 11.5). Splitting corrupts the packet.
"Streaming replaces memory-mapped AXI in these systems." They coexist — memory-mapped for storage endpoints, stream for the dataflow, AXI4-Lite for control. All three appear in a typical pipeline.
"A real-time camera can be backpressured freely." It can't stall — it needs buffering (FIFO/frame buffer) to absorb downstream stalls, or frames tear/drop (Chapter 11.6).

6. Debugging Insight

🔍 Debugging insight — use-case bugs map to the signal carrying that structure

In real pipelines, a symptom points at the signal carrying the relevant structure:

DMA writes the wrong buffer size / never completes a buffer? A TLAST issue at the S2MM boundary — a missing TLAST merges packets into one oversized buffer; an absent TLAST leaves the buffer never finalized. Check the stream's framing into the DMA.
Video frame torn or rolling? A framing issue — SOF (TUSER) or EOL (TLAST) misaligned, or the real-time camera overflowed under backpressure (insufficient buffering). Check SOF/EOL alignment and the camera FIFO depth.
Network frame length wrong / trailing garbage? A TKEEP issue on the partial last beat (Chapter 11.4) — the valid byte count is wrong, so the frame length is off. Check last-beat TKEEP.
A frame routed to the wrong processor? A TDEST issue (Chapter 11.5) — wrong destination tag or switch map; or the switch changed TDEST mid-frame (split). Check routing.
Frames misattributed across source ports? A TID issue — not preserved/extended through the switch.
Pipeline throughput low? Backpressure bottleneck (Chapter 11.6) — find the slowest stage; check FIFO depths.

The triage maps each use-case symptom to the stream signal that carries that structure: buffer/packet → TLAST; frame tearing → SOF/EOL + camera buffering; wrong length → TKEEP; misroute → TDEST/TID; slow → backpressure. The whole module's signals show up here in their real roles.

7. Verification Insight

✅ Verification insight — verify each use case as its real protocol contract

Verifying these systems combines the per-signal checks (Modules 11.2–11.6) into use-case-level scenarios. For DMA: verify the MM↔stream bridge end-to-end — data read from memory arrives correctly as a stream and vice versa, TLAST-delimited packets map to the right buffers/descriptors with correct lengths, and the AXI4-Lite control path configures it correctly (a multi-flavor test). For video: verify frame integrity — SOF (TUSER) and EOL (TLAST) frame every frame/line correctly, frames survive backpressure (no tearing), and the real-time source's buffering prevents overflow (or overflow is handled gracefully). For network: verify packet integrity — variable-length frames (correct TKEEP on the partial last beat), whole-frame routing by TDEST to the right queue, TID source attribution, and TUSER status correctness, all under adversarial backpressure.

Coverage should span: DMA transfers of various packet sizes (including buffer-boundary and descriptor cases); video frames of different resolutions with backpressure and the real-time overflow boundary; network frames of every length (min to max, exercising TKEEP), multiple source ports with distinct/overlapping TID, and routing to every TDEST. The highest-value tests are the end-to-end use-case scenarios — a full DMA round-trip, a complete video frame under backpressure, a routed network frame — because they prove the signals work together in their real roles, not just in isolation. These are effectively integration tests for the streaming subsystem, combining everything the module covered.

8. Interview Questions

9. Summary

AXI4-Stream lives in three canonical use cases that put every signal to work. A DMA bridges memory-mapped AXI and stream — MM2S reads memory (AXI4) and emits a stream; S2MM receives a stream and writes memory (AXI4), using TLAST to delimit buffers — the MM-edges, stream-middle pattern with AXI4-Lite control. A video pipeline streams pixels (TDATA) framed by EOL (TLAST) and SOF (TUSER[0]), paced by backpressure with FIFOs/frame buffers, where the real-time camera needs buffering. A network pipeline carries variable-length frames — TLAST end-of-frame, TKEEP sizing the partial last beat, TDEST/TID routing whole frames through a switch, TUSER status — exercising nearly every signal.

The unifying lesson: every stream signal maps to a concrete role (TDATA payload, TLAST boundary, TKEEP length, TUSER sideband, TID/TDEST routing, TVALID/TREADY flow), and real systems combine all three AXI flavors — memory-mapped for storage, stream for dataflow, AXI4-Lite for control — each where its model fits. Streaming is the right abstraction for sequential dataflow precisely because forcing it through an addressed model would be wasteful overhead. This completes Module 11 (AXI4-Stream). Next, Module 12 returns to the heart of memory-mapped systems: the AXI interconnect — how it routes, arbitrates, and converts between many managers and subordinates.

10. What Comes Next

You've grounded AXI4-Stream in real systems; Module 12 turns to the interconnect:

12.1 — AXI Interconnect Overview (coming next) — the interconnect's job: routing, arbitration, and protocol conversion between many managers and subordinates.

Previous: 11.6 — Stream Backpressure. Related: 11.1 — The AXI4-Stream Mental Model for the MM-edges/stream-middle pattern, and 10.1 — Why AXI4-Lite Exists for the control flavor. For the broader protocol catalog, see the AMBA family overview doc.

Continue learning

Standards & specifications

Governing standard: Arm AMBA AXI Protocol Specification (IHI 0022)(opens Arm in a new tab)
Defines the AXI channels, handshake and ordering rules. RTL structure, interconnect topology and verification strategy are design choices this specification does not mandate.

This page also covers RTL structure, verification approach and debugging technique. Those are engineering practice built on the standard, not requirements the standard itself imposes.

Where this fits

Part of the AMBA AXI curriculum.