HREADY Aggregation

Chapter 13.6 covered routing the data/response; this chapter covers a specific, subtle part of the return path: HREADY aggregation. Recall the HREADYOUT-vs-HREADY distinction (chapter 12.6): each slave drives its own HREADYOUT (its readiness), but a master needs a single HREADY input (is its current transfer done?). In a matrix, the question becomes: which slave's HREADYOUT should a master see? The answer: the slave that master is currently accessing. So the matrix muxes the active slave's HREADYOUT into each master's HREADY — using the same selection that routes the transfer (chapter 13.6). Each master gets its own HREADY, reflecting its target slave (with a default-ready when the master is idle / no slave selected). Crucially, the aggregated HREADY must also feed back to the slave being accessed — because an AHB slave samples its address phase only when HREADY is high (chapter 12.6), so the slave needs the same HREADY the master sees, keeping the pipeline aligned through wait states. This chapter details the per-master HREADY mux, the default-ready, and the feed-back-to-slave requirement.

1. What Is It?

HREADY aggregation is how the matrix combines the slaves' per-slave HREADYOUT signals into the right HREADY for each master. The mechanism:

• Per-master HREADY mux — each master's HREADY is the HREADYOUT of the slave it's accessing, selected by the same routing decode that connects them.
• Default-ready — when a master is idle (or its target slave isn't yet selected), the matrix supplies a default HREADY (typically high/ready) so the master can proceed.
• Feed back to the slave — the aggregated HREADY also goes to the accessed slave (it samples its address phase only when HREADY is high), keeping master and slave aligned.

So HREADY aggregation is the readiness part of the return routing (chapter 13.6): just as the read-data/HRESP are routed back to the originating master via a return mux, HREADY is also selected — the active slave's HREADYOUT becomes the master's HREADY. It's a per-master selection (each master sees its slave's readiness), with a default for idle. And it's bidirectional in a subtle way: the same HREADY must reach both the master (to gate its transfer) and the accessed slave (to time its address-phase sampling). So HREADY aggregation is the matrix combining per-slave HREADYOUT into a per-master HREADY (and feeding it back to the slave) — the readiness coordination that keeps each master-slave pair's pipeline aligned. It's a small but essential piece of correct matrix operation.

2. Why Does It Exist?

HREADY aggregation exists because the matrix has many HREADYOUT sources (one per slave) but each master needs one HREADY — its slave's — and because that HREADY must reach both the master and the slave to keep their pipeline aligned, the matrix must select and distribute it correctly.

The many-sources-one-needed problem is the root (extending chapter 12.6's HREADYOUT/HREADY distinction): each slave drives its own HREADYOUT (readiness). But a master needs a single HREADY signal telling it whether its current transfer is complete. In a matrix, the master is accessing one specific slave, so its HREADY should be that slave's HREADYOUT — not the others'. So the matrix must select the right slave's HREADYOUT for each master. So HREADY aggregation exists to pick, per master, the HREADYOUT of the slave it's accessing. So it's a selection problem, solved by a mux.

The same-selection-as-routing insight: which slave a master is accessing is already determined by the routing (decode → that slave port, chapter 13.6). So HREADY aggregation uses the same selection — the master's HREADY mux is steered by the same target-slave info that routes the transfer. So HREADY aggregation isn't a separate decision; it's the readiness output of the same routing. So it naturally piggybacks on the routing. So the matrix selects HREADY consistently with the data/response routing.

The default-ready exists for the idle case: when a master is not accessing any slave (idle, between transfers), there's no slave HREADYOUT to select — yet the master still needs a defined HREADY (so it can issue its next transfer when ready). So the matrix supplies a default HREADY (typically high/ready) for an idle master. So the default-ready exists to give an idle master a defined, proceed-able HREADY. So aggregation handles idle.

The feed-back-to-slave requirement is the subtle correctness piece (chapter 12.6): an AHB slave samples its address phase only when HREADY is high — because HREADY high means the previous transfer completed and the bus is advancing. So the slave needs to see the HREADY that the master sees, to know when to sample. In a matrix, this means the aggregated HREADY for a master-slave pair must reach both the master (to gate it) and the slave (to time its sampling). If the slave saw a different HREADY than the master, they'd desync — the slave might sample at the wrong time, misaligning the pipeline. So HREADY aggregation must distribute the same HREADY to both ends. So HREADY aggregation exists to: select each master's HREADY from the right slave's HREADYOUT (many-sources-one-needed), using the same routing selection (consistency), default-ready an idle master (defined idle behavior), and feed the HREADY back to the accessed slave (so master and slave stay aligned through wait states). It's the readiness coordination that makes the matrix's pipeline correct end-to-end — small, but essential. (The general pipeline-alignment-under-routing concern is chapter 13.6; this is its HREADY-specific realization.)

3. Mental Model

Model HREADY aggregation as a restaurant where each kitchen station has its own "order ready" bell, and each waiter watches only the bell of the station preparing their table's dish — the waiter advances (serves, takes the next order) when that station's bell rings, and crucially the station also needs to know the waiter is in sync, so the same "ready" signal coordinates both, ensuring the dish is handed off at the right moment; a waiter with no active order just sees a default "go ahead" so they can take a new order.

In a restaurant, each kitchen station (slave) has its own "order ready" bell (HREADYOUT) — it rings when that station's dish is done. Each waiter (master) is handling a table whose dish is being prepared at one specific station, so the waiter watches only that station's bell (the matrix muxes that station's HREADYOUT into the waiter's HREADY). The waiter advances — serves the dish and moves to the next order — when that bell rings (HREADY high). Crucially, the coordination is two-way: the station also needs to be in sync with the waiter — it should only start plating the next order when the waiter is ready to take it (the slave samples its address phase only when HREADY is high). So the same "ready" signal coordinates both the waiter (advance) and the station (hand off the next dish) — they stay synchronized, so a dish is never plated before the waiter is there to take it (no desync). And a waiter with no active order (idle) just sees a default "go ahead" (default-ready), so they're free to take a new order whenever one comes. So each waiter watches their station's bell, the bell coordinates both ends, and an idle waiter gets a default go-ahead.

This captures HREADY aggregation: each station's bell = each slave's HREADYOUT; the waiter watching only their station's bell = the per-master HREADY mux (selecting the active slave's HREADYOUT); the waiter advancing on the bell = the master proceeding on HREADY; the same ready coordinating both waiter and station = HREADY feeding back to the slave (alignment); the idle waiter's default go-ahead = default-ready. Each master watches its slave's readiness, the readiness syncs both ends, idle gets a default.

