AMBA AXI · Module 6

WSTRB Write Strobes

Master AXI's WSTRB write strobes — one byte-enable per byte lane, how they enable sparse and unaligned writes, how the valid lanes follow from address and AxSIZE, and why a subordinate must honor them exactly.

WSTRB is the AXI signal that turns the write-data bus from "write the whole word" into "write exactly these bytes." It is a byte-enable mask — one bit per byte lane — and it is the mechanism behind every byte write, halfword write, unaligned write, and sparse transfer on AXI. Unlike AxUSER (no defined meaning) the strobes have a precise, mandatory semantics: a subordinate must write only the asserted lanes and leave the rest untouched. Getting WSTRB wrong corrupts neighbouring bytes silently, which is why this signal is critical to understand exactly. This chapter covers what the strobes are, how the valid lanes follow from address and AxSIZE, and how to debug and verify them.

1. What WSTRB Is

WSTRB accompanies the write-data channel: one strobe bit per byte lane of WDATA.

WSTRB[n] = 1 → byte lane n carries valid data and must be written.
WSTRB[n] = 0 → byte lane n is masked — the subordinate must not modify that byte.

Its width is DATA_WIDTH / 8: a 32-bit data bus has WSTRB[3:0] (4 lanes), a 64-bit bus has WSTRB[7:0] (8 lanes), a 128-bit bus has 16, and so on. WSTRB exists per write-data beat (WVALID/WREADY handshake) — each beat of a burst carries its own strobes — and follows the channel's stability rules. There is no read equivalent: reads always return whole bytes and the manager takes what it needs; strobes are a write-only concept.

Figure 1 — WSTRB is one byte-enable per byte lane of WDATA. On a 32-bit bus, WSTRB[3:0] gate the four byte lanes: a 1 commits that lane's byte, a 0 masks it. Width is DATA_WIDTH/8, and each write-data beat carries its own strobes.

2. A Partial Write on the Wire

The classic use is writing some bytes of a word. Here a 32-bit beat carries WDATA = 0xAABBCCDD with WSTRB = 4'b0110 — only the middle two byte lanes are committed:

wstrb-lanes — partial write, WSTRB = 4'b0110

5 cycles

Figure 2 — wstrb-lanes: a single-beat partial write. WDATA presents 0xAABBCCDD but WSTRB = 4'b0110 asserts only lanes 1 and 2, so the subordinate writes bytes 0xCC and 0xBB and leaves the bytes in lanes 0 (0xDD) and 3 (0xAA) untouched. The strobes are stable with the data through the WVALID/WREADY handshake.

3. Which Lanes Are Valid — Address and AxSIZE

The asserted strobes are not arbitrary — they must be consistent with the transaction's address and AxSIZE (and the beat's position in the burst). The valid byte lanes are exactly the bytes the transfer addresses:

Transfer	Address (low bits) / size	Valid lanes (32-bit bus)	`WSTRB`
Full word, aligned	`0x...0`, size = 4 bytes	0,1,2,3	`4'b1111`
Single byte at offset 0	`0x...0`, size = 1	0	`4'b0001`
Single byte at offset 2	`0x...2`, size = 1	2	`4'b0100`
Halfword at offset 0	`0x...0`, size = 2	0,1	`4'b0011`
Halfword at offset 2	`0x...2`, size = 2	2,3	`4'b1100`

So a narrow transfer (AxSIZE < bus width) or an unaligned address shifts the asserted strobes to the addressed byte lanes; bytes outside the addressed range must have their strobes deasserted. Asserting a strobe for a byte the address/size doesn't cover (or vice versa) is a protocol violation. Within a burst, each beat's valid lanes advance per the burst type and size (the address arithmetic from Chapters 6.1–6.2).

Figure 3 — valid lanes follow address and AxSIZE. An aligned full-width transfer asserts all strobes (1111); a single-byte transfer asserts only the addressed lane (e.g. 0100 for offset 2); a halfword asserts its two lanes (1100 for offset 2). The strobes must match exactly the bytes the address and size cover — no more, no less.

4. Why It's Critical — Honoring the Strobes

WSTRB is mandatory semantics, not a hint. A subordinate (memory, register block, bridge) must commit only the asserted byte lanes and leave masked bytes unchanged:

Figure 4 — honoring WSTRB. For each byte lane the subordinate checks its strobe: assert → write that byte; deassert → leave it untouched. Ignoring the strobes (writing the whole word regardless) corrupts the masked neighbouring bytes — a silent data-integrity bug that the bus transfer itself looks correct for.

