AMBA AXI · Module 5

The Read Data (R) Channel

The AXI R channel in detail — RDATA delivery, the RVALID/RREADY handshake, RID pairing, and why R fuses the data and response that a write splits across W and B.

AR launched the read; the R (read data) channel brings the answer back. R is the subordinate's reply: it streams RDATA beats — each tagged with RID (which read it belongs to), carrying a per-beat RRESP (status), and with RLAST on the final beat. The single most useful idea here is that R fuses what a write splits: a write separates data (W) from response (B), but a read's R carries both at once — the data is the acknowledgement, with its status riding alongside. This chapter details RDATA delivery, the RVALID/RREADY handshake, and RID pairing; the depth of RRESP and RLAST is the next chapter.

1. R Returns the Data — and the Response

On a write, the manager is the source of data (W) and the subordinate replies with a separate response (B). On a read it's reversed and merged: the subordinate is the source of R, and the data it returns is the reply. There is no separate read-response channel — RRESP rides on R, per beat (Chapter 4.3's point, from the read side).

Each R beat carries:

RDATA — the read data for this beat.
RRESP — a per-beat response code (OKAY/EXOKAY/SLVERR/DECERR) — detailed in 5.3.
RID — the transaction identifier, matching the ARID of the read this beat belongs to.
RLAST — asserted on the final beat of the burst.

And RVALID/RREADY is the handshake — but note the roles flip versus the write data channel: here the subordinate drives RVALID (it's the source) and the manager drives RREADY (it's the destination).

Figure 1 — the R channel's signals. RDATA carries the bytes; RRESP gives this beat's status; RID identifies which read the beat belongs to (matching ARID); RLAST flags the last beat. RVALID/RREADY transfer one beat — with the subordinate as the source (R flows subordinate→manager), the reverse of the W channel.

2. R Fuses Data and Response

The defining contrast with the write path: a write splits data and acknowledgement across two channels (W for data, B for the response), while a read combines them into one (R carries data and RRESP together). This is why a read has two channels (AR, R) and a write has three (AW, W, B).

Figure 2 — R fuses what a write splits. A write sends data on W and gets a separate response on B (two channels for data + ack). A read receives both on R: each beat is data plus its RRESP status, so the returning data is the acknowledgement. That fusion is exactly why a read needs only two channels and a write needs three.

A practical consequence: a read needs no WLAST/BVALID-style separation between "data done" and "responded" — RLAST on the final R beat both delivers the last data and closes the transaction. The response was arriving all along, per beat.

3. RID — Pairing Returned Data to Its Read

RID is how the manager knows which read a returning beat belongs to. Every R beat carries an RID equal to the ARID of its read, so a manager with multiple reads outstanding can route each returning beat into the right buffer. Reads with different IDs may return out of order (across transactions); RID makes that safe to sort.

Within a single read (one ID), all its R beats carry the same RID and arrive in order, terminated by RLAST. Across reads, the RID tag is what lets the data come back interleaved-by-transaction-historically or simply out of order, and still be reassembled correctly. This is the read-side counterpart to the write's BID pairing.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — consume R beats and route each to its read by RID.
if (rvalid && rready) begin
  read_buf[rid].push(rdata);                 // collect this beat under its transaction
  if (rresp != OKAY) note_read_error(rid, rresp); // per-beat status (5.3)
  if (rlast) complete_read(rid);             // RLAST closes this read's burst
end

Figure 3 — RID pairs returned data to its read. The manager has two reads outstanding (ARID=0 and ARID=1); the subordinate returns R beats tagged with RID, which may arrive out of order across the two reads. The manager demuxes by RID — RID=1 beats into read B's buffer, RID=0 beats into read A's — so each read is reassembled correctly.

4. The R Beats on a Waveform

A read burst returning: RVALID/RREADY move one beat per cycle, RDATA changes each beat, RID stays constant for the transaction, and RLAST rises on the final beat.

R channel — a 4-beat read burst returning

7 cycles

Figure 4 — four R beats returning a read (ARLEN=3). RVALID and RREADY are high across cycles 1–4, so D0–D3 transfer one per cycle; RID stays ID0 for all beats of this read; RRESP is OKAY per beat; RLAST asserts on D3 (cycle 4), closing the burst. The beat count (4) equals ARLEN+1.

5. Backpressure on R — the Manager Throttles

