AMBA APB · Module 2

APB Version Evolution

How APB2, APB3, and APB4 extend one two-phase lifecycle — APB3 adds PREADY and PSLVERR, APB4 adds PSTRB and PPROT — without changing the basic transfer mental model.

You have spent this module building one mental model: an APB transfer is a walk through SETUP and ACCESS, two phases of a tiny lifecycle. It is natural to assume that "APB2," "APB3," and "APB4" are three different protocols you now have to learn three times. They are not. Every version extends the exact same two-phase SETUP/ACCESS lifecycle — each one only ADDS optional signals, and none of them changes how a transfer is structured. The single idea to carry: the lifecycle you already know is the lifecycle of all APB; the versions are layers on top of it, not replacements for it.

1. What problem is being solved?

The problem is letting APB grow new capabilities — wait states, error signaling, byte-level writes, protection attributes — without breaking the simple transfer model that makes it cheap.

The original APB was deliberately minimal: a subordinate could not stall, could not report an error, and a write always wrote all bytes. As SoCs grew, real needs appeared. Some peripherals sit in a slower clock domain and need to delay a transfer. Some accesses can fail — a reserved address, a protected register — and software wants to know. Some writes need to touch only part of a word. And in security-aware systems, the bus must carry who is making the access. Each of these is a genuine gap, but Arm had a constraint: APB's value is its simplicity, so any addition must not turn APB into a second AHB.

The solution APB takes across its versions is the same every time: add a small set of optional signals that ride on the existing SETUP and ACCESS phases, rather than redesigning the transfer. PREADY, PSLVERR, PSTRB, and PPROT are all introduced this way. The lifecycle's shape — IDLE → SETUP → ACCESS → done — is untouched; the new signals simply carry more information across phases that already exist.

2. Why the previous mental model is not enough

Your model so far is correct but it carries a hidden assumption: that there is one APB. In practice you will read datasheets, RTL, and IP that say "APB3 subordinate" or "APB4 master," and the danger is reading those as three protocols to learn separately. That framing is wrong, and unlearning it is the job of this chapter.

The right framing is the opposite. You learned ONE lifecycle, and that lifecycle is complete — every APB version, from the oldest to the newest, walks SETUP then ACCESS exactly as you already understand it. The versions differ only in which optional signals are present, and every one of those signals attaches to a phase you already know:

A version never changes the path. APB3 and APB4 still go SETUP for one cycle, then ACCESS until done. There is no new state, no new ordering, no pipelining. If you can read an ACCESS phase, you can read every version.
A version only adds optional information. PREADY adds "the subordinate is not ready yet" to ACCESS. PSLVERR adds "the access failed" to completion. PSTRB adds "write only these bytes" to a write. PPROT adds "here is who is asking" to the whole access. Each is a richer label on an existing phase, not a new mechanism.

So the model to upgrade is not the lifecycle — it is your assumption that newer means different. Newer means more optional signals on the same lifecycle. Carry that and version names stop being intimidating.

3. APB transfer mental model

The model for versions: APB is one base machine, and each version bolts an optional accessory onto it.

Think of a base car that every model shares — same chassis, same engine, same way it drives. One trim adds cruise control, another adds parking sensors. The accessories change what the car can do in specific moments, but the way you drive it — steer, accelerate, brake — never changes. A driver who learned on the base model drives every trim without retraining. APB is exactly this: the chassis is the two-phase SETUP/ACCESS lifecycle, and PREADY, PSLVERR, PSTRB, PPROT are accessories that successive versions bolt on.

Three refinements make this precise:

The chassis is the lifecycle, and it is shared. SETUP for one cycle, then ACCESS, then done — APB2, APB3, and APB4 all drive identically. Nothing a version adds touches the transition path.
Accessories are optional and additive. A version's new signals are extra, not mandatory rework. An APB4 design that never uses PSTRB (always writes full words) behaves exactly like an APB3 design; an APB3 subordinate that is always ready behaves like the old fixed-timing APB2.
Each accessory acts on a phase you already know. PREADY lengthens ACCESS; PSLVERR qualifies the completion of ACCESS; PSTRB masks the write data presented from SETUP; PPROT is an attribute of the whole access. None invents a new moment in the transfer.

