Slave-Inserted Wait States

Chapter 6.1 established that HREADY paces the bus: high advances, low holds. This chapter examines the mechanism by which a subordinate makes HREADY go low — the wait state. A subordinate that needs more time to complete a transfer simply drives HREADY low, and every cycle it holds HREADY low is one wait state that extends the transfer's data phase. The subordinate inserts as many wait states as it needs, then asserts HREADY high to complete. This is how a slow subordinate paces a transfer to its own speed — and it is the most common reason the AHB bus is anything other than one-transfer-per-cycle.

1. What Is It?

A wait state is a cycle in which a subordinate holds HREADY low to extend the data phase of the current transfer because it is not yet ready to complete.

The mechanism is simple and direct:

• A subordinate that can complete a transfer in one cycle asserts HREADY high in the data phase — the transfer completes immediately, with zero wait states.
• A subordinate that needs more time holds HREADY low — each cycle it does so is one wait state, extending the data phase by one cycle. When ready, it asserts HREADY high and the transfer completes.

So a wait state is the unit of delay a subordinate inserts: hold HREADY low for one cycle = one wait state = one extra cycle on the data phase. A transfer's data phase is (number of wait states + 1) cycles long — the +1 being the final cycle where HREADY is high and the transfer completes. This is the entire mechanism by which slow subordinates work on AHB.

2. Why Does It Exist?

Wait states exist because subordinates need a way to take more than one cycle to complete a transfer — and the bus needs a clean, uniform way for them to signal "not yet."

Many real subordinates cannot complete a transfer in a single cycle. A flash memory needs several cycles to read; an off-chip memory has access latency; a peripheral may need time to act on a write. These subordinates need to tell the bus "hold on — I'm not ready yet," and keep saying it until they are ready. Wait states are exactly that mechanism: holding HREADY low is the subordinate saying "not yet," and asserting it high is saying "now." So wait states exist to give slow subordinates a way to take the time they need while keeping the bus correctly paced.

The reason wait states are built on HREADY (rather than some separate "I need time" signal) is uniformity and simplicity — the bus already has HREADY pacing every transfer (chapter 6.1), so extending a transfer is just not yet asserting HREADY high. There is no separate mechanism to learn: the same signal that completes a transfer (HREADY high) inserts wait states by its absence (HREADY low). So wait states reuse the existing pacing signal — they are simply the cycles before HREADY goes high. This is elegant: one signal both completes transfers and stretches them, with no extra protocol.

Wait states also exist because the alternative — running the whole bus at the slowest subordinate's fixed speed — would be wasteful. With wait states, a fast subordinate completes in one cycle (zero waits) and only slow subordinates insert waits, per transfer. So the bus runs at each subordinate's speed rather than a fixed slow rate. Wait states are thus the per-transfer adaptation (chapter 6.1's adaptive pacing) made concrete: the subordinate inserts exactly as many wait cycles as it needs, no more. This is why AHB can host fast and slow subordinates efficiently on one bus.

3. Mental Model

Model wait states as a cashier saying "one moment" while ringing up an item — each "one moment" is one more cycle the queue waits.

At a checkout (the bus), the cashier (the subordinate) rings up your item. A fast item scans instantly — the cashier says "done" right away (HREADY high, zero waits). A tricky item needs a price check — the cashier says "one moment" (HREADY low, a wait state), and the whole queue behind you waits. The cashier keeps saying "one moment" each cycle the price check takes (more wait states), then finally "done" (HREADY high) and the queue advances. Each "one moment" is one wait cycle; the cashier inserts as many as the item needs, and the queue waits through all of them.

This captures wait states precisely: "one moment" = HREADY low = a wait state (the transfer not yet complete); "done" = HREADY high = completion; and the queue waiting = the whole bus held (the shared-stall coupling — everyone behind waits). The cashier inserts exactly as many "one moments" as needed, just as a subordinate inserts exactly as many wait states as it needs.

Watch a 2-wait-state transfer:

The model's lesson: a subordinate inserts wait states by saying "one moment" (HREADY low) until it can say "done" (HREADY high). In the waveform, HREADY low in T1/T2 are the two "one moments," and HREADY high in T3 is "done" — the data valid and the transfer complete. Read data is valid only on the completing cycle, never during the waits.

4. Real Hardware Perspective

In hardware, a subordinate inserts wait states by registering an internal "ready" condition out onto HREADYOUT (which becomes the bus HREADY via the interconnect, chapter 6.6), holding it low until its access logic can complete.

A subordinate has internal logic that knows when it can complete a transfer — a memory's read-data-valid signal, a peripheral's done flag, a FIFO's space-available. The subordinate drives its HREADYOUT from this condition: low while the access is in progress, high when it completes. So inserting wait states is not a special action — it is just the subordinate driving its ready output low until its logic is done. The number of wait states is however many cycles that logic takes. This is why wait-state count is subordinate-specific: it reflects the subordinate's internal access latency.

For a read, the subordinate holds HREADY low until its read data is available, then asserts HREADY high with valid HRDATA on the same cycle (chapter 5.4). The wait states are the read latency — the cycles between the address phase and data-available. Read data must not be assumed valid during the wait cycles; it is valid only on the completing (HREADY-high) cycle, as Figure 2 shows. So a subordinate's read wait states directly expose its read latency to the bus.

For a write, the subordinate holds HREADY low until it can accept the write data, then asserts HREADY high to acknowledge it has taken the data. During the wait, the manager must hold HWDATA stable (chapter 6.3 / 5.5) — the data stays presented until the subordinate is ready to take it. So write wait states are the subordinate signalling "I haven't accepted the data yet," and the manager holds the data until it does.

A hardware nuance: the subordinate's wait-state behaviour must be well-behaved — it must eventually assert HREADY high (no holding it low forever, which would hang the bus). Real subordinates bound their wait states (a memory completes in a fixed or bounded number of cycles); a subordinate that could wait indefinitely would need a timeout mechanism elsewhere (chapter 7's error handling, or a bus watchdog). So in hardware, wait states are bounded by design — the subordinate always completes within its known latency.

