HREADY & HREADYOUT

This chapter covers the distinction that confuses more engineers than any other in AHB: HREADY versus HREADYOUT. You already know HREADY as the signal that gates completion and inserts wait states (chapter 2.4). What you have not yet seen is that in a multi-subordinate system there are really two ready signals: each subordinate's own HREADYOUT output, and the single bus-wide HREADY that the interconnect builds from them and broadcasts to everyone. Getting this distinction right — what each is, how they relate, and why a subordinate needs both — is essential to building a correct AHB subordinate, and it is a classic interview discriminator. This is a Critical chapter; read it carefully.

1. What Is It?

In a multi-subordinate AHB system there are two distinct ready signals:

• HREADYOUT is each subordinate's own output: subordinate A drives HREADYOUT_A, subordinate B drives HREADYOUT_B, and so on. A subordinate asserts its HREADYOUT high to say "I can complete this cycle" or low to insert a wait state on its own access.
• HREADY is the single, bus-wide signal that the manager and every subordinate observe. The interconnect forms it by selecting the currently-addressed subordinate's HREADYOUT (via the multiplexor, using the decoder's selection) and broadcasting that as HREADY to the whole bus.

So the relationship is: the selected subordinate's HREADYOUT becomes the bus-wide HREADY. HREADYOUT is the per-subordinate output (how a subordinate stalls its own access); HREADY is the shared input (the one completion signal everyone watches). A subordinate has both — it drives HREADYOUT and it observes HREADY. Understanding why it needs both is the heart of this chapter.

2. Why Does It Exist?

The two signals exist because a multi-subordinate, pipelined shared bus needs each subordinate to be able to stall independently and one unified completion signal everyone agrees on — and those are two different jobs that need two different signals.

Why HREADYOUT (per-subordinate). Each subordinate runs at its own speed — a fast SRAM completes immediately, a slow peripheral needs wait states. Each must therefore be able to express its own readiness, independently of the others. HREADYOUT is each subordinate's private "am I ready for the access currently aimed at me?" output. Only the subordinate knows whether it can complete its access this cycle, so each needs its own output to say so. If there were only one shared ready signal that subordinates had to drive together, they could not express independent readiness cleanly.

Why HREADY (shared, single). But the manager needs exactly one completion signal — it cannot watch every subordinate's HREADYOUT and figure out which one matters. It needs one wire that says "the current transfer completes this cycle." So the interconnect selects the relevant subordinate's HREADYOUT (the addressed one) and presents it as the single HREADY. This gives the manager one clean signal, and — crucially — it gives every subordinate the same unified view of when the bus advances.

Why a subordinate needs the HREADY input too (the subtle part). Because the bus is pipelined, a subordinate that just sampled an address phase aimed at it must not immediately start its data phase — the previous transfer (possibly to a different subordinate) may still be in its data phase, holding the bus with wait states. The newly-addressed subordinate must wait until the bus actually advances to its data phase, which is signalled by HREADY going high. So a subordinate watches the shared HREADY to know when its sampled access actually becomes the active data phase. Without observing HREADY, a subordinate could not correctly align itself to the pipeline when another subordinate is stalling — it would start its data phase too early.

So the two signals exist because independent per-subordinate stalling (HREADYOUT) and a single unified completion view (HREADY) are both needed, and a subordinate needs both — its output to stall, and the shared input to align with the pipeline. The distinction is not redundancy; it is two genuinely different roles.

3. Mental Model

Model HREADY and HREADYOUT as a row of service windows feeding one shared "now serving" display.

Each service window (subordinate) has its own "I'm ready / one moment please" sign (HREADYOUT) — it controls only its own pace. But customers (the manager) and the windows themselves all watch a single overhead "now serving" display (HREADY), which the system drives from whichever window is currently active. When the active window puts up "one moment" (HREADYOUT low), the overhead display shows "wait" (HREADY low), and everyone — the customer at the counter and the other windows waiting their turn — sees it.

Why does a window watch the overhead display rather than just its own sign? Because of the queue (the pipeline). A window that has just been handed the next customer's ticket cannot start serving until the previous customer (at possibly a different window) is done — and it knows that previous customer is done when the overhead display advances (HREADY high). So each window both drives its own sign and watches the shared display.

Watch the selected subordinate's HREADYOUT becoming the bus HREADY:

The model's lesson: each window has its own sign (HREADYOUT), but everyone watches one overhead display (HREADY) driven by the active window. The selected subordinate's HREADYOUT is the bus HREADY; the others' HREADYOUTs are not currently shown but still exist. And every window watches the display to know when its turn truly starts.

4. Real Hardware Perspective

In hardware, HREADYOUT is a subordinate output and HREADY is an interconnect-driven input that goes to everyone — and wiring this correctly is where subordinate designs commonly go wrong.

