Read Transfer Timing

This chapter walks a read transfer cycle by cycle through both phases, applying the timing rules from 5.1–5.3 to a concrete access. A read is the transfer direction where the subordinate produces the data — it drives HRDATA in the data phase, which the manager captures. We trace a clean single read, then a read with a wait state, paying attention to when HRDATA must be valid (only on the HREADY-high cycle, the read-specific timing from chapter 3.7). Reads and writes (5.5) differ chiefly in which side drives the data and when it must be valid, and this chapter establishes the read side precisely.

1. What Is It?

A read transfer moves data from the subordinate to the manager, in two phases:

• Address phase (cycle N): the master drives HADDR, HWRITE = 0 (read), and the control (HSIZE, HBURST, HPROT). The decoder selects the subordinate.
• Data phase (cycle N+1): the selected subordinate drives HRDATA with the read data, which the manager captures on the cycle HREADY is high.

The defining feature of a read is who drives the data: the subordinate produces HRDATA (subordinate → manager), in contrast to a write where the manager drives HWDATA. And the read-specific timing (chapter 3.7): HRDATA need only be valid on the HREADY-high cycle — the cycle the manager captures it — because the subordinate is producing the data and only needs it ready at completion. This is the key asymmetry with a write (where the data is held from the start of the data phase).

2. Why Does It Exist?

The read timing is the way it is because the subordinate is the data source, and a data source naturally needs time to produce the data — so the read's data is required only at the moment of capture, not before.

For a read, the subordinate must fetch or generate the requested data — read a memory cell, sample a register, retrieve from a buffer. This takes time, and how much depends on the subordinate (a fast SRAM is immediate; a slow flash needs cycles). So the read protocol gives the subordinate until the HREADY-high cycle to have HRDATA valid: it can take as many wait-state cycles as it needs, and HRDATA only has to be correct on the final cycle when the manager captures it. This is why HRDATA's validity requirement is "valid at the end" — it accommodates the subordinate needing time to produce the data, which is the natural situation for the data source.

This contrasts with the write side (5.5) for a clear reason: on a write, the manager is the data source, and it already has the data (it is writing a known value), so it can drive HWDATA from the start of the data phase and hold it. On a read, the subordinate is the source and may not have the data ready immediately, so it is given until completion. So the read/write timing asymmetry — read data valid at the end, write data held from the start — reflects which side is the data source and whether that side has the data ready. The protocol matches the timing requirement to the natural capability of the data producer.

The two-phase structure (address then data) exists for reads exactly as for any transfer (chapter 2.3): the subordinate must be selected (decoded) before it can produce data, which takes the address-phase cycle. So a read is: address phase to select the subordinate and tell it "read from here," then data phase for the subordinate to drive the data back. The one-cycle lead gives the subordinate its selection-and-setup cycle; the data phase (possibly extended by wait states) is where it delivers. This is the read realizing the general two-phase timing, with the subordinate as the data producer.

3. Mental Model

Model a read as ordering a dish and the kitchen serving it when ready.

You place the order (address phase): "the salmon, please" (HADDR, HWRITE = 0 meaning "bring me," the control specifying the dish). The kitchen (subordinate) then prepares the dish — and it only needs the dish ready when it is served to you (HRDATA valid on the HREADY-high cycle), not before. If the kitchen is quick, the dish comes the next beat; if slow, it takes extra beats (wait states), and the dish only has to be on the plate when it finally arrives at your table. You (the manager) take the dish at the moment it is served. The kitchen produces; you receive; the dish need only be ready at the moment of serving.

Watch a clean read and a slow read:

The model's lesson: the kitchen produces the dish and serves it when ready — HRDATA is driven by the subordinate and need only be valid when the manager captures it (HREADY high). The fast read delivers next cycle; the slow read takes wait states, with HRDATA valid only on the final HREADY-high cycle. The manager simply takes the data at the moment of capture.

4. Real Hardware Perspective

In hardware, a read is the master presenting the address with HWRITE low, the subordinate driving HRDATA through the multiplexor, and the manager registering it on the HREADY-high edge.

In the address phase, the master drives HADDR, HWRITE = 0, and the control; the decoder asserts the subordinate's HSEL and sets the read-data multiplexor selection (chapters 3.8, 3.10). The selected subordinate, recognizing a committed read (the committed-transfer rule, 4.7), begins fetching the data. In the data phase, the subordinate drives HRDATA, which the multiplexor routes back to the manager, and the manager registers HRDATA on the clock edge where HREADY is high. That capture edge is the single sampling instant for the read data.

