The Data Phase

The previous chapter covered the address phase — the manager announcing the access. This chapter covers the second half: the data phase, where the payload actually moves and the subordinate reports completion. This is where two of the most important signals in all of AHB live: HREADY, the wire that gates every transfer and inserts wait states, and HRESP, the response that says whether the access succeeded. By the end you will understand exactly when a beat of data transfers, why a slow subordinate stalls the entire bus, and how the address and data phases lock together. We keep encodings light — HRESP's bit-level detail is Module 3 — and focus on the behaviour of the data phase.

1. What Is It?

The data phase is the part of an AHB transfer in which the payload moves and the access completes. It follows the address phase, and unlike the address phase — which is nominally a single cycle — the data phase can last one or more cycles, because the subordinate can extend it with wait states until it is ready.

The signals that define the data phase are:

• HWDATA — write data, driven by the manager toward the subordinate during a write.
• HRDATA — read data, driven by the selected subordinate back toward the manager during a read.
• HREADY — the completion gate: when high, the current beat completes this cycle; when low, the subordinate is inserting a wait state and the data phase is extended.
• HRESP — the response: whether the access completed successfully (OKAY) or failed (ERROR). The bit-level encoding and the two-cycle error sequence are covered in Module 3.

The one signal to fix in your mind above all others is HREADY. It is the heartbeat of AHB: every beat of every transfer completes only on a cycle where HREADY is high. When HREADY is low, nothing advances — the current beat is held and the whole shared bus waits. Understanding the data phase is largely understanding HREADY.

2. Why Does It Exist?

The data phase exists because, having described the access in the address phase, the transfer must now actually do it — move the bytes and report the outcome — and that step needs its own time, which may be more than one cycle.

Two realities force the data phase to be separate and extensible:

• Data movement is a distinct act from describing the access. The address phase said what; the data phase does it. Keeping them separate is what lets the next access's address phase overlap this access's data phase — the pipeline. If data moved in the address phase, there would be nothing to overlap.
• Subordinates are not all equally fast. An on-chip SRAM may complete in a single cycle; a flash controller or a slow peripheral may need several. The data phase must therefore be able to stretch to accommodate the slowest subordinate, and HREADY is the mechanism: the subordinate holds HREADY low until it can complete, inserting wait states. Without an extensible data phase, the bus would have to run at the speed of its slowest subordinate always — wasteful — or simply could not host slow subordinates at all.

So the data phase exists to perform and complete the access at the subordinate's pace, and HREADY exists so a fast bus can still host slow subordinates without permanently slowing down. The cost — the one we have flagged since the mental-model chapter — is that because the bus is shared and held, those wait states stall everyone. The data phase is where that cost is actually paid, cycle by cycle, on HREADY.

3. Mental Model

Model the data phase as the goods crossing the counter, with the clerk able to say "one moment."

The address phase handed over the order form. Now the goods cross: for a write, the manager pushes the goods to the clerk (HWDATA); for a read, the clerk hands goods back (HRDATA). But the clerk has a "one moment" sign (HREADY): while it is up, the goods stay on the counter, not yet handed over, and the whole queue waits. When the clerk lowers the sign (HREADY high), the exchange completes this instant, and the clerk also stamps the receipt OKAY or ERROR (HRESP).

Now watch a real write with a wait state — the canonical data-phase timing:

The model makes the chapter's core true: the beat completes on the cycle HREADY is high, and not before. Everything else — held data, stalled neighbours, the response — follows from that one rule. Watch HREADY, and you can read any AHB data phase.

4. Real Hardware Perspective

In hardware, the data phase is where the bus's "advance" is gated, and HREADY is physically the enable that decides whether state moves forward this cycle.

For a write, the manager drives HWDATA during the data phase and must hold it stable as long as HREADY is low, because the subordinate has not yet captured it. The subordinate samples HWDATA on the cycle HREADY is high — that is the instant the write actually lands. For a read, the selected subordinate drives HRDATA, and the manager captures it on the cycle HREADY is high. In both directions, HREADY high is the single sampling instant; until then, the driven data is just being held.

