AMBA APB · Module 3

PRDATA — The Read Data Bus

PRDATA, the subordinate-driven read data — the valid-only-when-PREADY rule, how the selected subordinate's read mux drives it, and how the bus stays clean when idle.

Module 2 told you read data is "valid at completion." That is the right moment, but to drive PRDATA in a real subordinate or sample it in a real manager you need its exact contract: who sources it, the single cycle it must be valid, what it is the rest of the time, and how one bus carries the answer from whichever subordinate was addressed. PRDATA is the subordinate-driven bus that carries read data back to the manager — and its defining rule is that it is required valid on exactly one cycle: the completion cycle of a read, where PREADY is high. The single idea to carry: PRDATA is a don't-care everywhere except that one cycle, so the manager must sample it then and the subordinate need only present it then.

1. What problem is being solved?

The problem is getting a register's value from the addressed subordinate back to the manager, on a bus shared by many subordinates, with a clean rule for when that value is real.

A read has to return data. But APB hosts many subordinates on one set of wires, and the manager has exactly one input bus for read data. So two questions must be answered unambiguously: which subordinate's value reaches the manager, and when is that value actually valid to sample. APB answers both with PRDATA:

PRDATA is driven by the subordinate, sourced from a read mux over its registers — the addressed register's value is presented on the bus.
PRDATA is required valid on exactly one cycle — the read's completion cycle, where PSEL, PENABLE, and PREADY are all high — and is don't-care otherwise.

Only the selected subordinate's value is muxed back to the manager; the unselected subordinates do not contribute, and the idle bus returns a clean default. That keeps a one-input read bus correct on a multi-subordinate fabric without any tri-state or contention.

2. Why the lifecycle view is not enough

Module 2 told you read data is "valid at completion" — a lifecycle role. That is true, but a role is not a contract. To wire PRDATA into a real subordinate's read path or sample it correctly in a manager, the lifecycle view leaves four things unstated:

Who sources it, and from what. PRDATA is driven by the subordinate, not the manager. Its value comes from a read mux that selects the addressed register — PRDATA is the output of case (paddr) ... endcase, not a captured input.
The exact valid window: one cycle only. PRDATA is required valid only on the completion cycle of a read (PSEL, PENABLE, and PREADY all high). Before that — in setup and in every wait-state cycle — it is don't-care. "Valid at completion" understates how narrow and exclusive that window is.
What it is the rest of the time. During writes, during setup, during wait states, and when no subordinate is selected, PRDATA is undefined and must not be sampled. A clean default (0) for the idle and unmapped paths keeps it deterministic.
How one bus carries many subordinates. Each subordinate drives its own PRDATA; only the selected one's value is muxed back to the manager. The unselected subordinates do not contribute to the bus.

Knowing the role tells you PRDATA carries read data; knowing the contract tells you who drives it, on which single cycle it is real, and how it gets back — which is what you actually need to build or debug a read.

3. The signal's mental model

The model: PRDATA is the answer the addressed subordinate holds up at the counter — and it only counts on the cycle the clerk stamps it.

You asked a question (the read address). The right clerk — the selected subordinate — looks up the answer in their ledger (the register read mux) and holds it up. But the answer is only official on the moment the stamp comes down (PREADY high). Before that, what is on the counter is a draft you must not copy; the other clerks (unselected subordinates) are not even holding anything up.

Three refinements make the model precise:

The subordinate sources it from a read mux. PRDATA is whatever the addressed register decodes to — PADDR selects the register, the mux drives its value onto the bus. It is generated, not stored from the bus.
Valid on exactly one cycle. PRDATA is required valid only on the completion cycle of a read — PSEL, PENABLE, and PREADY all high. That is the only cycle the manager samples it, and the only cycle the subordinate must guarantee it. Everywhere else it is don't-care.
Only the selected value reaches the manager. Each subordinate drives its own PRDATA; the interconnect muxes back the selected one. Unselected subordinates and the idle bus contribute nothing — a clean default of 0 covers them.