A subordinate has HREADYOUT as an output and HREADY as an input. The interconnect contains the read-data and ready multiplexor: driven by the decoder's selection, it picks the addressed subordinate's HREADYOUT (and HRDATA) and drives the bus-wide HREADY (and the read-data bus). That HREADY is then routed to the manager and back to every subordinate as an input. So the physical structure is: subordinates drive HREADYOUT out, the mux selects one, and the result (HREADY) is broadcast to all.

The reason a subordinate needs HREADY as an input is the pipeline alignment from the previous section, and in hardware it works like this: when a subordinate is selected (its HSEL is asserted) in an address phase, it samples the access — but it must use the incoming HREADY to know when the address phase it sampled is actually the one entering the data phase. Specifically, an address phase is only "accepted" into the data phase when HREADY is high; if HREADY is low (a previous transfer is stalling), the address phase persists. So the subordinate qualifies its sampling with HREADY: it acts on an address phase only when HREADY is high, ensuring it starts its data phase at the right cycle even when a different subordinate stalled the bus before it.

This is the classic subtle hardware point: a subordinate that drives only HREADYOUT and ignores the incoming HREADY will misbehave in a multi-subordinate system, because it cannot tell when the bus has actually advanced to its access. It might start its data phase while a previous transfer to another subordinate is still stalling, corrupting the pipeline. The fix — and the rule — is that a subordinate must qualify its address-phase sampling with HREADY: only treat an address phase as accepted (and begin the corresponding data phase) on a cycle where HREADY is high. In a single-subordinate or single-master-trivial system you might get away with ignoring HREADY input, but in any real multi-subordinate system it is mandatory.

5. System Architecture Perspective

At the system level, the HREADY/HREADYOUT split is what lets many independent subordinates of different speeds share one pipelined bus correctly — and it is why the interconnect's ready-multiplexing exists.

Each subordinate being able to drive its own HREADYOUT means subordinates of wildly different speeds coexist cleanly: a single-cycle SRAM holds HREADYOUT high (never stalls), a slow flash holds HREADYOUT low for several cycles per access, and each expresses its own timing without coordinating with the others. The system can mix fast and slow subordinates freely, each pacing only its own accesses. This independence is essential — you cannot build a real subsystem where every subordinate runs at the same speed.

The interconnect's job of selecting the active HREADYOUT into the shared HREADY is the system-level mechanism that turns those independent per-subordinate signals into the single completion signal the manager and pipeline need. This is the same multiplexor that routes HRDATA (chapter 3.7) — ready and read-data are selected together by the same decoder selection. So the ready-multiplexing is part of the interconnect's core routing function, and it is what makes the per-subordinate HREADYOUTs into a coherent bus-wide HREADY.

The requirement that every subordinate observe HREADY is what keeps the whole pipeline coherent across subordinates. Because all subordinates watch the same HREADY, they all agree on when the bus advances, so a transfer to subordinate B correctly waits behind a stalling transfer to subordinate A — the pipeline stays consistent even as it hands off between different subordinates. This shared view is what makes "a slow subordinate stalls the whole bus" (the mental-model rule) actually work mechanically across multiple subordinates: the stall is visible to everyone via the broadcast HREADY.

So the architecture is: independent per-subordinate readiness (HREADYOUT), unified by the interconnect into one bus-wide completion signal (HREADY) that everyone — manager and all subordinates — observes. This is precisely what lets a single pipelined shared bus host many subordinates of different speeds while keeping the pipeline coherent. The split is not an awkward detail; it is the mechanism that makes multi-subordinate AHB work.

6. Engineering Tradeoffs

The HREADY/HREADYOUT design reflects deliberate choices about where readiness lives.

• Per-subordinate HREADYOUT vs a shared driven-by-all ready. Giving each subordinate its own HREADYOUT lets subordinates express independent timing cleanly and be designed in isolation, at the cost of the interconnect needing to multiplex them. A single ready line driven by all subordinates would be simpler wiring but a coordination nightmare (who drives it when?). AHB chooses per-subordinate outputs plus muxing — clean independence at the cost of interconnect logic.
• Broadcasting HREADY to all subordinates vs only to the manager. Routing HREADY back to every subordinate (not just the manager) costs fanout but is what lets each subordinate align to the pipeline. Sending it only to the manager would leave subordinates unable to know when the bus advances, breaking multi-subordinate pipelining. The fanout cost buys pipeline coherence — a necessary trade.
• Subordinate complexity: must watch HREADY vs simpler design. Requiring subordinates to qualify their sampling with HREADY adds a little logic to each subordinate, but it is what makes them composable in a multi-subordinate system. A subordinate that ignored HREADY would be simpler but only work in isolation. AHB requires the HREADY input handling so subordinates compose — a small per-subordinate cost for system-level correctness.
• Two signals vs one. Having both HREADY and HREADYOUT is more conceptual overhead than a single "ready," but it cleanly separates the two roles (per-subordinate stall vs unified completion view). Collapsing them would muddle the roles and break either independence or the unified view. The two-signal design earns its place by keeping the roles distinct.