The read-specific validity is the key hardware point: HRDATA must be valid at the HREADY-high cycle, but not necessarily before. So a subordinate that needs time holds HREADY low (wait states) while it produces the data, and only has to present valid HRDATA on the final cycle. In hardware, this means the subordinate's read-data path must be settled and correct by the HREADY-high edge — it has the wait-state cycles to get there. This is gentler on the subordinate than the write requirement (where HWDATA is held by the manager from the start), because the subordinate, as the producer, is given until capture.

A hardware detail worth noting: because the manager captures HRDATA on the HREADY-high edge, the HRDATA-to-manager path (subordinate output → multiplexor → manager input) must meet timing within the cycle. On large systems with many subordinates, this read-data path through the mux can be timing-critical — the read data must propagate from the selected subordinate, through the mux, to the manager's capture register, all within the HREADY-high cycle. So read timing closure involves this path, which is why interconnects are designed to keep the read-data mux fast.

The address-phase control governs the read (chapter 5.3): the HSIZE in the address phase determines which byte lanes of HRDATA are meaningful; the HADDR determines what the subordinate reads. So the subordinate uses the latched address-phase control to produce the right HRDATA — the control/data alignment applied to a read. Reading a read on a waveform, you align the HRDATA (data phase) with the HADDR/HSIZE one cycle before it.

5. System Architecture Perspective

At the system level, read timing shapes read latency and stresses the read-data path, both of which matter for performance.

A read's latency — from issuing the address to capturing the data — is at least the one-cycle lead plus any wait states the subordinate inserts. For latency-sensitive masters (a processor stalling on a load), read latency is critical: every wait state the subordinate adds directly delays the processor. So the system cares about keeping read latency low for hot paths — fast subordinates (single-cycle SRAM) on the critical read path, slow ones (flash, peripherals) tolerated where latency matters less. Read timing is where this latency is determined, and it is why instruction and data memory are placed for low read latency while slow devices are bridged away.

The read-data path is a system-level timing concern. Because HRDATA flows from the selected subordinate through the multiplexor to the manager, and must be captured within the HREADY-high cycle, the read-data path (especially the mux on a many-subordinate system) is often a critical timing path. So the system's maximum clock frequency can be limited by the read-data path — which is why interconnect design pays attention to keeping the read-data mux fast and the path short. Read timing thus connects to the system's achievable frequency, not just its latency.

Read timing also interacts with pipelining and throughput. For a stream of reads (a burst, or back-to-back reads), the pipeline delivers one read per cycle when subordinates are fast (HRDATA valid each cycle, HREADY high). A slow subordinate inserting wait states reduces this throughput (each wait state is a non-work cycle, chapter 4.6). So read timing — specifically how often subordinates insert wait states on reads — determines read throughput. A read-heavy workload (instruction fetch, data streaming) performs as well as its subordinates' read timing allows. This is why read-side wait-state behaviour is a key performance parameter for read-heavy systems.

So at the system level, read timing determines read latency (critical for stalling masters), stresses the read-data path (a frequency limiter), and governs read throughput (via subordinate wait states). It is where the performance of reads — the dominant access for many masters — is set.

6. Engineering Tradeoffs

Read timing reflects the subordinate-as-producer choice.

• Valid-at-end (read) vs held-from-start (write). Requiring HRDATA only at the HREADY-high cycle gives the subordinate (the producer) time to fetch the data, at the cost that the read-data path must settle by that cycle. This is the right requirement for a read — the producer needs time — and it is gentler than the write's hold rule. The asymmetry matches the data source.
• Wait states for slow reads vs fixed timing. Allowing subordinates to insert wait states on reads accommodates slow data sources (flash, peripherals) at the cost of added read latency and reduced throughput during the waits. The alternative (fixed fast timing) would exclude slow subordinates. AHB accommodates slow reads via wait states, accepting the latency cost where it occurs.
• Read-data mux vs direct paths. Routing HRDATA through a shared multiplexor (selected by the decoder) is the clean, scalable way to return read data from many subordinates, at the cost of the mux being on the critical read path. Direct per-subordinate paths would be faster but not scalable. AHB uses the mux, and the system manages its timing.
• Single capture instant vs continuous validity. Requiring HRDATA valid only at the HREADY-high instant (not continuously) simplifies the subordinate's job (it need not hold the data) at the cost of the manager needing to capture at exactly the right edge. This is correct and standard — the manager captures on HREADY-high, the subordinate delivers then.

The throughline: read timing gives the subordinate (the data producer) until the HREADY-high cycle to deliver HRDATA, accommodating slow data sources via wait states, with the read-data path (through the mux) as the timing-critical element. The valid-at-end requirement matches the read's data source (the subordinate), distinct from the write's held-from-start requirement.

