AMBA AHB · Module 6

HREADY vs HREADYOUT

Why AHB has two ready signals — HREADYOUT, each subordinate's own readiness output, and HREADY, the single bus-wide signal the interconnect muxes from the data-phase subordinate's HREADYOUT and feeds back to everyone.

Throughout Module 6 we have spoken of "the subordinate driving HREADY low." That was a useful simplification; this chapter makes it precise. AHB actually has two ready signals. Each subordinate drives HREADYOUT — its own readiness output. The interconnect selects the HREADYOUT of whichever subordinate is currently in its data phase and feeds it back as the single bus-wide HREADY, which the manager and every subordinate observe as an input. So a subordinate both drives HREADYOUT and watches HREADY. Understanding why there are two signals — and how the interconnect aggregates one into the other — is the final piece of how HREADY actually works, and a classic interview discriminator.

1. What Is It?

There are two distinct signals:

HREADYOUT — a per-subordinate output. Each subordinate drives its own HREADYOUT to signal its own readiness: high when it can complete its transfer, low to insert wait states.
HREADY — the single bus-wide signal. The interconnect produces it by selecting the HREADYOUT of whichever subordinate is currently in its data phase, and feeds it back to the manager and every subordinate, which observe it as an input.

Figure 1 — HREADYOUT (per subordinate) is aggregated into HREADY (bus-wide). Each subordinate drives its own HREADYOUT. The interconnect multiplexer selects the HREADYOUT of the subordinate currently in its data phase and drives it out as the single bus-wide HREADY, which fans back to the manager and every subordinate (where it is an input). The mux select is the subordinate in the data phase — a registered version of the address-phase decode.

So the relationship is: HREADY = the HREADYOUT of the subordinate currently in its data phase, selected and rebroadcast by the interconnect. When we said "the subordinate drives HREADY low," precisely it means: the data-phase subordinate drives its HREADYOUT low, and the interconnect (having selected that subordinate) passes it through as the bus-wide HREADY. The two signals are the per-subordinate readiness (HREADYOUT) and the bus-wide aggregate (HREADY).

2. Why Does It Exist?

The two-signal split exists because a subordinate has two different needs around readiness: it must drive its own readiness (so the bus can pace its transfer), and it must observe the bus-wide pace (so it can align its access to the pipeline). One signal cannot serve both directions.