5. System Architecture Perspective

At the system level, wait states are the visible cost of slow subordinates — they are the HREADY-low cycles that reduce throughput and stall the whole bus, and managing them is a central performance concern.

Wait states are where throughput is lost (chapters 4.6, 6.1). A transfer with zero wait states completes in one data cycle (peak throughput); each wait state adds a non-productive cycle. So a subsystem's throughput loss is, concretely, its total wait-state count — the cycles spent with HREADY low doing no useful transfer. When an architect profiles AHB performance, the wait states are the gap between achieved and peak throughput. Reducing wait states (faster subordinates, caching, bridging) is how throughput is recovered.

Wait states stall the whole bus, not just the slow subordinate (chapters 2.4, 6.1) — the shared-stall coupling. Because HREADY is bus-wide, every wait state a slow subordinate inserts freezes every participant. So a subordinate with many wait states is not just slow itself; it slows everything on the bus during its transfers. This is the architectural significance of wait states: they are how a slow subordinate's latency becomes the whole bus's latency. It is precisely why slow, wait-state-heavy subordinates are isolated.

The architectural response to wait states is isolation and bridging: slow subordinates (flash, off-chip memory, slow peripherals) that would insert many wait states are placed behind a bridge (to APB) or on a separate bus segment, so their wait states do not stall the high-performance backbone (chapters 1.4, 6.1). So wait states drive topology: the more wait states a subordinate inserts, the stronger the case for isolating it. An architect reads expected wait-state counts to decide what goes on the fast bus and what gets bridged. Wait states are thus not just a timing detail but a system-partitioning input.

A subtle system point: wait states are per-transfer and dynamic — the same subordinate may insert different wait-state counts on different transfers (a cache hit vs miss, a ready vs busy peripheral). So the bus's throughput is not fixed but varies with the access pattern and the subordinates' dynamic state. This is why AHB throughput is characterized statistically (average wait states per transfer) rather than as a single number — the wait states depend on what is being accessed and when.

6. Engineering Tradeoffs

Wait states embody the slow-subordinate-accommodation tradeoff.

