What HREADY Means

This opens Module 6 — HREADY and Wait States, which examines in full the signal that paces the entire AHB bus. You have met HREADY repeatedly — as the data-phase completion gate (2.4), the pipeline-advance enable (2.5), and the shared completion signal (3.8). This module treats it as the subject in its own right: what HREADY means, how subordinates use it to insert wait states, what the master must do while it is low, and the HREADY/HREADYOUT split. This first chapter pins down the meaning: HREADY is the single, bus-wide signal that paces every transfer — high advances, low holds — and every participant observes it. It is, in effect, the bus's clock-enable. Get this crisp and the rest of the module follows.

1. What Is It?

HREADY is the single bus-wide signal that paces every AHB transfer. Its two states have precise, bus-wide meaning:

• HREADY high — the current transfer completes this cycle, and the pipeline advances one step. The data beat transfers, and the next transfer can proceed.
• HREADY low — everything holds. The current transfer's data phase is extended (a wait state), the pipeline is frozen, and the next transfer is delayed.

HREADY is best understood as the bus's clock-enable: the bus has a clock (HCLK), but HREADY decides whether the pipeline advances on each clock edge. High → advance (the bus "ticks"); low → freeze (the bus "holds"). So while HCLK provides the rhythm, HREADY provides the enable — the bus moves forward only on cycles where HREADY is high. This is why HREADY paces everything: it is the gate that decides, every cycle, whether the bus does work or stands still.

2. Why Does It Exist?

HREADY exists because subordinates run at different speeds, and the bus needs a way to pace transfers to the speed of the responding subordinate while keeping every participant synchronized.

Consider the problem. A fast SRAM completes a transfer in one cycle; a slow flash or peripheral needs several. The bus cannot run at a fixed one-cycle-per-transfer rate, because that would exclude slow subordinates; nor can it run at the slowest subordinate's rate always, because that would waste the fast ones. So the bus needs a way to adapt the pace per transfer to whichever subordinate is responding. HREADY is that mechanism: when the responding subordinate can complete this cycle, HREADY is high (advance); when it needs more time, HREADY is low (hold). So HREADY exists to let the bus pace each transfer to the responding subordinate's speed — fast subordinates complete in one cycle, slow ones extend via wait states, all on the same bus.

The reason HREADY is bus-wide (one signal everyone observes, not per-subordinate-private) is that the whole pipeline must stay coherent — every participant must agree on when the bus advances. Recall from chapter 3.8 that the pipeline overlaps transfers across subordinates, so when one subordinate stalls, the whole bus must hold (the next transfer cannot advance into a bus that is still completing the current one). For that to work, the manager and all subordinates must see the same "is the bus advancing?" signal — which is the single bus-wide HREADY. If each subordinate had a private ready signal with no shared view, they could not stay aligned to the pipeline. So HREADY is bus-wide to keep the pipeline coherent across all participants — everyone advances together, on the cycles HREADY is high.

So HREADY exists to pace transfers to the responding subordinate's speed (the per-transfer adaptation), and it is bus-wide to keep the pipeline coherent (everyone advances together). These two purposes — adaptive pacing and bus-wide coherence — are why HREADY is the single most important pacing signal in AHB, and why it is rated Critical.

3. Mental Model

Model HREADY as the conductor's beat that the whole orchestra follows — and the conductor holds the beat when a section needs more time.

An orchestra (the bus) plays to the conductor's beat (HREADY). On each beat the conductor gives (HREADY high), the whole orchestra advances to the next note together — coherent, synchronized. But if a section needs more time on the current passage (a slow subordinate), the conductor holds the beat (HREADY low) — and the entire orchestra waits, holding their current notes, until the conductor gives the next beat. Nobody advances ahead; everyone moves together when the beat comes. The conductor's beat paces the whole ensemble, and holding it pauses everyone in unison.

