AMBA AXI · Module 11

TUSER, TID & TDEST

AXI4-Stream's routing and sideband signals — TID (stream/source identifier), TDEST (routing destination), and TUSER (user-defined sideband). How stream interconnects route by TDEST, why these are tags not addresses, and TUSER's interoperability risk.

A point-to-point stream needs only TVALID/TREADY/TDATA (and maybe TLAST). But the moment you build a stream interconnect — multiple sources, multiple sinks, a switch in between — you need to route and identify streams. That's what TID, TDEST, and TUSER provide: TID identifies the stream/source, TDEST says where to route it, and TUSER carries user-defined sideband metadata. Crucially, none of these are addresses (there's no addressable storage in a stream) — they're routing tags and sideband. This chapter covers their roles, how a stream switch routes by TDEST, and the interoperability care TUSER demands.

1. The Three Signals

TID — a stream/source identifier. It tags which stream (or source) a transfer belongs to, letting a sink or interconnect distinguish multiple streams sharing a path and know a transfer's origin. Analogous to AxID in memory-mapped AXI.
TDEST — a routing destination identifier. It tells a stream interconnect/switch which output (destination) the stream should be routed to. This is the steering tag.
TUSER — user-defined sideband, carried alongside the data with no protocol-defined meaning (like AxUSER, Chapter 6.6). Width and semantics are implementation-defined; common uses include per-beat error/status flags, parity, timestamps, or markers like video start-of-frame.

All three are optional and implementation-defined in width. A bare stream omits them; they appear as a system needs identification, routing, or sideband. They follow the stream's handshake and (for per-transfer signals) the same stability rules as TDATA.

Figure 1 — the three roles. TID identifies the stream/source (which stream is this, where from). TDEST identifies the routing destination (where should it go). TUSER carries user-defined sideband metadata (no protocol meaning). All optional, implementation-defined width — added when a system needs identification, routing, or sideband.

2. Stream Routing — The Switch

TDEST exists for the stream interconnect (switch/router). A switch connects several stream sources to several sinks; it reads each stream's TDEST and routes it to the corresponding output port. Because a packet is a unit (Chapter 11.3), the switch commits to a TDEST for the duration of a packet and routes the whole packet there until TLAST, then re-evaluates for the next.

TID is preserved (or remapped) through the switch so the sink knows the stream's source. Just like AXI ID extension (Chapter 8.2), a stream interconnect may extend/remap TID so that streams from different sources stay distinct at a shared sink and can be demultiplexed — TID identifies who sent it, TDEST selects where it goes. Together they let a many-source, many-sink stream fabric steer and tag traffic, the streaming analog of address-decode-plus-ID-routing in memory-mapped AXI.

Figure 2 — a stream switch routes by TDEST. Multiple sources feed a switch; it routes each stream to the output port named by its TDEST, committing to that destination for a whole packet (until TLAST). TID identifies the source and is preserved/remapped so the sink can demultiplex streams. TDEST = where it goes; TID = where it came from.

3. TUSER — Sideband Metadata

TUSER is the stream's user-defined sideband, carrying whatever metadata an application threads alongside the data — with no protocol-defined meaning (exactly like AxUSER, Chapter 6.6). Common uses:

Video markers — a start-of-frame (SOF) bit on TUSER of the first pixel, framing a video stream (used heavily in video pipelines alongside TLAST for end-of-line).
Per-beat status/error flags — marking a beat as erroneous, a control word, or carrying a tag.
Parity / ECC — side-band check bits over TDATA.
Timestamps / metadata — a capture time or classification result accompanying the data.

TUSER can be per-transfer (qualified each beat) or per-packet (meaningful on the first/last beat), depending on the convention. Because its meaning is private, TUSER carries the same interoperability risk as AxUSER: both endpoints must agree on its width and semantics, and an interconnect must propagate it — a mismatch is a silent integration bug.

Figure 3 — TUSER sideband uses. Video start-of-frame markers, per-beat error/status flags, parity/ECC check bits, and timestamps/metadata — all carried alongside TDATA with no protocol-defined meaning. Like AxUSER, its width and semantics are a private agreement between endpoints (interoperability risk).

4. Tags, Not Addresses

A recurring point worth nailing: TID and TDEST are routing/identification tags, not memory addresses (Chapter 11.1). A stream has no addressable storage to point at; TDEST steers the pipe to an output, and TID labels the source. They route the flow; they don't index data. This is the streaming counterpart to memory-mapped routing, but the mechanism is tag-based steering, not address decode.

The practical contract for using these signals: agree the TDEST map (which value routes to which sink) across the fabric; preserve/extend TID so sources stay distinguishable; and treat TUSER as a documented private agreement (width + meaning) that every block on the path must honor and propagate. Get the TDEST map wrong and packets go to the wrong sink; mishandle TID and a sink can't tell sources apart; mismatch TUSER and metadata is silently lost or misinterpreted.

Figure 4 — the integration contract. TID/TDEST are routing tags (not addresses): agree the TDEST→sink map across the fabric and preserve/extend TID so sources stay distinct. TUSER is a private sideband agreement: every block must match its width/semantics and propagate it. Wrong TDEST map → misroute; mishandled TID → can't demux; TUSER mismatch → silent metadata loss.

5. Common Misconceptions

Myths to unlearn

