AMBA AXI · Module 7

Strobe Behavior in Bursts

How WSTRB evolves beat-by-beat across an AXI burst — full strobes for aligned beats, rotating strobes for narrow transfers, a partial first beat for unaligned starts, and constant strobes for FIXED.

This chapter completes Module 7 by tying three threads together — the per-beat addresses (Chapter 7.5), the active byte lanes (Chapter 7.7), and the write strobes (WSTRB, Chapter 6.7) — into one picture: how the strobes change beat by beat across a burst. For an aligned full-width burst the answer is boring (every beat is all-ones), but the moment a burst is narrow or unaligned, WSTRB evolves from beat to beat in exactly the pattern the lane mapping dictates. Seeing that progression concretely is what makes byte-accurate write handling click — and it's where a lot of real RTL and verification bugs live.

1. The Per-Beat Strobe Rule

There is one rule, applied independently to every beat: WSTRB[n] = 1 exactly when byte lane n is within that beat's valid byte range. The valid range is the lane span from Chapter 7.7 — starting lane Address mod Data_Bus_Bytes, spanning Number_Bytes lanes, clipped at the aligned boundary for a partial beat. So the strobes for a beat are simply the visible form of which lanes that beat addresses.

Because each beat has its own address (per the burst type), each beat has its own strobe pattern. The strobes are therefore a per-beat quantity that can change every beat — and tracking how they change across the burst is "strobe behavior."

strobe-progression — unaligned INCR write, partial first beat then full

6 cycles

Figure 1 — strobe-progression: an unaligned INCR write (4 bytes/beat, 32-bit bus, start 0x02, 3 beats). Beat 0 at 0x02 is partial — only lanes 2–3 valid → WSTRB=1100; beats 1–2 are aligned and full → WSTRB=1111. The strobes change beat-to-beat to match each beat's addressed lanes; the leading partial beat absorbs the unaligned offset.

2. Strobe Patterns by Case

The same rule produces a distinct progression for each situation:

Case	Strobe progression (32-bit bus example)
Aligned, full-width INCR	`1111, 1111, 1111, …` — every beat all-ones
Narrow (1 byte/beat) INCR	`0001, 0010, 0100, 1000, …` — single lane rotating with the address
Narrow (2 byte/beat) INCR	`0011, 1100, 0011, 1100, …` — lane pair alternating
Unaligned (4B/beat from 0x02)	`1100, 1111, 1111, …` — partial first beat, then full
FIXED (4B/beat)	`1111, 1111, 1111, …` — same lanes each beat (address constant)

The aligned full-width case is trivial; narrow makes the strobes rotate (because the active lane(s) move with the incrementing address); unaligned makes the first beat partial; FIXED keeps the pattern constant because the address never moves. WRAP follows the wrapped addresses (the strobe pattern tracks the wrapping lane positions). A burst can combine cases — a narrow and unaligned burst has both a partial leading beat and rotating lanes.

Figure 2 — strobe patterns by case on a 32-bit bus. Aligned full-width: 1111 every beat. Narrow 1-byte: a single 1 walking across the lanes. Unaligned: a partial first beat (1100) then 1111. FIXED: a constant pattern since the address doesn't move. Each is the same per-beat lane rule applied to that burst's addresses.

3. Deriving a Beat's Strobes

The derivation chains the Module 7 pieces in order:

Figure 3 — deriving a beat's WSTRB. Compute the beat address (burst-type rule, 7.5), reduce to a starting lane (Address mod Data_Bus_Bytes) and lane count (Number_Bytes), clip a partial beat at the aligned boundary, then set WSTRB to those lanes — optionally further masked for a sparse write. Lanes, addresses, and strobes are three views of the same computation.

The optional last step: a master may further deassert strobes within the addressed range for a genuinely sparse write (writing only some of the addressed bytes). But the addressed lane span is the maximum — a beat must never assert a strobe outside the lanes its address/size select. That over-assertion is the classic protocol violation.

4. Why This Closes the Loop

Strobe behavior is where the whole of Module 7 becomes observable on the wire. The address calculation (7.5) tells you where each beat goes; the lane mapping (7.7) tells you which lanes that implies; and WSTRB (6.7) is how the write side expresses it every beat. A subordinate writes exactly the strobed bytes (Chapter 6.7), so if any link in that chain is wrong — wrong address, wrong lanes, wrong strobes — the bytes land in the wrong place. Getting the strobe progression right is therefore the practical proof that the burst machinery is correct end to end.

Figure 4 — the closed loop. Address calculation (7.5) → lane mapping (7.7) → WSTRB (6.7) → the subordinate commits exactly the strobed bytes. The strobe progression is the observable output of the whole burst model; a defect anywhere in the chain shows up as wrong-position bytes, which the strobes make visible.

5. Common Misconceptions

Myths to unlearn

