AMBA AXI · Module 17

Wrong WSTRB

Diagnose byte-level data corruption from bad WSTRB — strobes that write bytes they shouldn't (clobbering neighbors) or mask bytes they should write (dropping data), and strobes inconsistent with the address/size. Why wrong WSTRB is a silent, byte-granular corruption that the burst structure hides, and the byte-level cross-check that catches it.

The previous debugging chapters dealt with bursts that hang or are the wrong shape. Wrong WSTRB is different: the burst is perfectly well-formed — right handshakes, right LAST, right LEN/SIZE — and the data beats all transfer, but individual bytes are written incorrectly. WSTRB is the per-byte write-enable: each bit says "write this byte lane." When it's wrong, the slave either writes bytes it shouldn't (clobbering neighbors that should have been preserved) or masks bytes it should write (silently dropping intended data), or the strobes are inconsistent with the address/size (an illegal combination). This is the most byte-granular and most silent of the data bugs — nothing hangs, the burst looks valid, and the corruption hides inside otherwise-correct transactions. This chapter diagnoses it: the failure modes, why they're invisible at the burst level, and the byte-level cross-check that catches them.

1. What WSTRB Does and How It Goes Wrong

WSTRB has one bit per data byte (DATA_W/8 bits); a set bit means "write the corresponding byte lane," a clear bit means "leave that byte unchanged." It exists for partial-word and byte-granular writes — writing one field of a register, a sub-word store, an unaligned transfer. It goes wrong in three ways: extra strobes (bits set that shouldn't be → writes bytes that should have been preserved, clobbering neighbors), missing strobes (bits clear that should be set → intended bytes never written, silently dropped), and inconsistent strobes (a strobe pattern that doesn't match the address/SIZE — e.g. a strobe on a lane outside the transfer's active byte range — which is an illegal combination).

Figure 1 — the three WSTRB failure modes. WSTRB is the per-byte write-enable: each bit gates one byte lane. Extra strobes write bytes that should have been preserved, clobbering neighboring data. Missing strobes leave intended bytes unwritten, silently dropping data. Inconsistent strobes don't match the address/SIZE-implied active byte range, an illegal combination. All three corrupt at byte granularity inside an otherwise well-formed burst.

2. Extra Strobes: Clobbering Neighbors

The classic corruption: a write intended to update only some bytes of a word asserts more strobe bits than it should, so the slave overwrites bytes that should have been preserved. The neighbors are clobbered with whatever was on those byte lanes (often stale or zero), silently corrupting adjacent fields. The waveform shows a write whose WSTRB is wider than the intended field, overwriting bytes that should have kept their old values.

Extra WSTRB strobe clobbers a neighbor

7 cycles

Figure 2 — extra strobes clobber neighboring bytes. A write intended to update only byte 0 of a word should assert WSTRB=0001, preserving bytes 1–3. With WSTRB=0011 (an extra strobe on byte 1), the slave also overwrites byte 1 with whatever is on that lane — clobbering a neighboring field that should have been preserved. The read-back later shows the neighbor corrupted, even though the burst was well-formed and the intended byte was written correctly.

The deceptive part: the response is OKAY, the burst is valid, the intended byte was written correctly — only the neighbor is wrong, and that surfaces only when something reads it back. Nothing in the write transaction itself looks abnormal.

3. Missing Strobes and Inconsistent Strobes

Missing strobes are the inverse: a strobe bit that should be set is clear, so an intended byte is never written — the data is silently dropped and a later read returns the stale value. Inconsistent strobes are an illegal-combination bug: the strobe pattern doesn't match the transfer's active byte lanes implied by the address and SIZE. For a narrow or unaligned transfer, only certain lanes are valid; a strobe asserted outside that range (or a pattern that contradicts the size/alignment) violates the protocol. Unlike extra/missing strobes (wrong-but-legal corruption), inconsistent strobes are a legality violation a protocol checker can catch.

Figure 3 — missing strobes drop data; inconsistent strobes are illegal. Missing strobe: a byte that should be written has its strobe clear, so the slave leaves it unchanged and the intended data is silently lost (a later read returns the stale value). Inconsistent strobe: the strobe pattern asserts lanes outside the address/SIZE-implied active byte range, an illegal combination. Missing strobes are wrong-but-legal (need a data check to catch); inconsistent strobes are illegal (a protocol assertion catches them).

4. The Byte-Level Cross-Check

Because a wrong-but-legal WSTRB produces a perfectly valid-looking burst, catching it requires a byte-granular check: the reference model must apply the observed WSTRB exactly as the slave should, byte by byte, and the scoreboard then compares the resulting memory state — including the neighbor bytes that should have been preserved — against the intended result. A whole-word data comparison isn't enough; the corruption is at byte granularity, so the check must be too. The protocol assertion catches the inconsistent (illegal) strobes; the scoreboard's byte-level model catches the wrong-but-legal extra/missing strobes by verifying every byte, written and preserved.

Figure 4 — the byte-level cross-check. Protocol assertions catch inconsistent (illegal) strobes — lanes outside the address/SIZE range. But extra/missing strobes are legal patterns that produce a valid burst, so only a byte-granular reference model catches them: apply the observed WSTRB byte-by-byte, then compare every byte of the resulting memory — both the bytes that should change and the neighbors that should be preserved — against intent. A whole-word check misses neighbor clobbering; the check must be per-byte because the corruption is per-byte.

5. Common Misconceptions

Myths to unlearn

"If the burst is well-formed, the data is correct." A wrong WSTRB produces a perfectly well-formed burst (right handshakes, LAST, LEN/SIZE) with byte-level corruption inside. Burst validity says nothing about whether the right bytes were written.
"Comparing the written word is enough to verify a write." No — you must also verify the bytes that should have been preserved (the neighbors). Extra strobes clobber neighbors, which a whole-word comparison of only the intended bytes misses. Check every byte, written and preserved.
"WSTRB only matters for the bytes being written." It equally matters for the bytes not being written — a clear strobe must leave a byte unchanged. A bug in the clear bits (extra strobes) corrupts data the write wasn't supposed to touch at all.
"A wrong WSTRB will be caught by the protocol checker." Only the inconsistent (illegal) case — strobes outside the address/SIZE range. Extra and missing strobes are legal patterns producing valid bursts; only a byte-level reference model catches them.
"Missing strobes cause an error response." No — a missing strobe just doesn't write that byte; the transaction completes with OKAY. The data is silently dropped, surfacing only when a later read returns the stale value. There's no error to alert you.
"WSTRB corruption is rare/edge-case." Partial-word and byte-field writes are common (register fields, sub-word stores, unaligned transfers), and the byte-lane/strobe alignment logic is a frequent bug site — especially for narrow and unaligned transfers where the active-lane computation is non-trivial.

6. Debugging Insight

🔍 Debugging insight — read-back reveals it; check neighbors and the strobe-vs-address mapping

Wrong WSTRB rarely shows at write time — it surfaces on read-back, so diagnose from the corrupted bytes:

A read returns a corrupted neighbor of a written field. Suspect extra strobes — the write asserted more strobe bits than intended and clobbered the neighbor. Check the WSTRB of the prior write to that word against the bytes it should have touched.
A read returns a stale value for a byte that should have been written. Suspect missing strobes — the intended byte's strobe was clear, so the write never updated it. Check whether that byte's strobe was set in the write.
A protocol assertion fired on WSTRB. Inconsistent strobes — the pattern asserts lanes outside the address/SIZE active range. Check the strobe-generation logic against the transfer's alignment and width.
Corruption only on narrow or unaligned transfers. The byte-lane mapping for the active strobes is wrong — narrow/unaligned transfers place valid bytes on specific lanes, and the strobe-vs-lane computation is a classic bug. Check the lane alignment from SIZE and the low address bits.
Whole-word writes are fine, partial-word writes corrupt. Confirms a WSTRB (not data) bug — full-word writes assert all strobes (no masking exercised), so the bug only appears when strobes selectively mask. Focus on the partial-write strobe logic.
The scoreboard flagged a byte mismatch the assertions didn't. Expected — extra/missing strobes are wrong-but-legal, caught only by the byte-level model, not protocol checks. Trust the byte-level comparison.

The diagnostic key: wrong WSTRB is byte-granular and surfaces on read-back, so check the neighbors (extra strobes) and the stale bytes (missing strobes), and verify the strobe-to-lane mapping against the address/SIZE — especially for narrow/unaligned transfers where the active-lane logic is the usual culprit.

7. Verification Insight

✅ Verification insight — byte-granular checking with neighbor preservation, and sweep every strobe pattern

Wrong WSTRB is caught only by byte-granular verification, because the bug is byte-granular and the burst structure hides it. The non-negotiable disciplines: (1) The reference model applies WSTRB exactly as the slave should — byte by byte, updating only strobed bytes and leaving cleared-strobe bytes unchanged, so the model mirrors the slave's byte-level semantics (the same requirement as the scoreboard's data-integrity check in 16.4, made central here). (2) The check verifies every byte, including preserved neighbors — a write's correctness is not just "did the intended bytes get the right values?" but also "did the bytes that should not change stay unchanged?" — so the byte-level comparison must include the neighbors, which is the only way to catch the extra-strobe clobbering that a whole-word or intended-bytes-only check misses. (3) Read-back is the detector — WSTRB corruption is silent at write time (response is OKAY, burst is valid), so the verification must read back and compare; the write-then-read-with-every-strobe-pattern test is the canonical WSTRB check. (4) Sweep strobe patterns and alignments — cover full, sparse, single-byte, and every partial pattern, across aligned and unaligned addresses and narrow (SIZE < bus) transfers, because the byte-lane/strobe alignment logic is the frequent bug site and full-word writes (all strobes set) never exercise the masking. (5) Assertions catch only the illegal case — the protocol checker flags inconsistent strobes (lanes outside the address/SIZE range), but extra/missing strobes are legal and need the byte-level scoreboard; relying on assertions alone misses the silent corruption — the compliance-vs-correctness split (16.1) at byte granularity. Negative tests (16.7) should inject an extra strobe (confirm the scoreboard catches the neighbor clobber), a missing strobe (confirm the dropped-byte detection on read-back), and an inconsistent strobe (confirm the assertion fires). The highest-value, easiest-to-miss case is neighbor clobbering from extra strobes on a partial-word write, because everything about the transaction looks correct and only a byte-granular read-back of the preserved bytes reveals it. This completes the data-corruption layer of the burst-bug family: 17.1 (a beat won't transfer) → 17.2 (the burst ends wrong) → 17.3 (the burst is the wrong shape) → 17.4 (the bytes within a correctly-shaped burst are written wrong) — each progressively finer-grained, and each requiring the check to descend one level, ending here at the individual byte. Next, we turn from data corruption to the response signals — interpreting and tracing BRESP/RRESP errors.

