AMBA APB · Module 3

PADDR — The Address Bus

PADDR, the APB address bus — its width, byte-addressing and alignment, the register it selects, and the rule that it must stay stable across both the setup and access phases.

Module 2 taught you that the address phase is where the access is presented. The signal carrying the what of that access is PADDR, and to drive or decode it correctly you need its exact contract: how wide it is, how it is aligned, how it splits into "which peripheral" and "which register," and the one rule that makes the whole transfer honest. PADDR is the manager-driven address bus that names exactly which register of which peripheral the transfer targets — up to 32 bits, byte-addressed, and held rock-stable from the moment it appears until the transfer completes. The single idea to carry: PADDR is the what of the transfer, and its value must not move while that transfer is in flight.

1. What problem is being solved?

The problem is naming, unambiguously, the one location an access targets — which peripheral on the bus, and which register inside it.

An APB subordinate fabric can hold many peripherals, and each peripheral holds many registers. A transfer is meaningless until it answers a single question: where? PADDR is that answer. The manager places an address on the bus and the fabric interprets it in two layers:

A high field picks the peripheral. The upper bits of PADDR feed an address decoder that asserts exactly one PSEL line — one-hot — so a single subordinate is selected.
A low field picks the register. The lower bits are the offset into the selected peripheral's register map, naming which register the access reads or writes.

Without PADDR, the protocol would have a direction (PWRITE), data (PWDATA / PRDATA), and timing (PSEL, PENABLE, PREADY) — but no destination. PADDR is the coordinate that gives every other signal a place to act on.

2. Why the lifecycle view is not enough

Module 2 named PADDR's role: it is "the address presented in SETUP." That is the right role, but a role is not a contract. To wire PADDR into a real manager or decode it in a real subordinate, you need three things the lifecycle view leaves unstated:

The exact shape: width and alignment. PADDR is up to 32 bits wide and byte-addressed — every increment of one counts one byte. Because peripheral registers are typically 32 bits, accesses are word-aligned, so the low address bits (PADDR[1:0]) are typically zero. The lifecycle says "an address"; the contract says a byte address, aligned to the transfer size.
How it is interpreted: page versus offset. PADDR is not one flat number to a subordinate — it splits into a high page field (which peripheral, via the decoder and one-hot PSEL) and a low offset field (which register). The lifecycle never tells you the address has structure.
Who owns it, and the stability rule. PADDR is driven by the manager only — a subordinate never drives it — and it must remain stable from SETUP through every ACCESS cycle until completion. The lifecycle mentions stability in passing; at the signal level it is the load-bearing rule.

Knowing the role tells you what PADDR means; knowing the contract tells you what PADDR looks like on the wire and in the decoder — which is what you actually need to build or debug a transfer.

3. The signal's mental model

The model: PADDR is a street address — a building number and an apartment number combined.

A full address tells the mail carrier two things at once: which building on the street (the page field, which selects the peripheral) and which apartment inside it (the offset field, which selects the register). Read the high part first to find the building; read the low part to find the door. And there is a rule every resident knows: apartments come in fixed sizes, so you do not address "apartment 3 and a half" — addresses land on clean boundaries. That is word-alignment: 32-bit registers sit on 4-byte boundaries, so the bottom bits of PADDR are zero.

Three refinements make the model precise:

Byte-addressed, word-aligned. Each unit of PADDR is one byte. A 32-bit register spans four bytes, so consecutive registers are four apart (0x00, 0x04, 0x08, …) and PADDR[1:0] is 00 for an aligned word access.
The split is structural, not physical. There is one PADDR bus; the decoder and the peripheral each look at a different slice of it. Nothing on the wire labels the page or offset boundary — the fabric's address map defines where it falls.
The address is frozen once placed. Like an envelope you do not relabel after it is in the post, PADDR must hold its value for the whole transfer. The decode that selects the peripheral and register is only consumed at completion, so the address must still be valid then.