This captures HREADY's two roles: the beat paces the bus (every transfer advances on a beat — HREADY high), and holding the beat synchronizes the pause (the whole bus holds together — HREADY low). The single shared beat is what keeps the ensemble coherent; if each musician followed their own beat, the music would fall apart — just as the pipeline would, without a single shared HREADY.

Watch HREADY pacing transfers, with a hold:

The model's lesson: HREADY is the conductor's beat — the whole bus advances on it and holds together when it is held. In the waveform, the bus advances on the HREADY-high cycles and freezes on the HREADY-low cycle (T2 — the data held, the next address C held). One shared beat paces everyone; holding it pauses everyone.

4. Real Hardware Perspective

In hardware, HREADY is a control signal that gates the advance of the bus's pipeline registers, and it is sourced from the responding subordinate (the detail of chapter 3.8 / 6.6).

HREADY functions as an enable on the pipeline's advance: the bus's state (the current transfer's progress, the next transfer's address phase) advances on a clock edge only when HREADY is high. When HREADY is low, the pipeline registers hold their values — the current transfer's data phase is not completed, and the next transfer's address phase is not consumed. So in hardware, HREADY is wired as the clock-enable (or the hold condition) for the bus's pipeline state. This is exactly why "HREADY high → advance, low → hold" — it is the literal enable on the registers that carry the pipeline.

The source of HREADY is the responding subordinate (chapters 3.8, 6.6, covered fully in 6.6): the currently-selected subordinate drives its readiness (HREADYOUT), and the interconnect feeds that back as the bus-wide HREADY. So the subordinate that is responding controls HREADY — it asserts high when it can complete, low when it needs to wait. This chapter establishes HREADY's meaning (the bus-wide pacing signal); chapter 6.6 details its sourcing (HREADYOUT → HREADY). For now, the key hardware fact is that HREADY is driven by whichever subordinate is responding, and it gates the whole bus.

The bus-wide fanout is a hardware reality: HREADY goes to the manager and every subordinate (chapter 3.8). So it is a high-fanout signal, observed everywhere, which is what makes the pipeline coherent — all participants gate their advance on the same HREADY. A subordinate uses the incoming HREADY to know when the bus advances (to align its access to the pipeline, the qualification rule of 3.8/4.7); the manager uses it to know when its transfer completes. So HREADY's hardware role is dual: it is driven by the responding subordinate and observed by everyone, gating the whole pipeline's advance.