4. Real SoC / hardware context

In hardware, PRDATA is the output of the subordinate's read path: a combinational read mux over its register file, selected by PADDR. When the subordinate is addressed for a read, that mux drives the addressed register's value onto PRDATA; when it is not addressed, its contribution is irrelevant because the interconnect routes only the selected subordinate's bus back to the manager. The width of PRDATA matches the data bus — the same width as PWDATA — so the read path and write path carry the same number of bits.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Subordinate read path: PRDATA read mux (teaching sketch — not a full slave).
// PADDR selects which register's value is driven onto PRDATA.
always_comb begin
  prdata = '0;                 // clean default: idle / unmapped reads return 0
  case (paddr)
    ADDR_CTRL:   prdata = ctrl_reg;
    ADDR_STATUS: prdata = status_reg;
    ADDR_DATA:   prdata = data_reg;
    default:     prdata = '0;  // unmapped address → 0, never undefined
  endcase
end
 
// CONTRACT: PRDATA is only REQUIRED valid on the read completion cycle —
// PSEL & PENABLE & PREADY all high (and PWRITE low). The manager samples it
// only on that cycle. In setup, in wait states, during writes, and when this
// subordinate is not selected, PRDATA is don't-care; the clean default of 0
// keeps it deterministic. The mux output is combinational off PADDR, so the
// value is settled and ready by the completion cycle.

Two facts fall out of that mux. First, because PRDATA is a pure combinational decode of PADDR, the value is settled well before the completion cycle — the subordinate does not need to register or pipeline it for a single-cycle access, it just has to present the right register when PREADY goes high. Second, because the read bus the manager sees is the muxed selection of subordinate buses, there is never contention: only one subordinate is selected, only its PRDATA is routed back, and the default of 0 cleanly covers the no-select and unmapped cases.

On the manager side, PRDATA is an input sampled on exactly one cycle: the read completion cycle, PSEL & PENABLE & PREADY high. Sampling it any earlier — at the start of access, or during a wait state — reads don't-care data. The manager's read register loads from PRDATA only on that completion pulse, the same pulse that completes the access phase.

Figure 1 — PRDATA's valid window across a read with one wait state, against PCLK. In the setup cycle (PENABLE low) and the wait-state cycle (PREADY low) PRDATA is don't-care — undefined and not to be sampled. PRDATA is required valid only on the completion cycle, where PENABLE and PREADY are both high; that is the single cycle the manager samples it. The diagram marks the don't-care region, the lone valid-and-sampled cycle, and that the rule is valid-only-when-PREADY-is-high on a read.

Figure 2 — the PRDATA return path. Each subordinate drives its own PRDATA from a read mux that selects the addressed register; only the selected subordinate's value is muxed back to the manager, and the unselected subordinates do not contribute. A clean default (typically zero) covers unmapped offsets and the idle bus. Because the return is shared and muxed, only the one selected subordinate drives a meaningful value — and only on the completion cycle — so there is never contention on PRDATA.

5. Engineering tradeoff table

PRDATA is a deliberately minimal read bus. Each property trades a capability APB does not need for the simplicity it does.

`PRDATA` property	What it gives up	What it buys	Why it is correct for APB
Valid only on the completion cycle	A continuously-driven read value	A single, unambiguous sample point	The subordinate's mux can settle over the access; one sample edge
Sourced from a register read mux	Pre-staged / pipelined read data	Trivial combinational read path	Sparse, latency-insensitive control reads do not need a pipeline
Muxed return (selected subordinate only)	Per-subordinate read wires to the manager	One read bus, no contention	One driver reaches the manager; unselected contribute nothing
Clean default of 0 on idle / unmapped	A "no data" status encoding	Deterministic value when nothing is selected	Removes undefined reads; safe, repeatable behaviour
Width matches the data bus	A narrower read-only path	Symmetry with `PWDATA`, full-width reads	Reads and writes carry the same register width