Figure 1 — how PADDR is interpreted. The bus splits into a high page field (PADDR[31:12] here) that feeds an address decoder driving a one-hot PSEL, so exactly one peripheral is selected, and a low offset field (PADDR[11:2]) that names which register within that peripheral the access targets. The lowest bits (PADDR[1:0]) are word-alignment bits, typically zero for 32-bit register accesses, since the bus is byte-addressed and consecutive 32-bit registers sit four bytes apart. The exact bit boundary between page and offset is set by the fabric's address map, not by anything on the wire.

4. Real SoC / hardware context

In hardware, PADDR originates at the manager — the APB bridge. The bridge translates an access from the faster system bus into APB terms and places the target address on PADDR in the SETUP cycle, then holds it. The manager is the single driver; PADDR is a point-to-fabric output, not a shared or bidirectional bus.

On the fabric side, PADDR is consumed in two places. First, the address decoder reads the high page bits and asserts one PSEL, routing the transfer to a single subordinate — this is the one-hot select mechanism. Second, the selected subordinate reads the low offset bits against its own register map to decide which register the access targets, setting up its read mux or write enable accordingly. The two consumers look at different slices of the same bus, which is why "page versus offset" is the right mental split: the boundary between them is just where the system's address map draws the line.

Width is a design parameter, not a fixed 32. PADDR is up to 32 bits; a small peripheral subsystem may only need a handful of bits to cover its register space, and APB lets you instantiate exactly the width the address map requires. What does not change is the byte-addressing and the alignment expectation: because registers are word-sized, an aligned access drives PADDR[1:0] to 00, and a subordinate's decode typically ignores those bits entirely.

The stability requirement is the load-bearing rule of the address bus, exactly as it was for the address phase. The manager must hold PADDR constant from the moment it is presented in SETUP, through every ACCESS cycle — including any wait state where the subordinate holds PREADY low — until PREADY is sampled high. The reason is concrete: the decode of PADDR into "this peripheral, this register" is only consumed when the access commits, so if PADDR moved between presentation and commit, the fabric could select one register and act on another.

Figure 2 — the PADDR stability contract. Top (legal): PADDR becomes valid in SETUP and is held as one unchanging address across SETUP, the ACCESS wait-state cycle where PREADY is low, and the completion cycle where PREADY is high; the fabric decodes and acts on the correct register. Bottom (illegal): the same PADDR is changed during an ACCESS cycle before completion, while PREADY is still low, which corrupts the transfer because the peripheral may decode or capture the wrong location. The rule is that PADDR, valid in SETUP, must remain stable through ACCESS until PREADY is high; changing it mid-transfer is a protocol violation.

5. Engineering tradeoff table

PADDR is a deliberately plain bus. Each property trades a capability APB does not need for the simplicity it does.

`PADDR` property	What it gives up	What it buys	Why it is correct for APB
Up to 32 bits, parameterizable	A fixed universal width	Exactly the address space a subsystem needs	Control fabrics are small; unused bits cost area
Byte-addressed, word-aligned	Sub-word addressing flexibility	A simple decode where `PADDR[1:0]` is ignored	Registers are word-sized; misalignment has no use
Page field → one-hot `PSEL`	A shared encoded select bus	A trivial decoder and one selected subordinate	Sparse fabrics make one-hot cheap and clear
Offset field → register index	A separate register-select signal	One address carries both layers of "where"	Fewer signals; the address already encodes both
Manager-driven, held stable	Mid-transfer retargeting	A decode that stays valid through commit	A moving address would select one place, act on another

The throughline: PADDR does exactly one job — name the location — and encodes both layers of that location (peripheral and register) into a single byte-addressed, aligned value. Everything about when the address is acted on is delegated to the timing signals, which keeps PADDR itself a plain, stable bus.

6. Common RTL / waveform mistakes

Misconceptions to unlearn

