Write Transfer Timing

This chapter walks a write transfer cycle by cycle — the counterpart to the read (5.4), and the place where the data-timing asymmetry and control/data alignment are most visible. A write is the direction where the master drives the data: it puts HWDATA on the bus in the data phase and holds it stable until the subordinate captures it. We trace a clean write, then a write with a wait state showing the held-data rule, and reinforce the control/data alignment (the write's address and control are one cycle before its HWDATA). Reads and writes share the two-phase structure; they differ in who drives the data and when it must be valid, and this chapter pins down the write side.

1. What Is It?

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

• Address phase (cycle N): the master drives HADDR, HWRITE = 1 (write), and the control (HSIZE, HBURST, HPROT). The decoder selects the subordinate.
• Data phase (cycle N+1): the master drives HWDATA with the write data and holds it stable until HREADY is high, when the subordinate captures it.

The defining features of a write: the master drives the data (HWDATA, master → subordinate), and — the write-specific timing (chapter 3.7) — HWDATA is held stable from the start of the data phase until HREADY is high. This is the opposite obligation from a read (where HRDATA is valid only at the end): for a write, the master holds the data throughout the data phase, because it already has the value and the subordinate may capture it at any HREADY-high cycle.

2. Why Does It Exist?

The write timing is the way it is because the master is the data source for a write, and the master already has the data — so it drives HWDATA immediately and holds it until the subordinate is ready to take it.

For a write, the master is writing a value it already possesses (a register value, a computed result, a buffer entry). Unlike a read — where the subordinate must fetch the data and may need time — the master has the write data ready at once. So the master drives HWDATA from the start of the data phase and holds it until the subordinate captures it. The subordinate, which may be slow, captures the held data whenever it is ready (the HREADY-high cycle). So the write protocol puts the holding obligation on the master (the producer that has the data ready) and lets the subordinate (the consumer) capture at its own pace via wait states. This matches the data source: the master has the data, so it holds it.

This is the mirror image of the read (5.4): on a read, the subordinate is the producer and may need time, so the data is valid at the end; on a write, the master is the producer and has the data, so the data is held from the start. The asymmetry is not arbitrary — it reflects which side produces the data and whether that side has it ready. The producer's timing obligation matches its situation: a read producer (subordinate) gets time; a write producer (master) holds. Understanding this symmetry-by-data-source unifies read and write timing.

The held-data rule specifically exists because the subordinate captures the write data on the HREADY-high cycle, which may be after wait states. The subordinate has not captured the data while HREADY is low; it only captures on the HREADY-high cycle. So the master must keep HWDATA valid and unchanged through the entire data phase, including the wait states, until that capture. If the master dropped or changed HWDATA before HREADY went high, the subordinate would capture wrong or stale data. So the held-data rule exists to guarantee the data is still correct at the (possibly delayed) moment of capture — a direct consequence of the subordinate capturing at HREADY-high and the master being the data holder.

3. Mental Model

Model a write as handing someone a parcel and keeping your hand out until they take it.

You (the master) have the parcel ready (the write data) and extend it (drive HWDATA from the start of the data phase). The recipient (the subordinate) takes it when they are ready — maybe immediately, maybe after a moment (wait states). Crucially, you keep your hand out, holding the parcel steady, until they actually take it — you do not pull it back or swap it (hold HWDATA stable until HREADY high). If you withdrew the parcel before they grasped it, they would grab nothing or the wrong thing (corrupted write). So you hold the parcel out, unchanged, until the recipient takes it.

This captures the write timing: the master has the data and offers it immediately (drive from the start), the subordinate captures when ready (HREADY high, possibly after wait states), and the master holds the data stable until then (the held-data rule). Contrast the read (the kitchen producing a dish): there, the producer (subordinate) needs time and delivers at the end; here, the producer (master) has it ready and holds it out.

Watch a write with a wait state:

The model's lesson: hold the parcel out until they take it — the master drives HWDATA from the start of the data phase and holds it stable across wait states until the subordinate captures it at HREADY high. In the waveform, DA is held through T1 (wait) and captured at T2. Dropping DA before T2 would corrupt the write.

4. Real Hardware Perspective

In hardware, a write is the master driving HWDATA on the data bus and holding it via the held-data rule, with the subordinate capturing on the HREADY-high edge — and the control/data alignment is most visible here.

In the address phase, the master drives HADDR, HWRITE = 1, and control; the decoder selects the subordinate. In the data phase, the master drives HWDATA on the (separate, unidirectional) write-data bus and registers it stable, holding the same value while HREADY is low and until HREADY is high. The subordinate captures HWDATA on the HREADY-high edge into its target (memory cell, register). So the hardware flow is: master drives and holds HWDATA; subordinate captures at HREADY-high. The held-data rule is the master's obligation to keep its HWDATA register unchanged across the wait states.

The control/data alignment (chapter 5.3) is most visible on a write because HWDATA is plainly in the data phase while HWRITE/HADDR/HSIZE were in the address phase one cycle earlier. So to know where a write's data goes and its size, you look at the address-phase control one cycle before the HWDATA. A subordinate latches that address-phase control and applies it when it captures HWDATA — directing the data to the right address with the right byte lanes. This is the latch-then-apply from 5.3, made concrete for a write: the subordinate uses the latched HADDR/HSIZE to place the captured HWDATA correctly.

The held-data rule is the write-specific hardware obligation, and its violation is a classic bug (chapter 3.7). If the master fails to hold HWDATA — drops it, or advances to the next transfer's data — before the subordinate captures it (HREADY high), the subordinate captures wrong or stale data. This matters specifically when there are wait states: with a fast subordinate (HREADY high immediately), the master only drives HWDATA for one cycle and the issue does not arise; with a slow subordinate (wait states), the master must hold HWDATA across the extra cycles. So write bugs from violating the held-data rule appear only with slow subordinates, which is the diagnostic signature (chapter 3.7).

A hardware note on the separate write-data bus (chapters 2.1, 3.7): HWDATA is its own unidirectional bus (master → subordinate), distinct from HRDATA. So a write drives HWDATA and a read drives HRDATA — no turnaround between them, and the master's write-data path is always master-to-subordinate. This is why the master can simply drive and hold HWDATA without contending with read data — the buses are separate.

5. System Architecture Perspective

At the system level, write timing involves the held-data discipline across the system and interacts with write buffering for performance.

Every master that writes must honour the held-data rule — hold HWDATA stable from the start of the data phase until HREADY high. This is a system-wide discipline: a master from any source, writing to any subordinate, must hold its write data correctly, especially across the wait states slow subordinates insert. So write correctness is a shared contract: masters hold, subordinates capture at HREADY-high. A protocol checker verifies that HWDATA is stable across the data phase (including wait states) until capture — making the held-data rule a checkable system property. This matters because held-data violations are intermittent (only with slow subordinates) and can escape minimal testing.

Write timing also interacts with write performance and buffering. Because a write's data phase can be extended by a slow subordinate's wait states, a master writing to a slow subordinate stalls during those waits (it is holding HWDATA, waiting for capture). To avoid stalling on slow writes, systems sometimes use write buffers (recall HPROT's bufferable bit, chapter 3.6): a write buffer can accept the write quickly (capturing HWDATA) and complete the actual slow write to the subordinate later, letting the master proceed. So the bufferable attribute connects to write timing: it is a way to decouple the master from a slow subordinate's write wait states. Write timing thus shapes whether write buffering is beneficial — slow writes on a hot path motivate buffering.

The write/read asymmetry has a system implication for the data buses: because writes drive HWDATA (master → subordinate) and reads drive HRDATA (subordinate → manager) on separate buses, a system can have a write and a read in flight on different buses without turnaround (chapter 3.7). So mixed read/write streams flow without direction-switch penalties — a system-level benefit of the separate-bus design that write timing relies on. The master always drives HWDATA out; the subordinate always drives HRDATA back; no contention. This is part of why AHB handles mixed traffic efficiently.

So at the system level, write timing imposes the held-data discipline (a checkable correctness contract), motivates write buffering (to avoid stalling on slow writes), and benefits from the separate write-data bus (no turnaround in mixed streams). It is where write correctness and write performance are set.

6. Engineering Tradeoffs

Write timing reflects the master-as-producer-with-data-ready choice.

• Held-from-start (write) vs valid-at-end (read). Requiring the master to hold HWDATA from the start of the data phase is natural (the master has the data) and lets the subordinate capture at its own pace, at the cost of the master being occupied holding the data during wait states. This matches the write's data source (the master has the data ready) and is the correct counterpart to the read's valid-at-end. The asymmetry is right.
• Master stalls on slow writes vs write buffering. Without buffering, a master writing to a slow subordinate stalls (holding HWDATA through the waits). A write buffer avoids the stall by capturing the write quickly and completing it later, at the cost of buffer logic and weaker ordering (the write completes asynchronously). The bufferable attribute (HPROT) chooses per access. The trade is master stall versus buffer complexity/ordering.
• Separate write-data bus vs shared. The separate HWDATA bus (master → subordinate) avoids turnaround with reads, at the cost of more wires (the separate-bus trade, chapter 3.7). For writes specifically, it means the master always drives HWDATA out with no direction-switching. AHB spends the wires.
• Strict held-data rule vs lenient. Enforcing the held-data rule strictly (HWDATA stable until HREADY high) guarantees write correctness across wait states, at the cost of requiring masters to implement the hold. There is no useful leniency — relaxing it corrupts writes to slow subordinates. The strict rule is simply correct.

The throughline: write timing puts the holding obligation on the master (which has the data) and lets the subordinate capture at HREADY-high, the mirror of the read's valid-at-end. The held-data rule is a strict correctness requirement; write buffering is the optional performance escape from stalling on slow writes; and the separate write-data bus is what lets writes and reads coexist without turnaround.

7. Industry Example

Trace writes through a fast SRAM and a slow peripheral.

• A fast write (single-cycle SRAM). The processor writes a word to SRAM. Address phase: HADDR = A, HWRITE = 1, HSIZE = word. Data phase (next cycle): the master drives HWDATA = the value; SRAM is fast, so HREADY is high immediately and SRAM captures the data that cycle. The master only had to drive HWDATA for one cycle — no holding across waits needed. The write completes in the minimum time.
• A slow write (peripheral with wait states). The processor writes a byte to a slow peripheral register. Address phase: HADDR = the register, HWRITE = 1, HSIZE = byte. Data phase: the master drives HWDATA = the byte; the peripheral is slow and holds HREADY low for a couple of cycles (wait states). The master holds HWDATA stable across the waits; the peripheral captures it when HREADY goes high. The master stalled during the waits (holding the data), and the write completed correctly because HWDATA was held until capture.
• The held-data rule in action. If the master had dropped HWDATA after one cycle (not holding it across the peripheral's wait states), the peripheral would have captured wrong data when HREADY finally went high — a silent corruption, occurring only on this slow peripheral, not on the fast SRAM. The correct master holds HWDATA, so the slow write is correct. This selective-by-slowness behaviour is the diagnostic tell of the bug.
• Control/data alignment on the capture. When the engineer checks where the byte write went, they look at the address-phase control one cycle before the HWDATA (chapter 5.3): HADDR = the register, HSIZE = byte. The peripheral latched that address-phase control and used it to place the captured HWDATA into the right register and byte lane. Reading the write correctly means aligning the HWDATA with the address one cycle earlier.
• The buffering option. If the processor wrote to this slow peripheral frequently and the stalls hurt, the system might mark the region bufferable (HPROT) and add a write buffer, so the writes complete quickly into the buffer and the slow actual writes happen later — avoiding the master stall. Write timing motivates this optimization.

The writes show the timing: fast subordinates capture immediately (minimum time), slow ones insert wait states (master holds HWDATA, stalls), and the held-data rule ensures correctness across the waits. The master-as-producer-with-data-ready model — drive and hold — governs throughout.

8. Common Mistakes

9. Interview Insight

Write-timing questions test the master-drives-data direction and the held-from-start rule.

The answer that lands walks both phases with the write-specific timing: "A write has an address phase where the master drives HADDR, HWRITE = 1, and control, and the decoder selects the subordinate. Then, one cycle later, the data phase: the master drives HWDATA and holds it stable until HREADY is high, when the subordinate captures it. The write-specific point is that the master holds the data from the start of the data phase — because it already has the value — across any wait states until capture. That's the opposite of a read, where the subordinate produces the data and it's only valid at the end. And to find the write's destination, you look at the address one cycle before the HWDATA." The master-drives-data direction, the held-from-start rule, and the read/write asymmetry are the senior signals.

10. Practice Challenge

Reason from the master-drives-data, held-from-start timing.

1. Walk a write. Describe the two phases of a write, naming who drives what each cycle.
2. State the hold rule. Say how long the master must hold HWDATA and why.
3. Read the waveform. From Figure 2, identify when the data is captured and what the master does during the wait state.
4. Contrast with read. Explain the read/write data-timing asymmetry and its cause.
5. Diagnose corruption. Writes corrupt only to slow subordinates. Explain the held-data violation and the fix.

11. Key Takeaways

• A write has an address phase (master drives HADDR, HWRITE = 1, control) then a data phase one cycle later where the master drives HWDATA.
• The master drives the write data (master → subordinate) and holds it stable from the start of the data phase until HREADY high, when the subordinate captures it.
• The held-data rule is the write-specific obligation: HWDATA stable across wait states until capture. Dropping it early corrupts the write.
• Write data held from the start; read data valid at the end — mirror images reflecting which side produces the data (master has it; subordinate produces it).
• Held-data violations corrupt writes selectively to slow subordinates (those with wait states); fast subordinates capture in one cycle and mask the bug.
• Control/data alignment is most visible on writes — the write's address and size are one cycle before the HWDATA; write buffering (bufferable) can decouple the master from slow-subordinate write stalls.

12. What Comes Next

You now know both read and write timing. The next chapter examines what the phase overlap can create and how AHB avoids it:

• 5.6 — Pipeline Hazards (coming next) — the hazards the address/data overlap creates and how AHB's in-order, single-path design avoids them.
• 5.7 — Phase Waveform Interpretation (coming soon) — reading the two-phase pipeline straight off a waveform.

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