AMBA APB · Module 6

The APB Read Flow

An APB read end to end as a request-response round trip — the manager presents an address, the subordinate decodes and drives PRDATA back through its read mux, and the manager captures that value on the one completion edge.

A write pushes a value out; a read is the opposite shape — it asks a question and waits for the answer to travel back. This chapter opens Module 6 by walking an APB read as one continuous round trip: the manager presents an address, the subordinate decodes it and routes the addressed register onto PRDATA, and the manager captures that value on the completion edge. The single idea to carry: a read is a request-response round trip in which the data flows subordinate→manager, and the returned value is real on exactly one cycle — the completion edge where PSEL, PENABLE, and PREADY are all high. Get the round trip in your head and every later read-timing chapter is just a closer look at one leg of it.

1. What problem is being solved?

The problem is getting a register's current value out of an addressed subordinate and safely into the manager, with one unambiguous cycle on which that value is valid to capture.

A read is not symmetric with a write. On a write the manager produces the data and the subordinate consumes it; on a read the subordinate produces the data and the manager consumes it. That reversal is the whole character of a read, and it creates a round trip the bus must sequence cleanly:

Request (outbound): the manager drives PADDR and PWRITE low to say "give me the value at this address." Nothing is returned yet.
Lookup (inside the subordinate): the address decodes to a register, and that register's value is routed through a read multiplexer onto PRDATA.
Response (inbound): PRDATA carries the value back, and the manager samples it on the completion edge.

The job APB has to do is make the response land on a cycle the manager can trust — not when the address appears, not while the subordinate is still fetching, but on the one edge the handshake declares the data good.

2. Why the previous model is not enough

You have met the pieces: Module 4 walked a read cycle by cycle, the PRDATA signal gave you its valid-only-at-completion rule, and Module 5 drilled the access-phase timing. Each is correct in isolation, but a read engineer needs the connected round trip, because that is what reveals the three things a per-piece view hides:

A read is a round-trip latency, not a one-way transfer. The address has to travel out, decode, select, and the data has to travel back — a combinational cone there and back. Seeing the read as "request → response" is what makes its latency, and why it can need wait states, obvious.
The data source is the subordinate, and that changes who is responsible for what. On a read the manager only presents an address and receives; the subordinate owns the data path (PADDR decode → read mux → PRDATA). Most read bugs are a confusion about which side drives the data — the round-trip framing fixes that.
The "answer" is valid for exactly one cycle. The round trip ends at the completion edge; that is the only cycle PRDATA is guaranteed good. Before it the answer is still in transit (don't-care); after it the bus belongs to the next transfer.

So the model to add is not another signal rule — it is the round trip: request out, lookup inside, response back, captured once.

3. Mental model

The model: a read is a request at a library counter — you hand over a call slip, the librarian fetches the book, and you take it only at the handoff. You never grab a book off the cart while they are still walking; you take it precisely when it is placed in your hands.

You write the call number on the slip (PADDR) and tick borrow, not return (PWRITE low) — that is the request, presented in setup. The librarian reads the slip and walks to the shelf (the subordinate decodes the address and its read mux settles) — that takes a cycle or several. The book travels back to the counter on PRDATA. And the handoff — the one instant the book is actually yours — is the completion edge, where PSEL, PENABLE, and PREADY are all high. Take the book any earlier and you are holding air.

Three refinements make the round trip precise:

The slip goes out frozen. PADDR and PWRITE are presented in setup and held stable through the whole access — the librarian must not have the call number change mid-fetch (the stability contract applied to a read).
The fetch can take time. A fast register answers immediately; a slow one (a register in another clock domain, a FIFO, a read that triggers a fetch) holds PREADY low until the book is at the counter. The round trip's return leg is what wait states stretch.
You capture on the handoff, once. The manager registers PRDATA on the single completion edge. Everything before it on PRDATA is in-transit don't-care; the handoff is the only real cycle.

Figure 1 — an APB read as a request-response round trip between manager and subordinate. Outbound, the manager presents PADDR with PWRITE low (the request) and asserts PSEL, then PENABLE; the request crosses the bus to the subordinate. Inside the subordinate, the address decodes to a register and the read multiplexer routes that register's value onto PRDATA (the lookup). Inbound, PRDATA carries the value back across the bus, and the subordinate raises PREADY when the value is valid. The manager captures PRDATA on the completion edge where PSEL, PENABLE, and PREADY are all high. The figure stresses that read data flows subordinate-to-manager and that the returned value is sampled exactly once, at the handoff.

4. Real SoC / hardware context

In silicon the read flow is a combinational data path inside the subordinate, bracketed by two registered edges in the manager. The manager registers the request (drives PADDR/PWRITE and sequences PSEL/PENABLE from its FSM) and registers the response (captures PRDATA at completion). Between those two edges, the subordinate's read path is usually pure combinational logic: decode PADDR, select the register, drive PRDATA.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Subordinate read path: the "lookup" leg of the round trip (teaching sketch).
// PADDR selects which register's value is routed onto PRDATA — combinational,
// so it settles during the access phase, ready by the completion edge.
always_comb begin
  prdata = '0;                       // default / unmapped read returns 0
  case (paddr)
    ADDR_STATUS: prdata = status_q;
    ADDR_COUNT:  prdata = count_q;
    ADDR_ID:     prdata = ID_CONST;
    default:     prdata = '0;        // never undefined on the bus
  endcase
end
 
// Manager side: the read completes — and PRDATA is captured — on ONE edge:
//   read_commit = psel & penable & pready & ~pwrite
// The manager registers PRDATA only on that edge; before it, PRDATA is
// in-transit don't-care, so sampling early latches garbage.

Two facts make the round trip robust. First, because PADDR is held stable from setup through completion, the combinational case settles long before PREADY rises — the subordinate just has to present the right register on the completion edge, which is why a simple peripheral needs no pipeline. Second, the round trip is the natural place a read earns a wait state: if the addressed value is not ready at the manager's first access edge (it lives across a clock boundary, or the read pops a FIFO that needs a cycle), the subordinate holds PREADY low and the return leg simply takes longer — the flow is unchanged, only its length grows. (The detailed timing of each leg is the rest of this module: PRDATA timing, the PREADY interaction, and read wait states.)

Figure 2 — a complete zero-wait APB read walked IDLE to IDLE against PCLK. In IDLE, PSEL is low. SETUP raises PSEL, presents the read address on PADDR, and drives PWRITE low while PENABLE stays low — the request is out, but nothing is returned. ACCESS raises PENABLE; the subordinate drives the addressed value onto PRDATA and asserts PREADY, so PSEL, PENABLE, and PREADY are all high on this single cycle — the completion edge, marked with a dashed line, where the manager captures PRDATA. PRDATA is shown don't-care in IDLE, SETUP, and the early part of access, and valid only at completion. After completion the bus returns to IDLE. The waveform makes the round trip concrete: request in setup, response captured on the one completion edge.

5. Engineering tradeoff table

Laying a read out as a request-response round trip with one valid cycle is a deliberate, minimal design. Each property trades a capability APB does not need for the clarity it does.

Read-flow property	What it gives up	What it buys	Why it is correct for APB
Subordinate drives `PRDATA`	A manager-sourced read path	Read data comes from the register that owns it	An address-decoded mux, no contention, no tri-state
`PRDATA` valid only at completion	A continuously-driven value	One unambiguous capture edge	The read mux settles over access; one sample point
Round trip can stretch (wait states)	Fixed, known read latency	Reads from any-speed sources on one bus	Slow registers, CDC, and FIFOs hold `PREADY` low
Combinational read path	Pipelined high-throughput reads	A trivially simple subordinate	Control reads are sparse and latency-insensitive
`PWRITE` low set in setup and held	Mid-transfer direction change	Direction fixed before any data moves	One decode of read-vs-write per transfer

The throughline: an APB read spends one round trip and one valid cycle and gains a flow that is identical whether the source is instant or slow — only the return leg lengthens. The completion edge is the single data landmark, which is why an APB read is small to build and easy to reason about.

6. Common RTL / waveform mistakes

Misconceptions to unlearn

"The manager drives the read data." No. On a read the subordinate drives PRDATA from its read mux; the manager presents PADDR with PWRITE low and only captures. PWDATA is unused on a read.
"PRDATA is valid as soon as the access phase starts." No. PENABLE high marks access, which can include wait cycles; PRDATA is required valid only on the completion edge (PREADY high). Sampling early latches in-transit garbage.
"A read is a one-way transfer like a write." No. A read is a round trip — request out, lookup, response back. That is why it has return-leg latency and why slow sources insert wait states.
"PADDR can change once the access phase begins." No. The address is the call slip; it is held stable from setup through completion. Change it mid-fetch and the subordinate may route the wrong register onto PRDATA.
"An unmapped read can leave PRDATA undefined." No. Drive a clean default (typically 0) so the bus is never X; an undefined PRDATA corrupts the manager's capture and is a classic source of intermittent reads.
"The read mux must be registered/pipelined." No, not for a control register. PADDR is stable across access, so a combinational mux settles in time; pipelining only adds latency the sparse control plane does not need.

Debugging scenario — a read returns stale data, captured off the round trip

Observed symptom: a peripheral register read intermittently returns the previous read's value (or 0) even though the register holds the right data. It looks like a "lagging" read.
Waveform clue: in Figure 2, the manager's read-data register updates a cycle before the dashed completion edge — it loads while PRDATA is still in the don't-care, in-transit band, not the green value at completion.
Root cause: the manager treated the read as a one-way transfer (like a write) and captured PRDATA when the request went out, not when the response came back — it sampled the return leg before the value arrived.
Fix / habit: capture PRDATA only on the round-trip handoff — read_commit = psel & penable & pready & ~pwrite — and bind assert property (@(posedge pclk) read_data_en |-> read_commit); so the read register can never load before the completion edge.

7. Interview framing

"Walk me through an APB read" is a staple, and the strong answer narrates the round trip, not a list of signals. A weak answer recites PRDATA and PREADY; a strong one shows you understand request-response and where the data is real.

Lead with the shape: a read is a request-response round trip where the data flows subordinate→manager. Then walk it: setup presents PADDR with PWRITE low (the request, nothing returned); access raises PENABLE while the subordinate decodes and drives PRDATA through its read mux; the subordinate raises PREADY when the value is valid; completion is the cycle PSEL & PENABLE & PREADY are all high, where the manager captures PRDATA. Then deliver the two depth points: the subordinate owns the read data path and PRDATA is valid only at completion (so the manager must not sample early), and the return leg is what wait states stretch when the source is slow. Volunteering "for a read, PWRITE is low and PWDATA is unused — the data comes back the other way" signals you think in data-flow direction, not just timing.

8. Q&A

9. Practice

Trace the round trip. From IDLE, narrate an APB read's request, lookup, and response legs, naming the signal active in each and the cycle the manager captures PRDATA.
Name the driver. State which side drives PADDR, PWRITE, PRDATA, and PREADY on a read, and which manager signal (PWDATA) is unused and why.
Place the valid edge. On a zero-wait read waveform, mark the one cycle PRDATA is valid and state what it is on every earlier cycle.
Stretch the return leg. Describe a read whose source needs two cycles; state which leg of the round trip lengthens and what PRDATA is during the wait.
Find the bug. A manager latches PRDATA on the first cycle PENABLE is high, ignoring PREADY. On a one-wait read, show which cycle it wrongly samples and what it captures.

10. Key takeaways

An APB read is a request-response round trip — the manager presents an address, the subordinate looks it up, and the value travels back on PRDATA. Data flows subordinate→manager.
The subordinate owns the read data path — PADDR decode → read mux → PRDATA. The manager presents PWRITE low and only captures; PWDATA is unused.
PRDATA is valid only on the completion edge (PSEL & PENABLE & PREADY, PWRITE low) and in-transit don't-care everywhere else. The manager captures it once, there.
The round trip can stretch. A slow source holds PREADY low; the return leg lengthens while the flow's shape stays identical — the read wait state.
The read path is combinational because PADDR is held stable across access and PRDATA is only needed at completion — a settled mux, no pipeline, the right design for sparse control reads.
Never leave PRDATA undefined — drive a clean default on unmapped addresses so the manager's capture is never X.