Figure 1 — APB2, APB3, and APB4 as additive layers on one shared lifecycle base. At the bottom is the common two-phase SETUP → ACCESS lifecycle (PSEL selects, PENABLE marks ACCESS, one transfer at a time) that every version keeps unchanged. APB2 is the historical baseline sitting directly on that base — a fixed two-cycle access with no PREADY, so a subordinate cannot stall. APB3 adds a thin layer contributing PREADY (wait states and backpressure) and PSLVERR (error response). APB4 adds a further layer contributing PSTRB (write byte strobes) and PPROT (protection/attributes). The figure makes visually clear that each version only ADDS optional signals and never rewrites the lifecycle base.

4. Real SoC / hardware context

In a real chip, APB3/APB4 is the modern baseline and APB2 is historical context — but they all share one bridge-driven lifecycle. The bridge still sequences SETUP and ACCESS exactly as before; the version just determines which extra wires run alongside the core signals.

The version that matters most in practice is APB3's PREADY. The original APB had a fixed two-cycle access — every transfer completed in exactly one ACCESS cycle, no exceptions. That was fine when every peripheral could answer instantly, but it forbade slow registers, and crucially it forbade a subordinate in a slower clock domain. PREADY made ACCESS elastic: the subordinate holds it low to insert wait states, and the bridge simply waits, holding everything stable. This is the single change that lets one APB bus host subordinates of wildly different speeds — and it is purely additive, because a subordinate that is always ready (drives PREADY high immediately) reproduces the old fixed-timing behavior exactly.

PSLVERR, also from APB3, lets a subordinate report that an access failed — a reserved address, a protected register, a parity problem — instead of completing silently with garbage. The bridge samples it at the same completion edge it already watches, so error reporting costs nothing structurally; it is just one more bit qualifying the moment the transfer finishes.

APB4 then adds two attribute-style signals. PSTRB carries write byte strobes: a per-byte mask saying which bytes of PWDATA actually update, so a write can touch one byte of a word without a read-modify-write. (It applies to writes only; reads always return a full word.) PPROT carries protection and privilege attributes — whether the access is privileged, secure, or instruction/data — so the bus can express the access-control information that security-aware fabrics, often bridged down from AXI, need to propagate to peripherals. Both are extra information on an access; neither changes how the access is sequenced.

Figure 2 — what each APB version adds, on one unchanged lifecycle. APB2 contributes the base two-phase SETUP/ACCESS transfer with fixed timing and no PREADY. APB3 adds PREADY (wait states and backpressure) and PSLVERR (an error response). APB4 adds PSTRB (write byte strobes) and PPROT (protection and access attributes). Every addition is an optional signal riding on the same two-phase lifecycle — the SETUP and ACCESS phases are identical across all three versions.

5. Engineering tradeoff table

Each version's additions are a deliberate trade: a new capability, at the cost of a little more interface, justified only when the traffic needs it.

Version addition	What it costs	What it buys	When you actually need it
APB3 `PREADY` (wait states)	A ready wire + the bridge must wait	Subordinates of any speed, including slower clock domains	Almost always — it is why APB3 is the baseline
APB3 `PSLVERR` (error response)	One status bit + software must check it	A standard way to report failed accesses	When accesses can legitimately fail (reserved/protected)
APB4 `PSTRB` (write byte strobes)	A strobe bus the width of the byte lanes	Partial-word writes without read-modify-write	When sub-word register fields are written independently
APB4 `PPROT` (protection attributes)	A few attribute bits carried per access	Privilege/security info propagated to peripherals	In security-aware SoCs (TrustZone-style bridged from AXI)
Staying on APB2 (no additions)	No stall, no error, full-word writes only	The absolute minimum interface	Only legacy/historical — modern designs start at APB3

The throughline: every addition is optional and local. You adopt PREADY because real subordinates stall; you adopt PSTRB only if you genuinely write sub-word fields. Because each rides the existing lifecycle, adopting one costs you a wire and some logic — never a redesign of the transfer.

6. Common RTL / architecture / waveform mistakes