"TID and TDEST are addresses." No — they're routing/identification tags. A stream has no addressable storage; TDEST steers the pipe to an output, TID labels the source. They route flow, not index memory.
"TDEST and TID do the same thing." Different roles: TDEST = where the stream goes (destination, for switching); TID = where it came from (source/stream identity, for demux).
"TUSER has a standard meaning." It doesn't — like AxUSER, TUSER is user-defined; both endpoints must agree on width and semantics, and the interconnect must propagate it.
"A switch can change a packet's TDEST mid-packet." It shouldn't — routing commits to a TDEST for the whole packet (until TLAST); changing it mid-packet splits the packet across destinations.
"These signals are always present." All three are optional. Point-to-point streams often omit them; they appear only when a system needs identification, routing, or sideband.
"TUSER is automatically carried through any interconnect." Not guaranteed — like AxUSER, an interconnect may drop it; propagation must be confirmed.

6. Debugging Insight

🔍 Debugging insight — routing, demux, and sideband-propagation bugs

These signals fail as misrouting, source confusion, or lost metadata:

A stream arrives at the wrong sink? A TDEST issue — wrong TDEST value at the source, or a wrong TDEST→port map in the switch. Trace the TDEST value and the switch's routing table. (Not an address bug — a routing-tag bug.)
A sink can't tell two streams apart / data interleaved wrongly? A TID issue — TID not preserved or not extended through the switch, so streams from different sources collide. Check TID handling (like AXI ID extension, 8.2).
A packet split across two destinations? The switch changed TDEST mid-packet instead of committing until TLAST. Enforce whole-packet routing.
Sideband metadata missing or misinterpreted at the sink? A TUSER mismatch — width/semantics disagreement between source and sink, or the interconnect dropped TUSER. Confirm both ends agree and the path propagates it (same as the AxUSER integration risk, 6.6).
Video frame boundaries wrong? If SOF is on TUSER, a dropped/misaligned TUSER bit corrupts frame framing — check the TUSER SOF handling alongside TLAST end-of-line.

The triage: wrong sink → TDEST; can't demux → TID; split packet → mid-packet TDEST change; lost/garbled metadata → TUSER width/semantics/propagation. All are tag/sideband issues, never addressing.

7. Verification Insight

✅ Verification insight — routing correctness, TID preservation, TUSER contract

For streams using these signals, verify routing, identification, and sideband separately. Routing (TDEST): every packet reaches the sink its TDEST selects, the whole packet goes to one destination (no mid-packet TDEST change), and the TDEST→port map is honored — drive packets to every destination and assert correct delivery. Identification (TID): TID is preserved (or correctly remapped/extended) through the fabric so a sink can demultiplex sources — drive multiple sources (including overlapping TID values through a switch, like the AXI ID-collision case, 8.2) and assert each stream is correctly attributed. Sideband (TUSER): like AxUSER (6.6), it's a contract — assert the agreed width/semantics, that the value arrives unmodified where propagation is expected, and that an interconnect that should carry it does.

Coverage should include: packets to every TDEST; multiple sources with distinct and overlapping TIDs through a switch; TUSER non-zero values across packets (and the SOF/per-beat patterns if used); and the negative cases — misrouting (wrong TDEST), TID collision without extension, and TUSER dropped by an interconnect. The highest-value tests are the multi-source switch (proves TDEST routing + TID demux together) and the TUSER propagation check (the silent-loss bug). Because these mirror AXI ID routing and AxUSER sideband, the verification approach transfers directly — applied to the stream fabric.

8. Interview Questions

9. Summary

TID, TDEST, and TUSER add identification, routing, and sideband to AXI4-Stream — the signals a stream interconnect needs. TID identifies the stream/source (for demultiplexing; extended/remapped through a switch like AxID); TDEST names the routing destination (a stream switch steers the whole packet to that output until TLAST); TUSER carries user-defined sideband (video SOF, error flags, parity, timestamps) with no protocol meaning. All are optional and implementation-defined in width. The central clarification: TID/TDEST are routing tags, not addresses — a stream has no addressable storage; TDEST steers the pipe and TID labels the source.

The integration contract: agree the TDEST→sink map, preserve/extend TID so sources stay distinct, and treat TUSER as a documented private agreement every block must match and propagate. Bugs are misrouting (TDEST), demux failure (TID), packet-split (mid-packet TDEST change), and silent metadata loss (TUSER mismatch/drop — the AxUSER risk). The mapping to memory-mapped AXI is direct — TID↔AxID, TUSER↔AxUSER — with TDEST the new concept (an explicit routing tag replacing address decode), so your interconnect knowledge transfers. Next: stream backpressure in depth — how TREADY throttles a stream and propagates through a pipeline.

10. What Comes Next

You've got the routing and sideband signals; next, backpressure in depth:

11.6 — Stream Backpressure (coming next) — how TREADY backpressure throttles a stream and propagates upstream through a pipeline.
11.7 — DMA, Video & Network Use Cases (coming soon) — grounding AXI4-Stream in real pipelines.

Previous: 11.4 — TKEEP & TSTRB. Related: 8.2 — Transaction IDs for the ID-routing parallel, and 6.6 — AxUSER & Sideband Signals for the TUSER interoperability risk. For the broader protocol catalog, see the AMBA family overview doc.