PWDATA — The Write Data Bus

Module 2 taught you that a write is "captured at completion" and that PWDATA is the value being stored. That is the right role, but to drive PWDATA in a real manager or capture it in a real subordinate you need its exact contract: who owns it, when it is presented, how long it must stay stable, and the single cycle on which it is actually consumed. PWDATA is the manager-driven bus that carries the value to be written — presented from the setup cycle, held stable through the entire access phase, and sampled by the subordinate on exactly one cycle. The single idea to carry: PWDATA is driven for the whole transfer but consumed at one instant — completion — and everything between presentation and that instant is the manager holding the data steady so the subordinate can capture it cleanly.

1. What problem is being solved?

The problem is getting a value from the manager into the subordinate's register, on a bus shared by subordinates that finish at different speeds.

When the control plane writes a configuration register, the value has to travel from the bridge to the addressed subordinate and land in a flip-flop. The naive picture is "put the data on the wires and the register grabs it" — but that hides two hazards. First, the subordinate needs a settled value, not one still changing as it decodes. Second, a slow subordinate may not be ready to commit the moment the data appears, so the data must remain valid until it is ready. APB solves both with one rule on one bus:

• PWDATA is presented early — from the setup cycle — so it is settled and available before the access is performed.
• PWDATA is held stable through the whole access phase, including any wait states, so the value is still valid on the cycle the subordinate finally captures it.

That bus carries the content of a write; PWRITE declares the direction. Together they let one shared bus serve a write to a fast register and a write to a clock-crossing bridge without the manager knowing or caring how long either takes.

2. Why the lifecycle view is not enough

Module 2 named PWDATA as the data captured at completion — where the data lives in the lifecycle. That is true, but a lifecycle role is not a signal contract. To drive PWDATA from a real manager or capture it in a real subordinate, you need its exact electrical behaviour, and the lifecycle view leaves three things unstated:

• When it must be valid, and for how long. The lifecycle says "captured at completion." The signal contract is stricter: PWDATA must be driven from the setup cycle and held stable for every cycle of the access phase, wait states included — not just valid on the completion edge. The manager presents it early and never changes it mid-transfer.
• Who owns it. PWDATA is driven only by the manager (the bridge), for the whole transfer. No subordinate ever drives it. It is a unidirectional, manager-to-subordinate bus, distinct from the subordinate-driven PRDATA read bus.
• When it is meaningful. PWDATA carries a real value only when PWRITE is high. On a read it is a don't-care; a correct subordinate ignores it entirely. The lifecycle's "where the data lives" does not say that the data is only live for half the transfers.

Knowing the role tells you what PWDATA is; knowing the contract tells you what PWDATA must look like on the wire — driven early, held stable, owned by the manager, and consumed at one instant.

3. The signal's mental model

The model: PWDATA is a value placed on the counter and left there until the clerk takes it.

You write the amount on a slip and lay it on the counter the moment you start the transaction (presented in setup). You do not snatch it back or scribble over it while the clerk works — you leave it sitting there, unchanged, however long the clerk takes (held stable through access and any wait states). The clerk picks it up exactly once, when they are ready to file it (captured at completion). The value was available the whole time, but it was consumed at a single instant.

Three refinements make the model precise:

• Presented early, so it is settled. PWDATA is on the bus from the setup cycle — the same cycle the subordinate decodes the address. By the time the access is performed, the data has been stable for a full cycle.
• Held stable until taken. Through the entire access phase — including every wait-state cycle where PREADY is low — the manager holds PWDATA constant. Changing it mid-access would mean the subordinate captures a value that was never the intended write.
• Captured at one instant, not whenever present. The subordinate samples PWDATA on exactly the completion cycle — PSEL, PENABLE, PWRITE, and PREADY all high — not when the data first appears and not on PENABLE alone. Presence is not permission to capture.

4. Real SoC / hardware context

In hardware, PWDATA is one direction of the APB data path. The bridge drives it from whatever the originating transaction supplied — a value from the CPU, a DMA descriptor, a higher-level register write — and routes it, unchanged, to every subordinate's data input. Its width matches the bus data width: 8, 16, or 32 bits in APB3/APB4, the same width as PRDATA. A 32-bit APB has a 32-bit PWDATA; byte-granular writes within that word are expressed with the separate PSTRB write strobes, not by changing PWDATA's width.