Misconceptions to unlearn

"APB2, APB3, and APB4 are different protocols I must learn separately." No. They are one protocol with one lifecycle; the versions differ only in which optional signals are present. Learn the lifecycle once and it applies to all of them.
"A newer APB version changes the transfer sequence or adds pipelining." No. SETUP is still one cycle, ACCESS still completes the transfer, and APB is still unpipelined in every version. No version touches the path.
"PREADY is what makes a transfer multi-cycle in some redesigned way." No. PREADY simply lets the subordinate hold the existing ACCESS state longer. It lengthens a phase you already know; it does not create a new one. A pre-PREADY APB2 access was just a fixed-length version of the same ACCESS.
"PSTRB applies to reads, masking which bytes are returned." No. PSTRB is a write byte strobe only — it masks which bytes of PWDATA update. Reads always return a full word; the master ignores lanes it does not want.
"PSLVERR aborts or retries the transfer like a fast-bus error." No. The transfer still completes normally at its completion edge; PSLVERR is just a status bit sampled there saying the access failed. There is no retry mechanism — handling the error is software's job.
"Targeting APB4 means I must drive PSTRB and PPROT on every access." No. They are optional. An APB4 design that always writes full words and uses default protection behaves exactly like an APB3 design — the signals are there for when you need them.

7. Interview framing

This topic separates someone who memorized a version table from someone who understands that APB evolved without changing its core. Interviewers ask "what is the difference between APB3 and APB4?" or "what did PREADY add?" — and the weak answer recites signals while the strong answer frames them against the unchanged lifecycle.

The strong answer leads with the invariant: every APB version extends the same two-phase SETUP/ACCESS lifecycle; the versions only add optional signals. Then place each one: APB3 added PREADY (wait states / backpressure, making ACCESS elastic so any-speed subordinates can share the bus) and PSLVERR (a standard error response); APB4 added PSTRB (write byte strobes for partial-word writes) and PPROT (protection/privilege attributes). Close with the depth point that lands every time: not one of these added a new phase, a new state, or pipelining — each rides an existing phase, which is why APB stayed cheap as it grew. That answer shows you understand the design discipline, not just the signal list.

8. Q&A

9. Practice

Map signals to phases. For each of PREADY, PSLVERR, PSTRB, and PPROT, name the phase it attaches to (presented in SETUP, sampled during/at-end-of ACCESS) and the capability it adds.
Defend the invariant. In two sentences, explain to a colleague why APB3 and APB4 are "the same protocol with extra signals," not three protocols to learn separately.
Reduce a version. Describe how an APB4 subordinate that always writes full words, is always ready, and never errors behaves identically to an old APB2 subordinate — and which signals it is effectively not using.
Pick the version. For (a) a UART in a slower clock domain, (b) a register block with independently written byte fields, and (c) a peripheral behind a TrustZone-style secure boundary, name which version's addition you need and why.
Spot the misconception. A teammate says "APB4 added pipelining and a retry-on-error mechanism." State exactly what is wrong with each claim using the lifecycle.

10. Key takeaways

Every APB version extends one unchanged two-phase SETUP/ACCESS lifecycle. APB2, APB3, and APB4 walk the same path; only the set of optional signals differs.
APB3 added PREADY and PSLVERR. PREADY makes ACCESS elastic (wait states / backpressure for any-speed subordinates); PSLVERR reports a failed access at the completion edge.
APB4 added PSTRB and PPROT. PSTRB masks which write bytes update (writes only); PPROT carries protection/privilege attributes for security-aware fabrics.
Each addition rides an existing phase, never a new one. PSTRB/PPROT are presented from SETUP; PREADY lengthens ACCESS; PSLVERR qualifies completion. No version adds a state, an ordering, or pipelining.
APB3/APB4 are the modern baseline; APB2 is historical context. A modern design starts at APB3; an APB4 design that ignores its extra signals behaves like APB3, which behaves like APB2 when always-ready.
The mental model you built transfers directly. Newer APB does not mean a different protocol — it means more optional signals on the same lifecycle. Hold that and every version name reads as a feature list, not a relearn.