HWDATA & HRDATA

This chapter covers the two data buses — HWDATA (write data) and HRDATA (read data) — the wires that carry the actual payload of every transfer. We touched them in the data-phase chapter (2.4); here we give their precise direction, width, and validity timing, and reinforce the architectural choice introduced in 2.1: AHB uses separate, unidirectional data buses rather than one bidirectional bus. The key behavioural rules — write data held across wait states, read data valid on the HREADY-high cycle, and byte-lane use for sub-word accesses — are what you need to read or drive these buses correctly.

1. What Is It?

HWDATA is the write-data bus: the manager drives it to send data to the subordinate during a write. HRDATA is the read-data bus: the selected subordinate drives it to send data back to the manager during a read.

Their key properties:

• Both are the data-bus width — commonly 32 bits (the same width HSIZE is bounded by).
• They are separate buses and each is unidirectional: HWDATA always flows manager→subordinate, HRDATA always flows subordinate→manager.
• Both move data in the data phase, and both are captured on the cycle HREADY is high (the single sampling instant from chapter 2.4).
• For sub-word accesses, only the active byte lanes (selected by HSIZE and the low address bits) carry meaningful data.

The single most important structural fact is the separate unidirectional design. On many older buses, one bidirectional data bus carries data both ways, which forces "turnaround" cycles when the direction flips and complicates timing. AHB avoids this entirely: write data has its own wires, read data has its own wires, and neither ever changes direction. This costs more wires but eliminates turnaround and simplifies timing — a very AHB tradeoff.

2. Why Does It Exist?

The data buses exist for the obvious reason — something must carry the payload — but the separate unidirectional design exists for a specific performance and simplicity reason worth understanding.

Every bus needs to move data both ways: managers write to subordinates and read from them. The question is how to wire that. Two options:

• One bidirectional bus: the same wires carry write data and read data, with the direction switched per access. This saves wires but requires turnaround cycles — when the bus flips from driving one way to the other, you must insert a cycle (or careful timing) to avoid two drivers contending while one releases and the other takes over. Turnaround wastes cycles and complicates timing closure.
• Two unidirectional buses (AHB's choice): write data on HWDATA, read data on HRDATA, each always flowing one way. No direction ever flips, so there is never any turnaround, and the timing of each bus is simple (one fixed driver each — the manager for HWDATA, the selected subordinate for HRDATA, via the multiplexor).

AHB chose the second because it targets performance and simplicity: eliminating turnaround keeps the pipeline flowing (a read can immediately follow a write with no turnaround bubble) and makes timing closure easier (each bus has a known, fixed direction). The price — more wires — is acceptable for a performance bus, especially on-chip where wires are relatively cheap compared to the timing complexity they save.

So the data buses exist to carry payload, and their separate unidirectional form exists specifically to avoid bidirectional-bus turnaround — trading wires for the cleaner, faster behaviour that lets writes and reads stream without direction-flip penalties. This is the concrete, signal-level form of the architectural point from chapter 2.1.

3. Mental Model

Model the data buses as a delivery chute (write) and a return chute (read), each one-way.

When you write, you drop the goods down the delivery chute (HWDATA) — it only goes from you to the destination. When you read, the goods come up a separate return chute (HRDATA) — it only goes from the destination to you. Because the chutes are separate and each one-way, you can drop something down the delivery chute and immediately receive something up the return chute without waiting for a chute to "switch direction." There is never a moment where a chute is being reconfigured.

The timing detail is when the goods are actually handed over. Watch a write with a wait state, then a read:

The model's lesson: two one-way chutes, and the hand-over happens at HREADY high. For a write, you must keep the goods in the delivery chute (hold HWDATA) until they are taken (HREADY high); for a read, the goods appear in the return chute on the cycle they are taken (HREADY high). No chute ever switches direction, so writes and reads stream without turnaround.

4. Real Hardware Perspective

In hardware, the two buses have fixed drivers and a specific validity discipline tied to HREADY, plus byte-lane handling for sub-word accesses.

HWDATA is driven by the manager. The critical rule, from chapter 2.4: during a write's data phase, the manager must hold HWDATA stable until HREADY is high, because the subordinate captures it at that instant. If the subordinate inserts wait states (HREADY low), HWDATA is held unchanged across them — the manager cannot drop or change it until the write is captured. So HWDATA is valid from the start of the data phase and held through any wait states to the HREADY-high cycle.

HRDATA is driven by the selected subordinate, routed back to the manager through the multiplexor (the same selection that the decoder produces). The discipline is slightly different from HWDATA: HRDATA must be valid on the cycle HREADY is high, when the manager captures it. During wait states (HREADY low) before that, HRDATA need not be valid — the subordinate is still producing it. So there is an asymmetry: write data is held from the start of the data phase, while read data only needs to be valid at the end (the HREADY-high cycle). Both are captured at HREADY high.

Byte lanes apply to both. For a sub-word access (a byte or halfword), only the byte lanes selected by HSIZE and the low address bits carry meaningful data; the other lanes are don't-care. So for a byte write, the manager places the byte on the appropriate lane of HWDATA and the others are ignored; for a byte read, the subordinate drives the relevant lane of HRDATA. This is why HSIZE and the aligned address matter for the data buses — they determine which lanes are live.

The separate unidirectional structure shows up in hardware as the manager always driving HWDATA out and always receiving HRDATA in, with no tristate direction-switching on either bus. The read-data multiplexor selects among subordinates' HRDATA outputs (driven by the decoder's selection), but each subordinate only drives read data; nothing drives write data back. This fixed-direction wiring is what makes turnaround unnecessary and timing clean.

