AMBA AXI · Module 17

Wrong LEN / Wrong SIZE

Diagnose AXI bursts whose declared shape is wrong — a mis-set AxLEN (beat count) or AxSIZE (bytes per beat) that makes producer and consumer disagree on how many beats and how wide each is. Why these are 'silent contract' bugs that can hang, truncate, mis-place data, or corrupt the address stream, and the cross-check that catches them.

A missing LAST (17.2) breaks where the burst ends; a wrong AxLEN or AxSIZE breaks what the burst is. AxLEN declares the beat count (LEN+1 beats) and AxSIZE declares the bytes per beat (the transfer width); together they define the burst's shape and its total byte span. When either is wrong — mis-latched, mis-computed, or mis-driven — producer and consumer disagree on the contract itself, and LAST may even fire consistently with the wrong LEN, so the burst looks internally valid while being the wrong shape. This is the most insidious layer of burst bugs: it can hang (like a LAST problem), truncate, mis-place data at wrong addresses, or corrupt the address stream — and the fix requires checking the declared fields against what was intended, not just internal consistency. This chapter diagnoses both.

1. What LEN and SIZE Declare

AxLEN and AxSIZE are the burst's contract. AxLEN = number of beats minus one (so AWLEN=3 means 4 beats). AxSIZE = log2 of the bytes per beat (so AWSIZE=2 means 4 bytes/beat), which must not exceed the data bus width and which positions data on the correct byte lanes. The total bytes moved is (LEN+1) << SIZE, and the per-beat address advance (for INCR) is 1 << SIZE. Get either field wrong and every downstream computation — beat count, addressing, byte lanes, total span — is wrong.

Figure 1 — what AxLEN and AxSIZE declare and what depends on them. AxLEN sets the beat count (LEN+1); AxSIZE sets bytes per beat (1 << SIZE) and the byte-lane placement. Together they determine the total byte span ((LEN+1) << SIZE), the per-beat address increment (1 << SIZE for INCR), and where LAST should fire (beat LEN). A wrong value in either field propagates into all of these — beat count, addressing, lanes, and span — so a single mis-set field corrupts the whole burst's interpretation.

2. Wrong LEN: Beat-Count Mismatch

A wrong AxLEN means producer and consumer disagree on how many beats. If the slave latches (or the master drives) a LEN larger than the actual data, the slave waits for beats that never come → hang (it looks like a missing-LAST hang, but the root is the wrong count). If LEN is smaller than the data, the burst ends early and extra beats are orphaned or misattributed → truncation/corruption (it looks like a premature-LAST problem). The tell-tale that distinguishes wrong-LEN from a LAST-timing bug: here LAST fires consistently with the (wrong) LEN — the burst is internally self-consistent but the declared length itself is wrong.

Wrong AWLEN — self-consistent but wrong-length burst

9 cycles

Figure 2 — a wrong AxLEN with self-consistent LAST. The master intended a 4-beat burst but drove AWLEN=2 (3 beats); it asserts WLAST on beat 2, consistent with the wrong LEN. The slave completes a 3-beat write and issues B — no hang, no internal inconsistency — but the intended 4th beat is lost, so the transaction is wrong. Because LAST agrees with the (wrong) LEN, the LAST-vs-count cross-check passes; only checking LEN against what was *intended* (the reference model) catches it.

3. Wrong SIZE: Beat-Width and Lane Mismatch

A wrong AxSIZE means producer and consumer disagree on how wide each beat is. The consequences are subtler than wrong-LEN because the beat count may be right while the data is mis-placed: a wrong SIZE changes the per-beat address increment (1 << SIZE) and the byte-lane mapping, so data lands at the wrong addresses or on the wrong byte lanes, and an oversized SIZE (exceeding the bus width) is an outright protocol violation. The total span (LEN+1) << SIZE is also wrong, which for INCR can push the burst across a 4 KB boundary it shouldn't, or misalign a WRAP.

Figure 3 — wrong AxSIZE mis-places data. With the correct SIZE, each beat advances the address by 1 << SIZE and maps to the right byte lanes. A wrong SIZE changes the increment and lane mapping, so the same data beats land at the wrong addresses or wrong lanes — silent data placement corruption even when the beat count is correct. An oversized SIZE (> bus width) is an illegal encoding; a wrong span can also cross a 4 KB boundary or misalign a WRAP. The data may all 'transfer' yet end up in the wrong place.

4. The Cross-Check: Declared Fields vs. Intended