A hardware consequence worth flagging: because HREADY gates the advance of the entire bus, it is on the critical timing path in a sense — the determination of HREADY (from the subordinate's readiness through the interconnect) must settle within the cycle so the pipeline can correctly advance or hold on the next edge. So HREADY's timing matters for the bus's achievable frequency, which is part of why interconnects are designed to compute HREADY quickly (the HREADYOUT-to-HREADY path, chapter 6.6).

5. System Architecture Perspective

At the system level, HREADY is the mechanism that lets a single bus host subordinates of wildly different speeds while staying coherent — and its behaviour is the primary determinant of bus throughput.

The system benefit is mixed-speed coexistence: a fast SRAM, a slow flash, and a medium peripheral can all live on one AHB, each pacing its own transfers via HREADY. The fast SRAM asserts HREADY high immediately (one-cycle transfers); the slow flash holds HREADY low for several cycles (wait states); the bus adapts per transfer. So HREADY is what makes a heterogeneous-speed subsystem possible on a single bus — without it, the bus could not accommodate the range of subordinate speeds real systems have. This is a core architectural enabler: the bus's ability to host any subordinate speed rests on HREADY's adaptive pacing.

HREADY behaviour is also the primary throughput determinant (chapter 4.6). Bus throughput is, fundamentally, how often HREADY is high (the bus advancing) versus low (holding). A subsystem where HREADY is high most cycles (fast subordinates, few waits) runs at near-peak throughput; one where HREADY is frequently low (slow subordinates inserting many wait states) runs slower. So when an engineer profiles AHB throughput, they are largely measuring HREADY's high/low ratio — and optimizing throughput means reducing the HREADY-low cycles (faster subordinates, or bridging slow ones). HREADY is thus the signal through which the system's performance is both measured and tuned.

The bus-wide coherence that HREADY provides has a system-level cost, the familiar one: because the whole bus holds when HREADY is low, a slow subordinate's wait states stall every participant (chapter 2.4 / 3.8) — the "slow slave stalls everyone" rule, which is HREADY going low for the whole bus. So at the system level, HREADY's coherence (everyone advances together) is also the coupling (everyone waits together). This is why slow subordinates are architecturally isolated (bridged to APB) — to keep their HREADY-low cycles off the high-performance bus. So HREADY is simultaneously the enabler of mixed-speed coexistence, the determinant of throughput, and the mechanism of the shared-stall coupling — the central pacing signal whose behaviour shapes the whole system's timing.

6. Engineering Tradeoffs

HREADY's design embodies the bus-wide-pacing choice.

• Bus-wide HREADY vs per-subordinate ready. A single bus-wide HREADY keeps the whole pipeline coherent (everyone advances together) at the cost of coupling (everyone holds when one subordinate stalls). Per-subordinate ready signals with no shared view would decouple them but break the pipeline's coherence (no agreement on when the bus advances). AHB chooses the bus-wide signal — coherence is essential for the pipeline, and the coupling is managed by isolating slow subordinates.
• Adaptive pacing (HREADY) vs fixed timing. Letting HREADY pace each transfer to the subordinate's speed accommodates any subordinate, at the cost of variable transfer timing (a transfer takes as long as HREADY-high takes to arrive). Fixed timing would be simpler to reason about but could not host slow subordinates. AHB chooses adaptive pacing — flexibility to host any subordinate is worth the variable timing.
• Clock-enable model vs handshake-per-signal. Using a single HREADY as the bus's clock-enable is simple and uniform — one signal gates everything. A more complex per-signal handshake (like a fully decoupled protocol) would allow more concurrency but be far more complex. AHB chooses the simple single-enable model, consistent with its in-order, single-path simplicity (chapter 5.6).
• Shared completion vs independent completion. A shared HREADY means all participants complete the current transfer together; independent completion (different transfers finishing at different times) is what a concurrent protocol like AXI provides, at the cost of complexity. AHB's shared completion is simpler and matches its in-order nature.

The throughline: HREADY is a single, bus-wide, adaptive clock-enable — it paces each transfer to the responding subordinate's speed while keeping the whole pipeline coherent. The tradeoff is the shared-stall coupling (everyone holds together), accepted for the coherence and simplicity it provides, and managed by isolating slow subordinates. This is the central design choice of AHB's timing, and it is why HREADY is so important.

7. Industry Example

Trace HREADY pacing a subsystem with mixed-speed subordinates.

A microcontroller has a fast SRAM, a slow flash, and a medium peripheral on one AHB, with a processor accessing all three.

• A fast SRAM access (HREADY high immediately). The processor reads SRAM. The SRAM can complete in one cycle, so it asserts HREADY high in the data phase — the transfer completes immediately, the pipeline advances, the processor gets its data with no wait. HREADY high paces this at one transfer per cycle.
• A slow flash access (HREADY low for several cycles). The processor reads flash. Flash is slow, so it holds HREADY low for several cycles (wait states) while it produces the data; the whole bus holds during those cycles (the processor waits, and any pending next transfer is delayed). When flash is ready, it asserts HREADY high and the transfer completes. HREADY low paced this transfer to flash's slower speed — and stalled the bus for it.
• Mixed-speed coexistence. All three subordinates coexist on one bus precisely because HREADY adapts per transfer: SRAM's transfers complete in one cycle (HREADY high), flash's take several (HREADY low then high), the peripheral's somewhere between. The bus does not run at a fixed rate; HREADY paces each transfer to its subordinate. This is HREADY enabling the heterogeneous subsystem.
• The throughput picture. If the processor reads SRAM mostly (HREADY high most cycles), throughput is near peak. If it reads flash frequently (HREADY low often), throughput drops — the flash's wait states are the HREADY-low cycles eating throughput. So the subsystem's throughput is the HREADY high/low ratio, determined by which subordinates are accessed and how often they wait. Reading HREADY tells you the throughput story.
• The coupling consequence. When flash holds HREADY low, the whole bus stalls — including any DMA engine that wanted the bus. This is the shared-stall coupling: HREADY low freezes everyone. It is why flash (and other slow devices) are often bridged to APB — to keep their HREADY-low cycles off the high-performance backbone. So HREADY's behaviour drives the architectural decision to isolate slow subordinates.

The subsystem shows HREADY's roles: pacing each transfer to its subordinate (fast SRAM one cycle, slow flash several), determining throughput (the high/low ratio), and coupling the bus (everyone holds when HREADY is low). HREADY is the heartbeat that makes the mixed-speed bus work — and whose low cycles are the cost.

8. Common Mistakes

9. Interview Insight

HREADY's meaning is a frequent and important interview question — it tests whether you see it as the bus's pacing signal.

The answer that lands frames HREADY as the bus's pacing signal: "HREADY is the single bus-wide signal that paces every AHB transfer. When it's high, the current transfer completes and the pipeline advances; when it's low, everything holds — the current transfer is extended (a wait state) and the next is delayed. It's effectively the bus's clock-enable: HCLK is the heartbeat, but HREADY gates whether the pipeline advances each cycle. And it's bus-wide — the manager and every subordinate observe the same HREADY — which is what keeps the pipeline coherent, because everyone advances together. The responding subordinate drives it, pacing each transfer to its own speed." The clock-enable framing, the bus-wide coherence, and the subordinate-paces-the-transfer points are the senior signals.

10. Practice Challenge

Reason from HREADY as the bus's clock-enable.

1. State the meaning. Give what HREADY high and HREADY low each mean for the bus.
2. Explain bus-wide. Why is HREADY a single signal everyone observes rather than per-subordinate?
3. Read the waveform. From Figure 2, identify the advancing cycles and the holding cycle, and what holds during the wait.
4. Connect to throughput. Explain why throughput is essentially the HREADY high/low ratio.
5. Explain the coupling. Describe how HREADY both enables mixed-speed subordinates and stalls the whole bus.

11. Key Takeaways

• HREADY is the single bus-wide signal that paces every AHB transfer — high completes the current transfer and advances the pipeline; low holds everything (a wait state).
• It is effectively the bus's clock-enable — HCLK provides the rhythm, HREADY gates whether the pipeline advances each cycle.
• It is bus-wide — the manager and all subordinates observe the same HREADY, which keeps the pipeline coherent (everyone advances together).
• The responding subordinate drives it (via HREADYOUT → HREADY, chapter 6.6), pacing each transfer to its own speed — fast subordinates one cycle, slow ones several.
• HREADY enables mixed-speed coexistence and determines throughput (the high/low ratio) — but its bus-wide nature also couples the bus (everyone holds when HREADY is low).
• HREADY is the first signal to read for any timing or throughput question — the bus's timing behaviour is HREADY's behaviour.

12. What Comes Next

You now understand HREADY's meaning. The next chapters examine how it is used and what it requires:

• 6.2 — Slave-Inserted Wait States (coming next) — how a subordinate drives HREADY low to stretch a transfer, and multi-wait transfers.
• 6.3 — Master Behavior During Wait (coming soon) — what the master must hold while HREADY is low.

To revisit HREADY's roles established earlier, see The Data Phase (completion gate), Pipelined Operation (pipeline advance), and HREADY & HREADYOUT (the shared signal and its sourcing). For how HREADY determines throughput, see How HTRANS Controls Bus Activity. For the broader protocol map, see the AMBA family overview.