AMBA APB · Module 2

The APB Transfer Lifecycle

The full APB state machine — IDLE → SETUP → ACCESS → IDLE or next SETUP — with no-wait and wait-state cases, and how back-to-back transfers work without APB being pipelined.

This is the chapter the whole module has been building toward: the complete lifecycle of one APB transfer, as a state machine. The two phases you met separately — SETUP and ACCESS — are two states of one small FSM, and a transfer is valid exactly when it walks that FSM from start to finish. Hold the state machine and everything else about APB timing — wait states, back-to-back transfers, the return to idle — falls out of it. The single idea to carry: a transfer is complete only when the lifecycle says it is complete, never a cycle sooner.

1. What problem is being solved?

The problem is defining, precisely and once, what counts as a complete APB transfer — so that a manager, a subordinate, and a verification engineer all agree on when a register access has actually happened.

A bus protocol is a contract about time: which signals are driven when, and which edge marks the access as done. If "done" is fuzzy, a manager might move on before a subordinate captured the data, a subordinate might act on a half-formed access, or a testbench might sample read data on the wrong cycle. APB removes the fuzziness by defining the transfer as a walk through a tiny set of states with exactly one completion point. The state machine is the contract:

IDLE — no transfer in progress; no subordinate selected.
SETUP — a transfer has started; the target is selected and the access is presented, but not yet performed.
ACCESS — the access is performed and completes here, gated by the subordinate's readiness.

The job of this chapter is to make that walk exact: when each transition fires, what holds each state, and where the single completion edge lives.

2. Why the previous mental model is not enough

So far you have seen the two phases described one at a time. That is necessary but not sufficient, because a phase in isolation cannot tell you when a transfer is done — only the lifecycle can.

The two-phases view answers "what is true during SETUP?" and "what is true during ACCESS?" It does not answer the questions that actually matter in a real design: How does a transfer start? What makes ACCESS end — one cycle, or several? What happens after completion — back to idle, or straight into another transfer? Those are properties of the transitions between states, not of any single state, so you need the whole machine. In particular, two things only the lifecycle makes precise:

Completion is a transition, not a phase. ACCESS is not "the cycle where it finishes"; ACCESS is a state the transfer sits in until PREADY is high. The completion is the sampled edge where PENABLE and PREADY are both high — and that edge can come on the first ACCESS cycle or the fifth.
"What next" is part of the protocol. After completion the manager either returns to IDLE or launches the next transfer's SETUP. APB never goes SETUP → SETUP or skips ACCESS; the legal path is fixed, and knowing it is what lets you read any APB waveform.

3. APB transfer mental model

The model: APB is a turnstile, and every register access walks through it one person at a time.

A turnstile has a fixed sequence — step up (SETUP), push through (ACCESS), and it only clicks over when the far side is clear (PREADY). You cannot push two people through at once, and you cannot count someone as "through" until the click. The next person waits at the front (IDLE) until the turnstile is free. APB is exactly this: present the access, drive it, and it counts only on the completing click; the next transfer cannot overlap the current one.

Three refinements make the model precise:

One click per transfer. There is exactly one completion edge per transfer — PENABLE high and PREADY high, sampled on the clock. Everything before it is preparation; nothing after it belongs to this transfer.
The turnstile can be held. If the far side is not clear, the subordinate holds PREADY low and the transfer stays in ACCESS — the manager keeps everything stable and waits. This is a wait state, and it changes the duration of ACCESS, never the shape of the lifecycle.
No overlap, ever. The next person only steps up after the click. APB returns to SETUP for the next transfer after this one completes — which is why APB is unpipelined no matter how fast transfers come (contrast AHB's overlap).

Figure 1 — the APB transfer lifecycle as a state machine. From IDLE, a transfer request moves the bus to SETUP (the selected subordinate sees PSEL high, PENABLE low) for exactly one cycle. SETUP always advances to ACCESS (PENABLE high). The bus stays in ACCESS while PREADY is low (the wait-state self-loop) and completes when PREADY is high; on completion it returns to IDLE if there is no further transfer, or goes straight to SETUP for the next one. The path is fixed — IDLE → SETUP → ACCESS → IDLE/SETUP — with the only branch being how long ACCESS is held and whether another transfer follows.

4. Real SoC / hardware context

In hardware, this lifecycle lives on the manager side — almost always the APB bridge — as a small finite state machine that sequences every peripheral access. Its job is to drive PSEL and PENABLE through the legal path and to sample PREADY at the right edge; the subordinate just answers.

The FSM is genuinely tiny — two non-idle states — which is the whole point of APB. Here is the canonical shape of the manager's sequencer (a teaching sketch, not a full bridge): a two-bit state, an unconditional SETUP → ACCESS step, and an ACCESS state that lingers until PREADY.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// APB manager-side lifecycle FSM (teaching sketch). Sequences ONE transfer
// at a time: IDLE -> SETUP -> ACCESS -> IDLE/SETUP. Not a full bridge.
typedef enum logic [1:0] { IDLE, SETUP, ACCESS } apb_state_t;
 
apb_state_t state, next;
 
// PENABLE is high only in ACCESS; PSEL is high in SETUP and ACCESS.
assign penable = (state == ACCESS);
assign psel    = (state == SETUP) || (state == ACCESS);
 
always_comb begin
  next = state;
  unique case (state)
    IDLE:   if (req)      next = SETUP;            // a transfer is requested
    SETUP:                next = ACCESS;           // SETUP always advances
    ACCESS: if (pready)   next = req ? SETUP : IDLE; // complete only on PREADY
    //      else stay in ACCESS  -> the wait state
  endcase
end
 
always_ff @(posedge pclk or negedge presetn)
  if (!presetn) state <= IDLE;
  else          state <= next;

Two structural facts follow directly from the FSM. First, SETUP is always exactly one cycle — there is no condition on the SETUP → ACCESS edge, so the bus never lingers in SETUP. Second, ACCESS is one or more cycles — it holds while PREADY is low, so a slow subordinate stretches only this state. The minimum transfer is therefore two cycles (one SETUP + one ACCESS); wait states add cycles to ACCESS and nothing else.

The lifecycle also defines what "back-to-back" means on APB. When a second transfer is waiting, completion goes ACCESS → SETUP directly, with no IDLE cycle between — but still through a fresh SETUP. So consecutive transfers cost two cycles each at best; they are adjacent, not overlapped. APB never presents the next address during the current access the way a pipelined bus does, so there is no throughput gain from queueing — exactly the unpipelined behavior the protocol promises.

Figure 2 — the same transfer with and without a wait state, against PCLK. Top (no wait): SETUP in cycle 1 (PSEL high, PENABLE low), ACCESS in cycle 2 (PENABLE high) where the subordinate drives PREADY high — the transfer completes in two cycles. Bottom (one wait state): SETUP in cycle 1, then ACCESS spanning cycles 2 and 3 — in cycle 2 the subordinate holds PREADY low (the FSM self-loops in ACCESS) and the manager keeps PSEL, PENABLE, address, and data stable; in cycle 3 PREADY is high and the transfer completes. The lifecycle shape is identical; only the time spent in ACCESS differs.

Figure 3 — back-to-back APB transfers are adjacent, not pipelined. When a second transfer is pending, completion goes ACCESS → SETUP with no IDLE cycle between, but still through a fresh SETUP — so the two transfers sit side by side, never overlapped. For contrast, a pipelined bus (AHB) would present the next transfer's address during the current transfer's data phase; APB never does, so each transfer still costs its full two cycles and queueing buys no throughput overlap.

5. Engineering tradeoff table

The lifecycle is a set of deliberate choices. Each keeps the machine small and unambiguous at the cost of throughput APB does not need.

Lifecycle choice	What it gives up	What it buys	Why it is correct for APB
Mandatory one-cycle SETUP	A cycle of latency per transfer	A guaranteed decode/prepare window before commit	Latency is free for sparse control traffic
ACCESS held until `PREADY`	Fixed, predictable timing	Subordinates of any speed on one bus	Slow registers and clock-crossing bridges need to stall
Single completion edge	Nothing real	An unambiguous "it happened" point	Removes all sample-timing ambiguity in RTL and verification
Return to SETUP, never overlap	Pipelined throughput	A two-state machine and trivial subordinates	Control traffic is sparse; overlap would buy idle gaps
No SETUP-skipping fast path	A possible one-cycle transfer	One legal path to verify	Simplicity and verifiability beat a cycle on rare traffic

The throughline: APB spends cycles to buy certainty. The lifecycle is shaped so that there is exactly one way a transfer can legally happen and exactly one cycle on which it completes — and that certainty, not speed, is what the control plane wants.

6. Common RTL / architecture / waveform mistakes

Misconceptions to unlearn

"A transfer completes at the end of SETUP / when the address appears." No. The address appearing only starts the lifecycle. Completion is the ACCESS cycle where PREADY is high — possibly several cycles later.
"SETUP can last more than one cycle." No. The SETUP → ACCESS transition is unconditional, so SETUP is always exactly one cycle. Only ACCESS stretches (via PREADY).
"Back-to-back transfers are pipelined." No. APB goes ACCESS → SETUP for the next transfer — adjacent, but never overlapped. The next address is never presented during the current access.
"During a wait state the manager can change the address or data." No. While PREADY is low the manager must hold PSEL, PENABLE, address, control, and write data stable. Changing them mid-ACCESS corrupts the transfer.
"The FSM can skip ACCESS for a fast subordinate." No. There is no IDLE/SETUP → ACCESS shortcut and no skipping ACCESS. Every transfer walks the full path; a fast subordinate just completes ACCESS in its first cycle.
"Returning to IDLE between transfers is required." No. With another transfer pending, completion goes straight to SETUP. IDLE is entered only when there is nothing to do.

7. Interview framing

This is the APB question that separates "I memorized the signals" from "I understand the protocol." Interviewers ask you to draw the state machine or walk a transfer cycle by cycle, because the FSM exposes whether you really know when a transfer completes.

The strong answer names the three states and the fixed path: IDLE until a request; SETUP for exactly one cycle (PSEL high, PENABLE low); ACCESS (PENABLE high) held until PREADY is high; then back to IDLE or directly to SETUP for the next transfer. Then volunteer the two depth points: completion is the single edge where PENABLE and PREADY are both high (the only cycle data is captured/valid), and back-to-back transfers are adjacent, not pipelined (ACCESS → SETUP, never overlap). What interviewers are really probing is whether you locate completion correctly and know SETUP is fixed while ACCESS is elastic — the difference between someone who can debug an APB waveform and someone who cannot.

8. Q&A

9. Practice

Draw the FSM. From memory, draw the three states and label every transition with its condition (req, unconditional, PREADY low, PREADY high).
Count the cycles. For a transfer whose subordinate inserts two wait states, state how many cycles it takes and which state each cycle is in.
Find completion. Given a waveform of two transfers, mark the single completion edge of each and name the cycle where read data is valid.
Walk back-to-back. Describe, state by state, two adjacent transfers where the first has one wait state and the second has none — note where (if anywhere) the bus enters IDLE.
Spot the bug. A manager changes PADDR during an ACCESS cycle in which PREADY was low. Using the lifecycle, explain what rule it broke and what can go wrong.

10. Key takeaways

One APB transfer is a walk through a tiny FSM: IDLE → SETUP → ACCESS → IDLE or next SETUP. The path is fixed; only ACCESS's length and "what next" vary.
SETUP is always exactly one cycle; ACCESS is one or more. The SETUP → ACCESS edge is unconditional; ACCESS is held while PREADY is low.
Completion is a single edge — PSEL, PENABLE, and PREADY all high — and it is the only cycle where a write is captured and read data is valid.
A transfer is complete only when the lifecycle says so, never when the address merely appears. The minimum transfer is two cycles.
Back-to-back transfers are adjacent, not pipelined. Completion can go straight to SETUP, but the next access is never overlapped with the current one — APB stays unpipelined by construction.
The lifecycle lives in the manager (the bridge) as a two-state sequencer; subordinates simply answer with PREADY. Certainty, not speed, is what the machine is designed to deliver.