Watch a master's HREADY track its slave through a wait state:

The model's lesson: each waiter watches their station's bell; the bell syncs both ends; idle gets a default go-ahead. In the waveform, the CPU's HREADY follows only SRAM's HREADYOUT (its target) — flash's readiness is ignored — and tracks SRAM's wait state then completion.

4. Real Hardware Perspective

In hardware, HREADY aggregation is a per-master mux selecting the active slave's HREADYOUT, steered by the master's registered target-slave, with default-ready logic for idle and the HREADY routed to both the master and the accessed slave.

The per-master HREADY mux is the core logic: each master has a mux that selects, among all slaves' HREADYOUT, the one for the slave it's accessing — steered by the same target-slave selection used for the data-return mux (chapter 13.6). Because the master's data phase (when HREADY matters) corresponds to its registered address-phase target (chapter 13.6's origin/target tracking), the HREADY mux uses that registered target. So in hardware, HREADY aggregation is a per-master mux on the slaves' HREADYOUT, steered by the registered target. So it's part of the return-path mux network.

The default-ready logic handles idle: when a master isn't accessing any slave (its decode targets nothing, or it's driving IDLE), the mux would have no valid slave to select — so the matrix supplies a default HREADY (high) for that master. This lets the idle master proceed to its next transfer without stalling on a stale/invalid HREADY. So in hardware, the HREADY mux has a default-ready input for the no-slave case. So idle masters see ready.