The through-line: the split puts readiness control at each subordinate (HREADYOUT) while keeping a single unified completion view for everyone (HREADY) — trading interconnect muxing and per-subordinate HREADY-watching logic for clean composition of many independent subordinates on one pipelined bus. It is the mechanism that makes multi-subordinate AHB both flexible and correct.

7. Industry Example

Trace a two-subordinate scenario where the distinction is decisive.

A system has a fast SRAM (subordinate A) and a slow peripheral (subordinate B) on one AHB, and a processor doing back-to-back accesses: first to the slow peripheral B, then to the fast SRAM A.

• Access to B (slow). The processor addresses B. B is slow, so it drives HREADYOUT_B low for a couple of cycles — wait states on its own access. The interconnect, with B selected, drives the bus-wide HREADY low. The processor sees HREADY low and waits; the data phase of the B access is extended.
• A's address phase, sampled but waiting. Meanwhile, the processor presents the next access's address phase, aimed at fast SRAM A. SRAM A's HSEL gets asserted and A samples the address — but here is the crucial part: A must watch HREADY, and HREADY is still low (B is stalling). So A must not start its data phase yet, even though A itself is fast and ready. A waits for HREADY to go high.
• B completes, HREADY rises, A proceeds. When B finally drives HREADYOUT_B high, HREADY goes high. Now A, seeing HREADY high, knows the bus has advanced and its sampled access is entering the data phase — and A completes immediately (it is fast, HREADYOUT_A high). The accesses happened in the correct pipelined order despite B's stall.
• What goes wrong without the HREADY input. Suppose SRAM A ignored HREADY and started its data phase as soon as it was selected, while B was still stalling. A would drive its read data and "complete" while the bus was still mid-B-transfer — corrupting the pipeline, returning A's data at the wrong time, and breaking the processor's view of the ordered transfers. This is exactly the canonical bug: A works fine alone but breaks next to a slow B, because it ignored the shared HREADY.

The scenario shows both signals doing their jobs: HREADYOUT_B let B stall its own access; the broadcast HREADY let fast A correctly wait for the bus to advance before starting. The distinction is not academic — it is what makes a fast and a slow subordinate coexist correctly on one pipelined bus.

8. Common Mistakes

9. Interview Insight

HREADY versus HREADYOUT is one of the strongest AHB interview discriminators — it separates people who have built subordinates from those who have only read the spec.

The answer that lands names both roles and the subtle point: "HREADYOUT is each subordinate's own ready output — how it inserts wait states on its own access. HREADY is the single bus-wide signal: the interconnect selects the addressed subordinate's HREADYOUT and broadcasts it as HREADY to the manager and all subordinates. A subordinate has both — it drives HREADYOUT to stall, and it watches HREADY to know when its sampled access actually enters the data phase, because a previous transfer to another subordinate might still be stalling the bus." That last sentence — why a subordinate needs the HREADY input — is the senior discriminator.

10. Practice Challenge

Reason from the per-subordinate-output vs shared-input split.

1. Define both. State what HREADYOUT and HREADY each are and their scope (per-subordinate vs bus-wide).
2. Trace the formation. Explain how the bus-wide HREADY is formed from subordinates' HREADYOUTs and who observes it.
3. Justify the input. In three sentences, explain why a subordinate must watch HREADY and not just drive HREADYOUT.
4. State the rule. Give the rule about when a subordinate may accept an address phase, in terms of HREADY.
5. Diagnose the integration bug. A subordinate works standalone but corrupts next to a slow peer. Name the cause, the fix, and why standalone tests miss it.

11. Key Takeaways

• HREADYOUT is each subordinate's own ready output; HREADY is the single bus-wide signal the interconnect forms by selecting the addressed subordinate's HREADYOUT and broadcasting it to the manager and all subordinates.
• The selected subordinate's HREADYOUT becomes the bus HREADY — same multiplexor that routes read data, driven by the decoder's selection.
• A subordinate has both: it drives HREADYOUT to stall its own access, and watches HREADY to track when the bus advances. Output to stall, input to track.
• A subordinate must observe HREADY because of pipelining — it must only accept its address phase when HREADY is high, so it does not start its data phase while a previous transfer (to another subordinate) is still stalling.
• Every subordinate watches HREADY, not just the manager — this shared view keeps multi-subordinate pipelining coherent and makes "a slow subordinate stalls everyone" work mechanically.
• The canonical multi-subordinate bug is a subordinate that ignores the HREADY input — it works standalone but corrupts next to a slow peer. The fix is qualifying address-phase acceptance with HREADY.

12. What Comes Next

You now understand the most subtle handshake distinction in AHB. The remaining signals cover the response and the selection:

• 3.9 — HRESP (coming next) — the response signal (OKAY/ERROR) and the two-cycle error protocol.
• 3.10 — HSEL (coming soon) — the decoder-driven subordinate select that this chapter's HREADYOUT multiplexing depends on.

To revisit the completion gating these signals implement, see The Data Phase; for the multiplexor that forms HREADY, see AHB Bus Architecture and HWDATA & HRDATA. For the broader protocol map, see the AMBA family overview.