AMBA APB · Module 6

PREADY Interaction in Reads

How PREADY gates PRDATA capture on a read — it completes the transfer and signals that read data is valid now, so the manager captures PRDATA on the same edge PREADY is high; the multi-cycle read mechanics.

On a write, PREADY only governs when the data you already drove gets taken. On a read it does something extra and read-specific: it also tells the manager that PRDATA is now valid to sample. The same rising edge that completes the transfer is the edge that licenses the capture — they are not two events, they are one. The single idea to carry: on a read, PREADY does double duty — it completes the access and declares PRDATA valid — so the manager captures PRDATA on the same edge PREADY is high, and not one cycle before. Everything in this chapter is that coupling, drawn out into waveform, RTL, and the multi-cycle mechanics that make it matter.

1. What problem is being solved?

The problem is deciding the exact cycle on which the manager is allowed to capture PRDATA, given that the value travels back from the subordinate and is not real until the subordinate says so.

A read returns data the manager did not produce — so the manager faces a question a write never poses: when is the value on PRDATA the real one? It cannot sample on a fixed cycle, because slow sources push the valid value later. It needs a per-transfer signal that means precisely "the value on PRDATA is valid this cycle — take it now." APB does not add a second signal for that. It reuses PREADY:

PREADY high on the access cycle means the read is complete and PRDATA is valid — the manager captures on this edge.
PREADY low means the read is held — PRDATA is still in transit and must not be sampled.

So the capture decision is solved by folding "data valid" into the existing completion handshake. The manager does not need to know why the value arrived late; it only watches PREADY and captures on the one cycle it is high.

2. Why the previous model is not enough

Module 3's PREADY handshake taught PREADY as backpressure — the subordinate's one lever over timing: high completes, low stretches the access phase. That is the general contract, and it is correct. But it is direction-agnostic — it describes completion the same way for a write and a read. This chapter drills the part the general contract leaves implicit: on a read specifically, PREADY carries a second meaning that has no analogue on a write.

PREADY gates PRDATA capture, not just transfer completion. On a write, completion means "the subordinate captured what I drove." On a read, completion also means "the value I am about to read off PRDATA is valid now." Module 3 told you PREADY ends the access; this chapter tells you it simultaneously unlocks the read-data sample.
The multi-cycle mechanics are read-specific. While PREADY is low, a held write just keeps its already-driven PWDATA waiting. A held read is different: PRDATA is not yet valid — it is in transit through the subordinate's read path — so the wait cycles are cycles on which sampling would latch garbage. The hold protects the capture, not just the timing.
The completion condition gains a data term. Module 3's completion is PSEL & PENABLE & PREADY. The read-capture enable adds & ~PWRITE: capture only when this completing transfer is a read. That extra term is the read-specific shape of the same handshake.

So this is not a re-run of Module 3. It is the same PREADY, viewed down the read direction, where it quietly becomes the data-valid strobe for PRDATA.

3. Mental model

The model: PREADY on a read is the cashier sliding your change across the counter and saying "here it is" in the same motion. The act of finishing the transaction is the act of handing you the value — you reach for the change exactly when it lands, never while the drawer is still open.

On a write, the cashier just takes your note and nods "done"; you handed over the value already. On a read you are owed something back, and PREADY high is the instant it is placed in your hand. Reach earlier — while PREADY is low — and you are grabbing at an empty counter; the change (PRDATA) is still being counted out inside the subordinate's read path.

Three refinements make the coupling precise:

One edge, two facts. The cycle PREADY is high is simultaneously "transfer complete" and "PRDATA valid." The manager does not wait an extra cycle to read the data — it samples on the very edge that completes the read.
Low means "not counted yet." While PREADY is low the read is held and PRDATA is in-transit don't-care. The hold is what gives the subordinate's read path (or its slow source) time to put the real value on the bus.
The manager only watches, then grabs once. The manager keeps PADDR and PWRITE low stable, samples PREADY each access cycle, and registers PRDATA on the single cycle PREADY is high. It captures once, on the handoff.