"PADDR can change once the transfer is in ACCESS." No. PADDR must hold stable from SETUP through every ACCESS cycle — including wait states — until PREADY is high. Changing it mid-transfer corrupts the access even though the lifecycle still looks legal.
"PADDR is word-addressed, so incrementing by one moves to the next register." No. PADDR is byte-addressed. The next 32-bit register is four bytes away, so consecutive registers are at 0x00, 0x04, 0x08 — incrementing by one lands inside the same word.
"PADDR[1:0] carries useful information for a 32-bit access." No. For an aligned word access those bits are 00 and the subordinate typically ignores them. Driving them non-zero on a word access is an alignment error, not a feature.
"The subordinate decodes the whole of PADDR to find its register." No. The high page bits already selected this subordinate via PSEL; the subordinate only needs the low offset bits to pick a register within its own map.
"PADDR is always 32 bits wide." No. It is up to 32 bits and is parameterizable. A small subsystem instantiates only the bits its address map needs.
"A subordinate can drive PADDR back to influence the transfer." No. PADDR is manager-driven only. The subordinate's single lever on the transfer is PREADY; it never sources the address.

7. Interview framing

PADDR is a good probe because a precise answer shows you understand that an address has structure and a contract, while a vague one ("it's the address") shows you treat it as a flat number. Interviewers ask "how wide is PADDR?", "how does the fabric know which peripheral and register?", or "what must be true of PADDR during a transfer?"

The strong answer states the shape, the split, and the rule. Shape: PADDR is up to 32 bits, byte-addressed, and word-aligned, so PADDR[1:0] is 00 for a 32-bit access. Split: the high page field feeds a decoder that asserts a one-hot PSEL to pick the peripheral, and the low offset field selects the register inside it. Rule: PADDR is manager-driven and must stay stable from SETUP through ACCESS until PREADY is high, because the decode is only consumed at commit. Volunteering that stability rule — and why it exists (decode is consumed at completion, not at presentation) — is exactly what separates an engineer who can debug an APB waveform from one who only recites signal names.

8. Q&A

9. Practice

State the shape. From memory, give the maximum width of PADDR, say whether it is byte- or word-addressed, and state the value of PADDR[1:0] for an aligned 32-bit access.
List the registers. A peripheral has four 32-bit registers starting at offset 0x00. Write the byte offset of each and explain why they are four apart rather than one apart.
Trace the decode. For a given PADDR, describe in order how the fabric turns it into a selected peripheral and a selected register, naming which signal the page field drives.
Spot the bug. A manager presents PADDR in SETUP, then changes it during an ACCESS cycle in which PREADY was low. State which rule it broke and what the fabric might do wrong.
Place the boundary. A fabric has 8 peripherals, each with up to 1 KB of register space. Reason about roughly how many low bits are offset and where the page field begins, and explain why a different fabric could split the same bus differently.

10. Key takeaways

PADDR is the manager-driven address bus that names which register of which peripheral a transfer targets — the what of the access. The manager is the single driver; a subordinate only reads it.
PADDR is up to 32 bits, byte-addressed, and word-aligned. Each unit is one byte, 32-bit registers sit four bytes apart, and PADDR[1:0] is 00 for an aligned word access. The width is parameterizable, not fixed at 32.
It carries two layers of "where" at once: a high page field that feeds the decoder to assert a one-hot PSEL (which peripheral), and a low offset field that selects the register inside that peripheral.
The page/offset boundary is set by the address map, not the wire. More peripherals push it lower, larger register maps push it higher — so the same width of PADDR can be split differently across designs.
The load-bearing rule is stability: PADDR becomes valid in SETUP and must hold unchanged through every ACCESS cycle — including wait states — until PREADY is high, because the decode is only consumed at completion.
The classic errors are addressing errors: changing PADDR mid-transfer, treating it as word-addressed, or reading meaning into PADDR[1:0] on an aligned access. Each corrupts the decode or the access.