AMBA APB · Module 7

The APB Write Flow

An APB write end to end as a one-way push — the manager presents an address and data and holds them, and the subordinate commits the value into its register on the single completion edge. Data flows manager→subordinate; there is no data return leg.

A read asks a question and waits for the answer to come back. A write is the opposite shape — it pushes a value out and waits only for acknowledgement. This chapter opens Module 7 by walking an APB write as one continuous push: the manager presents an address and data and holds them stable, and the subordinate captures that data into its register on the completion edge — the commit. The single idea to carry: a write is a one-way push in which data flows manager→subordinate, there is no data return leg, and the register changes on exactly one cycle — the completion edge where PSEL, PENABLE, PWRITE, and PREADY are all high. Hold that and every later write-timing chapter is just a closer look at the commit or the acknowledgement.

1. Problem statement

The problem is delivering a value from the manager into a specific register inside a subordinate, with one unambiguous cycle on which that register actually changes — and a way for the subordinate to say "done" or "failed."

A write is not symmetric with a read. On a read the subordinate produces data and the manager consumes it, so the data makes a round trip. On a write the manager produces the data and the subordinate consumes it — a one-way push, with no value travelling back. What does travel back is only acknowledgement: PREADY ("I have taken it / I am ready") and, on APB3+, PSLVERR ("the access failed"). So the write flow has three jobs:

Present (outbound): the manager drives PADDR, PWRITE high, and PWDATA to say "store this value at this address," and holds them stable.
Commit (inside the subordinate): the addressed register captures PWDATA — a single write-enable pulse — on the completion edge.
Acknowledge (inbound): the subordinate drives PREADY to complete and PSLVERR to flag failure. No data returns.

The job APB has to do is make the commit land on a cycle both sides agree on — not when the address appears, not while the subordinate is still busy, but on the one edge the handshake declares the transfer complete.

2. Why previous knowledge is insufficient

You have met the pieces: Module 4 walked a write cycle by cycle, the PWDATA signal gave you its capture-at-completion rule, and Module 6 framed a read as a round trip. Each is correct, but a write engineer needs the connected push, because that is what reveals the three things a per-piece or read-centric view hides:

A write is a push, not a round trip. Reusing the read mental model is the classic error: a write has no data return leg. The manager never waits for data to come back — it waits only for PREADY. The asymmetry changes who drives what and where the latency lives.
The data source is the manager, so the manager owns stability. On a read the subordinate owns PRDATA and its validity; on a write the manager owns PWDATA and must hold it stable from setup through the commit. The single most common write bug is a manager that stops driving PWDATA too early.
The "result" is a state change, not a returned value. A read's result is a value on PRDATA; a write's result is a register that changed inside the subordinate. You cannot see it on the bus — which is exactly why writes are verified with a scoreboard and debugged by reading the register back, not by watching the data lines.

So the model to add is not another signal rule — it is the push: present and hold, commit once, acknowledge with no data back.

3. Mental model

The model: a write is dropping a letter into a mailbox — you hold the letter at the slot, the slot accepts it with a click, and the only thing you get back is the click, not the letter. You never expect the letter to travel back to you; you only need to know it was taken.

You write the address on the envelope and hold the letter at the slot (PADDR, PWRITE high, PWDATA, presented in setup and held). The mailbox is the subordinate's register; the click — the instant the letter is actually accepted — is the commit, on the completion edge. The postal worker behind the slot may be slow (a wait state), so you keep holding the letter at the slot until the click. What comes back to you is only the click (PREADY) and, if the slot is jammed, a "rejected" light (PSLVERR) — never the letter.

Three refinements make the push precise:

You hold the letter until the click. PADDR, PWRITE, and PWDATA are held byte-for-byte from setup through the completion edge. Let go early — stop driving PWDATA before the commit — and the slot accepts whatever is there now, which may be garbage.
The click is one event. The register's write-enable pulses on exactly one cycle: completion, where PSEL, PENABLE, PWRITE, and PREADY are all high. Before it, nothing is stored; the data is merely offered.
Nothing comes back but the acknowledgement. There is no data return leg. The subordinate raises PREADY (taken / ready) and may raise PSLVERR (failed). The manager reads those, not a value.

