AMBA AXI · Module 6

RESP & LAST Signals

Consolidate AXI's response and burst-terminator signals — BRESP/RRESP (OKAY/EXOKAY/SLVERR/DECERR), the write-aggregate vs read-per-beat asymmetry, and WLAST/RLAST and their consistency with AxLEN.

This chapter consolidates two signal groups that have surfaced across the channel chapters and deserve a single, precise treatment: the response codes (BRESP on the write-response channel, RRESP on the read-data channel) and the burst terminators (WLAST, RLAST). The responses tell the manager whether each access succeeded — and the encoding is shared between reads and writes, but how many responses you get differs. The LAST signals mark the final beat of a burst — and their timing must agree exactly with AxLEN. Both are correctness-critical and a frequent source of hangs and misreported errors, so this is the chapter to nail them down.

1. RESP — The Response Encoding

BRESP (write) and RRESP (read) share the same 2-bit encoding:

`xRESP`	Name	Meaning
`2'b00`	OKAY	Normal access success.
`2'b01`	EXOKAY	Exclusive access success — only valid for an exclusive access (`AxLOCK=1`, Chapter 6.4).
`2'b10`	SLVERR	Slave error — the access reached the subordinate, but it could not complete it correctly (unsupported transfer, internal error, write to a read-only location, etc.).
`2'b11`	DECERR	Decode error — no subordinate exists at that address; the interconnect's default slave returns it when address decode finds no target.

The crucial distinction is SLVERR vs DECERR: SLVERR means "I'm the right slave and I failed"; DECERR means "there is no slave here" (an address-decode miss, generated by the interconnect, not by a real endpoint). EXOKAY is special — it appears only for exclusive accesses and signals the atomic sequence succeeded; a normal access never returns it.

