IDLE Transfers

This chapter examines IDLE, the transfer type that looks like the least important and is actually one of the most consequential to get right. IDLE is the bus's resting state — the type a master drives when it has nothing to do — and it is, in many systems, the most frequent cycle on the bus. Precisely because it is so common, a subordinate that mishandles IDLE misbehaves constantly. We cover when a master drives IDLE, the three rules a subordinate must follow, and the classic phantom-access bug that comes from treating an IDLE cycle as a real access. This builds directly on the HTRANS overview (4.1) and the encoding (3.3).

1. What Is It?

IDLE (HTRANS = 00) is the transfer type meaning no transfer this cycle, and the master is not in a burst. It is the bus's resting state. When a master has no access to perform — and is not pausing inside a burst (that would be BUSY) — it drives IDLE.

The defining rules for a subordinate on an IDLE cycle are three:

• Perform no access — do not read or write anything; the cycle is not a real transfer.
• Respond OKAY — never signal ERROR on an IDLE; IDLE is normal, not a fault.
• Use zero wait states — complete the IDLE immediately (HREADY high); do not stall an IDLE.

The address and control signals are effectively don't-care during IDLE and must be ignored.

The essence: IDLE is the bus saying "nothing is happening this cycle." A subordinate's only correct behaviour is to ignore it cleanly — no access, OKAY, no wait. It sounds trivial, but because IDLE is so frequent, any deviation (accessing, erroring, or stalling on IDLE) misbehaves repeatedly. IDLE is the easy type to encode and a common type to mishandle.

2. Why Does It Exist?

IDLE exists because a master frequently has nothing to transfer, and the bus needs a defined way to represent "nothing happening" so that subordinates do not mistake a stale bus for a real access.

Consider what the bus looks like when a master is not transferring. The address and control lines still carry some value — whatever was last driven, or whatever the master happens to be driving. Without a way to mark "this is not a real access," a subordinate would have no way to distinguish a genuine transfer from a leftover address the master simply has not changed. It might perform an access based on stale signals — a phantom access. IDLE exists to mark these cycles explicitly: "ignore the address/control, this is not a transfer." So IDLE's first purpose is to make "not transferring" a defined, recognizable state rather than an ambiguous one.

IDLE also serves specific situations a master genuinely encounters:

• Out of reset. Before the first real access, the master drives IDLE — the defined starting state established as the bus comes out of reset (chapter 3.1).
• Between unrelated transfers. When a master finishes one access and the next is not ready (it is computing the next address, waiting on something internal), it drives IDLE in between.
• Holding the bus with nothing to do. In a single-master AHB-Lite system, the master always owns the bus; when it has no access, it parks in IDLE rather than driving a spurious transfer.
• Cancelling after an error. On the two-cycle ERROR response (chapter 3.9), the master drives IDLE to cancel the next, already-pipelined transfer.

So IDLE exists to give "nothing happening" a clean, defined representation — both to prevent phantom accesses on stale signals and to cover the real situations (reset, gaps, parking, error-cancel) where a master has no transfer. It is the bus's way of saying nothing, clearly.

3. Mental Model

Model IDLE as a taxi with its "off duty" light on.

A taxi (the bus) is always somewhere, but the "off duty" light (IDLE) tells everyone "I'm not picking up — ignore me." People at the curb (subordinates) see the off-duty light and do nothing; they do not try to get in, and they certainly do not complain. The taxi might be driving past, parked, or just starting its shift — whatever it is doing, the off-duty light means "not a real fare, pay no attention." When the light goes off (NONSEQ — a real transfer), then it is picking someone up.

The three rules map cleanly: the curb-side person does nothing (no access), does not object (responds OKAY, no error), and does not hold the taxi up (zero wait states). And critically, they ignore whatever the taxi's destination sign says (address/control don't-care), because off-duty means the sign is meaningless.

Watch IDLE between two real transfers:

The model's lesson: IDLE is the off-duty light — the bus is present but not transferring, and the correct response is clean nothing. No access, no objection, no delay, and the destination sign (address) is meaningless. Reading a waveform, IDLE cycles are the gaps between real activity.

4. Real Hardware Perspective

In hardware, handling IDLE correctly is a matter of qualifying a subordinate's access logic on the transfer type — and the failure to do so is the phantom-access bug.

A correct subordinate gates its access on the transfer type: it performs a real access only when HTRANS indicates NONSEQ or SEQ (and its HSEL and HREADY are high — chapter 4.7). On IDLE, the access-enable is false, so the subordinate does nothing: no read, no write, no state change. It drives HREADY high (IDLE never stalls) and OKAY on the response. In hardware terms, IDLE handling is simply not enabling the access when the type is IDLE — the access logic is conditioned on "real transfer type," and IDLE fails that condition.