8. Interview Questions

9. Summary

Wrong WSTRB is byte-level data corruption inside a perfectly well-formed burst — right handshakes, LAST, LEN/SIZE, and an OKAY response — making it the most silent of the data bugs. WSTRB is the per-byte write-enable, and it fails three ways: extra strobes (write bytes that should have been preserved → clobber neighbors), missing strobes (don't write intended bytes → silently drop data), and inconsistent strobes (a pattern that doesn't match the address/SIZE active lanes → an illegal combination). The extra/missing cases are wrong-but-legal and silent at write time; they surface only on read-back, when a corrupted neighbor or a stale dropped byte is read.

Catching them requires byte-granular checking: the reference model applies the observed WSTRB byte-by-byte (mirroring the slave) and the scoreboard compares every resulting byte — including the preserved neighbors — against intent, because a whole-word check can't see a single corrupted byte and the corruption isn't visible at write time. Protocol assertions catch only the inconsistent (illegal) strobes; the wrong-but-legal extra/missing strobes need the byte-level scoreboard — the compliance-vs-correctness split at byte granularity. Verification must sweep all strobe patterns across narrow and unaligned transfers (where the byte-lane/strobe-alignment logic, the usual culprit, is exercised) and use write-then-read as the detector. This completes the burst-bug hierarchy — 17.1 (beat won't transfer) → 17.2 (burst ends wrong) → 17.3 (burst is wrong shape) → 17.4 (bytes within a correct burst are wrong) — each finer-grained and more hidden, each needing the check to descend one level, ending at the individual byte and read-back. Next, we turn from data to the response signals: interpreting and tracing BRESP/RRESP errors.

10. What Comes Next

You can now catch byte-level data corruption; next, the response signals:

17.5 — BRESP / RRESP Errors (coming next) — interpreting SLVERR/DECERR on the response channels and tracing them back to their root cause (bad address, read-only write, faulting slave, interconnect decode).

Previous: 17.3 — Wrong LEN / Wrong SIZE. Related: 6.7 — Write Strobes (WSTRB) for the strobe semantics, 7.7 — Narrow & Unaligned Transfers for the byte-lane logic where strobe bugs hide, and 16.4 — AXI Scoreboards for the byte-level reference model.