The strobes are exactly what lets a master do a byte or halfword write without a read-modify-write: it drives the full data bus but asserts only the relevant strobes, and the subordinate updates just those bytes. They also carry sparse writes (non-contiguous valid bytes within a beat, e.g., 4'b1010) and unaligned writes (the first/last beats of an unaligned burst use partial strobes). It is legal for a beat to have all strobes deasserted (WSTRB = 0) — a beat that writes nothing — though it still consumes a beat and counts toward the burst length.

5. Common Misconceptions

Myths to unlearn

"A slave can ignore WSTRB and just write the whole word." Never — honoring strobes is mandatory. Writing masked bytes corrupts data the master intended to preserve. This is the single most damaging WSTRB bug.
"Reads have strobes too." No — WSTRB is write-only. Reads return all bytes; the manager selects what it needs. There is no RSTRB.
"WSTRB can be anything regardless of address/size." No — the asserted lanes must match the bytes the address and AxSIZE cover. Strobes inconsistent with address/size are a protocol violation.
"Strobes are per-transaction." They're per beat — every write-data beat carries its own WSTRB, and they can differ beat to beat (e.g., partial first/last beats of an unaligned burst).
"All-zero WSTRB is illegal." It's legal — a beat with WSTRB = 0 writes nothing but still counts as a beat of the burst. (Whether a master should issue one is a design choice.)
"WSTRB width is fixed at 4." It's DATA_WIDTH/8 — 4 for 32-bit, 8 for 64-bit, 16 for 128-bit, etc.

6. Debugging Insight

🔍 Debugging insight — WSTRB bugs corrupt neighbours and look like memory errors

WSTRB problems usually manifest as adjacent bytes mysteriously changing — not as a bus error:

A byte/halfword write clobbers neighbouring bytes? The subordinate is ignoring WSTRB and writing the full word (committing masked lanes). The bus shows correct WDATA/WSTRB; the bug is in the slave's write logic. Check that it gates each byte's write-enable with the corresponding strobe bit.
The wrong bytes get written on a narrow/unaligned access? The strobe-to-lane mapping is wrong — strobes must align to the addressed byte lanes derived from address low bits and AxSIZE. A master computing strobes as if always aligned (or a byte-lane mux off by the address offset) writes the right data to the wrong lanes.
Data corruption only on bursts? The per-beat strobes are wrong — first/last beats of an unaligned burst need partial strobes while middle beats are full. A master that drives the same strobes every beat corrupts the burst edges.
Endianness-looking byte swaps? Often a byte-lane/strobe ordering mismatch between master and slave (lane 0 ↔ lane 3), so strobes and data disagree on which byte is which.

The signature is data integrity, not protocol error — masked bytes change, or the right data lands in the wrong byte. Debug by lining up WDATA, WSTRB, the address low bits and AxSIZE for the exact beat, and confirming the slave write-enables match the strobes lane-for-lane.

7. Verification Insight

✅ Verification insight — strobe legality, honoring, and full byte-enable coverage

WSTRB is a top-priority verification target because its bugs are silent data corruption. Three angles: legality — assert the asserted strobes are consistent with the address and AxSIZE on every beat (no strobe outside the addressed range; partial first/last beats on unaligned bursts), since an illegal strobe pattern is a protocol violation; honoring — the highest-value check: a byte-accurate scoreboard/reference memory that updates only strobed bytes, so any subordinate that writes a masked byte is caught immediately (a whole-word comparison would miss it — you must compare per byte); and coverage — exercise the full range of strobe patterns: all-ones, single-byte at each offset, halfwords, sparse (e.g. 1010), all-zero, and the unaligned-burst edge beats.

The negative tests matter most here: directed partial writes that would corrupt neighbours if strobes were ignored, with the reference model proving the masked bytes are preserved. Because reads have no strobe, the read-side equivalent is simply checking the returned bytes against the byte-accurate model that WSTRB writes built up. Strobe handling is one of the few signals where a byte-granular scoreboard is non-negotiable.

8. Interview Questions

9. Summary

WSTRB is the AXI byte-enable mask for writes — one strobe bit per byte lane of WDATA (WSTRB[n]=1 commits lane n, 0 masks it), width DATA_WIDTH/8, present per write-data beat. It is the mechanism for byte/halfword writes, sparse writes, and unaligned bursts — the master drives the full bus and asserts only the strobes for the bytes it means to write, so no read-modify-write is needed. The asserted lanes are not free: they must match exactly the bytes the address and AxSIZE cover, and they advance per beat across a burst (partial first/last beats on unaligned transfers). Reads have no strobe.

The reason this signal is critical: its semantics are mandatory, and its bugs are silent data corruption, not protocol errors. A subordinate must commit only the strobed bytes — ignoring WSTRB clobbers the neighbouring bytes the master intended to preserve, and a byte-lane mapping error writes the right data to the wrong byte. So both debug and verification hinge on a byte-granular view: line up strobes against address and size, and check writes against a byte-accurate reference model. Next: RESP and LAST — consolidating the BRESP/RRESP response codes and the WLAST/RLAST burst-terminator semantics in one place.

10. What Comes Next

You've mastered the write strobes; next, the responses and burst terminators:

6.8 — RESP & LAST Signals (coming next) — consolidating BRESP/RRESP (OKAY/EXOKAY/SLVERR/DECERR) and WLAST/RLAST semantics.

Previous: 6.6 — AxUSER & Sideband Signals. Related: 6.1 — AxADDR, AxLEN & AxSIZE and 6.2 — AxBURST for how addresses and sizes drive the valid lanes. For the broader protocol catalog, see the AMBA family overview doc.