AMBA AXI · Module 11

TKEEP & TSTRB

AXI4-Stream byte qualifiers — TKEEP (null vs kept bytes) and TSTRB (data vs position bytes). The data/position/null byte classification, the partial-last-beat use case, and how they relate to WSTRB byte enables.

TDATA is divided into byte lanes, and not every byte is always meaningful — a packet's length might not be a multiple of the bus width, or a stream might carry sparse/positioned data. TKEEP and TSTRB are the per-byte qualifiers that say what each byte lane carries: a real data byte, a position byte (placeholder, no value), or a null byte (removable). The most common use by far is the partial last beat — marking which bytes of the final beat of a packet are valid, exactly analogous to WSTRB byte enables in memory-mapped AXI. This chapter decodes the TKEEP/TSTRB combinations, the partial-beat use case, and how they're verified.

1. Per-Byte Qualifiers

Each has one bit per byte lane of TDATA (width = TDATA_WIDTH/8, like WSTRB):

TSTRB (data strobe) — distinguishes a data byte (TSTRB=1) from a position byte (TSTRB=0): is this byte an actual data value, or just a placeholder occupying a lane position?
TKEEP (null-byte indicator) — distinguishes a kept byte (TKEEP=1) from a null byte (TKEEP=0): is this byte part of the stream content (must be kept), or a null byte that can be removed?

Together they classify each byte lane on each beat. Both are optional — many streams use only TKEEP (for the partial last beat) and treat everything else as data, or omit both entirely for streams where every byte is always valid.

Figure 1 — TKEEP and TSTRB are per-byte-lane qualifiers, one bit each per byte of TDATA (width = TDATA_WIDTH/8, like WSTRB). TSTRB marks data vs position bytes; TKEEP marks kept vs null (removable) bytes. Together they classify every byte lane on every beat. Both are optional.

2. The Byte Classification

The TKEEP/TSTRB combination classifies each byte:

`TKEEP`	`TSTRB`	Byte type	Meaning
1	1	Data byte	Valid data, part of the stream
1	0	Position byte	Placeholder — no data value, but occupies the position (kept for alignment)
0	0	Null byte	No data, removable — can be dropped without affecting the stream
0	1	Reserved	Illegal combination

The intuition: TSTRB answers "does this byte have a real value?" and TKEEP answers "must this byte be preserved (vs droppable)?" A data byte (1/1) is real and kept; a position byte (1/0) holds a slot but has no value (for sparse/aligned data); a null byte (0/0) is nothing and can be removed (typically the trailing bytes of a partial last beat). TKEEP=0, TSTRB=1 is reserved/illegal — you can't have a removable byte that's also a data value.

Figure 2 — the byte classification. TKEEP=1/TSTRB=1: data byte (real, kept). TKEEP=1/TSTRB=0: position byte (placeholder, no value, kept for alignment). TKEEP=0/TSTRB=0: null byte (removable). TKEEP=0/TSTRB=1: reserved/illegal. TSTRB says 'has a value?', TKEEP says 'must keep?'.

3. The Partial Last Beat — The Common Case

By far the most common use of TKEEP is the partial last beat. A packet's total byte count rarely divides evenly by the bus width, so the final beat carries fewer valid bytes than the full width — the leftover upper byte lanes are null bytes (TKEEP=0). TKEEP marks exactly which bytes of the last beat are real, so the receiver knows the packet's true byte length (not just its beat count).

Example: a 4-byte-wide stream carrying a 6-byte packet. Beat 0 has all 4 bytes valid (TKEEP=4'b1111); beat 1 (the last, TLAST=1) has only the low 2 bytes valid (TKEEP=4'b0011) — the upper 2 are null. This is exactly analogous to WSTRB in memory-mapped AXI: a per-byte enable marking which bytes count. Most streams that use byte qualifiers use only TKEEP this way (all data bytes, with nulls on the last beat), treating TSTRB as tied to TKEEP (no position bytes).

tkeep-tstrb — partial last beat (6-byte packet on 4-byte stream)

5 cycles

Figure 3 — tkeep-tstrb: a 6-byte packet on a 4-byte stream. Beat 0 has all 4 bytes valid (TKEEP=1111). Beat 1 (TLAST=1) has only the low 2 bytes valid (TKEEP=0011) — the upper 2 are null bytes. TKEEP marks the partial last beat's valid bytes, giving the packet's true byte length — exactly like WSTRB byte enables.

4. Position vs Null — Sparse and Packed Streams

The distinction between position (1/0) and null (0/0) bytes matters for streams that aren't simply contiguous data:

Position bytes (TKEEP=1, TSTRB=0) are placeholders that must be kept in their lane position but carry no data value — used for sparse or aligned streams where a byte's position is significant even though it has no value (e.g., maintaining a fixed layout where some lanes are intentionally empty but must not collapse).
Null bytes (TKEEP=0, TSTRB=0) can be removed entirely — they don't affect the stream's data or layout. The trailing bytes of a partial last beat are null; a downstream block may compact them out.

So the question each byte answers: a data byte is real and stays; a position byte is empty but stays (position matters); a null byte is empty and may go. Most streams only need data + null (the partial-last-beat case); position bytes appear in specialized sparse/aligned formats. The reserved 0/1 combination — removable yet a data value — is contradictory and illegal.

