HRDATA Muxing

The previous chapter built the slave's pace output (HREADYOUT); this chapter builds its read-data output — HRDATA — and the muxing that returns it to the master. Read data flows through two mux levels. Inside each slave, a read mux selects the addressed source — the indexed register (16.2), the SRAM read data (16.3), a status value — onto that slave's HRDATA output. Then in the interconnect, a second mux selects the currently-addressed slave's HRDATA onto the master's HRDATA input. The critical point is a timing one: HRDATA is a data-phase signal — the master samples it in the data phase, one phase after the address, and only in the cycle HREADY is high. Because the address and data are one phase apart, the select that picked the slave (in the address phase) must be captured and used one cycle later to mux the data. Using the current address-phase select to mux HRDATA returns the next transfer's slave data, not the one whose data phase is actually happening — the wrong slave's data. This chapter builds both mux levels and gets the data-phase alignment right.

1. What Is It?

HRDATA muxing is the read-data return path — two mux levels (slave-internal and interconnect) that select the addressed read data onto the master, aligned to the data phase. Its parts:

• Slave-internal read mux — within a slave, select the addressed source (indexed register, SRAM rdata, status) onto that slave's HRDATA.
• Interconnect read mux — across slaves, select the addressed slave's HRDATA onto the master's HRDATA.
• Data-phase signal — HRDATA is sampled in the data phase (one phase after the address), only when HREADY is high.
• Registered (data-phase) select — both muxes use the captured address-phase select (now a data-phase select), not the current address-phase select.

