AMBA APB · Module 4

Transfer Completion Rules

The single contract for when an APB transfer completes — PSEL and PENABLE and PREADY all high — and everything that hinges on it: write commit, read-data validity, PSLVERR sampling, and signal stability.

This is the chapter that ties Module 4 together. Across the module you have watched a transfer move through IDLE, SETUP, and ACCESS, and seen wait states stretch it. The question that governs all of it is a single one: when, exactly, is the transfer complete? APB answers with one unambiguous contract — a transfer completes on the cycle where PSEL, PENABLE, and PREADY are all high — and almost every APB timing rule is a corollary of it. The single idea to carry: there is exactly one completion edge per transfer, and a write commit, read-data validity, PSLVERR sampling, and the release of stable signals all happen there and nowhere else.

1. What problem is being solved?

The problem is giving the manager and the subordinate one cycle they both agree is "the transfer happened" — so that data is captured, sampled, and reported at exactly the same instant on both sides.

A transfer touches many signals over several cycles: an address is presented, an enable rises, data sits on the bus, a ready handshake is watched. If "done" were fuzzy, the two ends would disagree about when the write landed or when the read data was valid, and every design would invent its own timing. APB removes the ambiguity by defining a single completion condition that is true on exactly one cycle of any legal transfer:

PSEL high — a subordinate is selected; this transfer is real and aimed somewhere.
PENABLE high — the bus is in the access phase; the access is being performed.
PREADY high — the subordinate declares it is ready; the access finishes now.

All three high on the same rising edge is completion. Not two of them, not "the access phase," not "the address appeared" — the conjunction, on one edge. Everything else in this module is what that edge causes.

2. Why the previous model is not enough

You already have two correct partial pictures: the lifecycle FSM (IDLE → SETUP → ACCESS) and the individual signals (PENABLE, PREADY, PSLVERR). Each is right, but neither by itself tells you the one thing every block keys off: the exact completion edge and everything that fires on it.

The danger is reasoning from a single signal and getting the timing subtly wrong:

PENABLE high is not completion. The access phase can span many cycles when the subordinate inserts wait states; PENABLE is high for all of them. Commit on PENABLE alone and you capture data during a wait, before the subordinate is ready.
"The address appeared" is not completion. The address is valid from SETUP onward — cycles before anything commits. Treating address-time as the event captures writes that never landed and samples read data that does not yet exist.
The events are not independent. Write commit, read-data validity, PSLVERR sampling, and signal-stability release are not four separate timing rules to memorise — they are one rule (the completion edge) seen four ways. The completion contract is what unifies them, which no single-signal view gives you.

So the model to add is not another phase or another signal; it is the one condition that says now, and the discipline of hanging every commit and every sample on it.

3. Mental model

The model: PSEL & PENABLE & PREADY is the referee's whistle — the transfer counts only when the whistle blows, and everything happens on the whistle.

In a race, the runners can be in position, moving, even at the line — but nothing is official until the whistle. APB's whistle is the conjunction of three conditions: a runner is entered (PSEL), the race is underway (PENABLE), and the finish is confirmed (PREADY). Before the whistle, signals are presented and held but nothing is recorded. On the whistle, the result is logged: the write is written, the read time is read, the pass/fail (PSLVERR) is noted. After the whistle, the slate clears for the next race.

Three refinements make the model precise:

One whistle per transfer. There is exactly one completion edge. A transfer with wait states still has exactly one — the first access cycle where PREADY is high. Every later analysis ("when did X happen?") resolves to that edge.
Everything fires on the whistle, nothing before. Write capture, read-data validity, and PSLVERR are all defined at completion. A correct subordinate gates every committing action on the same PSEL & PENABLE & PREADY term, never on a subset.
The whistle also releases the held signals. PADDR, PWRITE, PWDATA, and PSEL must stay stable up to and including the completion edge; only after it may they change (for the next transfer or back to IDLE). Stability is defined relative to completion, not to a fixed cycle count.