Figure 4 — position vs null bytes. A data byte is real and kept. A position byte (TKEEP=1, TSTRB=0) is empty but kept because its lane position matters (sparse/aligned streams). A null byte (TKEEP=0, TSTRB=0) is empty and removable (partial-last-beat trailing bytes; downstream may compact). Most streams need only data + null; position bytes are for specialized formats.

5. Common Misconceptions

Myths to unlearn

"TKEEP and TSTRB are the same thing." They're different: TSTRB = data vs position (has a value?); TKEEP = kept vs null (must preserve?). Their combination classifies the byte.
"Every stream needs TKEEP/TSTRB." Both are optional. Streams where every byte is always valid omit them; many use only TKEEP for the partial last beat.
"TKEEP=0, TSTRB=1 is a valid combination." It's reserved/illegal — a byte can't be removable (null) and a data value at once.
"Null and position bytes are the same." No — a position byte (1/0) must be kept (its position matters); a null byte (0/0) can be removed. Different handling.
"TKEEP is unrelated to WSTRB." For the partial-last-beat case, TKEEP is the stream's byte-enable equivalent of WSTRB — per-byte "this byte counts" marking. The concept transfers directly.
"The packet length is the beat count." No — with a partial last beat, the true byte length is (full beats × width) + (valid bytes on the last beat per TKEEP). Beat count alone over-counts.

6. Debugging Insight

🔍 Debugging insight — byte-qualifier bugs corrupt length and content

TKEEP/TSTRB bugs usually show as wrong packet length or stray bytes:

Packet has extra trailing garbage bytes? The partial last beat's TKEEP is wrong — null bytes weren't marked, so the receiver kept the leftover upper-lane bytes as data. Check TKEEP on the TLAST beat reflects exactly the valid byte count.
Packet length off by a few bytes? Same root — the receiver computed length from beats or a wrong TKEEP. True byte length uses TKEEP on the last beat.
A position byte got dropped (layout corrupted)? Something treated a position byte (1/0) as a null byte (0/0) and removed it, collapsing the layout. Position bytes must be kept; check the qualifier handling.
Reserved combination on the bus? TKEEP=0, TSTRB=1 appeared — illegal. A protocol checker should flag it; the source's qualifier logic is wrong.
Byte lanes misaligned downstream? A block compacting null bytes (legitimately removable) shifted lanes, but a downstream consumer expected fixed positions — a position-vs-null contract mismatch between blocks.

The triage: trailing garbage / wrong length → last-beat TKEEP; dropped placeholder → position-vs-null confusion; illegal value → reserved combination. Most reduce to mis-marking which bytes are valid on the (usually last) beat.

7. Verification Insight

✅ Verification insight — byte-accurate qualifier checking, especially the last beat

TKEEP/TSTRB verification is byte-accurate, like WSTRB for memory-mapped AXI. The scoreboard must reconstruct each packet's actual bytes using the qualifiers — keeping data bytes, preserving position bytes in place, and dropping null bytes — and compare the byte sequence (and computed byte length) against the expected packet. Assert the legal combinations only (flag the reserved TKEEP=0, TSTRB=1), and that the partial last beat marks exactly the valid bytes (the dominant case). For streams using position bytes, verify they're kept (not removed) through blocks that compact null bytes.

Coverage should include: full beats (all TKEEP=1), partial last beats with every valid-byte count (1 byte up to width−1 on the last beat — each a distinct TKEEP pattern), single-beat packets that are also partial, position bytes (if used) interspersed with data, and the negative reserved combination. The highest-value tests are the partial-last-beat byte counts (the common bug site — off-by-one byte lengths and trailing-garbage) and the byte-accurate packet reconstruction (proving the receiver extracts exactly the intended byte sequence). Because this is the stream analog of WSTRB, the same byte-granular discipline applies: a word/beat-level check misses byte-qualifier bugs; you must verify per byte.

8. Interview Questions

9. Summary

TKEEP and TSTRB are AXI4-Stream's per-byte-lane qualifiers (one bit each per TDATA byte, width TDATA_WIDTH/8). TSTRB marks data vs position (has a value?); TKEEP marks kept vs null (must preserve?). Their combination classifies each byte: data (1/1, real and kept), position (1/0, empty but kept — for sparse/aligned layouts), null (0/0, removable), and the reserved/illegal 0/1. Both are optional, and the dominant use is the partial last beat: TKEEP marks which bytes of the final beat are valid, giving the packet's true byte length — exactly the stream equivalent of WSTRB byte enables.

The distinctions that matter: a position byte must be kept (its lane position is significant), while a null byte may be removed — confusing them corrupts sparse layouts. Bugs are wrong byte length / trailing garbage (mishandled last-beat TKEEP), dropped placeholders (position-vs-null confusion), and illegal combinations — all caught only by byte-accurate packet reconstruction (a beat-level check misses them), with the partial-last-beat byte counts as the key coverage point. The two-signal design generalizes the byte-enable concept to express layout-significant sparse streams. Next: the routing and sideband signals — TUSER, TID, and TDEST — for stream interconnects.

10. What Comes Next

You've got the byte qualifiers; next, the routing and sideband signals:

11.5 — TUSER, TID & TDEST (coming next) — the sideband (TUSER) and routing (TID/TDEST) signals that let stream interconnects steer and tag streams.
11.6 — Stream Backpressure (coming soon) — how TREADY backpressure throttles a stream in depth.

Previous: 11.3 — TLAST & Packet Boundaries. Related: 6.7 — WSTRB Write Strobes — the memory-mapped byte-enable this parallels. For the broader protocol catalog, see the AMBA family overview doc.