Master Behavior During Wait

Chapter 6.2 covered the subordinate's side of a wait state — driving HREADY low to stretch a transfer. This chapter covers the manager's side: what it must do while HREADY is low. The answer is essentially nothing but hold. While the subordinate inserts wait states, the manager must keep all of its outputs — address, control, and write data — stable and unchanged, and it must take no action (sample no read data, assume no write accepted) until HREADY goes high. The transfer is, in effect, frozen in place until the wait ends. Getting this right is what makes wait states work correctly; getting it wrong corrupts the transfer.

1. What Is It?

The manager's wait-state behaviour is a hold-and-wait rule: while HREADY is low, the manager holds all its outputs stable and acts only on the cycle HREADY is high.

Concretely, while HREADY is low the manager must keep unchanged:

• The address — HADDR
• The control signals — HWRITE, HTRANS, HSIZE, HBURST, HPROT (and the rest of the control group)
• The write data — HWDATA (for a write), held until the subordinate accepts it

And while HREADY is low, the manager must not act: it must not sample read data (the data is not valid yet), must not treat a write as accepted (it hasn't been), and must not advance to the next transfer. All of that happens only on the completing cycle — when HREADY is high. So the rule has two halves: hold the outputs stable, and defer all action until HREADY high. The transfer stays frozen until the wait ends.

2. Why Does It Exist?

This rule exists because the subordinate must see a stable, unchanging transfer for the entire duration it is working on it — if the manager changed the address or data mid-transfer, the subordinate would be working on a moving target.

Consider what a subordinate does during its wait states: it is processing this transfer — decoding this address, producing read data for it, or preparing to accept this write data. For that to work, the transfer's defining outputs must stay fixed while the subordinate works. If the manager changed HADDR mid-wait, the subordinate would suddenly be addressed differently; if it changed HWDATA, the subordinate would accept the wrong write data. So the manager must hold its outputs stable so the subordinate sees one coherent transfer throughout the wait. The hold rule exists to give the subordinate a stable transfer to complete.

The reason the manager must act only on HREADY high is that HREADY is the signal that says "the transfer is now complete" (chapter 6.1) — before that, nothing has happened. Read data is not valid until HREADY high (the subordinate hasn't produced it); a write is not accepted until HREADY high (the subordinate hasn't taken it). So if the manager acted during a wait — sampled read data, assumed the write was done, moved on — it would be acting on a transfer that hasn't completed, capturing invalid data or losing the write. The act-on-HREADY-high rule exists because completion is HREADY high; acting before it is acting on nothing.

Together these two halves ensure the transfer completes correctly: the subordinate sees a stable transfer to work on (the hold), and the manager captures the result only when it is actually ready (the act-on-HREADY-high). This is the manager's contribution to the wait-state mechanism — the subordinate stretches the transfer, and the manager holds it stable and waits for the real completion. Both sides are needed for wait states to work.

3. Mental Model

Model the manager during a wait as holding a form up at a counter until the clerk says "got it" — you don't lower the form, change it, or walk away until they confirm.

You hand a filled-out form (the transfer: address, control, write data) across a counter to a clerk (the subordinate). The clerk needs a moment to process it (wait states). During that moment you must keep holding the form up, unchanged — you don't lower it, you don't scribble new values on it, you don't walk away. You wait. Only when the clerk says "got it" (HREADY high) do you know they've taken it — and only then do you take back any response (read data) and move to your next task (the next transfer). If you changed the form or walked off while they were still reading it, they'd process the wrong thing or lose it entirely.

This captures both halves: holding the form unchanged = holding outputs stable (the address/control/data must not change mid-wait); waiting for "got it" = acting only on HREADY high (the transfer isn't done until the clerk confirms). The form stays up, unchanged, until confirmation — exactly the manager's discipline during wait states.

Watch the manager hold through a 2-wait write:

The model's lesson: the manager holds the transfer up unchanged until the subordinate says "got it" (HREADY high). In the waveform, HADDR, HWRITE, and HWDATA all hold steady through the wait cycles — the manager changes nothing — and only on HREADY high (T3) is the write accepted and the manager free to advance.

4. Real Hardware Perspective

In hardware, the manager holds its outputs during waits because its output registers are gated by HREADY — they advance only when HREADY is high, so they naturally hold while HREADY is low.

The manager's outputs (address, control, write data) come from registers that update to the next transfer's values on a clock edge. But those registers are enabled by HREADY: they update only when HREADY is high. While HREADY is low, the enable is deasserted, so the registers hold their current values — the current transfer's outputs stay presented. So holding during waits is not extra logic the manager runs; it is the natural consequence of gating the output registers with HREADY (the same clock-enable framing from chapter 6.1). The manager advances its outputs exactly when the bus advances — on HREADY high.

This is why the manager's hold is automatic and correct when built properly: wire the output-advancing registers' enables to HREADY, and the manager holds during waits and advances on completion without special-casing. A manager that did not gate its outputs with HREADY — that advanced its address/data every cycle regardless — would change the transfer mid-wait and corrupt it. So the hardware rule is: gate the manager's transfer-advancing state with HREADY. This is a standard, well-understood manager design pattern.

For write data, the same gating holds HWDATA: the manager's write-data register advances only on HREADY high, so HWDATA stays presented through the waits until the subordinate accepts it. For reads, the gating means the manager's "capture read data" action (loading HRDATA into a destination register) is enabled by HREADY — so it captures the data only on the completing cycle, when it is valid. So both the output hold and the input capture are governed by the same HREADY gating: outputs advance on HREADY high, inputs are captured on HREADY high.

A hardware subtlety: because the manager's state is gated by HREADY, a long wait simply means the manager's pipeline stalls for those cycles — no work is lost, the manager just doesn't advance. This is clean and safe: the manager can be stalled arbitrarily by wait states without any special handling, because its advance is gated by HREADY. The manager is, in effect, paused by HREADY exactly as the subordinate intends. This is the elegance of the clock-enable model — both sides stall together, gated by the same signal.

5. System Architecture Perspective

At the system level, the manager's hold discipline is what makes the bus's stall-everyone behaviour safe — the manager being correctly paused by HREADY is the other half of the shared-stall coupling.

Chapter 6.1/6.2 framed wait states as stalling the whole bus. The manager's hold rule is what makes that stall correct rather than corrupting: when the bus stalls (HREADY low), the manager doesn't just idle — it actively holds its transfer stable so that when the stall ends, the transfer completes correctly. So the manager's discipline is the complement to the subordinate's wait: the subordinate says "wait," and the manager correctly waits, holding everything. Together they make a wait state a clean pause rather than a corruption. The system relies on both sides honoring HREADY.

This hold discipline is uniform across all managers — every AHB manager, simple or complex, follows the same rule (hold outputs, act on HREADY high). This uniformity is what lets any manager work with any subordinate's wait states: the manager doesn't need to know how many wait states a subordinate will insert, only to hold until HREADY high. So the manager's behaviour is decoupled from the subordinate's specific latency — it just waits for completion. This is the same decoupling that lets fast and slow subordinates share the bus (chapter 6.2): the manager adapts to any wait count automatically by gating on HREADY.

The architectural payoff is composability: because every manager holds correctly during waits and every subordinate signals completion via HREADY, any manager and any subordinate interoperate without knowing each other's timing. A new slow subordinate can be added and existing managers handle its wait states correctly, because they already gate on HREADY. So the manager's hold discipline, combined with the subordinate's HREADY signalling, is what makes AHB components composable across speeds — a key reason the protocol scales to diverse systems. The hold rule is not just a manager detail; it is part of what makes the bus's component model work.

6. Engineering Tradeoffs

The manager's hold discipline reflects the gate-on-HREADY design choice.

• Gate-on-HREADY vs free-running outputs. Gating the manager's outputs with HREADY makes it hold correctly during waits, at the cost of the manager being stallable (it cannot force progress). Free-running outputs would never stall but would corrupt transfers during waits. AHB requires gate-on-HREADY — correctness during waits is non-negotiable; the manager must be pausable by the subordinate.
• Hold-and-wait vs abort-and-retry. The manager holds the transfer through arbitrary waits (simple, always-correct). An alternative — aborting after some waits and retrying — would add complexity and is unnecessary for well-behaved subordinates. AHB managers hold-and-wait; aborting is reserved for actual errors (HRESP, chapter 7), not normal waits.
• Uniform discipline vs subordinate-aware managers. Every manager follows the same hold rule regardless of which subordinate it talks to (uniform, composable). A manager that knew each subordinate's latency could in principle optimize, but would be brittle and non-composable. AHB chooses the uniform rule — gate on HREADY, ignore the specific latency.
• Stall-together vs decoupled progress. The manager stalling in lockstep with the subordinate (via shared HREADY) is simple and coherent, at the cost of the manager being unable to do other work during the wait. A decoupled protocol (AXI) lets a manager issue other transactions during a wait, at the cost of complexity. AHB's stall-together is simpler and matches its single-path, in-order nature.

The throughline: the manager gates its transfer-advance on HREADY, holding stable during waits and acting on completion — a uniform, composable discipline that makes wait states safe. The cost is that the manager is fully pausable by the subordinate (it cannot make progress during a wait), accepted because it is exactly what keeps transfers correct and components composable.

7. Industry Example

Trace a manager (a processor) handling subordinates with different wait behaviours.

A processor issues reads and writes to an SRAM (zero-wait), a flash (multi-wait), and a peripheral (occasional waits).

• SRAM read (zero wait, no holding needed). The processor reads SRAM. HREADY is high in the first data cycle — the processor samples the data immediately and advances to the next transfer. No waits, so no holding; the manager just completes and moves on. The hold rule is trivially satisfied (zero wait cycles).
• Flash read (multi-wait, manager holds through the waits). The processor reads flash. Flash inserts several wait states (HREADY low). The processor holds its address and control stable through every wait cycle, does not sample HRDATA during the waits (the data isn't valid), and waits. When HREADY goes high, it samples the now-valid read data and advances. The manager held the transfer frozen until flash completed it — exactly the discipline.
• Peripheral write (manager holds write data through waits). The processor writes a peripheral that is momentarily busy. The peripheral inserts a couple of wait states. The processor holds HADDR, HWRITE, and HWDATA stable through the waits — it does not assume the write was accepted, and does not advance to the next write. When HREADY goes high, the write is accepted and the processor advances. Crucially, it held HWDATA — had it changed the write data mid-wait, the peripheral would have accepted the wrong value.
• The common discipline. In all three cases the processor follows the same rule: hold outputs stable, act only on HREADY high. It doesn't need to know that SRAM is zero-wait and flash is multi-wait — it gates everything on HREADY, so it automatically does the right thing for each. This is why the same processor works with all three subordinates: the hold discipline is subordinate-agnostic.
• A bug avoided. Imagine the processor had a bug where it advanced HWDATA every cycle regardless of HREADY. On the SRAM (zero-wait) it would work by luck. On the flash and peripheral (multi-wait), it would change the write data mid-wait — corrupting writes. The bug would manifest only with wait-inserting subordinates, making it a classic "works on fast memory, fails on slow flash" bug. Gating HWDATA on HREADY prevents it.

The example shows the manager's hold discipline as the universal, subordinate-agnostic rule: hold everything stable, act on HREADY high. It works identically for zero-wait and multi-wait subordinates because it gates on HREADY — and the bug that ignores HREADY shows up exactly when wait states appear.

8. Common Mistakes

9. Interview Insight

The manager's wait-state behaviour is a frequent interview question — it tests whether you understand both sides of the wait-state handshake.

The answer that lands covers both halves: "While HREADY is low, the manager holds all its outputs stable — the address, the control signals, and the write data — and takes no action. It must not change anything, must not sample read data (it isn't valid yet), and must not advance to the next transfer. Only on the cycle HREADY goes high does it act: sample the read data, treat the write as accepted, check the response, and then advance. The transfer is essentially frozen until HREADY high. In hardware, this falls out of gating the manager's output registers and read-capture on HREADY." Mentioning that the most common bug — changing HWDATA during a write wait — corrupts the write, signals real depth.

10. Practice Challenge

Reason from the manager's hold discipline.

1. State the rule. List what the manager must hold stable while HREADY is low, and what it must not do.
2. Read the waveform. From Figure 2, identify what the manager holds across the wait cycles and what happens on the HREADY-high cycle.
3. Explain the read rule. Why does the manager sample read data only on the completing cycle?
4. Diagnose the bug. A manager works on SRAM but corrupts writes to flash. Explain the likely cause in terms of HWDATA and HREADY.
5. Connect to composability. Explain how the uniform gate-on-HREADY discipline lets any manager work with any subordinate's wait states.

11. Key Takeaways

• While HREADY is low, the manager holds all outputs stable — address, control, and write data — and takes no action. The transfer is frozen in place.
• The manager acts only on the HREADY-high cycle — it samples read data, treats the write as accepted, checks the response, and advances only then.
• In hardware, this falls out of gating the manager's output registers and read-capture on HREADY — the standard manager design pattern. The manager is fully pausable by HREADY.
• The cardinal bugs are changing outputs (especially HWDATA) or sampling/acting during a wait — both corrupt the transfer; both are prevented by gating everything on HREADY.
• The discipline is uniform and subordinate-agnostic — the manager need not know the wait count, only to hold until HREADY high.
• This hold discipline, with the subordinate's HREADY signalling, makes AHB components composable across subordinate speeds — any manager works with any subordinate.

12. What Comes Next

You now understand both sides of a wait state — the subordinate inserting it and the manager holding through it. This completes the core wait-state mechanism. The next chapters in this module deepen specific aspects:

• 6.4 onward (coming next) — holding address & control in detail, data-phase extension, the HREADY vs HREADYOUT distinction, and common wait-state bugs.

To revisit the foundation, see What HREADY Means (the pacing signal) and Slave-Inserted Wait States (the subordinate's side). For the data-phase timing this builds on, see Write Transfer Timing and Read Transfer Timing. For the broader protocol map, see the AMBA family overview.