7. Industry Example

Trace reads through a processor's instruction fetch and a slow-peripheral read.

• A fast instruction fetch (single-cycle SRAM). The processor fetches an instruction from on-chip SRAM. Address phase: HADDR = the instruction address, HWRITE = 0, HSIZE = word. Data phase (next cycle): the SRAM, being fast, drives HRDATA with the instruction and asserts HREADY high — the processor captures the instruction immediately. One-cycle lead, no wait states; the read is as fast as possible. For a stream of fetches, the pipeline delivers one instruction per cycle.
• A slow peripheral read. The processor reads a status register from a slow peripheral. Address phase: HADDR = the register, HWRITE = 0. Data phase: the peripheral needs time, so it holds HREADY low for a couple of cycles (wait states) while it produces the register value; HRDATA becomes valid only on the final HREADY-high cycle, when the processor captures it. The read took longer (added latency), but completed correctly because HRDATA was valid at capture. The processor stalled for the wait states — read latency directly delaying it.
• The latency consequence. If the processor read from this slow peripheral frequently on a critical path, the wait states would repeatedly stall it — which is why such reads are kept off hot paths (and slow devices bridged to APB). The fast SRAM reads, by contrast, keep the processor fed at full rate. Read timing — fast vs slow subordinate — directly determines the processor's read performance.
• Reading the captures. On the SRAM read, HRDATA is valid the cycle after the address (one-cycle lead, HREADY high). On the peripheral read, HRDATA is valid only on the final HREADY-high cycle after the wait states — and the engineer associates that HRDATA with the address one cycle before the data phase started (chapters 5.2, 5.3). Reading reads correctly means capturing at HREADY-high and aligning with the address-phase control.

The reads show the timing: fast subordinates deliver HRDATA next cycle (low latency, full throughput), slow ones insert wait states (added latency), and in both the manager captures HRDATA at HREADY-high. The subordinate-as-producer model — valid at the end — governs throughout.

8. Common Mistakes

9. Interview Insight

Read-timing questions test the subordinate-produces-data direction and the valid-at-end rule.

The answer that lands walks both phases with the read-specific timing: "A read has an address phase where the master drives HADDR, HWRITE = 0, and the control, and the decoder selects the subordinate. Then, one cycle later, the data phase: the selected subordinate drives HRDATA, which the manager captures on the cycle HREADY is high. The read-specific point is that the subordinate produces the data, so HRDATA need only be valid on that final HREADY-high cycle — during any wait states the subordinate is still producing it. That's the opposite of a write, where the manager holds HWDATA from the start." The subordinate-produces-data direction and the valid-at-end timing are the senior signals.

10. Practice Challenge

Reason from the subordinate-produces-data, valid-at-end timing.

1. Walk a read. Describe the two phases of a read, naming who drives what each cycle.
2. State the validity rule. Say when HRDATA must be valid and why it need not be valid earlier.
3. Read the waveform. From Figure 2, identify the cycle each read's data is captured, and why the slow read's HRDATA is valid only on the final cycle.
4. Contrast with write. Explain the read/write data-timing asymmetry and its cause.
5. Diagnose wrong data. A slow subordinate's reads return wrong data. Explain how a too-early HREADY causes it and the fix.

11. Key Takeaways

• A read has an address phase (master drives HADDR, HWRITE = 0, control) then a data phase one cycle later where the subordinate drives HRDATA.
• The subordinate produces the read data (subordinate → manager), captured by the manager on the HREADY-high cycle.
• HRDATA need only be valid on the HREADY-high cycle — during wait states the subordinate is still producing it; valid at the end, not held throughout.
• The read/write timing asymmetry reflects the data source: read data valid at the end (subordinate may need time), write data held from the start (manager has the data).
• Read timing sets read latency, stresses the read-data path, and governs read throughput — fast subordinates give low-latency, full-rate reads; slow ones add wait states.
• A subordinate must not assert HREADY high before HRDATA is valid — it inserts wait states until the data is ready; asserting early returns wrong data.

12. What Comes Next

You now know read timing. The next chapter is its counterpart, where the data-timing asymmetry is most visible:

• 5.5 — Write Transfer Timing (coming next) — a write walked cycle by cycle, with the manager holding HWDATA from the start of the data phase.
• 5.6 — Pipeline Hazards (coming soon) — the hazards the phase overlap creates and how AHB avoids them.

To revisit the timing rules a read applies, see The Two-Phase Pipeline, Address Phase Leads Data Phase, and Control / Data Alignment; for HRDATA and HREADY specifics, see HWDATA & HRDATA and HREADY & HREADYOUT. For the broader protocol map, see the AMBA family overview.