AMBA APB · Module 3

PSEL — The Subordinate Select

PSEL, the per-subordinate select — its one-per-subordinate fan-out, the one-hot decode the bridge owns, and why exactly one PSEL high is what names the active subordinate.

Module 2 told you APB is point-to-multipoint and that a decoder asserts "exactly one PSEL" to name the selected subordinate. That is the right role, but to drive or sample PSEL correctly in real RTL you need its exact contract: how many PSEL lines exist, who drives them, when each one is high, and how long it stays high inside a single transfer. PSEL is the per-subordinate select line — one dedicated line for each subordinate — that the bridge holds high across both phases of a transfer to name the single active target. The one idea to carry: PSEL is high in the setup cycle and the access cycle (it does not toggle between them like PENABLE), and exactly one of the N PSEL lines is high at any instant — anything else is a hardware bug.

1. What problem is being solved?

The problem is picking exactly one subordinate out of many on a shared, broadcast bus, and naming it for the whole duration of the transfer.

A real APB fan-out hangs a UART, some timers, and GPIO off one bridge. PADDR, PWRITE, and PWDATA are driven once and broadcast to every subordinate in parallel — cheap, but ambiguous: every subordinate sees the same address, so which one should respond? APB answers with a dedicated select line per subordinate:

PSEL high on a subordinate means "this access is aimed at you — decode it, and if it completes, act on it and drive the return."
PSEL low means "this access is not yours — ignore the broadcast, drive nothing on the shared return."

That single per-subordinate bit is what turns a broadcast into a point-to-point conversation. Without it, a broadcast bus would have no way to designate a target, and the shared return path (PRDATA, PREADY) would have no defined owner.

2. Why the lifecycle view is not enough

Module 2 named PSEL's role — the one-hot select that picks "the subordinate." That is true, but a role is not a signal contract. To wire PSEL into a real bridge or check it in a real subordinate, the topology view leaves three signal-level facts unstated:

One PSEL per subordinate, and it is high across both phases. There is not one shared PSEL but N of them — one dedicated line per subordinate. And within a transfer, the selected subordinate's PSEL rises in the setup cycle and stays high through the access cycle until completion. It does not pulse for one cycle and it does not toggle between phases. This is the sharp contrast with PENABLE, which is low in setup and only high in access.
The decoder is combinational, owned by the bridge, and driven straight from PADDR. Each PSEL line is a pure combinational decode of an address page field — no register, no FSM state of its own. The bridge owns the decode; a subordinate never drives its own PSEL.
One-hot is an instantaneous invariant, not just a per-transfer one. At every instant a transfer is in progress, exactly one PSEL is high. Two high — even transiently from overlapping address windows — is contention on the shared return, not a slow transfer.

Knowing the role tells you what PSEL means; knowing the contract tells you what PSEL looks like on the wire across both phases — which is what you need to build or debug a transfer.

3. The signal's mental model

The model: PSEL is the spotlight that stays on the one performer for the entire act, not just the climax.

Picture a stage with several performers. The manager broadcasts the same cue (PADDR, PWRITE, PWDATA) to all of them, but a single spotlight — the decoder — picks out exactly one. That spotlight switches on the moment the act begins (the setup cycle) and stays on the same performer through the whole act, including the climax (the access cycle), until the act finishes. The other performers stand in the dark with their PSEL low. The crucial detail: the spotlight does not blink off between "begin" and "climax" — it is continuously on the selected subordinate, which is exactly why PSEL is high in both phases.

Three refinements make the model precise:

One spotlight, exactly one performer lit — one-hot. The decoder guarantees that exactly one PSEL is high while a transfer is live. The lit performer is the definition of "the selected subordinate."
The spotlight stays on across the whole act. PSEL is high in setup (where PENABLE is low — the decode window) and in access (where PENABLE is high), holding through any wait states until completion. It is not a one-cycle pulse.
Lit means "your turn," not "done." PSEL high means the access is aimed at this subordinate; completion is the separate condition PSEL, PENABLE, and PREADY all high. A subordinate uses PSEL to know the transfer is its own, not that it is finished.

4. Real SoC / hardware context

