HSEL

This chapter covers HSEL, the subordinate-select signal — how a subordinate knows that the current access is aimed at it. HSEL is the bridge between the address map (a design document) and live routing: the decoder reads HADDR and asserts exactly one subordinate's HSEL. But there is a subtlety we have been building toward since chapter 3.8 — HSEL alone is not enough; a subordinate must combine HSEL with HREADY to know when its selected access actually begins. We give HSEL's exact role, the decode mechanism, the HSEL-plus-HREADY rule, and how the default subordinate fits in. This closes the loop on subordinate selection.

1. What Is It?

HSEL is a per-subordinate select signal: each subordinate has its own HSEL input (HSEL_A, HSEL_B, …). The decoder examines HADDR in the address phase and, using the address map, asserts exactly one subordinate's HSEL — a one-hot selection telling that subordinate "the current access is for you."

Its key properties:

• It is driven by the decoder (in the interconnect), one HSEL per subordinate, asserted in the address phase.
• It is one-hot: exactly one subordinate (or the default subordinate) is selected per access.
• A subordinate must combine HSEL with HREADY: it only registers the access (HSEL and the address-phase signals) on a cycle where HREADY is high, because that is when the address phase actually advances into its data phase.
• If HADDR matches no subordinate's region, the decoder selects the default subordinate, so the access still completes (typically with ERROR).

The essence: HSEL is the address map turned into a per-access selection. The decoder is the address map in logic, and HSEL is its output — the wire that tells a specific subordinate "you are addressed." A subordinate watches its HSEL (qualified by HREADY) to know whether and when to respond.

2. Why Does It Exist?

HSEL exists because a shared bus reaches many subordinates, and something must tell each subordinate whether the current access is for it — the decoder's job, expressed through HSEL.

On a shared bus, the address and control signals are visible to every subordinate. Without a select, each subordinate would have to decode the full address itself to decide whether to respond — duplicating the address-map logic in every subordinate, and risking inconsistency (two subordinates both thinking they are addressed). HSEL centralizes that decision in the decoder: the decoder owns the address map, decodes HADDR once, and asserts the one HSEL that matters. Each subordinate then only needs to watch its own simple HSEL input rather than decode addresses itself. This is cleaner (one place owns the map), safer (one-hot guarantees exactly one responder), and lets subordinates be reusable (a subordinate does not embed its own address, so it can be mapped anywhere by configuring the decoder).

The one-hot property exists to guarantee exactly one responder. If two subordinates could be selected at once, they would both drive read data and HREADYOUT, contending on the bus. The decoder's one-hot HSEL ensures precisely one subordinate responds to each access — a correctness guarantee that the shared bus depends on.

The HSEL-plus-HREADY requirement exists because of pipelining, exactly as covered in chapter 3.8. HSEL is asserted in the address phase, but the bus may not have advanced to that access's data phase yet (a previous transfer could be stalling). So a subordinate cannot act on HSEL the instant it sees it; it must wait until HREADY is high, signalling the bus has advanced. HSEL says which subordinate; HREADY says when the access is live. Both are needed because selection (which) and timing (when) are separate questions on a pipelined bus.

The default subordinate selection exists so that an access to an unmapped address still has a responder. Without it, an address matching no subordinate would leave no HSEL asserted, no one to respond, and the bus would hang. The decoder asserts the default subordinate's HSEL in that case, so the access completes (with ERROR) rather than hanging — the robustness mechanism from earlier chapters, realized through HSEL.

3. Mental Model

Model HSEL as a receptionist lighting up exactly one office's "you're up" lamp, where each office also watches the lobby's "now serving" sign.

A visitor arrives with a destination on their form (HADDR). The receptionist (decoder) reads the form and lights up exactly one office's lamp (HSEL) — "this visitor is for you." Each office watches only its own lamp, not every visitor's form, so the offices stay simple and the receptionist owns the directory. If the form names no real office, the receptionist lights the "complaints desk" lamp (default subordinate) so the visitor is still handled.

But an office does not jump up the instant its lamp lights, because the previous visitor (at possibly another office) may still be being served — the lobby's "now serving" sign (HREADY) might still show "wait." The office combines its lamp (HSEL: you're up) with the lobby sign (HREADY: the queue has advanced) and only begins serving when both say go. Lamp lit and sign advanced = serve now.

Watch HSEL select a subordinate:

The model's lesson: the receptionist lights exactly one lamp (HSEL) from the destination, and each office acts only when its lamp is lit and the lobby sign has advanced (HREADY). Selection is centralized and one-hot; timing is gated by HREADY.

4. Real Hardware Perspective

In hardware, HSEL is decoder-driven combinational logic to each subordinate, and the subordinate's correct use of it requires the HREADY qualification.

