AMBA AXI · Module 17

Missing LAST

Diagnose a burst that never ends because WLAST/RLAST is missing or mis-timed — the two failure modes (LAST never asserts, or asserts on the wrong beat), how a missing LAST hangs the response while a premature LAST truncates the transaction, the beat-count vs. LAST cross-check, and the systematic method to localize it.

A stuck handshake (17.1) hangs because a beat never transfers. A missing or mis-timed LAST hangs for a different reason: the beats transfer fine, but the burst never ends — WLAST (write) or RLAST (read) is the explicit end-of-burst marker, and if it never asserts (or asserts on the wrong beat), the receiver's burst-tracking never closes. A missing WLAST means the slave keeps waiting for "more" write data and never issues the B response; a missing RLAST means the manager never knows the read burst finished. This chapter diagnoses both failure modes — LAST that never comes versus LAST on the wrong beat — explains why each produces its symptom, and gives the decisive cross-check: does the LAST-marked beat coincide with beat LEN?

1. Why LAST Matters and the Two Failure Modes

WLAST/RLAST is the protocol's explicit signal that "this beat is the final one of the burst." A receiver counts beats and uses LAST to know when to stop and complete the transaction. There are two ways it goes wrong: LAST never asserts (the burst-tracking never closes → hang), or LAST asserts on the wrong beat — too early (burst truncated, beats lost or misattributed) or too late (extra beats expected). Both stem from a disagreement between the burst length (AxLEN) and where LAST actually fires.

Figure 1 — the two LAST failure modes. LAST never asserts: beats transfer but the burst never ends, so the receiver waits forever for the final beat and never completes (write: no B response; read: burst never closes) — a hang. LAST on the wrong beat: too early truncates the burst (remaining beats lost or misattributed to the next transaction); too late leaves the receiver expecting more. Both come from a LAST-vs-LEN disagreement.

2. The Missing-WLAST Hang

The most common case: a write burst transfers all its data beats, but WLAST is never asserted on the final beat. The slave's write engine is counting beats and waiting for WLAST to move to its response state — without it, the engine sits in the data phase forever, never issues B, and the manager hangs waiting for the response. The waveform shows beats flowing normally, then silence where WLAST and B should be.

Missing WLAST — write hangs with no B

10 cycles

Figure 2 — a missing WLAST hangs the write. Four W data beats transfer normally (WVALID/WREADY handshakes), but WLAST is never asserted on the fourth beat. The slave's write engine keeps waiting for the final beat, never enters its response state, and BVALID never asserts — the manager hangs forever waiting for the B response. The beats moved fine; the burst simply never ended. The signature is a complete-looking data phase with no LAST and no response.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// The slave waits for WLAST to leave the data phase. If WLAST never comes,
// it never reaches W_RESP, so BVALID never asserts → manager hangs.
W_DATA: if (s_wvalid && s_wready) begin
  beat_q <= beat_q + 1;
  if (s_wlast) begin              // <-- if this never fires, the burst never ends
    s_bvalid <= 1'b1; wstate <= W_RESP;
  end
end
// Robust slaves ALSO check beat_q against the latched AWLEN and flag a mismatch,
// rather than trusting WLAST alone.

3. Premature or Late LAST — Truncation and Misattribution

The subtler failure is LAST on the wrong beat. Premature LAST (asserted before beat LEN) ends the burst early: the slave completes after fewer beats than AWLEN+1, so the remaining data beats are either lost or — worse — misattributed to the next transaction, corrupting it. Late LAST (or LAST never reached because LEN was over-counted) leaves the receiver expecting beats that don't come. Both desynchronize the beat stream from the burst boundaries.

Premature WLAST — burst truncated

9 cycles

Figure 3 — premature LAST truncates and misattributes. A burst declared with AWLEN=3 (4 beats) asserts WLAST on beat 1 (the second beat) instead of beat 3. The slave ends the burst after 2 beats and issues B; the remaining 2 beats (D2, D3) are now orphaned — either dropped or, if the slave starts a new transaction, misattributed to it, corrupting both. Premature LAST is more insidious than missing LAST because it doesn't hang — it silently corrupts.

The defining contrast: missing LAST hangs (obvious, the bus freezes), while premature LAST silently corrupts (insidious, no hang — the transaction just completed wrong and poisoned the next). The premature case is more dangerous precisely because it doesn't announce itself.

