AMBA AXI · Module 5

RLAST & RRESP

The two R-channel control signals — per-beat RRESP (OKAY/EXOKAY/SLVERR/DECERR) and RLAST, the burst terminator — and the rule that an error beat never truncates the burst.

Two R-channel signals deserve their own chapter because they govern how a read ends and how each beat is qualified: RLAST (the burst terminator) and RRESP (the per-beat status). RLAST is the read analogue of WLAST; RRESP shares its encoding with the write's BRESP — but with a twist that trips people up: RRESP is reported per beat, and a beat that errors does not truncate the burst. The subordinate still returns all ARLEN+1 beats and asserts RLAST. This chapter decodes RRESP, explains why it's per-beat, details RLAST, and nails the error-doesn't-truncate rule that catches both designers and verifiers.

1. The Two Signals That Close and Qualify a Read

A read burst needs two things beyond the data: a way to mark the end and a way to report status. RLAST does the first — asserted on the final beat, it tells the manager the burst is complete. RRESP does the second — on every beat, it reports whether that beat was a clean read or an error. Together they let the manager know both when the read is done and whether each part of it succeeded.

The subtlety, and the theme of this chapter: these two are independent. RRESP reporting an error on some beat does not change RLAST's job — the burst still runs to its full ARLEN+1 beats and RLAST still lands on the last. Error qualifies a beat; RLAST terminates the burst; neither overrides the other.

2. RRESP — Per-Beat Status

RRESP is a 2-bit code on each R beat, with the same four values as the write's BRESP:

`RRESP`	Code	Meaning
`OKAY`	`2'b00`	Normal read succeeded
`EXOKAY`	`2'b01`	Exclusive read succeeded (only for exclusive reads)
`SLVERR`	`2'b10`	Slave error — a real target returned this beat with an error
`DECERR`	`2'b11`	Decode error — no target at that address

The decode mirrors the write side exactly (Chapter 4.5): DECERR = no subordinate at the address (the interconnect's default slave answers — fix the address/map); SLVERR = a real subordinate signalled an error for this beat (fix inside the target); EXOKAY = exclusive-read success (only valid for exclusive reads). What's different is the granularity: there's an RRESP for each beat, not one for the whole transaction.

Figure 1 — decoding an RRESP value into action (per beat). OKAY: use the data. EXOKAY: exclusive read succeeded (only valid for exclusive reads). SLVERR: a real target errored on this beat — its data is invalid, investigate the target. DECERR: this beat's address mapped to nothing — fix the address/map. Each beat is judged on its own code.

3. Why RRESP Is Per Beat

A write gets one BRESP because it's acknowledged as a single completed operation. A read is different: its status travels with the data, beat by beat, and different beats can meet different conditions. A burst might begin in a valid region and cross into an unmapped one; a memory might fault on one location but not its neighbors; an interconnect might down-size a burst so some beats route differently. Per-beat RRESP lets the subordinate report exactly which beats were good and which weren't.

Figure 2 — per-beat RRESP (read) vs single BRESP (write). A write is acknowledged once: one BRESP covers the whole transaction. A read carries status with each data beat: every R beat has its own RRESP, so a burst can report OKAY on some beats and SLVERR/DECERR on others. The granularity follows where the status lives.

4. RLAST — The Burst Terminator

RLAST is asserted by the subordinate on the final R beat of the burst — beat number ARLEN+1. It is the read analogue of WLAST, and the manager relies on it to know the read is complete (it does not maintain a private beat counter as the source of truth — RLAST is). A single-beat read (ARLEN=0) asserts RLAST on its one beat.

RLAST must align with the ARLEN declared on AR: the subordinate must return exactly ARLEN+1 beats and put RLAST on the last. A burst that returns fewer beats than ARLEN+1, or never asserts RLAST, leaves the manager waiting forever for a beat that never comes — a hung read, the read-side counterpart of the missing-WLAST hang.

5. Errors Don't Truncate the Burst

Here is the rule that surprises people: an error on a beat does not end the burst early. If the subordinate returns SLVERR or DECERR on some beat, it must still return all ARLEN+1 beats and assert RLAST on the last one. The burst length is fixed by ARLEN at the AR handshake; an error qualifies individual beats but does not change the count or move RLAST.

Why: the manager has committed to receiving ARLEN+1 beats — its buffers, counters, and the channel's framing all assume that count. If a subordinate truncated the burst on an error (stopped early, asserted RLAST prematurely), the manager and subordinate would disagree on how many beats are coming, desynchronizing the channel. So even a fully-failed read returns the promised number of beats, each typically marked with the error code, with RLAST on the last. The manager reads the data as invalid (per the RRESP codes) but the framing stays intact.

Figure 3 — an error never shortens the burst. A read declared ARLEN+1 beats; even if a beat returns SLVERR/DECERR, the subordinate still returns the full ARLEN+1 beats and asserts RLAST on the last. The error qualifies beats; it does not truncate the burst. Truncating on error would desync the manager's beat count.

6. RLAST & RRESP on a Waveform

A 4-beat read where one beat errors: every beat carries its own RRESP, the bad beat shows SLVERR, and the burst still completes all four beats with RLAST on the last.

RLAST & RRESP — a 4-beat read with one error beat

7 cycles

Figure 4 — per-beat RRESP with a mid-burst error. Beats 0, 1, 3 return RRESP=OKAY; beat 2 returns RRESP=SLVERR (that location/access failed). The burst is not truncated — all four beats return and RLAST asserts on beat 3 (cycle 4). The manager treats beat 2's data as invalid (per its code) but the channel framing stays intact.

Handling it in code means checking RRESP per beat and always honoring RLAST to close the burst:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — per-beat status, burst always closes on RLAST.
if (rvalid && rready) begin
  data[beat] = rdata;
  if (rresp inside {2'b10, 2'b11})           // SLVERR or DECERR on THIS beat
    note_beat_error(rid, beat, rresp);
  if (rlast) finish_read(rid);               // closes even if a beat errored
  beat = rlast ? 0 : beat + 1;
end

7. Common Misconceptions

Myths to unlearn

"An error beat ends the read early." No — the burst still returns all ARLEN+1 beats and asserts RLAST on the last. Truncating on error would desync the manager's beat count. Error qualifies beats; RLAST terminates the burst.
"RRESP is one code for the whole read." It's per beat — different beats can carry different codes. (The single-response model is the write's BRESP.)
"RLAST is informational; I'll count beats myself." RLAST is the authoritative end-of-burst marker the manager relies on. A burst with no RLAST (or the wrong count) hangs the read.
"DECERR and SLVERR mean the same thing on a read." Same as writes: DECERR = no target at that address (fix the map); SLVERR = a real target errored on that beat (fix inside it). The localization is identical to BRESP.
"A read can return EXOKAY normally." EXOKAY is only for a successful exclusive read; a normal read returns OKAY. EXOKAY on a non-exclusive read is a bug.

