AMBA APB · Module 4

The IDLE State

APB's IDLE state — what is true on the bus when no transfer is in progress, which signals matter, and how a transfer leaves IDLE and enters SETUP.

Module 4 opens not with a transfer but with the absence of one. Before any address is presented, any subordinate selected, or any data driven, the APB bus sits in IDLE — its resting state. IDLE is easy to skip past because "nothing is happening" feels like nothing to learn, but it is the baseline every transfer departs from and returns to, and getting it right is what stops the most common beginner error: reading meaning into a bus that is, by definition, not transferring anything. The single idea to carry: in IDLE nothing is in flight, so the bus carries no meaning — and only PSEL rising starts a transfer.

1. What problem is being solved?

The problem is defining a precise, agreed resting state for the bus — a condition every manager and subordinate recognises as "no transfer in progress" — so that the start of a transfer is an unambiguous event rather than a guess.

A bus is busy only a fraction of the time; control traffic is sparse. Between accesses the wires still hold some value, but those values mean nothing. If "the bus is idle" were fuzzy, a subordinate might act on a stale address, or a manager might not know whether the bus is free to use. APB removes the ambiguity by defining IDLE concretely:

No subordinate selected — PSEL is low for every subordinate on the bus.
No access underway — PENABLE is low.
The data and address lines are don't-care — PADDR, PWRITE, and PWDATA are not meaningful; nothing is required to drive them.

With that defined, the transition out of IDLE becomes one clean event — PSEL rising — and the transition back becomes equally clean. IDLE is the frame that makes "a transfer started" and "a transfer finished" precise.

2. Why the previous model is not enough

If you have met the transfer lifecycle as IDLE → SETUP → ACCESS, you have seen IDLE named — but named is not understood. A list of states tells you IDLE exists; it does not tell you what is true on the wires while the bus rests, or why that matters for everything that follows.

The danger of treating IDLE as "just the empty state" is that you start reasoning about the bus as if its signals always carry meaning:

The bus is not "showing the last transfer." After a transfer completes and the bus returns to IDLE, PADDR and PWDATA may still hold old values, but they are don't-care. Reading them as if they describe a live access is a category error — nothing is being transferred.
IDLE is not "waiting for the address." The address does not start a transfer; PSEL does. The address only becomes meaningful once a subordinate is selected. Watching PADDR to detect a transfer is the wrong trigger.
IDLE is a destination as well as an origin. A transfer does not only leave IDLE — it returns to IDLE when there is no next transfer. So IDLE is not a one-time start condition; it is the state the bus rests in whenever nothing is in flight.

So the model to add is not another transition; it is the discipline of treating IDLE as a real, defined condition — PSEL low everywhere, PENABLE low, bus meaningless — and keying the start of every transfer on PSEL rising, nothing else.

3. Mental model

The model: IDLE is an empty road — lanes painted and lights on, but no car moving — and a transfer is a car pulling onto it.

An empty road still exists; it simply has no traffic. You would not read the position of a parked car as "where traffic is going," and you would not call the road busy because paint is on the tarmac. APB's IDLE is exactly this: the wires are there and hold values, but with PSEL low everywhere and PENABLE low, nothing is moving, so nothing on the bus means anything. A transfer begins the instant a car pulls on — the instant PSEL rises and a subordinate is selected, taking the bus into SETUP.

Three refinements make the model precise:

Resting, not broken. IDLE is the normal, healthy state of an APB bus between accesses. Sparse control traffic means the bus spends most of its life here. It is where the bus belongs when there is nothing to do.
Leaving IDLE is one event: PSEL rising. A transfer departs IDLE only by asserting PSEL for a target subordinate, which moves the bus into SETUP. The address and data become meaningful at the same moment, never before.
Returning to IDLE is automatic. After a transfer completes, if there is no next transfer the bus returns to IDLE; if another is pending it goes straight to a fresh SETUP — back-to-back, not pipelining, with no IDLE cycle between. IDLE is entered only when there is genuinely nothing to do.