4. The Decisive Cross-Check: LAST vs. Beat Count

Both failure modes reduce to one check: does LAST assert on exactly beat LEN (counting from 0, so the (LEN+1)-th beat)? A robust receiver counts beats itself and compares its count to LAST rather than trusting either alone — a mismatch is the bug, and which way it mismatches tells you the failure mode. The monitor (16.3) and protocol assertions (16.2) implement exactly this cross-check, so the diagnosis is usually already flagged.

Figure 4 — the LAST-vs-LEN cross-check that localizes the bug. Count beats and compare to the declared LEN at the moment LAST asserts (or should). If LAST never fires by beat LEN → missing-LAST hang. If LAST fires before beat LEN → premature/truncation. If beat LEN passes with no LAST → over-count/late. The receiver trusts neither LAST nor its count alone but cross-checks them; the direction of the mismatch names the failure mode. This is exactly what the protocol assertion and monitor enforce.

5. Common Misconceptions

Myths to unlearn

"A missing LAST is harmless if the data all arrived." No — the data arriving doesn't end the burst. Without LAST, the receiver's burst-tracking never closes: the write slave never issues B (hang), or the read manager never knows the burst finished. LAST is what terminates the transaction.
"LAST is redundant with the beat counter." They should agree, but LAST is the explicit marker and the counter is the receiver's independent tally — a robust design cross-checks them. Trusting only the counter (ignoring LAST) or only LAST (ignoring the count) misses exactly the bug where they disagree.
"Premature LAST is less serious than missing LAST." It's often more serious: missing LAST hangs (loud, obvious), but premature LAST silently corrupts — it truncates the burst and orphans or misattributes the remaining beats to the next transaction, with no hang to alert you.
"A hang waiting for B is always a handshake problem." It can be a missing WLAST — the W handshakes all completed, but the burst never ended, so the slave never reached its response state. Check WLAST against the beat count before assuming a stuck handshake (17.1).
"The manager always asserts LAST correctly." LAST is driven by the producer (manager for W, slave for R), and its logic can be wrong — off-by-one beat counting, wrong LEN latched, or a generator bug. Don't assume the other side's LAST is correct; the cross-check is what catches it.
"LAST and LEN can't both be wrong." They can — if LEN is mis-latched, LAST may fire consistently with the wrong LEN, so both agree on a wrong burst length. That's why the receiver counts independently and the next chapter (17.3) addresses wrong-LEN directly.

6. Debugging Insight

🔍 Debugging insight — distinguish the hang (missing) from the corruption (premature) by the symptom

The symptom tells you which LAST failure you have:

Write hangs waiting for B, with all W beats transferred. Strongly suggests missing WLAST — the data phase completed but the burst never ended. Check whether WLAST ever asserted; compare the transferred beat count to the latched AWLEN+1. If beats == AWLEN+1 but no WLAST, that's the bug.
Read burst never completes / manager waits forever. Possible missing RLAST — the slave sent all beats but never marked the last. Same check: beat count vs. ARLEN+1 vs. where RLAST fired.
Transaction completed but data is wrong / the next transaction is corrupted. Suspect premature LAST — the burst was truncated and remaining beats orphaned or misattributed. Check whether LAST fired before beat LEN; the missing beats poison the following transaction.
Receiver expects more beats than arrive. Late/over-counted LAST or a LEN-vs-LAST disagreement — the count exceeded where LAST fired. Cross-check LEN and the actual last beat.
LAST fires consistently but the burst length seems wrong. LEN itself may be mis-latched (both LAST and the engine agree on a wrong length) — that's a wrong-LEN problem (17.3), distinct from a LAST-timing bug.
The protocol assertion already flagged it. The WLAST/RLAST-vs-count assertion (16.2) pinpoints the beat and the disagreement — read it first; it tells you missing vs. premature directly.

The diagnostic split is hang vs. corruption: a hang with completed beats → missing LAST; a wrong/poisoned transaction with no hang → premature LAST. Both are confirmed by the same cross-check — beat count vs. where LAST fired vs. the declared LEN.

7. Verification Insight

✅ Verification insight — never trust LAST alone; cross-check against an independent beat count, and assert it