Figure 1 — PREADY gating PRDATA capture on a one-wait APB read against PCLK, with rows PSEL, PENABLE, PWRITE, PREADY, and PRDATA. PSEL rises in SETUP and holds through both access cycles; PWRITE is low for the whole read; PENABLE rises entering access and stays high across both access cycles. In the first access cycle PREADY is low and PRDATA is don't-care — the value is not yet valid and the read is held. In the second access cycle PREADY goes high and PRDATA becomes valid; the dashed completion marker on that cycle shows the manager samples PRDATA on the same edge PREADY is high. The figure stresses PREADY's double duty on a read: it completes the transfer and declares PRDATA valid in one instant, so capture is gated until PREADY rises.

4. Real SoC / hardware context

In silicon, the read-capture coupling is a single registered edge in the manager: a read-data flop whose enable is the read-completion condition. The manager does not gate on PREADY alone — it gates on the full term PSEL & PENABLE & PREADY & ~PWRITE, so the flop captures PRDATA only on the cycle a read actually completes. While PREADY is low, that enable is low, the flop holds its previous value, and the in-transit PRDATA is never latched.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Manager-side read capture, gated on the read-completion condition.
// read_commit is high on exactly one cycle: the read's completion edge.
wire read_commit = psel & penable & pready & ~pwrite;
 
// While PREADY is low the access is HELD and PRDATA is not yet valid, so the
// capture must wait for PREADY high. The flop's enable is read_commit, so it
// registers PRDATA on — and only on — the cycle PREADY (and the rest) is high.
always_ff @(posedge pclk or negedge presetn) begin
  if (!presetn)        read_data <= '0;
  else if (read_commit) read_data <= prdata;  // capture valid PRDATA, once
  // else: PREADY low (or not a read) -> hold; PRDATA in transit, do not sample
end

Two facts make this robust. First, because the enable carries ~pwrite, the same capture logic is inert on a write — PWDATA flows the other way and no spurious PRDATA latch occurs even when a write completes on identical PSEL/PENABLE/PREADY. Second, the multi-cycle mechanics are handled for free: if the read takes wait states, read_commit is simply low for those cycles and the flop holds — the manager needs no wait-counter of its own, because PREADY already encodes "valid now." The detailed cycle-by-cycle stretching is read wait states; the precise window in which PRDATA is required valid is PRDATA timing.

Figure 2 — the structural coupling of PREADY and PRDATA capture in the manager. PSEL, PENABLE, PREADY, and NOT PWRITE feed an AND gate whose output, read_commit = PSEL & PENABLE & PREADY & ~PWRITE, is the read-completion condition. read_commit drives the enable port of the manager's read-data capture register, while PRDATA from the subordinate feeds its data port and its output is read_data. PREADY is highlighted as the gate: it is one of the AND inputs, so while PREADY is low read_commit is low and the register holds, capturing valid PRDATA only on the cycle PREADY is high. The figure makes concrete that PREADY is the enable that says PRDATA is valid now, capture it.

5. Engineering tradeoff table

Reusing PREADY as the read-data-valid strobe is a deliberate economy. Each property trades a capability APB does not need for the simplicity it does.

Read-capture property	What it gives up	What it buys	Why it is correct for APB
`PREADY` doubles as data-valid	A dedicated read-valid line	One signal, one capture edge	Completion and data-valid coincide by construction
Capture enable `& ~PWRITE`	A shared write/read latch	A read-only capture, inert on writes	`PRDATA` is meaningless on a write — never latch it
`PRDATA` sampled on the completion edge	A separately-timed data sample	No manager-side capture timing logic	The valid cycle is exactly the completion cycle
Wait cycles hold the capture	A speculative early sample	No garbage latched from in-transit `PRDATA`	While `PREADY` is low the value is not yet real
No manager-side wait counter	Manager knowledge of source latency	A trivial enabled flop	`PREADY` already encodes "valid now"

The throughline: a read spends a dedicated data-valid signal to buy a manager that captures PRDATA with a single enabled flop, correct at any source speed, because PREADY high already means both "done" and "valid."

6. Common RTL / waveform mistakes

Misconceptions to unlearn