The throughline: PRDATA does exactly one job — present the addressed register's value on the one cycle the read completes — and delegates when to PREADY and which subordinate to the address-decoded select. That keeps the read bus a one-line mux with a single, well-defined sample point.

6. Common RTL / waveform mistakes

Misconceptions to unlearn

"PRDATA is valid for the whole access phase." No. PRDATA is required valid only on the completion cycle (PREADY high). During setup and wait states it is don't-care. Sampling it before PREADY reads undefined data.
"PRDATA is valid as soon as PENABLE goes high." No. PENABLE high marks the access phase, which can include wait states. PRDATA is guaranteed only when PREADY is also high — the same completion cycle, never a cycle sooner.
"The manager drives PRDATA." No. PRDATA is subordinate-driven — the output of the addressed subordinate's read mux. The manager only samples it. (PWDATA is the manager-driven write bus; PRDATA is its read-direction counterpart.)
"Every subordinate's PRDATA reaches the manager, so they could collide." No. Only the selected subordinate's PRDATA is muxed back; unselected subordinates do not contribute. There is no tri-state contention — the interconnect selects one bus.
"PRDATA should hold its last value when idle." No — rely on nothing about idle PRDATA. A clean default of 0 for idle and unmapped reads is the safe choice; do not read it as data when no read is completing.
"PRDATA can be narrower than the write bus." No. PRDATA matches the data bus width — the same width as PWDATA. Reads return the full register width.

7. Interview framing

PRDATA is a good probe because a precise answer proves you understand the read direction at the signal level, while a vague one ("it carries read data") proves you only know the role. Interviewers ask "who drives PRDATA and when is it valid?" or "how does one read bus serve many subordinates?"

The strong answer states the contract, not just the role: PRDATA is driven by the subordinate, sourced from a read mux over its registers selected by PADDR, and is required valid on exactly one cycle — the read's completion cycle, PSEL, PENABLE, and PREADY all high — and don't-care otherwise. Then deliver the two depth points: the muxed return (each subordinate drives its own PRDATA, the interconnect routes only the selected one back, unselected contribute nothing, idle defaults to 0), and valid-only-when-PREADY (the manager samples on the completion pulse alone, so the read path can be a settled combinational mux rather than a pipeline). That separation of who, when, and which is exactly what distinguishes an engineer who can build and debug an APB read from one who cannot.

8. Q&A

9. Practice

Write the read mux. From memory, write the case (paddr) read mux that drives PRDATA, including a default of 0, and state the cycle on which the value is required valid.
Mark the valid cycle. Given a read waveform with two wait states, mark the single cycle PRDATA is required valid and explain how you found it (PENABLE and PREADY both high).
Find the bug. A manager latches PRDATA on the first cycle PENABLE is high, regardless of PREADY. Explain what it captures when the subordinate inserts a wait state.
Trace the return. For a fabric with three subordinates, describe what reaches the manager's PRDATA input when subordinate 1 is selected, and what the other two contribute.
Defend the default. In two sentences, justify why PRDATA should default to 0 on idle and unmapped reads rather than holding its last value or floating.

10. Key takeaways

PRDATA is the subordinate-driven read data bus — the output of a read mux over the addressed subordinate's registers, selected by PADDR. The manager only samples it.
PRDATA is required valid on exactly one cycle: the read's completion cycle, where PSEL, PENABLE, and PREADY are all high. Everywhere else it is don't-care.
The manager samples PRDATA on the completion cycle alone — never at the start of access and never during a wait state, where the value is undefined.
Only the selected subordinate's value reaches the manager. Each subordinate drives its own PRDATA; the interconnect muxes back the selected one, unselected subordinates contribute nothing, and idle/unmapped reads return a clean default of 0.
The read path is a settled combinational mux, not a pipeline: PADDR is held stable through the access, so the decode is ready by completion. Width matches the data bus — the same width as PWDATA.
The classic errors are timing and direction errors: sampling PRDATA before PREADY, treating it as valid across the access phase, or thinking the manager drives it. Each breaks the single-cycle, subordinate-sourced contract.