5. System Architecture Perspective

At the system level, the data buses' width and structure are fundamental subsystem parameters, and the separate-bus design interacts with the interconnect.

The data-bus width (the width of HWDATA and HRDATA) is, with the address width, one of the defining parameters of an AHB subsystem. It sets the maximum HSIZE (a beat cannot be wider than the bus) and the per-beat bandwidth (wider bus = more bits per beat). Choosing it balances bandwidth against wiring cost, and HWDATA/HRDATA are the wires that cost scales with. A 32-bit subsystem has 32-bit data buses; a high-bandwidth memory subsystem might have much wider ones. So the data buses are where the subsystem's bandwidth-versus-cost decision physically lives.

The separate read/write buses interact with the multiplexor in the interconnect. HWDATA is broadcast from the (granted) manager toward the subordinates; HRDATA must be selected from the addressed subordinate and routed back, which is exactly the multiplexor's job (using the decoder's selection). So in a multi-subordinate system, HWDATA fans out and HRDATA fans in through the read-data mux. This is cheap and clean precisely because the directions are fixed — the mux only ever routes read data one way, with no bidirectional complications. The separate-bus design and the multiplexor architecture fit together naturally.

There is also a performance consequence at the system level: because there is no turnaround, a stream that mixes reads and writes does not pay direction-switch penalties. A processor that writes then immediately reads, or a DMA doing read-modify-write patterns, flows through the pipeline without turnaround bubbles between the read and write phases. On a bidirectional-bus protocol, such mixed streams would pay turnaround repeatedly; on AHB they do not. So the separate-bus design is a quiet, continuous performance benefit for real mixed traffic, not just a timing-simplicity choice.

6. Engineering Tradeoffs

The data buses embody one major tradeoff (separate vs bidirectional) and a couple of smaller ones.

• Separate unidirectional vs one bidirectional bus. Separate buses eliminate turnaround and simplify timing, at the cost of roughly double the data wires. On-chip, where wires are relatively cheap and timing closure is precious, AHB judges the wires worth spending. A pin-limited off-chip bus might choose bidirectional to save pins; on-chip AHB chooses separate. The trade is wires versus turnaround/timing.
• Data-bus width: bandwidth vs cost. Wider HWDATA/HRDATA move more bits per beat (more bandwidth, larger HSIZE) but cost more wires across the whole interconnect and larger byte-lane logic. The subsystem picks the width its bandwidth needs justify. The trade is per-beat bandwidth versus wiring/area.
• Hold-from-start (write) vs valid-at-end (read). Requiring write data held from the start of the data phase is simple for the subordinate (it can sample any time at HREADY high) but obliges the manager to commit and hold. Requiring read data only at the HREADY-high cycle gives the subordinate time to produce it during wait states. These asymmetric disciplines each suit the direction's natural producer, trading a little asymmetry for each side's convenience.
• Byte lanes vs always-full-width. Supporting sub-word accesses via byte lanes adds lane-selection logic but lets the bus carry bytes and halfwords efficiently, matching processor data types. An always-full-width data bus would be simpler but could not do sub-word accesses cleanly. AHB supports byte lanes because real software needs sub-word access.

The through-line: the data buses trade wires for turnaround-free, simply-timed data movement, and their width is the subsystem's bandwidth knob. The separate unidirectional design is the headline choice, and it pays off continuously in mixed read/write traffic.

7. Industry Example