The decoder drives each HSEL combinationally from HADDR: the address map is implemented as logic that maps address ranges to HSEL assertions, one-hot. This is the same decode that drives the read-data and HREADY multiplexor selection (chapter 3.8) — the decoder's selection feeds both "which subordinate responds" (HSEL) and "which subordinate's HREADYOUT/HRDATA is routed back" (the mux). So HSEL and the mux selection are two faces of the same decode.

The subordinate's correct behaviour is the HSEL-plus-HREADY rule: it samples HSEL in the address phase, but it must only register the access (latch the address-phase signals and begin its data phase) on a cycle where HREADY is high. Concretely, a subordinate's internal logic gates the capture of an access on (HSEL AND HREADY): when both are high, the access is committed to this subordinate's data phase; if HSEL is high but HREADY is low (a previous transfer stalling), the subordinate holds and waits. This is exactly the pipeline-alignment rule from chapter 3.8, now stated for selection: HSEL says you, HREADY says now.

The default subordinate is selected by the decoder when no region matches — its HSEL is asserted, and it responds (with ERROR via the two-cycle protocol from 3.9). In hardware this is often a small block or a decoder mode that catches the "no match" case, ensuring exactly one HSEL is always asserted (a real subordinate's or the default's) so there is never a no-responder hang. The one-hot guarantee — exactly one HSEL high — is a property the decoder must maintain, and verification checks it (two HSELs high would be a decode bug causing bus contention).

5. System Architecture Perspective

At the system level, HSEL is the address map made live, and it is the mechanism by which the chip's memory map becomes per-access routing.

The chip's address map — ranges assigned to memories, peripherals, bridges — is implemented entirely in the decoder's HADDR→HSEL logic. When an architect assigns a peripheral to an address range, they are defining the decode that asserts that peripheral's HSEL for addresses in that range. So HSEL is where the memory map document becomes silicon behaviour: every access's HSEL is the address map evaluating HADDR in real time. Re-mapping a subordinate, adding one, or carving a new region is a decoder (HSEL logic) change; the subordinates themselves do not embed their addresses, which is what makes them reusable across chips with different maps.