Figure 1 — IDLE highlighted within the APB lifecycle as the bus's resting state. In IDLE no subordinate is selected (PSEL low for every subordinate) and PENABLE is low, so the address and data lines are don't-care and nothing is being transferred. A transfer leaves IDLE only when PSEL rises, moving the bus to SETUP. After a transfer completes, the bus returns to IDLE when there is no next transfer, or goes straight to a fresh SETUP for a back-to-back transfer with no IDLE cycle between. The figure stresses that reading the bus in IDLE is meaningless and that only PSEL rising starts a transfer.

4. Real SoC / hardware context

On a real SoC the APB segment hangs off a bridge (the manager) and serves a handful of slow peripherals — a UART, a timer, a GPIO block, a few control registers. These are touched rarely: firmware writes a config word, reads a status flag, and otherwise leaves them alone. So the bus is in IDLE the overwhelming majority of the time, and only briefly walks a transfer when the CPU reaches through the bridge.

Concretely, while the bus rests in IDLE, every subordinate sees its own PSEL low and therefore does nothing — it does not decode PADDR, does not drive PRDATA, does not sample PWDATA. That is exactly why PSEL exists as a per-subordinate select: a subordinate is only involved when its select is high, and in IDLE none are. A correct peripheral is built so that its entire access behaviour is gated behind its PSEL, which means in IDLE it is, by construction, inert. (See PSEL for how the select isolates each subordinate.)

This also explains why the bus is "meaningless to read" in IDLE in a way that matters for both RTL and verification. The address and data lines are not actively driven to a defined idle pattern by the protocol — they are simply don't-care. A monitor that tries to log "the current transfer" during IDLE would record noise. The correct monitor qualifies everything on PSEL: it only considers a transfer to exist once a select goes high. The same discipline lives in the manager's sequencer — it leaves IDLE only when it has a request to drive, asserting PSEL to begin SETUP, and it parks back in IDLE the moment its queue is empty.

Figure 2 — several quiet IDLE cycles, then PSEL rises to enter SETUP, against PCLK. Through every IDLE cycle PSEL and PENABLE are both low and the address and write-data lines are don't-care — nothing is being transferred and the bus is inactive. On the fourth cycle PSEL rises while PENABLE stays low: this is the SETUP cycle that leaves IDLE and starts a transfer, and the address and write data become meaningful at the same moment. A dashed marker sits on the PSEL rising edge — the single event that departs IDLE. The figure stresses that reading the bus during the IDLE cycles is meaningless and that only PSEL rising begins the transfer.

5. Engineering tradeoff table

Defining an explicit resting state — rather than, say, treating the bus as always "in some transfer" — is a deliberate choice. Each property trades a capability APB does not need for the clarity it does.

IDLE design choice	What it gives up	What it buys	Why it is correct for APB
`PSEL` low everywhere defines IDLE	A bus that is "always active"	One clean condition for "bus at rest"	Sparse control traffic rests most of the time
Address / data don't-care in IDLE	Holding a defined idle pattern	No obligation to drive meaningless lines	Nothing reads them while no subordinate is selected
Leave IDLE only on `PSEL` rising	Starting on address change	One unambiguous start event	The select, not the address, owns "a transfer began"
Return to IDLE when nothing pending	Forcing a default transfer	A true quiescent state, low activity	The control plane is idle far more than it is busy
No IDLE cycle for back-to-back	A guaranteed gap between transfers	Adjacent transfers when traffic is dense	Completion can flow straight to the next SETUP