Figure 1 — an APB write as a one-way push from manager to subordinate. Outbound, the manager presents PADDR, PWRITE high, and PWDATA (the value to store) and asserts PSEL then PENABLE, holding the address and data stable; the push crosses the bus to the subordinate. Inside the subordinate, the address decodes to a register and, on the completion edge, that register captures PWDATA — a single write-enable pulse, the commit. Inbound, the subordinate returns only acknowledgement: PREADY when it has accepted the write, and PSLVERR if the access failed — no data travels back. The figure stresses that write data flows manager-to-subordinate, that the register changes on exactly one cycle (the commit), and that the only return is the handshake, not a value.

4. Real SoC implementation

In silicon the write flow is a registered capture inside the subordinate, driven by held signals from the manager. The manager registers the request (drives PADDR/PWRITE/PWDATA and sequences PSEL/PENABLE from its FSM) and holds them; the subordinate gates a single write-enable on the completion edge and clocks PWDATA into the addressed flop.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Subordinate write commit: the register changes on EXACTLY one edge.
// write_commit is high only on the completion cycle of a write — PSEL, PENABLE,
// PWRITE, and PREADY all high. PADDR is held stable across access, so the decode
// is settled by then; PWDATA is held stable, so the captured value is correct.
wire write_commit = psel & penable & pwrite & pready;   // the one commit edge
 
always_ff @(posedge pclk or negedge presetn) begin
  if (!presetn) begin
    ctrl_q <= '0;
    baud_q <= '0;
  end else if (write_commit) begin
    case (paddr)
      ADDR_CTRL: ctrl_q <= pwdata;        // commit here, and only here
      ADDR_BAUD: baud_q <= pwdata;
      default:   /* unmapped write: no side effect */ ;
    endcase
  end
  // NOTE: there is no other path that writes ctrl_q/baud_q. The register can
  // ONLY change on write_commit — that absence of other write paths IS the
  // guarantee that nothing commits early, late, or twice.
end

Two facts make the push robust. First, because PADDR and PWDATA are held stable from setup through completion, the address decode (case (paddr)) is settled and the captured value is the intended one — the subordinate just pulses the write-enable on the completion edge. Second, the write-enable is the only path that updates the register, so the register changes exactly once per write and never on a wait cycle. (The detailed timing of each piece is the rest of this module: PWDATA timing, the write completion contract, and write wait states.)

Figure 2 — a complete zero-wait APB write walked IDLE to IDLE against PCLK. In IDLE, PSEL is low. SETUP raises PSEL, presents PADDR, drives PWRITE high (a write), and presents PWDATA — the value is offered but not yet stored — while PENABLE stays low. ACCESS raises PENABLE; because the subordinate is ready, PREADY is high on this same cycle, so PSEL, PENABLE, PWRITE, and PREADY are all high — the commit edge, marked with a dashed line, where the register captures PWDATA. PWDATA and PADDR are held stable as one continuous band from setup through the commit. After commit the bus returns to IDLE. The waveform makes the push concrete: present and hold in setup, commit on the one completion edge, and no data returns — only PREADY acknowledges.

5. Engineering tradeoffs

Laying a write out as a held one-way push with a single commit edge is deliberate and minimal. Each property trades a capability APB does not need for the clarity it does.

Write-flow property	What it gives up	What it buys	Why it is correct for APB
One-way push, no data return	Read-after-write in one transfer	A trivially simple write path	A write only needs to deliver and be acknowledged
Manager holds `PWDATA` stable	Just-in-time data	A value guaranteed good on whatever cycle commits	One capture rule works at any subordinate speed
Commit on one edge only	A spread-out write	An unambiguous "the register changed here"	A single write-enable pulse, easy to build and verify
Acknowledge via `PREADY`/`PSLVERR`	A rich response payload	A two-signal ack with no return bus	Sparse control writes need no return data path
`PWRITE` high set in setup, held	Mid-transfer direction change	Direction fixed before any commit	One decode of write-vs-read per transfer