The one-hot per-access property is a system-level correctness invariant: exactly one subordinate (or the default) responds to each access, which is what keeps the shared bus coherent. A system where the address map had overlapping regions (two subordinates' HSELs could assert for one address) would be broken — two responders contending. So the address map must be non-overlapping, and the decoder's one-hot HSEL enforces and reflects that. Designing a clean, non-overlapping address map is, at the signal level, designing a correct one-hot HSEL decode.

The default subordinate via HSEL is the system's safety net for the address map's gaps. Real address maps have unmapped regions (reserved space, holes between peripherals), and an access into a gap must not hang the bus. By having the decoder assert the default subordinate's HSEL for unmapped addresses, the system guarantees every possible address has a responder — mapped ones to their subordinate, unmapped ones to the default (which errors). So HSEL plus the default subordinate make the address map total: every address routes somewhere, even if only to a clean error. This totality is essential for robustness, and it is realized through the HSEL decode.

So HSEL is the signal-level embodiment of the address map: it makes the map live (per-access routing), enforces its correctness (one-hot, non-overlapping), and completes it (default subordinate for gaps). Understanding HSEL is understanding how the abstract memory map becomes concrete bus behaviour.

6. Engineering Tradeoffs

HSEL's design reflects centralized-decode choices.

• Central decoder vs per-subordinate decode. Driving HSEL from one central decoder means the address map lives in one place (clean, consistent, one-hot guaranteed) and subordinates stay simple and reusable, at the cost of the decoder being a central block tied to the specific map. The alternative — each subordinate decoding the full address — duplicates logic and risks inconsistency. AHB centralizes decode; HSEL is its output.
• One-hot vs encoded select. A one-hot HSEL (one wire per subordinate) is simple for each subordinate to use (watch one bit) but uses more wires as subordinates multiply. An encoded select (log2 wires) would save wires but require each subordinate to decode it. For typical AHB subordinate counts, one-hot's simplicity wins; very large systems might encode. The trade is wires versus per-subordinate decode.
• HSEL-plus-HREADY vs HSEL-alone. Requiring subordinates to qualify HSEL with HREADY adds a little logic to each subordinate but is mandatory for pipeline correctness. Letting subordinates act on HSEL alone would be simpler but broken in multi-subordinate pipelined systems. AHB requires the qualification — the small cost of correctness.
• Default subordinate vs no default. Including a default subordinate (selected by HSEL on no-match) costs a little logic but makes the address map total and prevents no-responder hangs. Omitting it saves logic but risks fatal hangs on stray accesses. Including it is almost always right — cheap robustness.

The through-line: HSEL centralizes the address-map decision in the decoder and distributes it as a simple one-hot select, trading some wires and a central decode block for clean, consistent, reusable subordinate selection — completed by the default subordinate and qualified by HREADY for pipeline correctness.

7. Industry Example

Trace HSEL through accesses on a system with several subordinates and an address gap.

A microcontroller has SRAM, flash, and an APB bridge as AHB subordinates, plus a default subordinate, with a defined address map.

• An access to SRAM. The processor presents an address in SRAM's range. The decoder asserts HSEL_SRAM (one-hot; the others low). SRAM, seeing its HSEL high and qualifying it with HREADY high, registers the access and responds. The flash and bridge see their HSELs low and ignore the access.
• An access to the APB bridge. The processor accesses a peripheral, whose address falls in the bridge's range. The decoder asserts HSEL_bridge; the bridge accepts the access (and forwards it to APB beyond). Same one-hot mechanism, different target.
• An access into an unmapped gap. The processor (via a bug) accesses an address in a reserved gap that no subordinate owns. The decoder finds no match and asserts HSEL_default. The default subordinate responds with the two-cycle ERROR, the processor faults, and software handles it. The access did not hang — the default subordinate's HSEL ensured a responder.
• The pipeline-qualified selection. Suppose flash is mid-access and stalling (HREADY low), and the processor presents the next access aimed at SRAM. HSEL_SRAM is asserted in that address phase, but SRAM must not start its data phase yet — HREADY is low because flash is still stalling. SRAM waits, and only when HREADY goes high (flash done) does it register and begin its access. HSEL said "you"; HREADY said "now."

Every access routes through HSEL: the decoder asserts exactly one subordinate's select from the address, the subordinate qualifies it with HREADY, and unmapped accesses fall to the default subordinate. The pipeline-qualified case shows why HSEL alone is insufficient — the same lesson as chapter 3.8, now at the point of selection.

8. Common Mistakes

9. Interview Insight

HSEL questions test the centralized-decode model and the HSEL-plus-HREADY qualification.

The answer that lands explains the decode, the one-hot property, and the qualification: "HSEL is the per-subordinate select that the decoder drives from HADDR — one-hot, so exactly one subordinate is selected per access, in the address phase. A subordinate watches its own HSEL rather than decoding the address itself. Crucially, it combines HSEL with HREADY: it only registers the access on an HREADY-high cycle, because the bus may still be completing a previous transfer. And if no region matches, the decoder selects the default subordinate so the access still completes." The HSEL-plus-HREADY qualification and the default-subordinate point are the senior signals.

10. Practice Challenge

Reason from centralized decode and the HSEL-plus-HREADY rule.

1. Define HSEL. State what HSEL is, who drives it, and the one-hot property.
2. Explain the qualification. In three sentences, explain why a subordinate must combine HSEL with HREADY.
3. Trace the default. Walk an access to an unmapped address through the decoder, HSEL, and the default subordinate.
4. Connect to the mux. Explain how HSEL relates to the read-data/HREADY multiplexor selection.
5. Diagnose contention. Two subordinates corrupt reads on certain accesses. Explain how an overlapping map / HSEL decode causes it and the fix.

11. Key Takeaways

• HSEL is the per-subordinate select, driven one-hot by the decoder from HADDR in the address phase — the address map turned into live, per-access routing.
• Decode is centralized: the decoder owns the map and drives HSEL; subordinates watch their own HSEL rather than decoding the full address, which keeps them simple and reusable.
• A subordinate combines HSEL with HREADY — registering the access only on an HREADY-high cycle, because selection (which) and timing (when) are separate on a pipelined bus.
• HSEL is one-hot to guarantee exactly one responder; overlapping address maps break this and cause bus contention.
• No region match selects the default subordinate via HSEL, making the address map total so unmapped accesses error cleanly instead of hanging.
• HSEL and the read-data/HREADY mux selection are the same decode — one decision driving both forward selection and return routing.

12. What Comes Next

You have now covered the core AHB-Lite signal set — global, address-phase, data, and handshake. The remaining Module 3 chapters cover the multi-master signals that full AHB adds (and AHB-Lite drops):

• 3.11 — HMASTER & HMASTLOCK (coming next) — the current-master identifier and the locked-sequence indication for atomic operations.
• 3.12 — HGRANT & HBUSREQ (coming soon) — the bus-request / bus-grant arbitration handshake.

To revisit the decode and pipeline-qualification HSEL depends on, see Master, Slave, Decoder & Arbiter and HREADY & HREADYOUT; for the default subordinate that HSEL selects on a gap, see Manager / Subordinate Terminology. For the broader protocol map, see the AMBA family overview.