Figure 1 — the completion condition and everything that hinges on it. The centre shows the one rule: PSEL AND PENABLE AND PREADY, all high on the same PCLK edge, equals completion. Radiating from it are the four consequences that all fire on that single edge: a write is captured (PWDATA into the register), read data is valid and sampled (PRDATA), the error status is sampled (PSLVERR), and the held signals (PADDR, PWRITE, PWDATA, PSEL) are released for the next transfer. The figure stresses that these are not four independent timing rules but one completion edge seen four ways.

4. Real SoC / hardware context

In RTL, the completion condition is one wire that the whole subordinate and the manager's sampling logic key off. Naming it once and reusing it everywhere is exactly how a correct APB block is built.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// The APB completion event — one wire the whole design hangs off.
// True on EXACTLY one cycle per transfer: the access cycle where the
// subordinate is ready. (PWRITE splits it into the write/read variants.)
wire access_complete = psel & penable & pready;          // the completion edge
wire write_commit    = access_complete &  pwrite;        // capture PWDATA here
wire read_commit     = access_complete & ~pwrite;        // PRDATA valid/sampled here
 
// Subordinate: capture a write ONLY at completion (never on PENABLE alone).
always_ff @(posedge pclk or negedge presetn) begin
  if (!presetn)            ctrl_q <= '0;
  else if (write_commit && (paddr == CTRL_ADDR))
                           ctrl_q <= pwdata;
end
 
// Error and read data are likewise defined AT completion:
//   - pslverr is sampled by the manager when access_complete is high
//   - prdata is only required valid when read_commit is high

Two facts make this robust. First, access_complete is low for every SETUP cycle (PENABLE low) and every wait cycle (PREADY low), so anything gated on it acts exactly once, at the right edge — the wait-state behaviour is handled for free. Second, because the manager samples PRDATA and PSLVERR on the same edge the subordinate commits a write, the two ends never disagree about when the transfer happened.

The completion contract is also the natural thing to assert in verification. Two properties capture most of the module's rules — that the access-defining signals hold stable until completion, and that PENABLE is never high without PSEL:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// SVA: while a started transfer has not yet completed, the address/control/
// write data must not change (stability until completion).
property p_stable_until_complete;
  @(posedge pclk) disable iff (!presetn)
  (psel && penable && !pready) |=>
      $stable(paddr) && $stable(pwrite) && $stable(pwdata) && $stable(psel);
endproperty
assert property (p_stable_until_complete);
 
// SVA: PENABLE is only ever high inside a selected access (no enable without select).
assert property (@(posedge pclk) disable iff (!presetn) penable |-> psel);

These are not production verification IP — they are the completion and stability rules written as checks, which is exactly how a team turns "the spec says X" into something the simulator enforces.

Figure 2 — locating the one completion edge in a transfer with two wait states, against PCLK. The phase bands read IDLE, SETUP, then ACCESS spanning three cycles: two WAIT cycles where PREADY is low and a final COMPLETE cycle where PREADY is high. PSEL and PENABLE are high across all three access cycles, but the dashed completion marker sits only on the third — the single cycle where PSEL, PENABLE, and PREADY are all high. The annotation shows that the held signals (PADDR, PWDATA) are stable across the whole access and that the write commits, or PRDATA/PSLVERR are sampled, only on that marked edge.

5. Engineering tradeoff table

Defining completion as a single three-signal conjunction is a deliberate choice. Each property trades a capability APB does not need for the certainty it does.

Completion rule	What it gives up	What it buys	Why it is correct for APB
`PSEL & PENABLE & PREADY`, one edge	A simpler "one signal = done"	An unambiguous, single commit point	No two blocks can disagree about when it happened
Everything fires at completion	Spreading events across cycles	One rule, four consequences — easy to verify	A subordinate gates every commit on one term
*Stability defined until* completion**	A fixed-latency, countable window	Correctness regardless of wait-state count	The access can take any number of cycles
`PSLVERR` / `PRDATA` valid only at completion	Early-available status / data	No sampling of stale or undriven values	One safe sample edge for the manager
Completion can flow straight to the next SETUP	None real	Adjacent transfers with no idle gap	Sparse traffic still benefits from back-to-back