"WSTRB is the same on every beat of a burst." Only for aligned full-width (and FIXED). For narrow bursts it rotates each beat; for unaligned bursts the first beat differs. Strobes are per-beat.
"Narrow strobes are always the low lanes." No — they rotate with the address (0001, 0010, 0100, 1000 for 1-byte beats). Using a fixed low lane every beat is a bug.
"Only the first and last beats can be partial." For unaligned INCR the first beat is partial (and the last may be too if the length doesn't end on a boundary); narrow beats aren't "partial" so much as using few lanes — but the principle is per-beat lane selection throughout.
"A beat can strobe any lanes the master wants." No — the strobes must be within the lanes the beat's address/size select; asserting outside that range is illegal. Within the range, a master may deassert for a sparse write.
"FIXED strobes change because the data changes." The data differs each beat, but the strobe pattern is constant for FIXED because the address (and thus the lanes) doesn't move.
"Reads have a strobe progression too." No — reads have no strobe; the lane positions still rotate for narrow/unaligned reads, but there's no RSTRB. Strobe progression is a write concept.

6. Debugging Insight

🔍 Debugging insight — strobe progression makes burst bugs visible

Because the strobes are the observable form of the lane mapping, a wrong strobe progression is the fastest way to spot a burst bug:

Narrow write corrupts / drops bytes? Capture WSTRB per beat — it should rotate (0001, 0010, …). If it's stuck (e.g., 0001 every beat) the active lane isn't tracking the address, so all but one byte land wrong.
Unaligned write clobbers a byte below the start, or loses leading bytes? The first beat's strobes are wrong — they should be partial (e.g., 1100 for start 0x02), masking the lanes below the offset. Full 1111 on beat 0 overwrites bytes the master meant to preserve.
A strobe asserted outside the addressed range? Protocol violation — recompute the legal lane span (Address mod bus, Number_Bytes) for that beat and confirm no strobe is set beyond it.
Trailing-beat corruption on an odd-length unaligned burst? The last beat may also be partial — its strobes must clip to the remaining bytes, not run full.
FIXED strobes drifting beat to beat? They should be constant (address fixed); a changing pattern means the FIXED address handling is wrong.

The method: line up, per beat, the computed address → expected lane span → expected WSTRB, and diff against the observed strobes. The first beat whose strobes don't match is the bug — and the strobe value tells you whether it's a rotation (narrow), a clip (unaligned), or an over-assert (illegal) error.

7. Verification Insight

✅ Verification insight — model the strobe progression and check it byte-accurately

The capstone check is a golden strobe model: for each beat, derive the expected WSTRB from the beat address, Number_Bytes, and bus width (the chain of Chapters 7.5 → 7.7 → here), and assert the observed strobes match exactly — catching rotation errors (narrow), clip errors (unaligned partial beats), and out-of-range over-asserts (protocol violations) uniformly. Pair it with a byte-accurate reference memory that commits only strobed bytes, so a subordinate honoring the wrong strobes is caught at the byte level (a word-granular check would miss it). The two together verify both that the strobes are legal/correct and that they're honored.

Coverage must exercise the progressions, not just static patterns: aligned full-width (all-ones every beat), every narrow size with the active lanes rotating through a full bus word, unaligned starts at each offset (partial first beat at each lane span), unaligned and odd-length (partial last beat too), narrow + unaligned combined, FIXED (constant pattern), and sparse writes (legal sub-masking) plus the negative case of an out-of-range strobe (must be flagged). Because this ties together the whole module, a robust strobe-progression check effectively validates the address and lane models as well — making it the single highest-leverage write-side check in the burst suite.

8. Interview Questions

9. Summary

Strobe behavior is the per-beat application of one rule — WSTRB[n] = 1 iff lane n is in the beat's valid range (Address mod Data_Bus_Bytes, spanning Number_Bytes, clipped if partial) — across a whole burst. For aligned full-width (and FIXED) the pattern is constant (1111 / same lanes); for narrow bursts it rotates with the address (0001, 0010, 0100, 1000); for unaligned starts the first beat is partial (1100 then 1111); for WRAP it tracks the wrapped lanes. A master may sub-mask within the addressed range (sparse write) but must never strobe outside it.

This closes Module 7: the strobe progression is the observable output of the address (7.5) → lane (7.7) → strobe (6.7) chain, so verifying it beat-by-beat against a golden, lane-aware model — paired with a byte-accurate reference memory — validates the entire burst model at once and catches rotation, clip, and over-assert bugs that aligned full-width traffic hides. With bursts, addressing, boundaries, and strobes fully covered, Module 8 turns to a higher-level capability: outstanding transactions — issuing multiple transactions before earlier ones complete, the key to AXI's latency-hiding throughput.

10. What Comes Next

You've completed the burst model; Module 8 raises the abstraction to concurrency:

8.1 — Why Outstanding Transactions Exist (coming next) — how issuing multiple in-flight transactions hides latency and lifts throughput, the foundation of AXI performance.

Previous: 7.7 — Narrow & Unaligned Transfers. Related: 7.5 — Burst Address Calculation and 6.7 — WSTRB Write Strobes — the two models this chapter ties together. For the broader protocol catalog, see the AMBA family overview doc.