The throughline: APB spends nothing to gain a precisely defined rest. By making IDLE a real condition (PSEL low everywhere, PENABLE low, bus don't-care) it turns "a transfer started" and "a transfer finished" into clean, unambiguous events — which is exactly the certainty the control plane wants.

6. Common RTL / waveform mistakes

Misconceptions to unlearn

"The bus always shows the current transfer." No. In IDLE no subordinate is selected and nothing is in flight; PADDR and PWDATA are don't-care. Reading them as a live access is meaningless.
"A transfer starts when the address appears." No. The address becomes meaningful only once a subordinate is selected. A transfer leaves IDLE on PSEL rising — the select is the start event, not the address.
"IDLE is a special idle pattern driven on the bus." No. The protocol does not require a defined idle value on PADDR / PWDATA; they are simply don't-care. Only PSEL and PENABLE being low define the rest.
"After a transfer the bus must return to IDLE." No. With another transfer pending, completion flows straight to a fresh SETUP — no IDLE cycle between. IDLE is entered only when nothing is pending.
"A subordinate should watch the bus while in IDLE." No. A subordinate does nothing until its own PSEL is high. In IDLE every select is low, so every subordinate is, by construction, inert.
"Back-to-back means the bus never idles, so it is pipelined." No. Adjacent transfers skip IDLE but still run one at a time through SETUP then ACCESS. Skipping IDLE is not overlapping.

7. Interview framing

IDLE looks like a throwaway question, which is exactly why it separates someone who memorised the FSM from someone who understands the bus. An interviewer asks "what is true on the APB bus when it is idle?" or "what starts a transfer?" — and a precise answer shows you reason about the bus correctly.

Lead with the definition: IDLE is the resting state — PSEL low for every subordinate, PENABLE low, and the address and data lines don't-care, so nothing is being transferred and the bus is meaningless to read. Then give the start event: a transfer leaves IDLE only when PSEL rises for a target subordinate, moving the bus into SETUP — not when the address changes. Close with the two depth points: the bus returns to IDLE only when no transfer is pending (otherwise completion flows straight to a new SETUP, back-to-back, not pipelined), and a correct subordinate is inert in IDLE because its whole behaviour is gated on its own PSEL. Volunteering "the address doesn't start a transfer, the select does" signals you know where the protocol's boundaries actually are.

8. Q&A

9. Practice

Define it on the wires. Without notes, state the exact condition for IDLE in terms of PSEL and PENABLE, and say what is true of PADDR, PWRITE, and PWDATA.
Mark the departure. Given a waveform with several quiet cycles followed by a transfer, mark the single cycle and edge where the bus leaves IDLE, and name the signal responsible.
Read the rest. Given a transfer followed by leftover values on PADDR and PWDATA while PSEL is low, explain in one sentence why those values mean nothing.
Trace return vs back-to-back. Describe two scenarios after a completing transfer — one where the bus enters IDLE and one where it goes straight to SETUP — and state what determines which happens.
Spot the bug. A subordinate decodes PADDR and updates a register whenever the address changes, ignoring PSEL. Show, using an IDLE stretch, exactly when it wrongly acts and why gating on PSEL fixes it.

10. Key takeaways

IDLE is the APB bus's resting state: no transfer in progress, PSEL low for every subordinate, and PENABLE low. It is where the bus belongs whenever there is nothing to do.
In IDLE the bus is meaningless to read. PADDR, PWRITE, and PWDATA are don't-care; whatever they hold describes no live access, because no subordinate is selected.
A transfer leaves IDLE on one event: PSEL rising. The select, not the address, starts a transfer and moves the bus into SETUP — the address only becomes meaningful at that same moment.
The bus returns to IDLE only when nothing is pending. After a completion with no next transfer the bus rests in IDLE; with one pending it goes straight to a fresh SETUP — back-to-back, not pipelined.
A correct subordinate is inert in IDLE. Its whole access behaviour is gated on its own PSEL, so with every select low it does nothing — which is exactly why the bus can rest safely.
IDLE is the frame that makes start and finish unambiguous. By defining rest precisely, APB turns "a transfer began" and "a transfer ended" into clean, single events the manager, subordinate, and verification all agree on.