Figure 1 — the shared 2-bit RESP encoding. OKAY (normal success), EXOKAY (exclusive success only), SLVERR (the addressed slave failed), DECERR (no slave at the address — from the interconnect's default slave). The same codes apply to BRESP and RRESP; the key contrast is SLVERR 'wrong result from the right slave' vs DECERR 'no slave there at all'.

2. One Response vs One Per Beat

A subtle but important asymmetry: a write burst gets a single response; a read burst gets a response per beat.

BRESP is driven once per write transaction on the B channel — a single aggregate result for the whole burst, after all W beats are accepted.
RRESP is driven on every R beat — each returned data beat carries its own response, so different beats of the same burst can report different statuses (e.g., most beats OKAY, one SLVERR).

This follows from the channel structure: the write-response channel B is single-beat by nature (one response closes the write), while the read-data channel R is multi-beat (data and its status arrive together, beat by beat). An error on one read beat does not cancel the rest of the burst — the subordinate still returns the remaining beats and asserts RLAST normally; the manager decides how to handle the flagged beat.

Figure 2 — response cardinality. A write burst produces one BRESP covering the whole transaction on the B channel. A read burst produces one RRESP per R beat, so each data beat carries its own status and beats can differ. An error beat doesn't abort a read — the remaining beats and RLAST still come.

3. LAST — Marking the End of a Burst

WLAST and RLAST mark the final beat of a data burst:

WLAST — the manager asserts it on the last write-data (W) beat, telling the subordinate "this is the final beat of the write burst."
RLAST — the subordinate asserts it on the last read-data (R) beat, telling the manager "this is the final beat of the read burst."

LAST exists only on the data channels (W, R) because only they are multi-beat. The address channels (AW, AR) carry a single address transfer, and the B channel is a single response — none of them needs a terminator. The directions mirror who drives the data: the manager produces write data (so it drives WLAST); the subordinate produces read data (so it drives RLAST).

resp-last — 4-beat read burst, per-beat RRESP, RLAST on the final beat

6 cycles

Figure 3 — the resp-last waveform: a 4-beat INCR read burst (AxLEN=3). Each R beat carries its own RRESP — here beat 2 returns SLVERR while the others are OKAY — and the burst still runs to completion. RLAST asserts on the 4th and final beat, exactly matching AxLEN+1 beats. The error beat does not abort the burst.

4. LAST Must Agree With AxLEN

LAST is not free-running — its position is determined by AxLEN. A burst has exactly AxLEN + 1 beats, so LAST must assert on beat number AxLEN + 1 and on no other:

Figure 4 — LAST consistency. The subordinate (RLAST) or manager (WLAST) counts beats; LAST must assert on exactly beat AxLEN+1. Asserting it early ends the burst short (missing beats — a likely hang or data loss); asserting it late or never leaves the burst open (the receiver waits forever — a hang). Both are protocol violations.

A receiver uses LAST to know the burst is complete and to release/match resources (e.g., an outstanding-transaction slot, or the next transaction's ordering). If WLAST/RLAST disagrees with AxLEN, the burst is malformed: assert early and beats are lost or the next transaction is misframed; assert late or never and the receiver waits indefinitely — a classic hang.

5. Common Misconceptions

Myths to unlearn

"SLVERR and DECERR are the same kind of error." No — DECERR means no slave decoded at that address (interconnect default slave); SLVERR means the real slave was reached and failed. They point at completely different root causes.
"A write burst returns one response per beat like reads." No — BRESP is one response for the whole write transaction; only RRESP is per beat. This asymmetry trips up many people.
"An error response aborts the burst." It doesn't — a read with a SLVERR/DECERR on one beat still returns all remaining beats and asserts RLAST; the error is informational and the manager decides what to do.
"EXOKAY can come back on any access." Only on exclusive accesses (AxLOCK=1). A normal access returning EXOKAY — or an exclusive one never getting it — is a bug (Chapter 6.4).
"LAST can be asserted whenever the sender is done." No — it must land on beat AxLEN + 1 exactly. Early/late LAST is a protocol violation that causes short bursts or hangs.
"There's a LAST on every channel." Only on the data channels (W, R). AW/AR are single address transfers and B is a single response — no terminator needed.

6. Debugging Insight

🔍 Debugging insight — RESP and LAST bugs cause misdiagnosed errors and hard hangs

These signals are behind two of the most common AXI bring-up symptoms — wrong error attribution and bus hangs:

Getting DECERR when you expected the slave to respond? The address didn't decode to any slave — check the address map and the interconnect's decode (the response is coming from the default slave, not your peripheral). Conversely a SLVERR means the slave was reached but rejected the access (unsupported size/length, read-only write) — debug the slave, not the address map.
Bus hangs at the end of a burst? Suspect LAST. If RLAST/WLAST is never asserted (or asserted late), the receiver waits forever for the burst to end — a hard hang. Check the beat count against AxLEN: LAST must be on beat AxLEN+1.
Data loss or a misframed next transaction? LAST asserted early ends the burst short; the remaining beats are orphaned and the next transaction's beats can be misattributed. Again, compare LAST timing to AxLEN.
An error you can't see on writes? Remember BRESP is aggregate — a write failure is reported once on B, not per beat. If you're watching the W channel for an error code you won't find one; the status is on B.
Per-beat read errors missed? Since RRESP is per beat, a single bad beat in an otherwise-OK burst is easy to overlook — you must check RRESP on every beat, not just the last.

So: wrong-error-source → SLVERR vs DECERR; end-of-burst hang or data loss → LAST vs AxLEN; "missing" write error → look at BRESP, not W.

7. Verification Insight

✅ Verification insight — check every response and every LAST against AxLEN

RESP and LAST are high-value targets because their bugs are hangs and misreported errors. For RESP: check RRESP on every read beat (not just the last) and BRESP once per write against a reference model that knows the expected status; cover all four codes — drive accesses that should yield OKAY, SLVERR (e.g., unsupported access at a real slave), and DECERR (an unmapped address, proving the default slave responds), plus EXOKAY only on exclusive accesses and never on normal ones. For LAST: assert that WLAST/RLAST lands on exactly beat AxLEN+1 for every burst — a protocol checker should flag early, late, or missing LAST — and add directed tests for single-beat bursts (AxLEN=0, where LAST is on the first beat) and maximum-length bursts.

The most valuable negative tests target the failure semantics: confirm an error response does not abort a read burst (all beats and RLAST still arrive), and that a missing LAST is caught as a hang rather than silently timing out the test. Because LAST framing and response codes drive outstanding-transaction tracking, scoreboard them together — a mis-asserted LAST corrupts transaction matching, which surfaces far from the root cause.

8. Interview Questions

9. Summary

RESP and LAST close out the AXI signal set. The response codes — shared 2-bit encoding on BRESP and RRESP — are OKAY (success), EXOKAY (exclusive success only), SLVERR (the addressed slave failed), and DECERR (no slave at the address, from the interconnect default slave); the key contrasts are SLVERR vs DECERR (right-slave-failed vs no-slave-there) and the write/read asymmetry — BRESP is one aggregate response per write transaction, while RRESP is per beat, so read beats can differ and an error beat never aborts the burst. The terminators — WLAST (manager-driven) and RLAST (subordinate-driven) — mark the final beat and exist only on the multi-beat data channels; their timing must match AxLEN exactly (beat AxLEN+1), or the burst is short (loss) or open (hang).

Their bugs are the bread-and-butter of AXI bring-up: misattributed errors (confusing SLVERR/DECERR), "missing" write errors (looking at W instead of B), overlooked per-beat read errors, and — most painfully — hangs and corrupted transaction tracking from mis-framed LAST. Debug and verify them by checking every response against a reference model and every LAST against AxLEN. This completes Module 6 — the AXI signal reference. Next, Module 7 builds on these signals to treat bursts as first-class: how beats, length, and size compose real data transfers.

10. What Comes Next

You've finished the per-signal reference; Module 7 turns to bursts as a whole:

7.1 — Burst Length, Size & Beats (coming next) — formalizing the beat, burst length (AxLEN+1), and transfer size (AxSIZE) as the basis of every AXI data transfer.

Previous: 6.7 — WSTRB Write Strobes. Related: 6.4 — AxLOCK & AxCACHE for EXOKAY and exclusive access. For the broader protocol catalog, see the AMBA family overview doc.

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.