Because a wrong LEN/SIZE makes the burst internally self-consistent (the LAST-vs-count check passes, the beats are well-formed), the only way to catch it is to compare the declared fields against what was intended — the reference model's expected transaction (16.4). The scoreboard knows the intended address, length, and size for each transaction (from the test's intent or the address map), so it flags a LEN/SIZE that doesn't match even when the burst is internally valid. Protocol assertions catch the illegal cases (oversized SIZE, span crossing 4 KB), but the wrong-but-legal case needs the reference model.

Figure 4 — the two-level check for LEN/SIZE bugs. Protocol assertions catch the illegal cases: SIZE exceeding the bus width, a span crossing a 4 KB boundary, an illegal WRAP length. But a wrong-but-legal LEN/SIZE (e.g. AWLEN=2 when 4 beats were intended) is internally self-consistent and passes every protocol check — only the scoreboard's reference model, which knows the *intended* transaction shape, catches it by comparing declared fields against intent. Internal consistency is necessary but not sufficient; intent comparison is required.

5. Common Misconceptions

Myths to unlearn

"If LAST agrees with the beat count, the burst is correct." Not necessarily — a wrong AxLEN makes LAST fire consistently with the wrong length, so the burst is internally self-consistent but the declared length itself is wrong. Internal consistency doesn't mean the burst matches what was intended.
"A wrong SIZE just changes the beat width harmlessly." No — SIZE drives the address increment and byte-lane mapping, so a wrong SIZE places data at the wrong addresses or on the wrong lanes (silent data-placement corruption), and an oversized SIZE is an illegal encoding. It's not a benign width relabel.
"A burst-length hang is always a missing-LAST bug." It can be a wrong LEN — if the slave expects more beats than were sent (LEN too large), it hangs waiting, exactly like a missing LAST. Distinguish by checking whether LEN matches the intended length, not just whether LAST arrived.
"Protocol assertions catch wrong LEN/SIZE." They catch the illegal cases (oversized SIZE, 4 KB-crossing span, illegal WRAP length), but a wrong-but-legal LEN/SIZE passes every protocol check — only the reference model/scoreboard comparing against intent catches it.
"LEN and SIZE are independent of the data." They define how the data is counted and placed, so an error in either silently changes the meaning of the same data beats — wrong total span, wrong addresses, wrong lanes. The fields are the interpretation contract for the data, not separate metadata.
"Only the producer can get LEN/SIZE wrong." Either side can mis-handle them: the producer drives wrong values, or the consumer mis-latches/mis-interprets correct values (e.g. latching AWLEN into the wrong register, or computing the increment with the wrong SIZE). Check both the driven value and how it was captured/used.

6. Debugging Insight

🔍 Debugging insight — separate 'illegal' from 'wrong-but-legal', and check fields against intent

Diagnose LEN/SIZE bugs by first asking whether the value is illegal or merely wrong:

An assertion fired on SIZE/span/WRAP-length. The value is illegal — oversized SIZE (> bus width), span crossing 4 KB, or a non-2/4/8/16 WRAP length. The assertion names the field; check the logic driving it (a constant, a miscomputation).
Burst hangs, all sent beats transferred, LAST never came. Could be missing LAST (17.2) or a LEN larger than intended (slave waits for beats that won't come). Compare the driven AWLEN to the intended length — if AWLEN is too big, that's the bug, not LAST.
Burst completed but data is wrong / next transaction corrupted, LAST agreed with count. Suspect wrong LEN (too small) — the burst was internally consistent but shorter than intended; the cross-check against intent (not against LAST) catches it.
Data ended up at the wrong addresses or wrong byte lanes, beat count correct. Suspect wrong SIZE — the increment (1 << SIZE) and lane mapping are off. Check AxSIZE against the intended transfer width and the resulting addresses.
Span unexpectedly crossed 4 KB or a WRAP misaligned. A wrong SIZE (or LEN) changed (LEN+1) << SIZE. Recompute the span from the declared fields and compare to intent.
Both LAST and the engine agree but the transaction is wrong. Classic wrong-LEN/SIZE signature — internal consistency holds, so only the reference model flags the mismatch. Trust the scoreboard over the internal checks here.

The decisive move: internal consistency (LAST-vs-count) is necessary but not sufficient — for LEN/SIZE you must compare the declared fields to the intended transaction. An illegal value is caught by assertions; a wrong-but-legal value is caught only by the reference model.

7. Verification Insight

✅ Verification insight — two-level checking: assertions for illegal, reference model for wrong-but-legal

LEN/SIZE bugs require two levels of checking because they split into two categories with different detectability. Level 1 — illegal values, caught by protocol assertions (16.2): AxSIZE must not exceed the data bus width; the span (LEN+1) << SIZE must not cross a 4 KB boundary for INCR; WRAP lengths must be 2/4/8/16. These are structural rules checkable from the fields alone, so assertions catch them the cycle the address is driven — no reference needed. Level 2 — wrong-but-legal values, caught only by the reference model/scoreboard (16.4): an AWLEN of 2 when 4 beats were intended, or an AWSIZE of 2 when 8-byte beats were intended, is a perfectly legal burst that's simply the wrong shape — it passes every protocol assertion and even the LAST-vs-count check (because LAST fires consistently with the wrong LEN), so the only thing that catches it is comparing the declared fields against the intended transaction the reference model holds. This is the crucial lesson: internal consistency is necessary but not sufficient — a burst can be flawlessly self-consistent and still be wrong, and no amount of protocol checking detects a wrong-but-legal contract; you need an independent statement of intent. Practically: the scoreboard must check not just data but the transaction shape (address, LEN, SIZE, burst type) against the expected, so a mis-shaped burst is flagged even when its data and LAST are internally fine; the monitor (16.3) must reconstruct and report the declared fields so the scoreboard can compare them; negative tests (16.7) should inject both an illegal SIZE/span (confirm the assertion fires) and a wrong-but-legal LEN/SIZE (confirm the scoreboard flags it, proving the intent-comparison works); and coverage should include the full range of legal LEN/SIZE values and the boundary cases (max LEN, max SIZE = bus width, spans near 4 KB). The highest-value, easiest-to-miss bug is the wrong-but-legal LEN/SIZE, precisely because every protocol check passes — a verification environment that only runs assertions (compliance) and not a shape-checking scoreboard (correctness) will miss it entirely, which is the compliance-vs-correctness split (16.1) made concrete at the burst-field level. This chapter is the deepest layer of the burst-bug family (17.1 handshake, 17.2 LAST, 17.3 fields): the bug has moved from "a beat won't transfer" to "the end-marker is wrong" to "the declared contract is wrong," and each layer requires checking one level further from the raw signals — culminating here in checking the declared shape against intent, which only an independent reference can do. Next, we look at wrong WSTRB, where the data that does arrive is corrupted at the byte level.

8. Interview Questions

9. Summary

A wrong AxLEN or AxSIZE breaks what the burst is — its declared shape — as opposed to where it ends (17.2) or whether beats transfer (17.1). AxLEN sets the beat count (LEN+1); AxSIZE sets the bytes per beat (1 << SIZE), the address increment, and the byte-lane mapping; together they set the total span (LEN+1) << SIZE and where LAST should fire — so a single wrong field corrupts beat count, addressing, lanes, and span. Wrong LEN makes producer and consumer disagree on beat count: too large → hang (waits for beats that never come), too small → truncation/corruption — and critically, LAST fires consistently with the wrong LEN, so the burst is internally self-consistent but the wrong shape. Wrong SIZE is subtler: the beat count can be right while data is mis-placed at wrong addresses or lanes (silent corruption), with oversized SIZE being an illegal encoding and a wrong span crossing 4 KB or misaligning a WRAP.

Because a wrong-but-legal LEN/SIZE passes every protocol check (legality and LAST-vs-count), catching it requires two levels: protocol assertions for the illegal cases (oversized SIZE, 4 KB-crossing span, illegal WRAP length), and the reference-model scoreboard comparing declared fields against intent for the wrong-but-legal cases. This is the chapter's deepest lesson — internal consistency is necessary but not sufficient for burst correctness; only an independent statement of intent catches a flawlessly self-consistent but wrong-shaped burst, which is the compliance-vs-correctness split (16.1) made concrete at the field level. Across 17.1→17.3 the bug moves from "a beat won't transfer" to "the end-marker is wrong" to "the declared contract is wrong," each requiring a check one level further from the raw signals. Next, we examine wrong WSTRB — where the data that arrives is corrupted at the byte level.

10. What Comes Next

You can now catch a wrong burst shape; next, byte-level data corruption:

17.4 — Wrong WSTRB (coming next) — diagnosing corrupted data from bad byte strobes, where the burst shape is right but individual bytes are written or masked incorrectly.

Previous: 17.2 — Missing LAST. Related: 7.5 — Burst Address Calculation for how SIZE drives the per-beat address, 7.6 — The 4 KB Boundary Rule for the span constraint, and 16.4 — AXI Scoreboards for the reference model that checks shape against intent.

Continue learning

Standards & specifications

Governing standard: Arm AMBA AXI Protocol Specification (IHI 0022)(opens Arm in a new tab)
Defines the AXI channels, handshake and ordering rules. RTL structure, interconnect topology and verification strategy are design choices this specification does not mandate.

This page also covers RTL structure, verification approach and debugging technique. Those are engineering practice built on the standard, not requirements the standard itself imposes.

Where this fits

Part of the AMBA AXI curriculum.