The phantom-access bug is what happens when a subordinate fails to qualify on the transfer type — when it performs an access based on the address/control without checking whether HTRANS is a real transfer. On an IDLE cycle, the address lines carry don't-care values, but the unqualified subordinate treats them as a real access: it reads (returning garbage, or worse, reading a register with read side-effects like a FIFO pop or a clear-on-read status) or writes (corrupting state). Because IDLE is frequent, this happens constantly — the subordinate is repeatedly "accessing itself" on cycles that were never real transfers. The symptom is mysterious behaviour when the bus should be quiet: a FIFO draining when no one is reading it, a status bit clearing unexpectedly, corrupted registers.

The fix is the qualification rule: a subordinate must perform an access only on a real transfer type (NONSEQ/SEQ), qualified by HSEL and HREADY. This is the same discipline the HSEL chapter (3.10) and the committed-transfer chapter (4.7) develop, applied here specifically to not acting on IDLE. The hardware cost is trivial (one AND condition on the access-enable), but forgetting it is a serious, common bug — especially dangerous for registers with read or write side-effects, where a phantom access has real consequences beyond returning wrong data.

5. System Architecture Perspective

At the system level, IDLE is what makes the bus's resting behaviour clean, and it matters most for side-effect-bearing subordinates and for debug.

The system relies on the bus being able to rest cleanly between operations. On a lightly-loaded bus, or in a single-master system between accesses, IDLE is the dominant cycle — the bus spends most of its time idle. For the system to behave correctly, every subordinate must treat these frequent IDLE cycles as clean nothing. If even one subordinate mishandles IDLE, it misbehaves on a large fraction of all cycles, which at the system level looks like persistent, hard-to-localize corruption or spurious activity. So correct IDLE handling is a baseline requirement for every subordinate, and it is especially critical for the peripherals (often behind an APB bridge) whose registers carry side-effects.

IDLE also matters for system debug and validation. Because IDLE explicitly marks non-transfer cycles, a bus monitor or protocol checker can verify that no subordinate acts on an IDLE cycle — a key correctness property. Conversely, when debugging mysterious side-effects (a FIFO draining, a status clearing) the engineer checks whether a subordinate is phantom-accessing on IDLE. So IDLE is part of the system's diagnostic framework: it defines which cycles must be inert, making violations detectable. A protocol checker keying off HTRANS can flag any access on an IDLE cycle as a bug.

There is also the error-cancel role at the system level: IDLE is how a master cleanly aborts a pipelined transfer after an error (chapter 3.9). When a transfer errors, the next transfer is already in flight; the master drives IDLE to cancel it, ensuring a transfer that should not proceed (given the error) does not commit. So IDLE participates in the system's error-handling flow, not just its resting state. This is a subtle but important system role: IDLE is the master's tool for retracting a pipelined access.

So at the system level, IDLE underpins clean bus rest (critical for side-effect subordinates), supports debug/validation (defining inert cycles), and participates in error handling (cancelling pipelined transfers). Its correct handling across all subordinates is foundational to a correctly-behaving system.

6. Engineering Tradeoffs

IDLE is simple, so the tradeoffs are mostly about the discipline around it.

• Explicit IDLE vs inferred-idle. Marking idle cycles explicitly (a dedicated HTRANS value) costs nothing extra (HTRANS already exists) and gives subordinates an unambiguous "do nothing" signal, preventing phantom accesses on stale signals. Inferring idle from other signals would be ambiguous and error-prone. Explicit IDLE is clearly the right design.
• Subordinate qualification cost vs correctness. Requiring every subordinate to qualify its access on the transfer type (not act on IDLE) adds a trivial gate but is mandatory for correctness, especially for side-effect registers. There is no real tradeoff here — the cost is negligible and the consequence of skipping it is severe; it is simply a discipline that must be followed.
• IDLE zero-wait vs allowing stalls. IDLE must complete with zero wait states — a subordinate may not stall an IDLE. This keeps the bus's resting behaviour predictable (idle cycles never block) at the cost of removing a (pointless) flexibility. Allowing IDLE stalls would serve no purpose and complicate the bus, so the zero-wait rule is the right constraint.
• Parking in IDLE vs releasing the bus. In a single-master system the master parks in IDLE when idle rather than doing anything special; in a multi-master system it might instead drop its bus request so another master can use the bus. The trade is "hold the bus in IDLE" (simple, fine for one master) versus "release it" (better utilization with multiple masters) — a system-structure choice rather than an IDLE-design one.