The throughline: an APB write spends a held push and one commit edge and gains a flow identical whether the subordinate is instant or slow — only the acknowledgement is delayed, never the data, because there is no data to wait for. The commit edge is the single state-change landmark, which is why an APB write is small to build and easy to verify.

6. Common RTL mistakes

Misconceptions to unlearn

"A write is like a read in reverse, so it has a return leg." No. A write has no data return leg. The manager pushes PWDATA and waits only for PREADY/PSLVERR; nothing comes back on the data bus.
"The subordinate drives the write data." No. On a write the manager drives PWDATA; the subordinate captures it. PRDATA is unused on a write.
"Commit the write when PENABLE goes high." No. PENABLE high marks the access phase, which can include wait cycles. The register must commit only on the completion edge — PSEL & PENABLE & PWRITE & PREADY.
"PWDATA only matters on the commit cycle, so I can drive it late." No. It must be valid and stable from setup through the commit; you cannot predict which access cycle completes, and a faster-than-expected subordinate captures whatever is there.
"An unmapped write is harmless to ignore silently." It is harmless to the register, but it should produce no side effect and ideally a defined response (PSLVERR in a strict design); silently dropping it without a decode is fine, leaving registers floating is not.
"The write is done when I see PREADY — I do not need to confirm it landed." In bring-up you do: a write can complete on the bus yet not commit if the write-enable is misgated. Read the register back, or scoreboard it.

7. Debugging scenario

A write that "completes" on the bus but never changes the register is the canonical APB write bug — and it is invisible on the data lines, because a write has no return leg.