On the subordinate side, PWDATA feeds the register write path, and the whole correctness of that path is one gated capture. The subordinate decodes the address during setup, but it must not write its register until the access actually completes — otherwise a wait state would let it capture data before the manager and subordinate have agreed the transfer is finishing.

// APB subordinate write capture (teaching sketch — not a full slave).
// PWDATA is captured into the addressed register on EXACTLY one cycle:
// the completion cycle of a write. Nothing commits before completion.
wire write_commit = psel & penable & pwrite & pready;
 
always_ff @(posedge pclk or negedge presetn) begin
  if (!presetn)
    ctrl_reg <= '0;
  else if (write_commit && (paddr == CTRL_ADDR))
    ctrl_reg <= pwdata;       // sample PWDATA only here, at completion
end

Two facts fall straight out of that one condition. First, write_commit is low for every setup cycle (PENABLE low) and every wait-state cycle (PREADY low), so PWDATA is captured on exactly the completion cycle — never earlier, even though it has been driven on the bus since setup. Second, the PWRITE term means the same capture logic is dormant on reads: PWDATA could be anything during a read and ctrl_reg never moves. The bus can be busy with the data for several cycles, but the flip-flop only ever clocks it once.

5. Engineering tradeoff table

PWDATA is a deliberately simple, one-direction bus. Each property trades a capability APB does not need for the simplicity it does.

The throughline: PWDATA does exactly one job — carry the write value from manager to subordinate — and does it with a bus that is always valid early and held until taken. All the timing-with-the-subordinate is delegated to PREADY; PWDATA just stays steady and waits to be captured.

6. Common RTL / waveform mistakes

7. Interview framing

PWDATA is a clean way for an interviewer to test whether you separate presentation from capture. A weak answer ("it's the write data") proves you know the label; a strong one proves you know the timing contract. Interviewers ask "when is PWDATA valid?" or "when does the subordinate capture the write data?"

The strong answer states the contract, not just the role: PWDATA is the manager-driven write data bus, presented from the setup cycle and held stable through the entire access phase — wait states included — and captured by the subordinate on exactly the completion cycle, where PSEL, PENABLE, PWRITE, and PREADY are all high. Then deliver the two depth points: PWDATA is presented early but consumed once (driven from setup, captured only at completion — never on PENABLE alone), and it is meaningful only on writes (PWRITE high), ignored on reads, and is a separate unidirectional bus from PRDATA. That distinction between "the data is on the bus" and "the data has been captured" is exactly what lets you debug a write that appears to land a cycle early.

8. Q&A

9. Practice

1. Draw the waveform. For a write with one wait state, draw PWRITE, PWDATA, PENABLE, and PREADY across all cycles and mark the single cycle on which the subordinate captures PWDATA.
2. Write the capture. From memory, write the RTL condition a subordinate uses to capture PWDATA into a register, and explain each term in PSEL & PENABLE & PWRITE & PREADY.
3. Spot the bug. A waveform shows PWDATA changing during a wait-state cycle. State which rule is broken and what the subordinate may capture as a result.
4. Separate the buses. In two sentences, explain why PWDATA and PRDATA are separate unidirectional buses rather than one shared bidirectional bus, and what each one's single driver is.
5. Reason about reads. For a read transfer, state what PWDATA carries and why a correct subordinate's register write path stays dormant — name the signal that keeps it dormant.

10. Key takeaways

• PWDATA is the manager-driven write data bus — a unidirectional, manager-to-subordinate path carrying the value to be written, separate from the subordinate-driven PRDATA.
• It is presented from the setup cycle and held stable through the whole access phase, wait states included, so the value is settled early and still valid whenever the subordinate completes.
• It is captured on exactly one cycle — completion. The subordinate samples PWDATA only when PSEL, PENABLE, PWRITE, and PREADY are all high, never when it first appears and never on PENABLE alone.
• It is meaningful only on writes (PWRITE = 1). On a read it is a don't-care, and a correct subordinate ignores it; gating capture on PWRITE keeps the write path dormant on reads.
• Its width is the bus data width (8/16/32 in APB3/APB4), the same width as PRDATA; byte-granular writes are selected with PSTRB, not by changing the bus width.
• Present early, consume once is the contract to remember: the data sits valid on the bus the whole transfer, but the register clocks it exactly once, at completion.