AMBA APB · Module 2

The APB Transfer Overview

One valid APB transfer end to end — IDLE → SETUP → ACCESS → complete — for both a read and a write, and why a transfer is not done the moment the address appears.

You now know the who and the where of APB: a manager, one or more subordinates, and the bus topology that wires them together. What you do not yet have is the when. This chapter walks one complete APB transfer at a high level — IDLE → SETUP → ACCESS → complete — so you can finally say when a register access has actually happened. The single idea to carry: an APB transfer is not finished the moment the address shows up; it finishes later, in ACCESS, only when PREADY is high.

1. What problem is being solved?

The problem is knowing when a register access has actually happened — turning the static picture of roles and wires into a transfer that unfolds over time.

A manager driving an address onto PADDR has not done anything yet; it has only announced an intention. Somewhere later in time the subordinate captures a write or returns a read, and only then is the access real. APB makes that "later" precise by splitting every transfer into two ordered phases and a single completion point:

SETUP — the subordinate is selected (PSEL high) and the access is presented — address, direction, and (for writes) data — but the access has not yet been performed.
ACCESS — the access is performed (PENABLE high), and the bus waits here until the subordinate is ready.
Complete — the one point where PREADY is high: write data is captured, or read data is valid.

This chapter's job is the gentle, high-level walk through that sequence — enough to read a basic waveform and locate completion. The formal state machine, wait states, and back-to-back behaviour are built rigorously in the transfer lifecycle chapter; here we just take the conceptual tour.

2. Why the previous mental model is not enough

So far the module has given you a structural picture: the manager and subordinate roles and the bus topology that connects them. That picture is necessary but incomplete, because structure tells you who and where, never when.

Knowing that a manager drives PADDR and a subordinate decodes it tells you the access can happen and where the data will land — but not at which instant it does happen. A bus protocol is fundamentally a contract about time, and the structural view has no time axis. Two questions it simply cannot answer:

When has the access actually occurred? The address being present on the wires is not the same as the access being done. Something must mark the moment the subordinate has captured the write or produced the read — and that moment is a property of the transfer over time, not of the wiring.
What ordering does a transfer obey? A transfer is not one undifferentiated event; it is a presented phase followed by a performed phase. You cannot read or debug an APB waveform until you can see those phases unfold in sequence, which the static topology never shows.

The transfer walk supplies exactly this missing time dimension — the when that turns roles and wires into an access that has, demonstrably, happened.

3. APB transfer mental model

The model: an APB transfer is a knock, then a handshake. You knock to announce yourself, then the door actually opens — and you are only "in" once it does.

In SETUP you knock: you point at the subordinate (PSEL high), name the access — this address, this direction, this write data — but nothing has been exchanged yet. In ACCESS the handshake happens: you commit the access (PENABLE high) and wait for the other side to confirm. The confirmation is PREADY going high, and that is the instant the exchange is real — the write lands or the read comes back. A knock without the confirming handshake is just noise on the wires.

Three refinements make the model precise:

Presented is not performed. Everything in SETUP is announcement. The address sitting on PADDR commits nothing; it only tells the subordinate what is coming so it has a cycle to decode.
Completion is one point, marked by PREADY. The transfer is done at the single moment PENABLE and PREADY are both high. Before that point nothing has been captured or returned; after it, the transfer belongs to history.
Write and read share the walk — only direction and data location differ. Both go SETUP → ACCESS → complete. A write carries PWDATA and the subordinate captures it at completion; a read carries PRDATA and the manager samples it at completion. The lifecycle shape is identical.

Figure 1 — the conceptual walk of one APB transfer. Starting from IDLE (bus quiet, no subordinate selected), a request moves the bus to SETUP, where the subordinate is selected and the access is presented but not yet performed. The walk then always advances to ACCESS, where the access is performed and the bus waits for the subordinate. The final step, taken when PREADY is high, reaches COMPLETE — the single point where a write is captured or read data is valid. The banner stresses the chapter's core: the transfer is complete only at that last stage, never back in SETUP when the address merely appeared.

4. Real SoC / hardware context

In a real chip this walk is what happens every time firmware touches a peripheral register. When boot code sets a UART baud rate or reads a timer's count, the AHB/AXI-to-APB bridge — acting as the APB manager — drives exactly this sequence: present in SETUP, perform in ACCESS, finish when the peripheral asserts PREADY.

Two everyday accesses make the walk concrete. A write — "configure this register" — presents the target address, PWRITE high, and the value on PWDATA during SETUP; in ACCESS the peripheral captures that value at completion, and the register now holds the new setting. A read — "what is the status?" — presents the address with PWRITE low during SETUP; in ACCESS the peripheral drives the register's current value onto PRDATA, and the manager samples it at completion. Same two-phase walk; the only differences are which direction PWRITE indicates and where the data lives — outbound on PWDATA for a write, inbound on PRDATA for a read.

The completion point matters in hardware because it is the only cycle that is real. A peripheral must not act on a write until completion, and the manager must not latch PRDATA before completion — sample a read a cycle early and you capture whatever stale or undriven value sat on the bus. This is why APB ties data validity to PREADY rather than to the address: the address says what, but PREADY says now.