The throughline: APB spends nothing and gains certainty. By collapsing "when did it happen?" into one edge, it makes write commit, read sampling, error reporting, and stability the same rule — which is why a correct APB block is small and an APB waveform is easy to read.

6. Common RTL / waveform mistakes

Misconceptions to unlearn

"PENABLE high means the transfer completed." No. PENABLE marks the access phase, which includes every wait cycle. Completion also needs PREADY high — the conjunction PSEL & PENABLE & PREADY.
"The transfer completes when the address appears." No. The address is valid from SETUP, cycles before completion. Nothing commits until the completion edge in ACCESS.
"With wait states there are several completion cycles." No. There is exactly one — the first access cycle where PREADY is high. The wait cycles (PREADY low) are not completions.
"PSLVERR / PRDATA can be sampled any time in ACCESS." No. Both are only meaningful on the completion edge. Sampling during a wait reads undefined status or data.
"Signals can change after PENABLE rises." No. PADDR, PWRITE, PWDATA, and PSEL must hold stable through every access cycle until completion, including across wait states. Changing them mid-access corrupts the transfer.
"Back-to-back completion means APB is pipelined." No. Completion may flow directly to the next SETUP with no IDLE, but the next access never overlaps the current one. Adjacent is not pipelined.

7. Interview framing

This is the APB timing question that separates "I know the signals" from "I know the protocol." Interviewers ask "when does an APB transfer complete?" or "what exactly happens on the completion cycle?" — and a precise answer demonstrates you can build or debug a real interface.

Lead with the one contract: a transfer completes on the single cycle where PSEL, PENABLE, and PREADY are all high. Then list the consequences that all fire on that edge — a write is captured, PRDATA is valid and sampled, PSLVERR is sampled, and the held signals (PADDR/PWRITE/PWDATA/PSEL) are released. Close with the two depth points: wait states give exactly one completion (the first access cycle with PREADY high, not several), and stability is defined relative to completion, not a fixed cycle. Volunteering that "write commit, read validity, PSLVERR, and stability are one rule seen four ways" signals you understand the protocol's structure, not just its waveform.

8. Q&A

9. Practice

Mark the edge. Given a transfer with two wait states, draw PSEL, PENABLE, and PREADY, and mark the single completion cycle. State what is true on every earlier access cycle.
Write the wire. From memory, write the access_complete, write_commit, and read_commit expressions and say what each gates.
Find the bug. A subordinate captures PWDATA whenever PENABLE is high. Show, on a one-wait transfer, exactly which cycle it wrongly writes and what the register ends up holding.
Place the samples. On a read with one wait state, mark the cycle the manager may sample PRDATA and PSLVERR, and explain why sampling a cycle earlier is wrong.
Assert it. Write, in words or SVA, a property that fails if the address changes during a wait state, and one that fails if PENABLE is high while PSEL is low.

10. Key takeaways

An APB transfer completes on one edge: PSEL, PENABLE, and PREADY all high. That conjunction, on a single PCLK rising edge, is the whole completion contract.
Four things fire on that edge: the write is captured, PRDATA is valid and sampled, PSLVERR is sampled, and the held signals are released. They are one event seen four ways.
PENABLE high is not completion, and "address appeared" is not completion. The access phase (and the address) precede completion, possibly by several wait cycles.
Wait states give exactly one completion — the first access cycle with PREADY high — not several. Everything before it is preparation and waiting.
Stability is defined relative to completion. PADDR, PWRITE, PWDATA, and PSEL hold stable through ACCESS until the completion edge, regardless of wait-state count.
The contract is verifiable. access_complete = psel & penable & pready is the wire every commit hangs off, and the stability/no-enable-without-select rules are natural SVA — one rule, easy to build and to check.