Observed symptom: firmware writes a configuration register (say, a baud divisor), but the peripheral behaves as if unconfigured, and a read-back of the same register returns its old value. The write "doesn't stick."
Waveform clue: the write transfer looks complete — PSEL, PENABLE, PWRITE, and PREADY all high on the completion edge (Figure 2's dashed line) — but the register's internal write-enable never pulses there, or pulses a cycle early during a wait when PREADY was still low.
Root cause: the subordinate gated its register update on a subset of the commit — PSEL alone, or PENABLE alone — instead of the full write_commit. With a wait state, the misgated enable fires on the wrong cycle or, with a wrong address-decode comparison, never fires for that register at all.
Correct RTL: gate every register update on the full commit term: wire write_commit = psel & penable & pwrite & pready; then if (write_commit) case (paddr) ... endcase — the register changes only on that edge, only for the matched address.
Verification assertion: bind a check that the register only changes on a commit, and that a write is observed: assert property (@(posedge pclk) $changed(ctrl_q) |-> (write_commit && paddr == ADDR_CTRL)); plus a scoreboard write-then-read-back that fails if the read does not return the written value.
Debug habit: when a write "doesn't stick," do not stare at PWDATA — check the register's write-enable pulse against the completion edge first: is it firing at all, and on the exact cycle PSEL & PENABLE & PWRITE & PREADY is high? Nine times in ten the enable is misgated or the address decode is off by a bit.

Figure 3 — the 'write doesn't stick' bug. Both rows are the same write with one wait state; PSEL, PENABLE, PWRITE, PADDR, and PWDATA are identical. Top (correct, green): the register write-enable pulses on the completion edge where PREADY is high, so the register captures PWDATA and a read-back returns the new value. Bottom (bug, red): the write-enable was gated on PENABLE alone, so it pulsed a cycle early — during the wait, when PREADY was still low — and the completion edge passes with no pulse, so the register keeps its old value and the write silently does nothing. The figure shows that a transfer can look complete on the bus while the commit never lands, which is why the write-enable pulse, not the data lines, is where you debug a lost write.

8. Verification perspective

A write's result is a hidden state change, so verification cannot watch it on the bus — it must predict it. The standard structure is a reference model plus a scoreboard: a model of the register file that the testbench updates on every write commit, and a comparison on every read.

Model the commit, not the access. On each write_commit (the monitor sees PSEL & PENABLE & PWRITE & PREADY), the reference model updates model_reg[paddr] = pwdata. On each read completion, the scoreboard compares PRDATA to model_reg[paddr]. A misgated or mistimed commit shows up as a read mismatch — the very symptom of the debug scenario above, now caught automatically.
Assert the commit is exact. Two properties cover most write bugs: the register changes only on a commit ($changed(reg) |-> write_commit), and a write commits exactly once per transfer (no double-pulse across a wait). Bind them per register or generate them from the register map.
Cover the corners that hide write bugs. Coverage should hit: a write to every register, a write-then-immediate-read-back, a write with wait states, a write with PSLVERR, and a write whose PWDATA changes value between back-to-back transfers (to catch a stale-data capture). Functional coverage on write_commit && paddr per register closes the "did we ever write this one" gap.

The point: because the effect is invisible on the bus, the scoreboard is the test. A write monitor that only checks PREADY rose has verified nothing about whether the right value reached the right register.

9. Interview discussion

"Walk me through an APB write" is a staple, and the strong answer leads with the push, not a signal list. A weak answer recites PWDATA and PREADY; a strong one shows you understand one-way data flow and where the state change is.

Lead with the shape: a write is a one-way push where data flows manager→subordinate, committed on a single edge, with no data return. Then walk it: setup presents PADDR, PWRITE high, and PWDATA and holds them; access raises PENABLE; the commit is the cycle PSEL & PENABLE & PWRITE & PREADY are all high, where the subordinate's write-enable pulses and the register captures PWDATA; the only thing that returns is PREADY (and PSLVERR). Then deliver the two depth points that separate levels: the manager owns PWDATA and must hold it stable until the commit (a read's data is subordinate-owned, the mirror image), and a write's result is a hidden state change, so you verify it with a scoreboard and debug it by reading the register back — you cannot see the commit on the data bus. Volunteering "for a write, PWRITE is high, PWDATA carries the value out, and PRDATA is unused" signals you think in data-flow direction.

10. Practice

Trace the push. From IDLE, narrate an APB write's present, commit, and acknowledge legs, naming the signal active in each and the exact cycle the register changes.
Name the owner. State which side drives PADDR, PWRITE, PWDATA, PREADY, and PSLVERR on a write, and which signal (PRDATA) is unused and why.
Place the commit. On a zero-wait write waveform, mark the one cycle the register changes and state what is stored on every earlier cycle.
Write the gate. From memory, write write_commit and the always_ff that commits PWDATA into one register, and explain why gating on PENABLE alone is wrong under a wait state.
Catch the lost write. Describe the assertion and the scoreboard check that would have caught a "write doesn't stick" bug before silicon, and what each compares.

11. Q&A

12. Key takeaways

An APB write is a one-way push — the manager presents an address and data and the subordinate commits the value into its register. Data flows manager→subordinate; there is no data return leg.
The manager owns PWDATA and must hold it (with PADDR and PWRITE) stable from setup through the commit. The subordinate captures; PRDATA is unused.
The register changes on exactly one edge — the commit, where PSEL, PENABLE, PWRITE, and PREADY are all high — via a single write-enable pulse. Nothing commits earlier or twice.
The only thing that returns is acknowledgement — PREADY (taken / ready) and PSLVERR (failed). A write waits for the ack, never for data.
A write's result is invisible on the bus, so verify it with a scoreboard (model on commit, compare on read) and debug it by checking the write-enable pulse against the completion edge — not by staring at PWDATA.
Gate every commit on the full term psel & penable & pwrite & pready; gating on a subset is the "write doesn't stick" bug, and it only shows up under a wait state.