Figure 2 — a basic APB write transfer with no wait state. In the SETUP cycle PSEL is high, PWRITE is high (a write), PADDR holds the target register address, PWDATA holds the value to store, and PENABLE is low — the access is presented but not performed. In the ACCESS cycle PENABLE goes high while everything else holds stable; the subordinate captures the write data and drives PREADY high, so the transfer completes at the end of that cycle. The dashed marker shows the single completion edge — the address appearing in SETUP completed nothing; the write lands later, in ACCESS, when PREADY is high.

Figure 3 — a basic APB read transfer with no wait state. In the SETUP cycle PSEL is high, PWRITE is low (a read), PADDR holds the target register address, and PENABLE is low — the access is presented but not performed. In the ACCESS cycle PENABLE goes high; the subordinate drives the addressed register value onto PRDATA and asserts PREADY, and the manager samples the read data at that completion edge. As with the write, the address appearing in SETUP completed nothing — the read data is valid only later, in ACCESS, when PREADY is high.

5. Engineering tradeoff table

The two-phase walk is a deliberate choice. Splitting every transfer into a presented phase and a performed phase costs a cycle but buys clarity the control plane values far more than speed.

Design choice	What it gives up	What it buys	Why it is correct for APB
Separate SETUP before ACCESS	A cycle of latency per transfer	A decode/prepare window before anything commits	Latency is free for rare register pokes
Completion tied to `PREADY`, not the address	Fixed, address-time completion	An unambiguous "it happened now" point	Removes all sample-timing guesswork in RTL and verification
Write and read share one walk	A read-optimized fast path	One sequence to learn, build, and verify	A second path would double the corner cases for no gain
Data valid only at completion	Early-available read data	No stale or undriven sampling, ever	Correctness beats saving a cycle on sparse traffic

The throughline: APB spends a cycle and a handshake to make "the access happened" a single, unmistakable instant. For traffic that is rare and latency-insensitive, that certainty is the whole point — and it is the same walk whether you are writing or reading.

6. Common RTL / architecture / waveform mistakes

Misconceptions to unlearn

"The transfer is done as soon as the address appears." No. The address on PADDR only presents the access in SETUP. Completion is later, in ACCESS, when PREADY is high — that is the only cycle the access is real.
"PSEL high means the access happened." No. PSEL high means a subordinate is selected and a request is visible. The access is performed in ACCESS (PENABLE high) and completes only at PREADY high.
"Read data is available during SETUP." No. In SETUP the subordinate has only just seen the address. PRDATA is valid at completion; sampling it earlier reads a stale or undriven value.
"Writes and reads follow different sequences." No. Both walk SETUP → ACCESS → complete. Only the PWRITE direction and where the data lives differ — PWDATA outbound for a write, PRDATA inbound for a read.
"PENABLE high means the transfer is finished." No. PENABLE high marks the ACCESS phase — the access is being performed. It finishes only when PREADY is also high.

7. Interview framing

This is the question that checks whether you think of an APB access as an event in time or just as a set of signals. Interviewers ask you to "walk a basic APB write" or "walk a read," and the tell is whether you place completion correctly.

The strong answer narrates the walk and names the completion point: from IDLE, a request enters SETUP, where the subordinate is selected (PSEL high) and the access is presented — address, direction, write data — with PENABLE low; the walk advances to ACCESS (PENABLE high), where the access is performed and the bus waits; completion is the cycle where PREADY is high, and only there is a write captured or read data valid. Then volunteer the depth point that separates strong from average: the address appearing does not complete the transfer — PREADY does, and a write and a read share this exact walk, differing only in direction and where the data lives. What interviewers probe is whether you tie "it happened" to PREADY rather than to the address — the same instinct that lets you debug a real waveform.

8. Q&A

9. Practice

Walk a write. From memory, narrate a basic APB write cycle by cycle: name what PSEL, PENABLE, PWRITE, PADDR, and PWDATA do in SETUP and in ACCESS, and state exactly where completion is.
Walk a read. Do the same for a read, and say precisely which cycle PRDATA is valid and why sampling it earlier is wrong.
Spot the difference. In two sentences, state everything that differs between an APB write and an APB read, and everything that stays the same.
Place completion. Given a basic two-cycle waveform, mark the one cycle where the transfer completes and justify it using PENABLE and PREADY.
Find the error. A junior engineer says "the access is done the moment the address is on PADDR." Using the SETUP/ACCESS walk, explain what they got wrong and when the access is truly done.

10. Key takeaways

An APB transfer is a walk over time: IDLE → SETUP → ACCESS → complete. Structure told you who and where; this walk supplies the when.
SETUP presents, ACCESS performs. In SETUP (PSEL high, PENABLE low) the access is announced; in ACCESS (PENABLE high) it is actually carried out.
Completion is a single point, marked by PREADY. The transfer is done only when PENABLE and PREADY are both high — the one cycle a write is captured or PRDATA is valid.
A transfer is not complete when the address merely appears. The address on PADDR only presents the access; completion comes later, in ACCESS.
Write and read share the walk. Both go SETUP → ACCESS → complete, differing only in the PWRITE direction and whether data rides out on PWDATA or in on PRDATA.
This is the gentle overview; the formal machine comes next. Wait states, back-to-back transfers, and the exact state machine are built rigorously in the transfer lifecycle chapter.