Trace the data buses through writes and reads, including a mixed stream.

• A word write to SRAM. The processor writes 32 bits to SRAM. In the data phase it drives HWDATA with the value, and since SRAM is fast (HREADY high immediately), the SRAM captures HWDATA that cycle. All four byte lanes are live (a word). One-cycle data phase, no holding needed beyond the single cycle.
• A byte write to a peripheral with a wait state. The processor writes one byte to a peripheral register. It drives the byte on the appropriate lane of HWDATA. The peripheral is slow and inserts a wait state (HREADY low for a cycle), so the processor holds HWDATA across the wait; the peripheral captures it when HREADY goes high. Only the addressed byte lane matters; the others are don't-care.
• A word read from flash. The processor reads 32 bits from flash. The flash subordinate drives HRDATA with the value, routed back through the multiplexor, and it is valid on the HREADY-high cycle when the processor captures it. If flash is slow, it holds HREADY low while producing the data, and HRDATA only needs to be valid on the final HREADY-high cycle.
• A mixed write-then-read stream (no turnaround). A processor does a write immediately followed by a read — common in read-modify-write or back-to-back accesses. Because HWDATA and HRDATA are separate one-way buses, the write's data flows out on HWDATA and the read's data flows back on HRDATA with no turnaround cycle between them; the pipeline flows continuously. On a bidirectional-bus protocol, this write-then-read would cost a turnaround bubble; on AHB it does not.

Every transfer's payload rides one of the two buses — write data out on HWDATA, read data back on HRDATA — captured at HREADY high, with byte lanes selecting the live bytes for sub-word accesses. The mixed stream flowing without turnaround is the separate-bus design delivering its everyday benefit.

8. Common Mistakes

9. Interview Insight

Data-bus questions test the separate-unidirectional design and the validity timing.

The answer that lands names the structure and the timing: "HWDATA carries write data from the manager to the subordinate; HRDATA carries read data from the selected subordinate back to the manager. They are separate, unidirectional buses of the data-bus width, so there are no turnaround cycles — a deliberate AHB choice for clean timing. Both are captured on the HREADY-high cycle, but with an asymmetry: write data must be held stable across wait states until HREADY is high, while read data only needs to be valid on that final cycle." The separate-bus rationale and the hold/valid asymmetry are the senior signals.

10. Practice Challenge

Reason from the separate-bus design and the validity timing.

1. Name the directions. State which way HWDATA and HRDATA each flow and who drives each.
2. Justify the design. In two sentences, explain why separate unidirectional buses avoid turnaround and what they cost.
3. Read the waveform. In Figure 2, identify the cycle the write data is captured and what the manager does during the wait state, and the cycle the read data is captured.
4. Explain the asymmetry. Contrast the validity windows of HWDATA and HRDATA, and why each suits its direction.
5. Diagnose corruption. Writes corrupt only to slow subordinates. Explain how an HWDATA hold-rule violation causes this and why fast subordinates are unaffected.

11. Key Takeaways

• HWDATA carries write data (manager→subordinate); HRDATA carries read data (selected subordinate→manager) — both the data-bus width, commonly 32 bits.
• They are separate, unidirectional buses — neither changes direction, so there are no turnaround cycles and timing is clean, at the cost of more wires than a bidirectional bus.
• Both are captured on the HREADY-high cycle, but with a validity asymmetry: HWDATA is held from the start of the data phase across wait states; HRDATA need only be valid on the final HREADY-high cycle.
• Byte lanes apply: for sub-word accesses only the lanes selected by HSIZE and the address carry meaningful data; the rest are don't-care.
• The data-bus width is a key subsystem parameter — it caps HSIZE and sets per-beat bandwidth, balancing bandwidth against wiring cost; the read-data multiplexor routes HRDATA from the selected subordinate.
• The separate-bus design is a continuous performance benefit — mixed read/write streams flow without turnaround bubbles, unlike a bidirectional bus.

12. What Comes Next

You now know how payload moves. The next chapter covers the most subtle handshake signals — and one of the most important distinctions in multi-subordinate AHB:

• 3.8 — HREADY & HREADYOUT (coming next) — the shared HREADY the whole bus observes versus each subordinate's individual HREADYOUT output, and why the distinction matters.
• 3.9 — HRESP (coming soon) — the response signal and the two-cycle error protocol.

To revisit the data phase these buses serve and the byte-lane rules, see The Data Phase and HSIZE; for the separate-bus architectural origin, see AHB Bus Architecture. For the broader protocol map, see the AMBA family overview.