In a real chip, each PSEL line is the output of a small combinational address decoder at the bridge. The decoder reads a page field of PADDR, compares it against the address map, and drives high the single psel_* whose page matches — every other psel_* stays low. There is no FSM state inside PSEL itself: it is a pure function of the address (gated by a bus-level select), which is why it tracks the address window for the whole transfer rather than pulsing.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// One-hot PSEL fan-out (teaching sketch — not a full bridge).
// From a bus-level select and the PADDR page field, assert exactly ONE psel_*.
logic        sel;          // bus-level: a transfer is targeting the APB space
logic [3:0]  page;         // PADDR[15:12] — the per-peripheral page
localparam logic [3:0] UART_PAGE = 4'h0, TIMER_PAGE = 4'h1, GPIO_PAGE = 4'h2;
 
// Each PSEL is the gated page match. Because the pages are mutually exclusive,
// AT MOST ONE psel_* is ever high at a time — the one-hot property.
assign psel_uart  = sel & (page == UART_PAGE);
assign psel_timer = sel & (page == TIMER_PAGE);
assign psel_gpio  = sel & (page == GPIO_PAGE);

Two facts fall straight out of that decode. First, because the page values are mutually exclusive, at most one equality holds for any address, so the one-hot property is structural — it comes from the address map, not from a runtime check. Second, because sel and page stay stable for the whole transfer (the address holds across setup and access), the asserted psel_* holds high across both phases automatically — no extra logic is needed to keep the select alive through the access cycle.

Figure 1 — the bridge's combinational decoder fanning one shared PADDR out to one dedicated PSEL per subordinate (one-hot). PADDR is broadcast on the shared bus to every subordinate, but the decoder reads its page field and drives exactly one PSEL high — here PSEL_uart, for the worked example where the page equals 0 — while PSEL_timer and PSEL_gpio are held low. Only the subordinate whose PSEL is high acts on the broadcast and drives the shared return; the unselected subordinates stay idle. There is one PSEL line per subordinate, fanned out one-to-one from the single decoder.

On the subordinate side, PSEL is the gate that says "this transfer is mine." A correct subordinate qualifies everything it does on its own PSEL: it only decodes the broadcast when PSEL is high, and only commits at completion (PSEL and PENABLE and PREADY all high). Crucially, because its PSEL is high in both phases, the subordinate uses the setup cycle (PSEL high, PENABLE low) to decode and prepare, and the access cycle (PSEL high, PENABLE high) to perform — the same select line spanning both.

Figure 2 — PSEL timing across one transfer, against PCLK, with PENABLE plotted for contrast. PSEL rises at the very start of the transfer (the setup cycle) and stays high continuously through the access cycle until completion — it is high across BOTH phases. PENABLE, underneath, is low during setup and only rises one cycle later for the access phase; the setup cycle is therefore the unique PSEL-high, PENABLE-low cycle, the subordinate's decode window. PREADY is low until completion. After the transfer both PSEL and PENABLE return low. PSEL names the active subordinate for the whole two-phase transfer, not just the access phase.

5. Engineering tradeoff table

PSEL is a deliberately minimal, per-subordinate signal. Each property trades a capability APB does not need for the simplicity it does.

`PSEL` property	What it gives up	What it buys	Why it is correct for APB
One dedicated line per subordinate	A shared encoded select bus	A trivial, decoded per-peripheral gate	One select wire per peripheral is nearly free
Combinational decode from `PADDR`	Registered / pipelined selection	Zero-latency, glitch-bounded selection	Slow sparse traffic needs no pipelined decode
High across both phases	A one-cycle select pulse	A full setup-cycle decode window	The held select is what makes two-phase work
One-hot (exactly one high)	Multi-target broadcast writes	A single legal driver of the shared return	Two drivers on shared `PRDATA`/`PREADY` is contention
Bridge-driven, address-derived	Subordinate-chosen selection	One owner of the address map and decode	Centralizing the map keeps one-hot easy to guarantee

The throughline: PSEL does one job — name the single active subordinate, for the whole transfer — and does it as a pure combinational decode of the address. Holding it across both phases is what gives the subordinate its decode window; keeping it one-hot is what keeps the shared return single-driver.