The throughline: IDLE's design is deliberately minimal — an explicit "do nothing" type with a zero-wait, no-access, OKAY response — and the only real engineering content is the discipline of qualifying every subordinate's access on the transfer type. The cost of that discipline is trivial; the cost of skipping it (phantom accesses on the bus's most frequent cycle) is severe.

7. Industry Example

Trace IDLE through a real subsystem, including the phantom-access failure.

A microcontroller has a processor and a peripheral with a clear-on-read status register and a FIFO data port (both side-effect registers), on the AHB.

• The bus rests in IDLE. Most of the time the processor is executing from cache or computing, not accessing the bus. During these cycles it drives IDLE. The peripheral, correctly qualifying on the transfer type, does nothing on these IDLE cycles — its status register is untouched, its FIFO is not popped.
• A real read (NONSEQ). When the processor reads the peripheral's status, it drives NONSEQ at the status address; the peripheral, seeing a real transfer with its HSEL and HREADY high, performs the read — and clears the status (its side-effect). This is correct: a real, intended access.
• The phantom-access bug (if mishandled). Now suppose the peripheral were buggy — it performed a read whenever its address happened to be on the bus, without checking HTRANS. During the frequent IDLE cycles, the stale address lines might point at the status register or FIFO port, and the buggy peripheral would "read" them — clearing status the processor had not read yet, or popping FIFO data no one consumed. The processor would then find status mysteriously cleared and FIFO data missing, with no apparent cause. This is the phantom-access bug, and it is especially destructive here because of the side-effects.
• The fix. The correct peripheral qualifies its access logic on HTRANS (real transfer) plus HSEL and HREADY, so it acts only on genuine, committed accesses and ignores all IDLE cycles. With that qualification, the frequent IDLE cycles are clean nothing, and the side-effect registers behave only on real accesses.

The contrast shows IDLE's importance: it is the bus's most common cycle, and the difference between a correct and a buggy subordinate is entirely whether it ignores IDLE. The side-effect registers make the phantom-access bug catastrophic, which is why correct IDLE handling is non-negotiable.

8. Common Mistakes

9. Interview Insight

IDLE questions test whether you appreciate the phantom-access bug — the reason a "trivial" type matters.

The answer that lands gives the rules and the phantom-access consequence: "IDLE is the resting state — no transfer, not in a burst — driven out of reset, between accesses, while parked, and to cancel a pipelined transfer after an error. A subordinate must do three things: perform no access, respond OKAY, and use zero wait states, ignoring the address and control. The critical point is that a subordinate must qualify its access logic on the transfer type — if it acts on IDLE cycles it causes phantom accesses, which is especially destructive on side-effect registers like clear-on-read or FIFO ports, and which happens constantly because IDLE is the most frequent cycle." The phantom-access bug and the side-effect danger are the senior signals.

10. Practice Challenge

Reason from the resting-state role and the phantom-access bug.

1. State the rules. Give the three rules a subordinate must follow on an IDLE cycle.
2. List the uses. Name four situations where a master drives IDLE.
3. Explain the bug. In three sentences, explain the phantom-access bug and how qualifying on the transfer type prevents it.
4. Rank the danger. Explain why phantom accesses are worse on side-effect registers than on plain memory, with two examples.
5. Diagnose the symptom. A FIFO loses data when the bus is quiet. Explain how IDLE mishandling causes it and the fix.

11. Key Takeaways

• IDLE (00) means no transfer and not in a burst — the bus's resting state and often the most frequent cycle.
• A master drives IDLE out of reset, between unrelated transfers, while parked holding the bus, and to cancel a pipelined transfer after an error.
• A subordinate must, on IDLE, perform no access, respond OKAY, and use zero wait states — and ignore the don't-care address/control.
• The phantom-access bug comes from a subordinate acting on the address without qualifying on the transfer type — it performs accesses on IDLE cycles, which is most cycles.
• Phantom accesses are catastrophic on side-effect registers (clear-on-read, FIFO ports, write-one-to-clear) — they corrupt system state, not just return wrong data.
• The fix is one rule: perform an access only on a real transfer type (NONSEQ/SEQ), qualified by HSEL and HREADY. Trivial to implement, severe to omit.

12. What Comes Next

You now understand the bus's resting state. The next chapter covers its trickier sibling — the non-transfer that keeps a burst alive:

• 4.3 — BUSY Transfers (coming next) — BUSY: pausing inside a burst without abandoning it, and the IDLE-vs-BUSY-vs-wait-state distinctions.
• 4.4 — NONSEQ Transfers (coming soon) — the first beat of a burst or a single transfer.

To revisit the type system IDLE sits in, see Transfer Types Overview and HTRANS; for the qualification rule that prevents phantom accesses, see HSEL and (ahead) the valid-transfer-identification chapter. For the broader protocol map, see the AMBA family overview.