The root discipline for LAST correctness is that no component should trust LAST alone or the beat count alone — it must cross-check them, because the bug is precisely a disagreement between the explicit end-marker and the declared length. Concretely: a robust slave/receiver latches AxLEN, counts beats independently on each handshake, and at the LAST-marked beat asserts that the count equals LEN+1 — flagging a missing LAST (count reaches LEN+1 with no LAST), a premature LAST (LAST before the count reaches LEN), or an over-count (count exceeds LEN+1). This is exactly the protocol assertion from 16.2 (WLAST/RLAST on exactly the (LEN+1)-th beat) and the monitor's reconstruction check from 16.3, so in a well-instrumented environment the bug is already localized to a beat and a direction-of-mismatch before manual debugging. The two failure modes need different verification emphasis: missing LAST is a liveness failure (the burst never ends → hang), caught by the response-eventually-comes liveness assertion and a per-transaction watchdog (17.1's instrumentation applies — a write that never gets its B trips the watchdog); premature LAST is a safety/correctness failure (silent truncation and misattribution), caught by the count-equals-LEN assertion and the scoreboard (16.4), which sees the truncated transaction's wrong data and the next transaction's corruption. The verification plan must therefore: sweep LAST timing in negative tests (16.7) — deliberately inject a missing LAST and a premature LAST and confirm the assertion fires and the watchdog/scoreboard catches the consequence; cover the LAST-on-exactly-LEN condition across all burst lengths; and ensure the receiver's own RTL cross-checks rather than blindly trusting the producer's LAST (defensive design — a slave that hangs because it trusted a never-arriving LAST is itself fragile). The highest-value, easiest-to-miss case is premature LAST's misattribution to the next transaction, because it doesn't hang and the corruption surfaces one transaction later — only an independent beat-count cross-check plus a scoreboard that tracks transaction boundaries reliably catches it. The unifying principle echoes 17.1: trust no single signal's claim — cross-check the explicit marker (LAST) against the independent tally (counted beats vs. declared LEN), and the direction of any disagreement names the failure. Next, we go one level deeper to the LEN/SIZE fields themselves, where a mis-latched length makes LAST and the engine agree on a wrong burst.

8. Interview Questions

9. Summary

A missing or mis-timed LAST hangs or corrupts a burst not because beats fail to transfer, but because the burst never ends correctly. WLAST/RLAST is the explicit end-of-burst marker; the two failure modes are LAST never asserts (burst-tracking never closes → the write slave never issues B, the read never completes → a hang) and LAST on the wrong beat — premature (truncates the burst, orphaning or misattributing remaining beats → silent corruption) or late/over-counted (receiver expects beats that don't come). The defining contrast: missing LAST hangs loudly; premature LAST corrupts silently and is therefore more dangerous, often surfacing as a later transaction's failure.

The decisive diagnosis is the LAST-vs-beat-count cross-check: does LAST assert on exactly beat LEN (the (LEN+1)-th)? The receiver counts independently and reconciles its count with LAST and the declared AxLEN — and the direction of any disagreement names the mode (no LAST by LEN → hang/late; LAST before LEN → truncation). This is exactly the protocol assertion (16.2) and monitor (16.3) check, so the bug is usually pre-flagged. The robust-design principle is defensive cross-checking: a receiver must not trust the producer's LAST alone but validate it against the counted beats vs. the contracted LEN, degrading an upstream LAST bug into a flagged, contained error rather than a hang or corruption. Missing LAST is a liveness failure (watchdog + liveness assertion); premature LAST is a safety failure (count assertion + scoreboard catching the misattribution). Next, we go one layer deeper to the LEN/SIZE fields themselves, where a mis-latched length makes LAST and the engine agree on a wrong burst.

10. What Comes Next

You can now diagnose a burst that ends wrong; next, a burst whose declared shape is wrong:

17.3 — Wrong LEN / Wrong SIZE (coming next) — catching beat-count and beat-width mismatches at the AxLEN/AxSIZE fields, where the burst's declared shape itself is wrong and LAST may fire consistently with the wrong length.

Previous: 17.1 — Stuck VALID / Stuck READY. Related: 6.8 — RRESP, BRESP & RLAST for the LAST semantics, 15.3 — AXI Write FSM for the write engine's WLAST-driven completion, and 16.2 — AXI Assertions (SVA) for the LAST-vs-count assertion.