The feed-back-to-slave routing is the alignment-critical piece: the aggregated HREADY for a master-slave pair must reach the slave too (not just the master), because the slave gates its address-phase sampling on HREADY (chapter 12.6). In a matrix, the slave being accessed must see the HREADY of the master accessing it — which is the aggregated HREADY (= that slave's own HREADYOUT, plus the readiness of the overall path). In practice, since the slave's HREADYOUT is the dominant term (the slave knows its own readiness), the matrix routes the combined HREADY (accounting for any matrix pipeline stages, chapter 13.6) back to the slave so it samples at the right time. The key correctness point: master and slave see the same HREADY, so a wait state stalls both together — no desync. So in hardware, HREADY aggregation is a per-master mux (steered by registered target) + default-ready + feed-back-to-slave routing, all part of the return path — ensuring each master sees its slave's readiness and each master-slave pair stays pipeline-aligned, even across matrix pipeline registers (chapter 13.6). So the hardware is a small but precise readiness-distribution network.

5. System Architecture Perspective

At the system level, HREADY aggregation is the mechanism that lets independent master-slave pairs each run their own wait-state timing concurrently — it's what makes the matrix's parallel transfers (chapter 13.4) actually work with slow slaves, and a place where matrix correctness is easily gotten wrong.

The independent per-pair timing: in a matrix, different master-slave pairs run concurrently (chapter 13.4) — and they may have different timing (one slave fast, another slow with wait states). HREADY aggregation is what lets each pair have its own HREADY: the CPU↔SRAM pair sees SRAM's readiness, the DMA↔flash pair sees flash's readiness — independently. So if flash is slow (wait states), the DMA↔flash pair stalls, but the CPU↔SRAM pair continues (it sees SRAM's ready, unaffected by flash). So per-master HREADY is what makes the concurrent transfers truly independent in timing. Without per-master HREADY (e.g. one global HREADY), a slow slave would stall all masters — defeating the matrix's concurrency. So at the system level, HREADY aggregation is essential to realizing independent concurrent timing — each pair paces itself. This is a non-obvious requirement: the matrix's parallelism needs per-master HREADY, not a shared one.

The wait-state isolation: because each master's HREADY reflects only its slave, a slow slave's wait states only stall the master(s) accessing it — not masters accessing other slaves. So a slow peripheral doesn't drag down the CPU's fast SRAM access. This isolation of wait-state penalties is a key performance property: the matrix confines a slow slave's latency to its own traffic. So at the system level, HREADY aggregation provides wait-state isolation — slow slaves penalize only their own accessors. So it's part of why the matrix delivers good aggregate performance even with mixed-speed slaves.

The correctness-criticality: HREADY aggregation is a frequent source of matrix bugs because it's subtle — the HREADY must be per-master, must select the right (registered-target) slave, must default-ready when idle, and must feed back to the slave consistently (especially across pipeline stages, chapter 13.6). Getting any of these wrong causes desync: a master stalling forever (wrong HREADY selected), a slave sampling at the wrong time (HREADY not fed back), or all masters stalling (global instead of per-master). So HREADY aggregation is a key verification focus for matrix interconnects (assertions: each master's HREADY tracks its target slave; idle masters see ready; master and slave see consistent HREADY). So at the system level, HREADY aggregation enables independent per-pair timing (essential to concurrency), isolates slow-slave wait states (performance), and is a correctness-critical, bug-prone area (verification focus). It's the readiness coordination that makes the matrix's concurrent, mixed-speed operation both correct and performant — small in logic, large in importance. So it's where the matrix's per-pair independence is realized and verified.

6. Engineering Tradeoffs

HREADY aggregation embodies the per-master-readiness, aligned-pipeline design.

• Per-master HREADY vs global HREADY. Per-master HREADY (each master sees its slave's readiness) enables independent concurrent timing and wait-state isolation, at the cost of per-master mux logic. A global HREADY would stall all masters on any slow slave — defeating concurrency. Per-master is required for a matrix.
• Default-ready vs stall-on-idle. Supplying a default-ready to an idle master lets it proceed to its next transfer immediately; stalling an idle master (no valid HREADY) would needlessly delay it. Default-ready is correct.
• Feed-back-to-slave vs master-only. Routing HREADY to both the master and the accessed slave keeps them aligned (the slave samples correctly); HREADY to the master only would desync the slave's sampling. Both must see it.
• Aligned across pipeline stages vs naive. When the matrix is pipelined (chapter 13.6), HREADY must account for the added latency so master and slave stay aligned; a naive HREADY (ignoring pipeline delay) would desync. Pipeline-aware HREADY is required.

The throughline: HREADY aggregation muxes the HREADYOUT of the slave a master is accessing into that master's HREADY (per-master, same selection as the routing), supplies a default-ready when the master is idle, and feeds the aggregated HREADY back to the accessed slave (which samples its address phase only when HREADY is high) — keeping each master-slave pair's pipeline aligned through wait states. Per-master HREADY is what gives the matrix independent concurrent timing and wait-state isolation (a slow slave stalls only its accessors). It's correctness-critical (a bug-prone desync source) and must be pipeline-aware in a registered matrix.

7. Industry Example

Trace HREADY aggregation in a matrix with mixed-speed slaves.

A matrix connects a CPU and DMA to fast SRAM and slow flash.

• CPU↔SRAM, fast. The CPU accesses SRAM, which completes in one cycle (HREADYOUT_SRAM high). The matrix muxes HREADYOUT_SRAM into the CPU's HREADY → the CPU's HREADY is high, the transfer completes immediately. The CPU sees SRAM's readiness.
• DMA↔flash, slow (concurrent). Simultaneously, the DMA accesses flash, which is slow (HREADYOUT_Flash low for several wait states). The matrix muxes HREADYOUT_Flash into the DMA's HREADY → the DMA's HREADY is low, the DMA waits. The DMA sees flash's readiness.
• Independent timing. Crucially, the CPU's fast SRAM access completes while the DMA's slow flash access waits — because each has its own HREADY (per-master aggregation). The slow flash does not stall the CPU. This is wait-state isolation: flash's slowness penalizes only the DMA.
• Feed-back-to-slave. The CPU's HREADY (high) is also routed to SRAM, so SRAM samples its next address phase correctly. The DMA's HREADY (low) is routed to flash, so flash holds. Each master-slave pair stays aligned via its shared HREADY.
• Idle master. When the CPU finishes and goes idle (no slave access), the matrix supplies a default-ready HREADY to the CPU, so it can immediately issue a new transfer when it has one — not stalled on a stale HREADY.
• The counter-example (global HREADY). If the matrix mistakenly used a single global HREADY (e.g. requiring all slaves ready), the slow flash would stall both the CPU and DMA — the CPU's fast SRAM access would be needlessly blocked, destroying the matrix's concurrency. Per-master HREADY avoids this.

The example shows HREADY aggregation enabling independent, isolated per-pair timing: the CPU's fast access completes while the DMA's slow access waits, each pacing on its own slave's HREADYOUT, with the HREADY fed back to each slave for alignment, and default-ready for idle. The global-HREADY counter-example shows why per-master aggregation is essential. This is how the matrix runs mixed-speed slaves concurrently and correctly.

8. Common Mistakes

9. Interview Insight

HREADY aggregation is a precise interview topic — the per-master selection, the default-ready, and the feed-back-to-slave (and why global HREADY is wrong) are the signals.

The answer that lands gives the per-master selection and the both-ends point: "In a matrix, each slave drives its own HREADYOUT, but each master needs a single HREADY telling it whether its current transfer is done. So the matrix muxes the HREADYOUT of the slave a master is accessing into that master's HREADY — using the same selection that routes the transfer. So HREADY is per-master: each master sees only its target slave's readiness. This is essential — if there were one global HREADY, a single slow slave would stall every master, destroying the matrix's concurrency. With per-master HREADY, the CPU's fast SRAM access can complete while the DMA's slow flash access waits, each pacing on its own slave — wait-state isolation. When a master is idle with no slave selected, the matrix gives it a default-ready so it can proceed to its next transfer. And crucially, the aggregated HREADY must also feed back to the accessed slave, because an AHB slave samples its address phase only when HREADY is high — so the slave needs the same HREADY the master sees, or they desync. In a pipelined matrix, this HREADY must also account for the matrix's added latency. So HREADY is per-master, equal to the active slave's HREADYOUT, reaching both the master and that slave to keep the pipeline aligned." The per-master selection, the default-ready, the feed-back-to-slave, and the why-not-global point are the senior signals.

10. Practice Challenge

Reason from HREADY aggregation.

1. The mechanism. Explain how each master's HREADY is selected from the slaves' HREADYOUT.
2. Why per-master. Explain why a global HREADY would break the matrix's concurrency.
3. Read the waveform. From Figure 2, explain why the CPU's HREADY follows SRAM and ignores flash.
4. Both ends. Explain why HREADY must reach the slave too, not just the master.
5. Isolation. Explain how per-master HREADY gives wait-state isolation and why it matters.

11. Key Takeaways

• HREADY aggregation muxes the active slave's HREADYOUT into each master's HREADY — per-master, using the same selection that routes the transfer (each master sees only its target slave's readiness).
• HREADY is per-master, not global — a global HREADY would stall all masters on any slow slave, defeating concurrency. Per-master HREADY gives independent timing.
• It provides wait-state isolation — a slow slave's wait states stall only the master(s) accessing it; masters on fast slaves proceed unaffected (key to mixed-speed performance).
• A default-ready is supplied to an idle master (no slave selected) so it can proceed to its next transfer.
• The aggregated HREADY must feed back to the accessed slave — the slave samples its address phase only when HREADY is high (chapter 12.6), so both ends must see the same HREADY or they desync.
• It must be pipeline-aware in a registered matrix (account for the added latency, chapter 13.6) — and it's a correctness-critical, bug-prone area (global-vs-per-master, master-only-vs-both-ends) warranting careful verification.

12. What Comes Next

You now understand HREADY aggregation — the per-master readiness coordination that keeps the matrix's concurrent, mixed-speed transfers aligned. The final chapter of Module 13 ties topology to performance:

• Bus Matrix Performance (next) — relating matrix topology (ports, sparsity, slave organization) to achievable system bandwidth.

To revisit the HREADYOUT/HREADY distinction this builds on, see AHB-Lite Slave Design; for the routing this completes, see Interconnect Routing.