"PREADY only ends the transfer; a separate signal says PRDATA is valid." No. On a read PREADY is the data-valid strobe — its high cycle is the one cycle PRDATA is guaranteed valid. There is no other valid signal.
"The manager can sample PRDATA one cycle after PREADY goes high." No. Capture is on the same edge PREADY is high. By the next cycle the bus has moved to IDLE or the next transfer and PRDATA is no longer guaranteed.
"While PREADY is low, PRDATA is just the old value, so sampling it is harmless." No. During wait cycles PRDATA is in-transit don't-care — the subordinate's read path may not have settled the addressed value. Sampling then latches garbage.
"Gating capture on PSEL & PENABLE & PREADY is enough." Risky. Without & ~PWRITE, a completing write on the same lines could enable a spurious PRDATA latch. The read-capture enable must carry ~PWRITE.
"A multi-cycle read needs a wait counter in the manager to know when data is ready." No. The manager needs none — it captures whenever read_commit is high. PREADY carries the timing; the manager just enables on it.
"Holding PREADY low restarts the read so PRDATA must be re-presented." No. The read is held, not restarted: PADDR/PWRITE stay stable and the subordinate keeps driving toward a valid PRDATA, which lands when PREADY rises.

Debugging scenario — manager captures PRDATA while PREADY is low

Observed symptom: reads from slow peripherals (ones that insert wait states) come back wrong, while reads from fast peripherals are always correct — a confusing "only some devices" failure.
Waveform clue: the read-capture enable pulses on an access cycle where PREADY is 0 (the WAIT cycle in Figure 1) — the flop loads the in-transit don't-care PRDATA, not the value that appears when PREADY rises.
Root cause: the capture was gated on PENABLE (the access phase) instead of PREADY (the completion). On a zero-wait read PENABLE and PREADY coincide, so the bug is invisible; a single wait state exposes it.
Fix / habit: put PREADY in the capture AND — read_commit = psel & penable & pready & ~pwrite — so the enable is the completion edge; bind assert property (@(posedge pclk) (read_data_en) |-> pready); so the read flop can never load while PREADY is low.

7. Interview framing

A sharp interviewer separates "how does PREADY work" (Module 3 material) from "what is special about PREADY on a read." The second question is this chapter, and the strong answer leads with the double duty: on a read, PREADY high both completes the transfer and declares PRDATA valid — so the manager captures PRDATA on the same edge PREADY is high.

Then deliver the mechanics: while PREADY is low the read is held and PRDATA is in-transit don't-care, so the capture is gated until PREADY rises — a wait state on a read is a wait on the data being valid, not just on completion. Close with the RTL shape: the manager's read-data flop is enabled by PSEL & PENABLE & PREADY & ~PWRITE, and volunteering the ~PWRITE term — "so a completing write never spuriously latches PRDATA" — signals you have actually built the capture path, not just memorised the waveform. If you can also note that APB reuses PREADY rather than adding a data-valid line, because completion and data-valid coincide by construction, you have shown you understand why the protocol is shaped this way.

8. Q&A

9. Practice

State the double duty. In one sentence, say the two things PREADY high tells the manager on a read, and on which edge the manager captures PRDATA.
Hold the capture. On a two-wait read waveform, mark every cycle the manager must not sample PRDATA, state what PRDATA is on each, and mark the one cycle it captures.
Write the enable. Write the read-capture enable expression and explain why each term — including ~PWRITE — is necessary.
Find the bug. A manager captures PRDATA whenever PSEL & PENABLE & PREADY is high, with no ~PWRITE. Describe the failure on a back-to-back write-then-read and what wrong value the read-data register can hold.
Defend the reuse. In two sentences, explain why APB reuses PREADY as the read-data-valid strobe instead of adding a separate valid line.

10. Key takeaways

On a read, PREADY does double duty — it completes the transfer and declares PRDATA valid in the same instant. The two events coincide by construction.
The manager captures PRDATA on the same edge PREADY is high — never a cycle before (in transit) and never a cycle after (bus moved on).
While PREADY is low the read is held and PRDATA is in-transit don't-care — the wait cycles protect the capture, and sampling then latches garbage.
The read-capture enable is PSEL & PENABLE & PREADY & ~PWRITE — the ~PWRITE term keeps a completing write from spuriously latching PRDATA.
The manager needs no wait counter — PREADY already encodes "valid now," so one enabled flop captures correctly at any source speed.
APB reuses PREADY rather than adding a data-valid line — completion and data-valid always coincide on a read, so one signal carries both meanings.