Consider the subordinate's situation. On one hand, it must tell the bus when it is ready — that is an output it drives (HREADYOUT), so the bus can insert wait states for it. On the other hand, it must know when the bus advances — that is an input it observes (HREADY), because the bus's advance depends on whichever subordinate is currently responding, which may not be this one (the pipeline overlaps transfers across subordinates). So the subordinate needs both an output (its own readiness) and an input (the bus's pace). Two needs, two directions, two signals. HREADYOUT and HREADY exist because readiness has both a "what I signal" and a "what I observe" side for each subordinate.

The reason the bus-wide HREADY must be aggregated by the interconnect (rather than just being one subordinate's wire) is that which subordinate's readiness matters changes every transfer — it is whichever subordinate is currently in its data phase. The interconnect knows which subordinate that is (it did the address decode), so it is the natural place to select that subordinate's HREADYOUT and broadcast it as HREADY. So the interconnect aggregates because it is the component that knows the current data-phase subordinate and can mux accordingly. A subordinate cannot do this itself — it does not know whether it is the current data-phase responder relative to all others; only the interconnect has the global view.

The reason every participant receives HREADY (not just the manager) is the pipeline-alignment need (chapters 3.8, 4.7): a subordinate must know when the bus advances so it can correctly time its own address-phase sampling and data-phase response relative to the shared pipeline. Even a subordinate not currently responding needs HREADY to know when the current transfer completes, so it knows when its turn (its data phase) begins. So HREADY fans out to all subordinates because all of them must stay aligned to the one shared pipeline — which requires seeing the one shared completion signal. This is why HREADY is a bus-wide input everywhere, and HREADYOUT a per-subordinate output.

3. Mental Model

Model HREADYOUT and HREADY as each chef in a kitchen calling out "ready!" for their own dish (HREADYOUT), while the expediter announces the one dish the whole line is currently waiting on (HREADY).

In a kitchen (the bus), each chef (subordinate) works on dishes and calls "ready!" when their current dish is done — that is their own output (HREADYOUT). But the line moves at the pace of the one dish currently being plated (the data-phase subordinate). The expediter (the interconnect) knows which dish that is, listens to that chef's "ready!", and announces to the whole kitchen "we're waiting on table 5" or "table 5 is up — move!" — that one announcement is what everyone listens to (HREADY). Every chef listens to the expediter (HREADY input) to know when the line advances, even while calling out their own "ready!" (HREADYOUT output) for their own dishes.

This captures the split: each chef's own "ready!" = HREADYOUT (per-subordinate output); the expediter's single announcement, picking the relevant chef's call = HREADY (bus-wide, interconnect-aggregated); and everyone listening to the expediter = HREADY fanned out as an input to all. The expediter selecting which chef's call to broadcast is the interconnect muxing the data-phase subordinate's HREADYOUT.

Watch HREADY track the selected subordinate's HREADYOUT:

HREADY mirrors the selected (data-phase) subordinate's HREADYOUT

4 cycles

Figure 2 — HREADY follows the data-phase subordinate's HREADYOUT. In the data phase of a transfer to subordinate A, HREADY tracks HREADYOUT_A (A inserts one wait, so HREADYOUT_A is low then high — and HREADY matches). Subordinate B's HREADYOUT is high throughout but is not selected (B is not in its data phase), so it does not affect HREADY. The interconnect mux passes only the data-phase subordinate's HREADYOUT to HREADY.

The model's lesson: HREADY is the expediter broadcasting the one relevant chef's call — it tracks the data-phase subordinate's HREADYOUT and ignores the others. In the waveform, HREADY mirrors HREADYOUT_A (the selected subordinate) and is unaffected by HREADYOUT_B (not selected).

4. Real Hardware Perspective

In hardware, the interconnect implements HREADY as a multiplexer over the subordinates' HREADYOUT signals, selected by the subordinate currently in its data phase — which, because of the pipeline, is a registered version of the address-phase select.

The mechanism: each subordinate has an HREADYOUT output wired into the interconnect. The interconnect has a mux that selects one HREADYOUT to drive HREADY. The select is "which subordinate is in its data phase right now." Because the data phase follows the address phase by one cycle (chapter 5.2), the data-phase subordinate is the one that was address-selected in the previous cycle — so the interconnect registers the address-phase decode (HSEL) to know the data-phase subordinate. So the HREADY mux select is a one-cycle-delayed (registered) version of the address decode. This registered-select is a subtle but important hardware detail: the interconnect must track the data-phase subordinate, not the address-phase one, to mux HREADY correctly.

The default subordinate participates too (chapter 3.10): when the address decodes to no real subordinate (an unmapped address), the default subordinate is selected, and its HREADYOUT feeds HREADY (typically completing with an error response, chapter 7). So the mux includes the default subordinate's HREADYOUT as one of its inputs, selected when no real subordinate matches. This ensures HREADY is always driven — even for unmapped addresses — so the bus never hangs on a missing subordinate. The default subordinate's HREADYOUT is part of the aggregation.

The fanout is the other half: the muxed HREADY is broadcast back to the manager and every subordinate as an input (chapter 6.1's bus-wide observation). So in hardware, HREADY is a mux output with high fanout — one signal computed by the interconnect and distributed everywhere. This is why HREADY's timing matters for frequency (chapter 6.1): the path from each HREADYOUT through the mux to all the HREADY inputs must settle in a cycle. Interconnect designers optimize this path because it gates the whole bus's advance.

A subtle but important hardware point about the input HREADY to a subordinate: a subordinate uses the incoming HREADY to qualify its own pipeline timing — specifically, it samples the address phase only when the incoming HREADY was high (chapters 3.8, 4.7), because that is when the previous transfer completed and this transfer's address phase is the current one. So a subordinate's HREADYOUT (its output) and its HREADY (its input) play different roles: HREADYOUT paces its transfer's completion; the incoming HREADY tells it when the bus advances so it samples and responds at the right cycles. Conflating the two — using HREADYOUT where HREADY is needed, or vice versa — is a real subordinate design bug.

Figure 3 — a subordinate has both ready signals. It drives HREADYOUT (an output — its own readiness, low to insert wait states) and it receives HREADY (an input — the bus-wide pace). HREADYOUT paces its own transfer; the incoming HREADY tells it when the bus advances, so it can align its data-phase access to the pipeline. Two signals, two directions, two purposes.

5. System Architecture Perspective

At the system level, the HREADYOUT-to-HREADY aggregation is a core interconnect responsibility — it is where the bus's pacing is centralized — and it is what makes adding subordinates modular.

The aggregation centralizes pacing in the interconnect: the interconnect is the one component that collects all subordinates' HREADYOUT and produces the single bus-wide HREADY. So the bus's pace is determined in one place, from the readiness of whichever subordinate is responding. This centralization is why the interconnect is the heart of bus timing (chapter 3.11): it not only routes address and data but also aggregates readiness into the pacing signal. An architect designing or selecting an interconnect must ensure this aggregation is correct (right select, default included) and fast (the HREADY path), because it governs the whole bus.

The split makes adding subordinates modular: a new subordinate just drives its own HREADYOUT and receives HREADY, exactly like every other subordinate — the interconnect's mux incorporates it. So a subordinate is designed against the simple local contract (drive HREADYOUT, observe HREADY) without knowing the global aggregation. This is the same composability theme as chapter 6.3: each subordinate honors a local readiness contract, and the interconnect handles the global aggregation. So the two-signal design is what lets subordinates be designed independently and dropped into any system — the interconnect adapts. This modularity is a key architectural benefit of separating HREADYOUT (local) from HREADY (global).

The aggregation also defines the default-subordinate behaviour that keeps the system robust (chapter 3.10): because the interconnect includes the default subordinate's HREADYOUT and selects it for unmapped addresses, an access to a nonexistent subordinate still gets a driven HREADY (completing, usually with an error) rather than hanging the bus. So the aggregation is where the system's "no hang on bad address" guarantee is implemented — the interconnect always has some HREADYOUT to select. This robustness is an architectural property delivered by the aggregation design: the bus-wide HREADY is always sourced, so the bus always makes progress.

6. Engineering Tradeoffs

The two-signal split reflects AHB's centralized-aggregation design.

Two signals (HREADYOUT + HREADY) vs one. Splitting readiness into a per-subordinate output and a bus-wide input cleanly serves the subordinate's two needs (drive its own, observe the bus) at the cost of two signals and an aggregating mux. A single signal cannot be both a per-subordinate output and a bus-wide input. AHB uses two — clarity and correctness over signal count.
Centralized aggregation vs distributed. Having the interconnect mux all HREADYOUT into HREADY centralizes pacing (one place, modular subordinates) at the cost of a central mux on the critical path. A distributed scheme would be more complex and harder to make coherent. AHB centralizes — simplicity and modularity.
Registered (data-phase) select vs address-phase select. Selecting the mux on the registered data-phase decode is correct (the data-phase subordinate is who's responding) but requires the interconnect to register the decode. Using the address-phase select directly would be simpler but wrong (off by one phase). AHB requires the correct registered select — correctness is non-negotiable.
Including the default subordinate vs not. Including the default subordinate's HREADYOUT in the mux guarantees HREADY is always driven (no hang on bad address) at a small cost (one more mux input + the default subordinate). Omitting it would risk a hung bus on unmapped accesses. AHB includes it — robustness is worth the small cost.

The throughline: AHB splits readiness into per-subordinate HREADYOUT and bus-wide HREADY, aggregated by the interconnect with a registered data-phase select and a default-subordinate input. The cost is two signals and a central mux on the critical path; the benefits are clear semantics (each subordinate drives its own, observes the bus), modular subordinate design, and a robust always-driven HREADY — well worth it.

The classic confusion: which signal, and which subordinate's, becomes HREADY

Two related confusions trip people up. First, conflating HREADYOUT and HREADY: they are different signals with different directions — HREADYOUT is each subordinate's output (its own readiness), HREADY is the bus-wide input everyone observes. A subordinate drives the former and watches the latter; mixing them up is a real design bug (e.g., a subordinate timing its response off its own HREADYOUT instead of the incoming HREADY). Second, which subordinate's HREADYOUT becomes HREADY: it is the one currently in its data phase, not its address phase — and because the data phase trails the address phase by one cycle, the interconnect selects on a registered version of the decode. A common interconnect bug is muxing HREADY on the address-phase select (off by one phase), which pairs the wrong subordinate's readiness with the transfer. When reasoning about HREADY, always ask: whose HREADYOUT, and is it the data-phase (registered) selection? Getting both right is the crux of correct pacing.

7. Industry Example

Trace HREADYOUT and HREADY through an interconnect with several subordinates.

A system has an SRAM, a flash, and a peripheral behind an interconnect; a processor accesses them.

Each subordinate drives its own HREADYOUT. The SRAM drives HREADYOUT_SRAM (high — it's fast), the flash drives HREADYOUT_flash (low during its multi-cycle access), the peripheral drives HREADYOUT_periph. Each reflects only that subordinate's own readiness, regardless of what the others are doing.
The interconnect muxes the data-phase subordinate's HREADYOUT. When the processor reads flash, the flash is the data-phase subordinate, so the interconnect selects HREADYOUT_flash as the bus-wide HREADY. While flash holds HREADYOUT_flash low (inserting waits), HREADY is low — the whole bus waits. The SRAM's and peripheral's HREADYOUT (both high) are not selected, so they don't affect HREADY. Only the responding subordinate's readiness matters.
The registered select. The flash became the data-phase subordinate one cycle after it was the address-phase (decoded) subordinate. The interconnect registered the decode so that, in the data phase, it muxes HREADYOUT_flash. If the interconnect had (buggily) muxed on the address-phase select, it might pair the wrong subordinate's HREADYOUT with the flash's data phase — a classic off-by-one-phase interconnect bug.
Everyone observes HREADY. The muxed HREADY (low during flash's waits) fans back to the processor (which holds its transfer) and to all subordinates — including the SRAM and peripheral — so they all stay aligned to the pipeline and know the bus is paused. Even the idle SRAM sees HREADY low and knows the current transfer hasn't completed.
An unmapped access. If the processor accessed an unmapped address, the interconnect selects the default subordinate, whose HREADYOUT drives HREADY (completing with an error). So even a bad address gets a driven HREADY — the bus doesn't hang. The aggregation always has a subordinate (real or default) to select.

The example shows the split in action: each subordinate drives its own HREADYOUT (local readiness), the interconnect selects the data-phase subordinate's HREADYOUT (via a registered decode) as the bus-wide HREADY, everyone observes HREADY (staying aligned), and the default subordinate ensures HREADY is always driven. The pacing is centralized in the interconnect, subordinates are modular, and the bus is robust to bad addresses — all from the two-signal aggregation.

8. Common Mistakes

HREADY/HREADYOUT mistakes

"HREADY and HREADYOUT are the same signal." No — HREADYOUT is each subordinate's output (its own readiness); HREADY is the bus-wide input the interconnect muxes and everyone observes. Different signals, different directions.
"Each subordinate drives the bus-wide HREADY directly." No — each drives its own HREADYOUT; the interconnect selects the data-phase subordinate's HREADYOUT to form HREADY. No single subordinate owns HREADY.
"The interconnect muxes HREADY on the address-phase select." No — it muxes on the data-phase subordinate, which is a registered (one-cycle-delayed) version of the address decode. Using the address-phase select is an off-by-one-phase bug.
"A subordinate times its response off its own HREADYOUT." No — it qualifies its pipeline timing off the incoming HREADY (when the bus advances), and drives HREADYOUT to pace its own completion. Two roles, two signals.
"Only the manager observes HREADY." No — every subordinate observes it too, to stay aligned to the shared pipeline (know when the current transfer completes and its own turn comes).
"Unmapped addresses have no HREADY source." No — the default subordinate's HREADYOUT feeds HREADY for unmapped addresses, so the bus completes (with an error) rather than hanging.

9. Interview Insight

HREADY vs HREADYOUT is a classic AHB interview discriminator — it separates those who memorized "the slave drives HREADY" from those who understand the aggregation.

Figure 4 — a strong answer in one card: HREADYOUT is each subordinate's own readiness output; the interconnect muxes the HREADYOUT of the subordinate in its data phase to produce the bus-wide HREADY, which everyone observes as an input. The two exist because a subordinate must both drive its readiness and watch the bus pace. The senior point: the mux selects the data-phase subordinate — a registered version of the address-phase select.

The answer that lands distinguishes the signals and explains the aggregation: "They're two signals. HREADYOUT is each subordinate's own readiness output — it drives HREADYOUT low to insert wait states for its transfer. HREADY is the single bus-wide signal that the interconnect produces by selecting the HREADYOUT of whichever subordinate is currently in its data phase, and it feeds HREADY back to the manager and every subordinate as an input. So when we casually say 'the slave drives HREADY,' precisely it means the data-phase subordinate drives its HREADYOUT and the interconnect muxes it through. They exist as two signals because a subordinate has two needs: drive its own readiness (output) and observe the bus's pace (input). And the mux select is the data-phase subordinate — a registered version of the address-phase decode, since the data phase trails by a cycle." The registered-select detail and the two-needs reasoning are the senior signals.

🔍 The discriminator: the interconnect muxes the data-phase (registered) subordinate's HREADYOUT

This topic cleanly separates depth levels. A junior answer says "the slave drives HREADY." A mid-level answer distinguishes the two signals: "HREADYOUT is the slave's output; HREADY is the bus-wide version." A senior answer adds the aggregation mechanics: "the interconnect muxes the subordinates' HREADYOUT onto HREADY, selecting the subordinate currently in its data phase — which is a registered version of the address-phase decode, since the data phase trails the address phase by a cycle — and the default subordinate is included so HREADY is always driven even on unmapped addresses." The flourish is explaining why two signals (a subordinate must both drive its own readiness and observe the bus pace) and the architectural payoff (subordinates stay modular — drive HREADYOUT, observe HREADY — while the interconnect centralizes the pacing). A candidate who explains the registered data-phase select and the default-subordinate inclusion demonstrates they understand how HREADY is actually built, not just its name — exactly the interconnect-level depth that distinguishes a strong AHB answer.

10. Practice Challenge

Reason from the two-signal aggregation.

Distinguish the signals. State what HREADYOUT and HREADY each are, including direction (output vs input) and scope (per-subordinate vs bus-wide).
Explain the aggregation. Describe how the interconnect produces HREADY from the subordinates' HREADYOUT.
Read the waveform. From Figure 2, explain why HREADY follows HREADYOUT_A and ignores HREADYOUT_B.
The registered select. Explain why the mux selects on the data-phase (registered) subordinate, not the address-phase one, and what bug arises otherwise.
Robustness. Explain how the default subordinate keeps HREADY always driven on an unmapped access.

11. Key Takeaways

HREADYOUT is a per-subordinate output — each subordinate's own readiness (drive low to insert wait states). HREADY is the single bus-wide input the interconnect produces and everyone observes.
HREADY = the HREADYOUT of the data-phase subordinate, selected and rebroadcast by the interconnect. No single subordinate owns HREADY.
Two signals exist because a subordinate has two needs: drive its own readiness (output) and observe the bus-wide pace (input) to stay aligned to the pipeline.
The mux select is the data-phase subordinate — a registered version of the address-phase decode (the data phase trails by a cycle). Muxing on the address-phase select is an off-by-one-phase bug.
The default subordinate's HREADYOUT is included in the mux, so HREADY is always driven (no hang on unmapped addresses).
The split makes subordinates modular (local HREADYOUT/HREADY contract) and the bus robust (always-driven HREADY) — with pacing centralized in the interconnect.

12. What Comes Next

You now know how HREADY is actually sourced. The final chapter of this module catalogues what goes wrong:

6.7 — Common Wait-State Bugs (coming next) — the recurring HREADY/HREADYOUT mistakes (stuck low, dropped hold, glitching, off-by-one select) and their waveform signatures.

To revisit the foundations, see What HREADY Means, HREADY & HREADYOUT (the earlier introduction), and Master Behavior During Wait. For the interconnect that does the aggregation, see Master, Slave, Decoder & Arbiter and HSEL. For the broader protocol map, see the AMBA family overview.