The wait state is mechanically simple and powerful: the subordinate holds HREADY low. Because HREADY is a shared bus signal that the whole system observes, holding it low freezes the pipeline — the manager cannot advance to the next transfer, the address phase of any pending next transfer cannot complete, and other managers cannot be granted the bus to start moving data. One subordinate, one wire, the whole bus held. This is the literal hardware seat of "a slow slave stalls everyone."

HRESP rides alongside as the response. In the normal case it indicates OKAY. For an error, AHB uses a defined response sequence (a two-cycle error protocol detailed in Module 3) so the manager can cleanly observe the failure — but conceptually, HRESP is the subordinate telling the manager whether the access succeeded, sampled at the same completion instant as the data. The reason the error case needs a defined multi-cycle sequence, rather than a single flag, is to give the manager an unambiguous, glitch-free way to see the failure even across the pipeline — a detail we leave to Module 3.

5. System Architecture Perspective

At the system level, the data phase — specifically HREADY behaviour — is where a subsystem's real-world performance is won or lost, and where the architecture's tradeoffs become measurable.

Every subordinate's wait-state profile is a system-level performance parameter. A subsystem full of single-cycle SRAM runs the data phase at one beat per cycle and sustains high throughput; add a subordinate that inserts many wait states on the critical path, and the whole bus's effective throughput drops, because HREADY is low for those cycles and the shared bus is frozen. So when you size or profile an AHB subsystem, you are largely asking "how many wait states do the frequently-accessed subordinates insert, and how often?" The answer lives in the data phase.

This is also the architectural justification, now made precise, for the APB bridge pattern from Module 1. A genuinely slow peripheral, left directly on the AHB, would insert long runs of wait states in its data phase, freezing the backbone every time it is accessed. By placing it behind an APB bridge, its slowness is contained on the APB side; the bridge presents a better-behaved data phase to the AHB, and the slow device no longer stalls the high-performance backbone. The data phase is exactly where "why bridge slow peripherals?" gets its concrete answer: to keep their wait states off the shared HREADY.

Finally, HRESP connects the data phase to system robustness. Errors — an access to a faulty region, a protection violation, the default subordinate catching an unmapped address — are reported in the data phase via HRESP. A well-designed system uses these responses to fail cleanly and diagnosably rather than hang. So the data phase is not only where performance is decided but where error handling is realized: the same phase that moves the data also reports when moving it went wrong.

6. Engineering Tradeoffs

The data phase concentrates several of AHB's sharpest tradeoffs, all turning on HREADY and HRESP.

• Wait states: hosting slow subordinates vs stalling the bus. Allowing a subordinate to insert wait states lets a fast bus host slow devices correctly — a real benefit. The cost is that those wait states stall the whole shared bus. The tradeoff is flexibility (any subordinate speed) versus throughput (the shared bus freezes during waits), and it is the reason for the APB-bridge architectural pattern.
• Single shared HREADY: simplicity vs coupling. One completion signal that everyone observes keeps the protocol simple and the timing clean, but it couples every manager to the currently-selected subordinate's readiness. Simplicity bought with coupling — and the coupling is precisely the "slow slave stalls everyone" cost.
• Held data vs buffering. Requiring the manager to hold HWDATA (and the subordinate to hold HRDATA) stable across wait states keeps the design simple — no buffering needed — but it means the driving side is occupied for the whole extended phase. The alternative (buffering to decouple) is exactly the kind of mechanism a more concurrent protocol like AXI introduces, at higher cost.
• Error reporting: clean failure vs protocol complexity. Defining a response sequence for errors (HRESP) lets a manager observe failures unambiguously rather than hang on a bad access — robustness. The cost is a slightly more complex completion protocol (the two-cycle error sequence). AHB pays that complexity to make failures clean.

The unifying theme: the data phase trades throughput and simplicity against flexibility and robustness, all mediated by HREADY and HRESP. Wait states buy the ability to host any subordinate at the price of stalling the bus; the shared HREADY buys simplicity at the price of coupling; HRESP buys clean errors at the price of a defined sequence. These are the trades that make AHB the cheap, predictable, moderately-fast bus it is.

7. Industry Example

Trace a read from a slow peripheral and a read from fast SRAM, and watch HREADY decide everything.

A processor (manager) on an AHB reads first from on-chip SRAM, then from a slower peripheral, while a DMA engine waits for the bus.

