AMBA AXI · Module 2

The Read Path

Walk an AXI read end-to-end across the AR and R channels — address out, data back, RRESP per beat, RLAST to close the burst, and where read latency comes from.

The last chapter named all five channels. Now we follow one read all the way through, across the two channels that carry it: AR (read address) out, R (read data) back. A read is the simpler of the two paths — two channels, no separate response — which makes it the right place to watch a transaction actually move: an address is accepted, time passes while the subordinate fetches, then data streams back one beat at a time until RLAST closes it. By the end you should be able to read a read off a waveform, explain where its latency went, and reconstruct it from the two channels. Signal-level detail is fair game now; the deep handshake rules are still Module 3.

1. A Read Is Two Channels — Address Out, Data Back

Strip a read to its essence and it is a question and an answer:

The manager asks on AR: "give me the data at this address."
The subordinate answers on R: the data, a per-beat response (RRESP), and a RLAST flag on the final beat.

That is the whole read. There is no separate response channel because the returning data is the acknowledgement — when R arrives, the read happened, and RRESP says whether each beat was clean. The two channels are independent in time: the address is accepted on AR at one moment, and the data comes back on R some cycles later, after the subordinate has actually fetched it. That gap between "address accepted" and "data returns" is read latency, and making it visible is half of what this chapter is about.

2. The Read Address Channel (AR) — Launching the Read

AR carries the read's intent: the read address plus the transaction attributes — how many beats (ARLEN), how wide each beat (ARSIZE), the burst type (ARBURST), the transaction ID (ARID), and protection/cache hints. One AR handshake launches one read transaction, which may return many beats of data.

Two things to hold:

AR carries no data — it is purely the request. The data comes back later on R.
One AR can request a whole burst. ARLEN says how many beats the single request will return, so a manager issues one address and receives many data beats — the efficiency Module 1 promised, now concrete.

Once the AR handshake completes, the manager's job for that read is essentially done; it now waits for R.

3. The Read Data Channel (R) — The Answer Comes Back

R carries the answer, and it carries three things per beat:

RDATA — the actual read data for this beat.
RRESP — a per-beat response code (OKAY / EXOKAY / SLVERR / DECERR). Note "per-beat": unlike a write's single BRESP, a read reports status on every beat, because different beats of a burst could hit different conditions.
RLAST — asserted on the final beat, telling the manager the burst is complete. Until RLAST, more data is coming.

So the subordinate streams beats on R, each with its own RRESP, and raises RLAST on the last one. A single-beat read is just the degenerate case: one R beat with RLAST already asserted.

Figure 1 — a 4-beat burst read, time downward. One AR handshake launches the read; the subordinate then returns four R beats, each carrying RDATA and a per-beat RRESP, with RLAST asserted on the final beat to close the burst. One address out, many data beats back.

4. A Single-Beat Read, End to End

Drop to the cycle level for the simplest case — a one-beat read — and watch the two handshakes and the latency between them.

valid / ready (per channel)

AXI4 single-beat read — AR → R

10 cycles

Address accepted on the AR handshake; data returns several cycles later on the R handshake (rlast=1, rresp=OKAY). The cycles between them are read latency.

Figure 2 — a single-beat AXI read. The address transfers when arvalid and arready are both high (the AR handshake); some cycles later the data transfers when rvalid and rready are both high (the R handshake), with rresp=OKAY and rlast=1 on that single beat. The gap between the two markers is the read latency.

Walking it: the manager drives arvalid with the address; the subordinate raises arready; on the cycle both are high the address is accepted. The manager then waits. Several cycles later — after the subordinate has fetched the data — rvalid rises with rdata, rresp, and rlast; the manager accepts with rready; the data transfers and, because rlast=1, the read is complete. Two handshakes, one read, with the latency sitting visibly in the gap.

5. Where Read Latency Comes From

That gap is not waste — it is the real time it takes to get data, and a good engineer can name its parts. Read latency decomposes into roughly four contributors, in order:

Figure 3 — the parts of read latency, in order. The address must be accepted on AR, routed through the interconnect to the owning subordinate, serviced (the actual access — fast for SRAM, slow for DRAM), and then the first R beat must travel back. Only after all of that does data appear; the rest of a burst then streams beat-by-beat.

The biggest term is usually the subordinate's own access time — a DRAM controller may take tens of cycles, an on-chip SRAM only a few. Crucially, this latency is paid once per transaction, not once per beat: after the first beat arrives, the remaining beats of a burst stream back with little or no extra delay. That is exactly why bursts and outstanding transactions matter — they amortize this latency, a thread that runs through the performance modules. The read path is where you first see the latency you will later learn to hide.

6. The Read Lifecycle

Stepping back up to the transaction level, a read moves through a small set of states, and the loop in the middle is the burst:

Figure 4 — the read lifecycle. After the AR handshake the subordinate fetches; then R beats return one at a time, looping until the beat carrying RLAST, which completes the read. A single-beat read takes the loop exactly once.

Reconstructing a read in code is exactly this lifecycle — capture the address when AR transfers, then collect R beats until RLAST:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — reconstruct one read transaction from its two channels.
if (arvalid && arready)               // AR handshake: the read is launched
  addr = araddr;
 
if (rvalid && rready) begin           // each R handshake: one data beat
  data.push_back(rdata);              // collect the beat
  if (rresp != OKAY) note_error(rresp); // per-beat status
  if (rlast) complete_read(addr, data); // RLAST closes the burst
end

This is the skeleton of a read monitor: one address in, beats collected until RLAST out. The same shape reappears in Module 16's verification components.

7. Common Misconceptions

Myths to unlearn

"A read needs a response channel like a write's B." It doesn't. The read response (RRESP) rides on the R channel with the data — the returning data is the acknowledgement. Only the write needs a separate response channel.
"RRESP is one code for the whole read." RRESP is per beat. Each R beat carries its own response, because different beats of a burst can encounter different conditions.
"Read latency is paid per beat." The big latency (routing + subordinate access) is paid once per transaction, before the first beat. After that, burst beats stream back with little extra delay — which is why bursts amortize latency.
"RLAST is optional / you count beats yourself." RLAST is the protocol's explicit end-of-burst marker on R; you rely on it (not a private beat counter) to know the read is done. A burst that never asserts RLAST hangs the read.
"The address and data move together." AR and R are separate, independent channels. The address is accepted first; the data comes back cycles later. Their separation is what creates the visible latency — and enables outstanding reads.

8. Debugging Insight

🔍 Debugging insight — read the read by its two handshakes

A read on a capture is just two handshake events and the gap between them, so debugging a read is a short checklist:

Did the AR handshake happen? Look for arvalid and arready both high on one edge. If arvalid never rises, the manager never issued the read (wrong address, disabled). If arvalid is high but arready never rises, the subordinate/interconnect isn't accepting — a routing or busy-slave problem.
Did R come back, and how long after? If the AR was accepted but R never arrives, the read is stuck in the subordinate (or the address routed nowhere). If R comes back but very late, that gap is your latency — measure it, then attribute it (routing vs access).
Does the burst close with RLAST? Count the R beats and confirm RLAST on the last one. A burst that returns fewer beats than ARLEN requested, or never asserts RLAST, leaves the read hanging — a classic "the read never completes" bug.
Check RRESP on each beat. A SLVERR/DECERR on any beat localizes the failure: DECERR means the address routed to no subordinate; SLVERR means a real subordinate rejected the access.

Two handshakes, a gap, and a last-beat flag — that is the entire read, and each of those is one specific thing to check.

9. Verification Insight

✅ Verification insight — what a read monitor and scoreboard actually check

A read monitor watches AR and R and reassembles the transaction: it captures the address (and ARLEN) on the AR handshake, then collects R beats until RLAST, exactly like the snippet above. From that reconstruction, the checks fall out: the beat count must match ARLEN + 1, the burst must terminate with RLAST, the returned data must match the reference model for that address, and the RRESP codes must be legal and expected. Coverage, in turn, wants reads of varied burst length, every RRESP code seen, and back-to-back and outstanding reads exercised.

The reason this is tractable is that a read is only two channels — the verification surface is small compared to a write's three (or the coherent protocols' many). Get the read monitor right and the write monitor is the same idea with an extra response channel to pair. Full mechanics are Module 16; the read path is where the pattern is clearest.

10. Interview Questions

11. Summary

A read is two channels: the manager launches it with one AR handshake (read address plus attributes, including ARLEN for burst length), and the subordinate answers on R with the data — each beat carrying its own RRESP, and RLAST marking the final beat. There is no separate response channel because the returning data is the acknowledgement. Between the AR handshake and the first R beat sits the read latency — address acceptance, interconnect routing, the subordinate's access time (usually dominant), and the return trip — paid once per transaction, after which burst beats stream back cheaply.

Read a read off a waveform as two handshakes and the gap between them; reconstruct it in code as capture the address, collect beats until RLAST; and debug it by checking the AR handshake, the arrival and timing of R, the RLAST termination, and the per-beat RRESP. The read is the simpler path on purpose — master it here and the write path is the same idea plus a separate response channel, which is exactly where we go next.

12. What Comes Next

You've followed a read end-to-end. The write path is next — same handshake, one more channel:

2.3 — The Write Path (coming next) — a write across AW, W, and B, and why the write needs the separate B response that the read didn't.
2.4 — Independent Channels & Decoupling (coming soon) — why the channels are decoupled and the performance it unlocks.

Previous: 2.1 — The Five AXI Channels. For the broader protocol catalog, see the AMBA family overview doc.