Because the manager is the destination of R, it can apply backpressure by holding RREADY low — telling the subordinate "I can't take a data beat this cycle." The subordinate then holds RVALID and the current RDATA/RID/RRESP stable until RREADY rises (the stability rule, from the subordinate's side this time). This is the same flow control as Chapter 3.3, just with the roles assigned by the read direction: a manager whose buffer is full backpressures incoming read data exactly as a subordinate backpressures incoming write data.

A manager that never asserts RREADY jams the R channel — the read-side version of the drain bug — so simple managers often tie RREADY high.

6. Common Misconceptions

Myths to unlearn

"R only carries data; the response is elsewhere." No — R carries both data (RDATA) and per-beat response (RRESP). There is no separate read response channel; the returning data is the acknowledgement.
"The subordinate drives RREADY." Roles flip versus W: on R the subordinate drives RVALID (it's the source) and the manager drives RREADY (the destination). Mixing this up inverts who backpressures whom.
"RID can change within one read's beats." All beats of a single read carry the same RID (equal to its ARID) and end with RLAST. RID distinguishes different reads, not beats within one.
"A read needs its own WLAST and a B-like response." It doesn't — RLAST on the last R beat both delivers the final data and closes the read, and RRESP rode along per beat. R fuses what the write splits.
"RRESP is one code for the whole read." It's per beat (the read counterpart of the write's single BRESP). Different beats can carry different status. (Detail in 5.3.)

7. Debugging Insight

🔍 Debugging insight — read R against the AR that launched it

The R channel is debugged relative to the AR handshake (5.1), and the checks are quick:

Count R beats against ARLEN. Capture AR for ARLEN, then count RVALID && RREADY beats to RLAST. Fewer/more than ARLEN+1, or RLAST on the wrong beat, is a length-mismatch — the subordinate and the AR disagree.
Check RID on every beat. Each returning beat's RID must equal an outstanding read's ARID. An RID matching no outstanding read, or beats with the wrong RID, is a response-routing bug (often interconnect/ID handling) — and the data lands in the wrong buffer.
No R after a clean AR? The AR was accepted but data never came: the read is stuck in the subordinate, or the address routed nowhere (look at RRESP for DECERR if any beat appears).
R stalling unexpectedly? If RVALID is high with RREADY low for long, the manager isn't accepting (its buffer is full or its RREADY logic is stuck) — the read-side backpressure/drain check.

Anchor on AR for the expected count and RID; most read-data bugs are R disagreeing with what AR declared.

8. Verification Insight

✅ Verification insight — the read monitor reassembles by RID and checks against AR

A read monitor watches AR and R and reassembles each read: it records the outstanding ARID/ARLEN on the AR handshake, then collects R beats — routing each by RID — until that read's RLAST. From that it checks: per-read beat count = ARLEN+1, the burst ends with RLAST, every beat's RID pairs to an outstanding read, the data matches the reference model, and RRESP is as expected (5.3). Because R is the subordinate→manager direction, the responder/slave agent generates the R stream (with configurable RVALID delays for stalls), and the manager agent applies random RREADY backpressure to exercise the manager-side flow control.

The read-specific coverage is multi-outstanding: issue several reads with distinct ARIDs and verify the monitor correctly demuxes interleaved/out-of-order returns by RID — a case the single-outstanding happy path never exercises. Protocol assertions bind to R as to any channel (stability, cardinal rule, RLAST alignment, RID validity). Mechanics in Module 16.

9. Interview Questions

10. Summary

The R channel returns the read's answer, and it carries more than data: each beat is RDATA plus a per-beat RRESP (status), an RID (matching the read's ARID), and RLAST on the last beat — moved by RVALID/RREADY with the subordinate as the source (manager drives RREADY). The defining idea is that R fuses what a write splits: a write separates data (W) from response (B), but R carries both at once, which is exactly why a read uses two channels and a write three — and why RLAST alone closes a read (the response rode along per beat).

RID pairs each returning beat to its read, enabling multiple outstanding reads and out-of-order/interleaved returns demuxed correctly; the manager applies backpressure via RREADY, with the never-drain hang as the read-side failure. Debug and verify R against the AR that launched it — count beats to RLAST (= ARLEN+1), check each RID, reassemble per transaction. Next we zoom into the two R signals deferred here: per-beat RRESP and the RLAST burst terminator.

11. What Comes Next

The data return is covered; next, its status and terminator in depth:

5.3 — RLAST & RRESP (coming next) — per-beat RRESP semantics and how RLAST closes a read burst.
5.4 — Read Latency (coming soon) — what contributes to read latency across a system.

Previous: 5.1 — The Read Address (AR) Channel. For the broader protocol catalog, see the AMBA family overview doc.