• Wait states vs fixed fast timing. Allowing subordinates to insert wait states accommodates any subordinate speed, at the cost of variable, sometimes-low throughput. Forcing all subordinates to complete in one cycle would give fixed peak throughput but exclude every slow subordinate. AHB chooses wait states — accommodating real subordinates is essential, and fast ones still get one-cycle transfers.
• Reusing HREADY vs a separate wait signal. Building wait states on the existing HREADY (just don't assert it high yet) is simple and uniform — no extra signal. A dedicated "need time" signal would be redundant. AHB reuses HREADY — wait states are simply its low cycles.
• Bounded vs unbounded waits. Real subordinates bound their wait states (complete within a known latency), keeping the bus predictable. Unbounded waits would risk hangs and require timeouts everywhere. AHB assumes well-behaved, bounded subordinates — a subordinate that cannot complete should signal an error (chapter 7), not wait forever.
• Per-transfer adaptation vs worst-case design. Wait states let each transfer take exactly the time it needs (fast transfers stay fast). Designing for worst-case (always assume slow) would waste the fast cases. AHB's per-transfer wait states are efficient — only slow transfers pay.

The throughline: wait states are the cheap, uniform mechanism that lets slow subordinates share the bus with fast ones — built on the existing HREADY, bounded by well-behaved subordinates, and paid for per-transfer. The cost is the throughput lost to the wait cycles and the whole-bus stall they cause, which the architecture manages by isolating the slowest subordinates.

7. Industry Example

Trace wait states across a few subordinates with different latencies.

A system has an SRAM (zero-wait), a flash (multi-wait), and a status register (zero-wait) on one AHB.

• SRAM read (zero wait states). The processor reads SRAM. The SRAM completes in one cycle — it asserts HREADY high in the first data cycle, with valid data. Zero wait states; the data phase is one cycle; peak throughput. The fast subordinate inserts no waits.
• Flash read (several wait states). The processor reads flash. Flash has multi-cycle access latency, so it holds HREADY low for several cycles (several wait states) while it fetches, then asserts HREADY high with the data. The data phase spans (waits + 1) cycles. During the waits, the whole bus is stalled. The slow subordinate inserts several waits, exposing its latency to the bus.
• Status-register read (zero wait states). The processor reads a peripheral's status register. The register value is immediately available — HREADY high in the first data cycle, zero waits. Fast, like the SRAM.
• A write to a busy peripheral (wait states until accepted). The processor writes a peripheral that is momentarily busy. The peripheral holds HREADY low until it can accept the write (a few wait states), during which the processor holds HWDATA stable; then HREADY high acknowledges acceptance. The wait states are the cycles before the peripheral takes the data.
• The throughput picture. Across a workload, the average wait states per transfer determine throughput. An SRAM-heavy workload (mostly zero-wait) runs near peak; a flash-heavy one (many waits) runs slower. The flash's wait states are the throughput cost — which is why flash is often cached or bridged. The wait-state profile is the performance profile.

The example shows wait states as the per-subordinate, per-transfer latency made visible: SRAM and status register insert zero (fast), flash inserts several (slow), the busy peripheral inserts a few (until ready). Each subordinate paces its own transfers via the wait states it inserts, and the bus's throughput is the sum of those waits.

8. Common Mistakes

9. Interview Insight

Wait states are a core interview topic — they test whether you understand the HREADY mechanism concretely.

The answer that lands is concrete and mechanism-first: "A subordinate inserts wait states by holding HREADY low during the data phase — it drives HREADY (via HREADYOUT) low while it's not ready, and each low cycle is one wait state that extends the transfer. When it can complete, it asserts HREADY high — for a read, with valid data on that cycle; for a write, acknowledging it accepted the data. Zero wait states means HREADY high immediately, a one-cycle data phase. And because HREADY is bus-wide, every wait state stalls the whole bus, not just the slow subordinate." Mentioning that read data is valid only on the completing cycle, and that the manager holds HWDATA during write waits, signals depth.

10. Practice Challenge

Reason from the wait-state mechanism.

1. Insert a wait state. Describe exactly what a subordinate does to insert two wait states, and how long the resulting data phase is.
2. Count from a waveform. From Figure 2, identify the wait-state cycles and the completing cycle, and state when read data is valid.
3. Zero vs N. Contrast a zero-wait transfer with an N-wait transfer in terms of data-phase length and throughput.
4. Write behaviour. Explain what the manager must do with HWDATA during write wait states and why.
5. System impact. Explain why a subordinate's wait states stall the whole bus and what the architecture does in response.

11. Key Takeaways

• A wait state is a cycle where a subordinate holds HREADY low to extend the transfer's data phase because it is not yet ready to complete.
• One HREADY-low cycle = one wait state. A transfer's data phase is (wait states + 1) cycles; zero waits = HREADY high immediately = one-cycle data phase.
• The subordinate inserts the wait states (drives HREADY low via HREADYOUT), reflecting its internal access latency; it always eventually asserts HREADY high.
• Read data is valid only on the completing (HREADY-high) cycle — never during the waits. During write waits, the manager holds HWDATA stable until accepted.
• Wait states stall the whole bus (HREADY is bus-wide), so a slow subordinate's latency becomes the whole bus's latency — the throughput cost of accommodating it.
• Wait states are normal, not errors — but they drive system topology: heavy-wait subordinates are isolated (bridged) to keep their stalls off the high-performance bus.

12. What Comes Next

You now know how a subordinate inserts wait states. The next chapter examines the other side:

• 6.3 — Master Behavior During Wait (coming next) — what the manager must hold stable (address, control, write data) while HREADY is low, so the transfer completes correctly when the wait ends.

To revisit the foundation, see What HREADY Means (the pacing signal) and The Data Phase (where wait states extend the transfer). For how read data timing works, see Read Transfer Timing; for write data, Write Transfer Timing. For the throughput impact, see Address Phase Timing and the AMBA family overview.