8. Debugging Insight

🔍 Debugging insight — read RRESP per beat, trust RLAST for the count

For a misbehaving read, inspect the two signals together:

Scan RRESP on every beat. Don't just check the first or last — a burst can be OKAY, OKAY, SLVERR, OKAY. A SLVERR/DECERR on any beat means that beat's data is invalid. DECERR → the address (or part of the burst) mapped to nothing; SLVERR → a real target errored — and which beat tells you where in the address range it failed.
Count beats to RLAST against ARLEN. Exactly ARLEN+1 beats must arrive with RLAST on the last. Too few or no RLAST → the read hangs (the manager waits for missing beats). RLAST early → length mismatch.
Watch for truncation-on-error bugs. If a subordinate stops the burst when a beat errors (fewer beats than ARLEN+1, premature RLAST), that's a protocol violation — and it desyncs the manager. The correct behavior is "error the beat, finish the count."
Cross-check RID. Per-beat status only makes sense once you've demuxed by RID (5.2) — make sure you're reading the RRESP of the right transaction's beats.

So: RRESP tells you which beats and where failed; RLAST + ARLEN tell you the framing is intact. Both must be right.

9. Verification Insight

✅ Verification insight — the error-doesn't-truncate rule is a must-test assertion

A read scoreboard checks per-beat status and burst framing, and the highest-value assertion here is exactly the rule designers get wrong: even when a beat returns SLVERR/DECERR, the subordinate returns all ARLEN+1 beats and asserts RLAST on the last. Bind an assertion that the read-beat count always equals ARLEN+1 regardless of RRESP values, and that RLAST lands on that beat — this catches truncate-on-error bugs that a happy-path test never sees. Alongside it: RRESP per beat must be legal and expected for the scenario (a read of an unmapped address should return DECERR on the affected beats), and EXOKAY only on exclusive reads.

Stimulus must include negative reads: target unmapped addresses and erroring regions, and craft bursts that cross from a valid region into an error region so some beats are OKAY and later beats SLVERR/DECERR — the per-beat mixed-status case. Coverage wants every RRESP code seen, mixed-status bursts, single-beat reads (RLAST on beat 0), and max-length bursts. The monitor reconstructs by RID (5.2), records each beat's RRESP, and confirms the full count + RLAST. Mechanics in Module 16.

10. Interview Questions

11. Summary

RLAST and RRESP are the R channel's control signals, and they do independent jobs. RRESP is the per-beat status — OKAY/EXOKAY/SLVERR/DECERR, the same decode as the write's BRESP (DECERR = no target; SLVERR = a real target errored; EXOKAY = exclusive-read success) — reported on every beat because a read's status rides its data and different beats can meet different conditions. RLAST is the burst terminator, asserted on beat ARLEN+1; the manager relies on it, and it must match the ARLEN contract from AR.

The rule that ties them together and trips people up: an error beat never truncates the burst. A read with a SLVERR/DECERR beat still returns all ARLEN+1 beats and asserts RLAST on the last — the error qualifies a beat, RLAST terminates the burst, and truncating on error would desync the manager. Debug by scanning RRESP per beat (which beat, where) and counting to RLAST (framing intact); verify with the error-doesn't-truncate assertion plus region-crossing/negative reads. Next: where read latency comes from across a system.

12. What Comes Next

The read's status and terminator are covered; next, its timing:

5.4 — Read Latency (coming next) — what contributes to read latency across a system, from request to first data.
5.5 — Read Data Interleaving (coming soon) — interleaving by ID in AXI3 and its removal in AXI4.

Previous: 5.2 — The Read Data (R) Channel. For the broader protocol catalog, see the AMBA family overview doc.