So HRDATA muxing is the read-data return path with two selection levels and one timing rule. Level 1 (slave-internal): the slave selects which of its sources (a register by index, the SRAM's read data, a status value) goes onto its HRDATA — the read mux from chapters 16.2/16.3. Level 2 (interconnect): the interconnect selects which slave's HRDATA goes to the master — a mux across all slaves' HRDATA outputs. The timing rule binds both: HRDATA is a data-phase signal, so the select (which slave, which source) is the one captured in the address phase and used one cycle later — the registered, data-phase select — to align the data with the data phase it belongs to. Get the alignment wrong (use the current address-phase select) and you return the wrong slave's data. So HRDATA muxing is the two-level, data-phase-aligned read path. So it's how read data gets back correctly.

2. Why Does It Exist?

HRDATA muxing exists because many slaves (each with many internal sources) share one read-data bus to the master — so read data must be selected (twice: source-within-slave, then slave-across-bus) and aligned to the data phase (because AHB's pipelining puts the data one phase after the address).

The shared read bus needs selection: the master has one HRDATA input, but there are many slaves, each with many readable sources (registers, memory, status). On a read, exactly one source (in one slave) holds the data the master wants. So the data must be selected — which slave, and which source within it — onto the shared HRDATA. That's two muxes: the slave-internal mux (source → slave HRDATA) and the interconnect mux (slave → master HRDATA). So HRDATA muxing exists to select the one wanted source onto the shared bus. So it's the read-side selection. So muxing is inherent to a shared bus.

The pipelining demands data-phase alignment: AHB is pipelined — the address phase precedes the data phase by one cycle (chapter 3). So when the master drives an address (selecting a slave) in the address phase, the read data for that address comes back in the next cycle (the data phase). This means the select used to mux HRDATA must be the select from the previous cycle's address phase — not the current address phase (which belongs to the next transfer). So the select must be captured (registered) in the address phase and used one cycle later in the data phase. So HRDATA muxing exists with a registered select because the data is one phase behind the address. So alignment is forced by pipelining. So the timing is structural.

The clean-bus requirement drives the zero-default: with many slaves' HRDATA outputs feeding the interconnect mux (sometimes implemented as an AND-OR / OR of gated outputs), the unselected slaves must not corrupt the result. So unselected slaves drive HRDATA = 0 (or the mux cleanly selects only the addressed one), keeping the combined read data clean. So the convention exists for a clean shared bus. So HRDATA muxing exists because: many slaves with many sources share one read bus (needing two-level selection — the why); AHB's pipelining puts the data one phase after the address (forcing a registered, data-phase select for alignment — the timing); and the shared bus must stay clean (unselected slaves drive 0 — the convention). So HRDATA muxing is the two-level, data-phase-aligned, clean read-data return path — the read-side counterpart to the address/write distribution, selecting the one wanted source onto the master's HRDATA at the right cycle. So this chapter builds the read path correctly. So read data returns from the right place at the right time.

3. Mental Model

Model HRDATA muxing as a mail-sorting relay where you requested a document one window ago. Each office (slave) has an internal clerk who pulls the right file from its own cabinets (the slave read mux). A central dispatcher (the interconnect) then routes the requested office's file to you. But because you placed the request one window-step earlier than you collect it, the dispatcher must remember which office you asked — using the ticket from your earlier request, not whoever is at the request window now — or you'll be handed the next person's document.

A mail relay where requesting a document and collecting it happen one step apart (the pipeline). You go to the request window and ask office B for a file (the address phase — HADDR selects slave B). One step later, at the collection window, office B's file comes back to you (the data phase — slave B drives HRDATA, you sample it). Inside each office (each slave), a clerk pulls the right file from that office's own cabinets — the right drawer (a register by index), the archive (the SRAM), or the notice board (a status value) — and puts it on the office's outgoing tray (the slave read mux → that slave's HRDATA). Then a central dispatcher (the interconnect) routes the requested office's tray to your collection window (the interconnect mux → master HRDATA). Here's the crux: because you requested one step earlier than you collect, the dispatcher must route based on which office you asked at the request window one step ago — using the ticket from your earlier request (the captured, data-phase select). If the dispatcher instead looked at whoever is at the request window right now (the current address-phase select), it would route the file for the next person's request — and hand you the wrong document. So the dispatcher remembers your earlier ticket and uses it. And offices you didn't ask put nothing on the shared belt (drive HRDATA = 0), so your file arrives clean. And you only trust the document when the "ready" lamp is lit (only sample HRDATA when HREADY is high).

This captures HRDATA muxing: the request window = the address phase (HADDR selects a slave); the collection window one step later = the data phase (slave drives HRDATA, master samples); each office's clerk pulling the right file = the slave-internal read mux (source by index); the office's outgoing tray = the slave's HRDATA; the central dispatcher routing the requested office's tray = the interconnect mux (slave → master); using the ticket from your earlier request = the registered, data-phase select; the wrong document if the dispatcher uses the current window = wrong-slave data from using the current address-phase select; empty belt from offices you didn't ask = unselected slaves driving 0; trusting only when the lamp is lit = sampling HRDATA only when HREADY high. Two mux levels, routed by the remembered (data-phase) select.

Watch a read return through the two levels, aligned to the data phase:

The model's lesson: two mux levels, routed by the remembered (data-phase) select — the data comes back one cycle after the address. In the waveform, the master samples Q in the data phase, and the mux that routed it used the captured B (from the address phase), not the current address.

4. Real Hardware Perspective

In hardware, HRDATA muxing is a read mux inside each slave (source-select by the registered index), a read mux in the interconnect (slave-select by the registered data-phase decode), and the convention that unselected slaves drive 0 — all aligned to the data phase.

The slave-internal read mux: within a slave, HRDATA is a combinational mux selecting the addressed source. For a register bank (16.2): HRDATA = regs[addr_q] (or attribute-specific values). For a memory slave (16.3): HRDATA = sram_rdata (the SRAM's read output). For a mixed slave: a mux over registers, memory, status, by the captured address (addr_q). The select is addr_q — the registered, data-phase address (captured in the address phase, used in the data phase). So in hardware, the slave's read mux is combinational, selected by the captured address. So it's source selection. So that's level 1.

The interconnect read mux: the interconnect builds the master's HRDATA by selecting the addressed slave's HRDATA — a mux over all slaves' HRDATA outputs, driven by the registered data-phase decode (which slave was addressed last cycle). This is often an AND-OR structure: each slave's HRDATA is ANDed with its data-phase select and the results ORed — so only the addressed slave's data passes. (This is why unselected slaves driving 0 keeps the OR clean.) So in hardware, the interconnect read mux is a registered-decode-driven mux/AND-OR over slave HRDATA. So it's slave selection. So that's level 2.

The data-phase select and the zero-default: the binding detail is that both muxes use the data-phase (registered) select — the address-phase decode captured one cycle. The interconnect registers the slave-select decode (from the address phase) and uses it in the data phase to mux HRDATA. If it used the combinational (current) address-phase decode, it would mux the next transfer's slave — returning wrong data (the classic bug). And unselected slaves drive HRDATA = 0 so the AND-OR / mux is clean. So in hardware, HRDATA muxing is: a slave-internal combinational read mux (source by addr_q), an interconnect AND-OR/mux (slave by registered data-phase decode), unselected slaves driving 0, all aligned to the data phase. The registered select is the piece that's easy to get wrong and critical to get right. So in hardware, align the read mux to the data phase with a registered select. So the alignment is the hardware crux.

5. System Architecture Perspective

At the system level, HRDATA muxing is the read-data distribution network — the counterpart to address/write distribution — and its data-phase alignment is a direct consequence of AHB's pipelined timing, making it a place where the protocol's pipeline structure shows up concretely in the RTL.

The read distribution network: just as the interconnect distributes the address and write data from the master to the slaves (chapter 13), it collects read data from the slaves to the master — and HRDATA muxing is that collection network. So at the system level, HRDATA muxing is the read-return half of the interconnect's data path (the write half distributes HWDATA; the read half collects HRDATA). So it's the read distribution. So it mirrors the write path.

The pipeline made concrete: AHB's defining feature is its pipelining — address and data phases overlap (chapter 3). HRDATA muxing is where this pipelining becomes a concrete RTL requirement: because the data is one phase behind the address, the read mux must use the registered (data-phase) select. So the abstract pipeline structure forces a specific implementation detail (register the select). So at the system level, HRDATA muxing is a concrete manifestation of the pipeline — a place where "address and data are one phase apart" becomes "register the select before muxing the data". So the pipeline is visible here. So it's pipelining in the RTL.

The timing-closure path: the read path (slave read mux → interconnect mux → master) is often a long combinational path — especially with many slaves (a wide interconnect mux) and wide data (32/64-bit). So the HRDATA path is a timing-critical path that limits the clock frequency — and is often pipelined (registered at the slave output or interconnect) to close timing, at the cost of added read latency (an extra wait state). So at the system level, the HRDATA mux is a performance-relevant path (interconnect width, data width, pipelining choices). So at the system level, HRDATA muxing is the read-data distribution network (the read-return half of the interconnect — mirroring the write path), a concrete manifestation of AHB's pipeline (the data-phase-behind-address structure forcing the registered select), and a timing-critical path (wide muxes over many slaves/wide data — often pipelined to close timing, adding read latency). So HRDATA muxing is where the read data is gathered correctly across the bus and where the pipeline's timing shows up as a concrete RTL and timing-closure concern. So gather read data with the right (registered) select, and watch the read-path timing.

6. Engineering Tradeoffs

HRDATA muxing embodies the two-level, data-phase-aligned, clean-bus read path.

• Registered (data-phase) select vs current (address-phase) select. The registered select correctly aligns data to the data phase (correct); the current address-phase select returns the next slave's data (a classic wrong-data bug). Always use the registered, data-phase select.
• Unselected slaves drive 0 vs don't-care. Driving 0 keeps the AND-OR/mux clean and avoids X-propagation (robust); leaving don't-care risks contaminating the combined read data. Drive 0 when unselected.
• Combinational read path vs pipelined. A combinational read path (slave mux → interconnect mux) has low latency but a long timing path (limits frequency, especially wide interconnects); pipelining (registering the read data) closes timing at the cost of +1 read latency. Trade frequency for latency.
• Wide single mux vs hierarchical. A single wide mux over all slaves is simple but slow for many slaves; a hierarchical (tree) mux closes timing better at the cost of structure. Use hierarchy for large interconnects.

The throughline: HRDATA muxing is the read-data return path with two mux levels — inside each slave, a read mux selects the addressed source (indexed register, SRAM rdata, status) onto that slave's HRDATA; in the interconnect, a mux selects the addressed slave's HRDATA onto the master. Because HRDATA is a data-phase signal (sampled one phase after the address, only when HREADY is high), both muxes must use the registered, data-phase select — not the current address-phase select (which would return the next slave's data). Unselected slaves drive HRDATA = 0 (clean AND-OR/mux). It's the read-return half of the interconnect, a concrete manifestation of AHB's pipeline, and a timing-critical path (often pipelined, adding read latency).

7. Industry Example

Trace a read that switches slaves between consecutive transfers — the case that exposes the alignment.

The master reads Slave B (an SRAM), then immediately reads Slave C (a register bank), back to back.

• Cycle 0 — B's address phase. The master drives B's address. The interconnect decodes "B" and captures it as the data-phase select for the next cycle. (Meanwhile B begins its SRAM read.)
• Cycle 1 — B's data phase / C's address phase. Two things happen: B's data phase (B drives HRDATA_B = Q_B), and C's address phase (the master drives C's address; the interconnect decodes "C" and captures it for cycle 2). The HRDATA mux must return B's data — so it uses the captured select from cycle 0 (B), routing HRDATA_B = Q_B to the master. The master samples Q_B (with HREADY high) — correct. If the mux had used the current (cycle 1) decode (C), it would return HRDATA_C — but C's data isn't ready (C's data phase is cycle 2) — wrong data.
• Cycle 2 — C's data phase. C drives HRDATA_C = Q_C; the HRDATA mux uses the captured select from cycle 1 (C), routing HRDATA_C = Q_C to the master, sampled (HREADY high) — correct.
• The slave-internal mux. Within B, its read mux selected the SRAM rdata (by addr_q) onto HRDATA_B; within C, its read mux selected regs[addr_q] onto HRDATA_C — each using its own captured address.
• Unselected slaves. In each data phase, the non-addressed slaves drive HRDATA = 0, keeping the interconnect's AND-OR clean.

The example shows the data-phase alignment in the case that matters: when the address switches slaves between consecutive transfers, the HRDATA mux must use the registered (data-phase) select to return the right slave's data (B's in cycle 1, C's in cycle 2) — using the current address-phase select would return the wrong slave. The two mux levels (slave-internal source select, interconnect slave select) and the zero-default keep the read path correct and clean. This is HRDATA muxing done right. This is the pipeline made concrete.

8. Common Mistakes

9. Interview Insight

HRDATA muxing is a precise RTL interview topic — the two-level structure, and especially the data-phase-aligned registered select, are the signals.

The answer that lands gives the two levels and the alignment: "The read-data path has two mux levels. Inside each slave, a read mux selects the addressed source — the indexed register, the SRAM read data, a status value — onto that slave's HRDATA, using the captured address. Then in the interconnect, a second mux selects the addressed slave's HRDATA onto the master's HRDATA. The critical thing is the timing: HRDATA is a data-phase signal. The master samples it in the data phase, one cycle after it drove the address, and only when HREADY is high. Because the data comes back one phase after the address, both muxes must use the registered, data-phase select — the address-phase decode captured and used one cycle later — not the current address-phase select. If you mux with the current select, you return the next transfer's slave data, because in the data phase cycle the master is already driving the next address. That's a classic wrong-slave-read bug. It's the same capture-the-address-phase, act-in-the-data-phase discipline as the slave itself, applied to the mux select. The bug hides in single-slave bursts, where the current and registered selects coincide, and surfaces when consecutive transfers address different slaves. Also, unselected slaves drive HRDATA to zero so the interconnect's AND-OR stays clean, and the read path — a wide mux over many slaves and wide data — is often a timing-critical path that gets pipelined, adding read latency." The two levels, the data-phase signal, and the registered-select alignment are the senior signals.

10. Practice Challenge

Build and reason from HRDATA muxing.

1. The two levels. Describe the slave-internal read mux and the interconnect read mux, and what each selects.
2. Data-phase signal. Explain why HRDATA is a data-phase signal and when the master samples it.
3. Read the waveform. From Figure 2, explain how the read data returns one cycle after the address, muxed by the captured (B) select.
4. Registered select. Explain why the mux must use the registered (data-phase) select, the bug otherwise, and why it hides in single-slave bursts.
5. Clean and fast. Explain why unselected slaves drive 0, and why the read path is often pipelined.

11. Key Takeaways

• HRDATA muxing has two levels — a slave-internal read mux (addressed source → slave HRDATA) and an interconnect read mux (addressed slave → master HRDATA).
• HRDATA is a data-phase signal — sampled one phase after the address, only in the cycle HREADY is high; it need only be valid then.
• Both muxes use the registered (data-phase) select — not the current address-phase select (which points to the next transfer's slave → wrong data). Same capture-then-act discipline as the slave (16.1), applied to the mux select.
• The wrong-slave bug hides in single-slave bursts (current and registered selects coincide) and surfaces when consecutive transfers switch slaves.
• Unselected slaves drive HRDATA = 0 — keeping the interconnect's AND-OR/mux clean (no X-propagation).
• The read path is timing-critical — a wide mux over many slaves and wide data, often pipelined to close timing (adding read latency).

12. What Comes Next

You now can build the read-data path. The next chapter builds the slave's response output:

• HRESP Generation (next) — generate correct OKAY/ERROR responses, including the two-cycle ERROR.
• Address / Control Capture, the Write/Read FSMs, and more — the rest of the slave RTL.

To revisit the slaves whose sources feed this mux, see Register Bank Slave and Memory Slave; for the pace signal that gates the sample, see HREADYOUT Generation.