• Read from SRAM. Address phase: the processor presents the SRAM address. Data phase: SRAM is fast, so it drives HRDATA and asserts HREADY high in the first data-phase cycle — the beat completes immediately, HRESP OKAY, and the processor captures the data. One-cycle data phase; the bus stays at full speed; the DMA gets the bus right after.
• Read from the slow peripheral. Address phase: the processor presents the peripheral address. Data phase: the peripheral needs time, so it holds HREADY low for a couple of cycles — wait states. During those cycles the processor holds its address-phase control stable and simply waits; the data has not arrived. Critically, the DMA engine, which wanted the bus, is also stalled the whole time, because HREADY low freezes the shared bus. When the peripheral finally asserts HREADY high with HRESP OKAY, it drives HRDATA, the processor captures it, and only now can the bus advance and the DMA be granted.
• The lesson in numbers. If that peripheral is read often, its wait states repeatedly freeze the bus and starve the DMA — a measurable throughput loss attributable entirely to HREADY behaviour. The architectural response, as Module 1 argued and this chapter makes concrete, is to put such a slow device behind an APB bridge so its wait states never reach the AHB's shared HREADY.

Every observable behaviour here — instant completion, wait states, a stalled neighbour, the eventual transfer and OKAY — is read directly off HREADY and HRESP in the data phase. That is the practical skill: given a capture, watch HREADY to know when each beat completes and HRESP to know whether it succeeded.

8. Common Mistakes

9. Interview Insight

The data phase, and HREADY especially, is prime interview territory because it is where candidates reveal whether they understand AHB's timing or just its diagram.

A strong answer centres on HREADY: "In the data phase the payload moves — HWDATA for a write, HRDATA for a read — and HREADY gates it: the beat completes only on a cycle where HREADY is high. A subordinate that needs time holds HREADY low, inserting wait states, during which the manager holds its data and control stable and — because the bus is shared — every other manager is stalled too. HRESP reports OKAY or ERROR at completion." Naming the held-data rule and the global stall shows you understand AHB timing, not just its block diagram.

10. Practice Challenge

Reason from HREADY and the held-data rule.

1. Name the signals. List the four data-phase signals and give each a one-line role. Check against Figure 1.
2. Read the waveform. In Figure 3, state which cycle the write data actually transfers and why, and what the manager is doing during the wait state.
3. Explain the global stall. In three sentences, explain why a single subordinate holding HREADY low stalls managers that are not accessing it.
4. Apply the hold rule. For a write stalled by three wait states, describe exactly what the manager drives and holds during those cycles.
5. Diagnose throughput. A subsystem misses throughput while passing all functional tests; a hot subordinate inserts wait states. Explain the mechanism and give the architectural fix.

11. Key Takeaways

• The data phase moves the payload and completes the access, following the address phase, and can last one or more cycles.
• HREADY gates completion: a beat transfers only on a cycle where HREADY is high. Low HREADY inserts wait states and extends the phase.
• HREADY is a shared completion signal, so one subordinate holding it low freezes the whole bus — the literal mechanism of "a slow slave stalls everyone."
• Held-data rule: across wait states, the manager holds HWDATA and its address-phase control stable (and a read's HRDATA is captured at HREADY-high). Dropping data early corrupts the access.
• HRESP reports OKAY or ERROR at completion; errors use a defined response sequence (detailed in Module 3) so failures are observed cleanly rather than hanging.
• The data phase is where performance and robustness are realized — wait states on hot subordinates leak throughput (the reason slow devices are bridged to APB), and HRESP makes failures diagnosable.

12. What Comes Next

You now know both phases of an AHB transfer. The next chapter puts them together fully — the address and data phases of consecutive transfers overlapping at signal level — and then the module turns to bursts:

• 2.5 — Pipelined Operation (coming soon) — the address and data phases of back-to-back transfers overlapping, and what creates pipeline bubbles.
• 2.6 — Single Transfer vs Burst Transfer (coming soon) — single beats versus multi-beat bursts and when each is used.

To revisit the first half of the transfer and the components behind it, see The Address / Control Phase, AHB Bus Architecture, and Master, Slave, Decoder & Arbiter. For why HREADY stalls matter system-wide, revisit The AHB Mental Model. For the broader protocol map, see the AMBA family overview.