6. Common RTL / waveform mistakes

Misconceptions to unlearn

"PSEL and PENABLE are the same kind of signal." No. PSEL is high across both phases (setup and access); PENABLE is low in setup and high only in access. The setup cycle is exactly where they differ, and that difference is the decode window.
"PSEL is a one-cycle pulse at the start of a transfer." No. The selected subordinate's PSEL rises in setup and holds high through the access phase, including any wait states, until completion. A waveform showing PSEL dropping after one cycle is broken.
"There is one shared PSEL for the whole bus." No. There is one dedicated PSEL line per subordinate. The decoder drives N select lines; exactly one is high at a time.
"Two PSEL high just means two subordinates respond — slower, but fine." No. Two selected subordinates both drive the shared PRDATA/PREADY — bus contention, an unknown X on the return, not a valid transfer. A non-one-hot PSEL is a bug.
"PSEL high means the access is complete." No. PSEL high means the transfer is aimed at this subordinate. Completion is PSEL and PENABLE and PREADY all high. Committing on PSEL alone captures data in the setup cycle, before the access is even performed.
"Overlapping address windows are a firmware problem." No. Overlapping windows make the combinational decoder assert two PSEL lines for one address — a hardware contention bug baked into the address map, independent of any firmware.

7. Interview framing

PSEL is a favourite because a precise answer proves you understand selection at the signal level, and a vague one ("it selects the slave") proves you do not. Interviewers ask "when is PSEL high?", "how does PSEL differ from PENABLE?", or "what happens if two PSEL are high?"

The strong answer states the contract, not just the role: PSEL is a per-subordinate select — one dedicated line per subordinate — driven by the bridge as a combinational decode of a PADDR page field, and the selected subordinate's PSEL is high across both the setup and access phases, held until PREADY completes the transfer. Then deliver two depth points. First, the PSEL-vs-PENABLE distinction: PSEL is high in setup where PENABLE is low, and that single cycle is the subordinate's decode window. Second, the one-hot invariant: exactly one PSEL is high at a time because the shared return has exactly one legal driver, so two PSEL high is contention — usually from overlapping address windows, fixed in the map, not with extra logic. Connecting "shared return path" to "must be one-hot," and "high in both phases" to "the decode window," is exactly what separates an engineer who can debug an APB waveform from one who cannot.

8. Q&A

9. Practice

Draw the waveform. For one transfer, draw PSEL, PENABLE, and PREADY across all cycles. Mark the setup cycle, the access cycle, and the one cycle where PSEL is high and PENABLE is low.
Contrast the pair. From memory, state the value of PSEL and of PENABLE in the setup cycle and in the access cycle, and explain what the difference in the setup cycle buys the subordinate.
Fan out the decode. Given pages 0x0 → UART, 0x1 → Timer, 0x2 → GPIO and an address with page 0x2, write which psel_* is high and which are low, and name the selected subordinate.
Break the map. Assign UART and Timer overlapping address windows. For an address in the overlap, state how many PSEL lines assert, what happens on the shared PRDATA/PREADY, and what the manager reads.
Gate the commit. Write the condition a subordinate should use to capture a write, and explain why gating on PSEL alone would commit in the setup cycle, before the access is performed.

10. Key takeaways

PSEL is the per-subordinate select: one dedicated line for each subordinate, and exactly one of the N lines is high at a time — one-hot — naming the single active target.
PSEL is high across both phases. It rises in the setup cycle and holds through the access cycle until completion — unlike PENABLE, which is low in setup and high only in access.
The setup cycle — PSEL high, PENABLE low — is the decode window. It exists only because PSEL rises first and holds while PENABLE waits a cycle.
It is bridge-driven, a pure combinational decode of PADDR. Each PSEL is the gated page match; the held address keeps the select alive across both phases for free.
PSEL names the target, not the finish. A write commits, and read data is valid, only when PSEL, PENABLE, and PREADY are all high — never on PSEL alone.
A non-one-hot PSEL is a contention bug, not a slow path. Two PSEL high means two subordinates drive the shared PRDATA/PREADY — usually from overlapping address windows, fixed in the address map.