AMBA AHB · Module 18

Incorrect HSEL

Diagnosing a transfer hitting the wrong (or no, or multiple) slave — HSEL is the per-slave select the interconnect's address decoder generates from HADDR. Wrong slave reads/writes the wrong device; no slave falls in an unmapped hole (hang, or a default slave should ERROR); multiple slaves cause contention on HRDATA/HREADYOUT. Diagnose by taking the address, computing which single HSEL the address map says should be asserted, and comparing against what the decoder actually asserted — the decoder must be exactly one-hot for any mapped address and select a default slave for unmapped ones. Test the region boundaries (off-by-one bugs hide there); the cause is in the interconnect's address decoder.

The misalignment chapter (18.3) covered data going to the wrong cycle; this chapter covers a transfer going to the wrong place: an incorrect HSEL. HSEL is the per-slave select that the interconnect's address decoder generates from HADDR — telling each slave whether it is the one being addressed (chapters 3.10, 11.2). An incorrect HSEL means a transfer hits the wrong slave, no slave, or multiple slaves. The failure modes: wrong slave selected (the decode picks the neighbor's region → the transfer reads/writes the wrong device); no slave selected (the address falls in an unmapped hole → nothing responds, which can hang the bus, or a default slave should return an error); and multiple slaves selected (two HSELs asserted at once → two slaves drive the bus → contention on HRDATA/HREADYOUT). The diagnosis is systematic: take the address, compute which slave the address map says should be selected, and compare against which HSEL the decoder actually asserted — the decoder must produce exactly one-hot HSEL for any mapped address (and a clean default-slave selection for unmapped ones). The causes — a wrong decode range/mask, an off-by-one boundary, overlapping regions, or a missing default slave — are all in the interconnect's address decoder, so the fix is there. This chapter builds the diagnosis.

1. What Is It?

Incorrect HSEL is a decode bug where a transfer selects the wrong/no/multiple slaves; debugging it means comparing the map's expected select against the decoder's output. Its parts:

HSEL is the decoder's select — the per-slave select generated from HADDR by the interconnect's address decoder (one HSEL per slave).
The failure modes — wrong slave (neighbor's region), no slave (unmapped hole → hang or default-ERROR), multiple slaves (contention).
The diagnosis — HADDR → which single HSEL the address map says → compare vs what the decoder asserted. Must be exactly one-hot (mapped) / default (unmapped).
The cause — in the interconnect's address decoder (wrong range/mask, off-by-one, overlapping regions, missing default).

Figure 1 — diagnosing an incorrect HSEL. HSEL is the address decoder's per-slave select (from HADDR). Failure modes: wrong slave selected (decode picks the neighbor's region → reads/writes the wrong device; cause: wrong range/mask, off-by-one); no slave selected (address falls in an unmapped hole → nothing responds (hang), or a default slave should ERROR); multiple slaves selected (two HSELs asserted → contention on HRDATA/HREADYOUT; cause: overlapping regions). Diagnosis: take HADDR → compute which slave the address map says should be selected → compare vs which HSEL the decoder asserted. Mismatch = the bug; exactly-one HSEL must match the map. The cause is in the interconnect's address decoder. Common causes → fix the decoder: wrong decode range/mask, off-by-one boundary, overlapping regions, missing default slave, HSEL not aligned to the address phase.

So incorrect HSEL is a decode bug — the address decoder generating the wrong select. The key to debugging it is the address map: the map defines the correct answer (which slave should be selected for each address), so you compare the decoder's actual HSEL against the map's expected one. The decoder's contract is precise: for any mapped address, exactly one HSEL must be asserted (one-hot) — the one matching the map; for any unmapped address, a default slave should be selected (to handle the access — typically with an ERROR — chapter 11.5). The three failure modes are deviations from this contract: wrong slave (the wrong one-hot — a decode range error), no slave (zero HSELs — an unmapped hole with no default), multiple slaves (more than one HSEL — overlapping regions). All three originate in the decoder (the interconnect's address-decode logic — 11.2). And HSEL, being an address-phase signal, must align with the rest of the address-phase context (related to misalignment — 18.3). So incorrect HSEL is the decode bug debugged by map-vs-decoder comparison. So it's a wrong-place transfer.

Incorrect HSEL = a transfer hits the wrong/no/multiple slaves (the decoder's per-slave select is wrong). Debug by comparing the ADDRESS MAP's expected one-hot HSEL against the decoder's actual output; the decoder must be exactly one-hot (mapped) / default (unmapped); the cause is in the interconnect's address decoder

Incorrect HSEL in one frame: HSEL is the per-slave select the interconnect's address decoder generates from HADDR (one HSEL per slave, telling each whether it is addressed); an incorrect HSEL means a transfer hits the wrong slave, no slave, or multiple slaves. The three failure modes: (a) wrong slave selected — the decode picks the neighbor's region, so the transfer reads/writes the wrong device (cause: a wrong decode range/mask or an off-by-one boundary); (b) no slave selected — the address falls in an unmapped hole, so nothing responds (which can hang the bus — like a stuck HREADY — 18.1), unless a default slave catches it and returns an ERROR (11.5); (c) multiple slaves selected — two HSELs are asserted at once, so two slaves drive the bus, causing contention on HRDATA/HREADYOUT (cause: overlapping regions). The diagnosis is systematic: take the address, compute which slave the address map says should be selected (the expected HSEL), and compare against which HSEL the decoder actually asserted. The decoder's contract: exactly one-hot HSEL for any mapped address (the one matching the map), and a default-slave selection for unmapped addresses. A mismatch (wrong one-hot, zero, or multiple) is the bug. The causes — wrong range/mask, off-by-one boundary, overlapping regions, missing default slave, or HSEL not aligned to the address phase — are all in the interconnect's address decoder (11.2), so the fix is there. (Note: HSEL is an address-phase signal — related to misalignment, 18.3.)

2. Why Does It Exist?

Incorrect HSEL exists because the address decoder maps a continuous address space onto discrete slaves — a range-matching problem that's easy to get wrong (boundaries, masks, overlaps, holes) — and the select drives where the transfer goes, so a decode error sends the transfer to the wrong place (wrong/no/multiple slaves), causing wrong-device access, hangs, or contention.

The range-matching is error-prone is the root: the decoder maps the continuous HADDR space onto discrete slave regions — a range-matching problem (is HADDR in slave A's range? B's? ...). This involves boundaries (where one region ends and the next begins — off-by-one prone), masks (the address bits that select the region — wrong-mask prone), coverage (every address mapped — hole prone), and exclusivity (no overlaps — overlap prone). Each is easy to get wrong. So incorrect HSEL exists because range-matching is error-prone. So it's a decode-logic bug. So matching can err.

The the select drives where the transfer goes is the consequence: HSEL determines which slave the transfer reaches. So a decode error misdirects the transfer: a wrong HSEL sends it to the wrong device (reading/writing the wrong registers/memory — corruption); no HSEL sends it nowhere (an unmapped hole — nothing responds → hang, or a default-ERROR); multiple HSELs send it to two slaves (both respond → contention). So the consequence of a decode error is a misdirected transfer. So incorrect HSEL matters because it corrupts/hangs/contends. So the select is consequential. So errors are harmful.

The the map is the reference is the debug basis: the address map (11.4) defines the correct decode — which slave for each address. So debugging a decode error is comparing the decoder's actual output against the map's intended output. The map is the golden reference. So the debug method exists because the map provides the correct answer. So it's map-referenced. So incorrect HSEL exists because: the address decoder maps a continuous space onto discrete slaves (a range-matching problem — boundaries/masks/holes/overlaps — error-prone — the why); the select drives where the transfer goes (a decode error misdirects — wrong-device/hang/contention — the consequence); and the address map is the golden reference (defining the correct decode — the debug basis). So incorrect HSEL is the decode bug — caused by error-prone range-matching in the decoder, misdirecting transfers, and debugged by comparing the decoder's output against the address map. So this chapter teaches the map-vs-decoder comparison. So compare against the map to find the decode bug.

3. Mental Model

Model debugging an incorrect HSEL as finding why a mail sorter is delivering to the wrong apartment — you check the building directory (the address map) against where the sorter actually put each letter. A letter for apartment 2B that lands in 2A (wrong slave), or in a non-existent unit so it's lost (no slave / unmapped hole), or photocopied into two boxes (multiple slaves). To find the fault, you take the address on the envelope, look up the correct box in the directory, and compare against where the sorter sent it. The fault is in the sorter's rules — a wrong range, an off-by-one floor boundary, two units mapped to the same box.

A mail-sorting room (the interconnect's decoder) that routes letters (transfers) to apartment mailboxes (slaves) based on the address on the envelope (HADDR). There's a building directory (the address map) that says exactly which box each apartment number maps to — 2A → box 1, 2B → box 2, 3A → box 3, etc. The sorter's job is to read the address and put the letter in the one correct box. Now, incorrect routing (incorrect HSEL) is when the sorter gets it wrong. Wrong box: a letter for 2B lands in 2A — the neighbor's box (wrong slave — a range error). No box: a letter addressed to a non-existent unit (an unmapped hole) — it's lost (nothing responds → the sender waits forever — hang), unless there's a "dead letter" box (a default slave) that catches it and returns it marked "no such address" (an ERROR). Two boxes: the sorter photocopies the letter into two boxes (multiple slaves — two units overlapping the same address) — now two people respond, clashing (contention). To find the fault, you take the address on the envelope, look up the correct box in the directory (the map's expected select), and compare against where the sorter actually put it (the decoder's actual HSEL). The mismatch is the bug. And the fault is in the sorter's rules (the decoder): a wrong range (it thinks 2B is in 2A's range), an off-by-one floor boundary (it puts the first unit of floor 3 with floor 2), two units mapped to the same box (overlap), or no dead-letter box (no default → lost mail). The directory is the reference — the sorter must match it exactly, one box per mapped address.

This captures incorrect-HSEL debug: the mail sorter = the address decoder; the apartment mailboxes = the slaves; the address on the envelope = HADDR; the building directory = the address map; putting the letter in the one correct box = asserting the one correct HSEL; wrong box (neighbor's) = wrong slave selected; non-existent unit, lost = unmapped hole (no slave); the dead-letter box returning "no such address" = the default slave returning ERROR; photocopied into two boxes = multiple slaves selected (contention); looking up the correct box and comparing = comparing the map's expected HSEL against the decoder's actual; the fault in the sorter's rules = the cause in the decoder (range/off-by-one/overlap/no-default). Look up the directory, compare against where the sorter sent it, and fix the sorter's rules.

Watch an incorrect HSEL on the waveform — a wrong-slave decode:

Incorrect HSEL: wrong-slave decode at a boundary

3 cycles

Figure 2 — an incorrect HSEL: a wrong-slave decode (off-by-one boundary). The address map: 0x0–0x3 = Slave A, 0x4–0x7 = Slave B. A transfer to address 0x4 should select Slave B (the start of B's region). But a buggy decoder with an off-by-one boundary (it treats 0x4 as still in A's region, e.g. using '<= 0x4' instead of '< 0x4' for A) asserts HSEL_A instead of HSEL_B. The 'expected HSEL' row shows B for 0x4; the 'actual HSEL' shows A. The 'check' fires: the transfer reads/writes Slave A (the wrong device) instead of Slave B. The boundary address (0x4) is exactly where off-by-one decode bugs bite — test the region boundaries specifically.

The model's lesson: look up the directory, compare against where the sorter sent it, and fix the sorter's rules. In the waveform, the boundary address 0x4 (the start of B's region) is mis-decoded to Slave A — an off-by-one in the decoder. Comparing the map's expected (B) against the actual (A) reveals it. The fix is in the decoder's boundary logic.

4. Real Hardware Perspective

In debug, you build the address-map reference table (address → expected HSEL), check the decoder's actual HSEL against it (especially at boundaries), classify the failure (wrong/no/multiple), and trace to the decoder's range/mask/default logic.

The the reference table: from the address map (11.4), build a table mapping test addresses (especially boundary addresses — the first and last of each region, and just outside) to the expected HSEL (which single slave). This is the golden reference for the decode. So in debug, build the address → expected-HSEL table. So it's the reference. So that's step one.

Figure 3 — the decode check: address map vs asserted HSEL. The map: 0x0–0x1 → Slave A, 0x2–0x3 → Slave B, 0x4–0x5 → Slave C, else → default slave. A transfer to 0x2 (in B's region) → the map says assert HSEL_B only. Check what the decoder actually asserted: HSEL_B only → correct; HSEL_A/C high → wrong range/off-by-one; no HSEL → unmapped hole/missed decode; two HSELs → overlapping regions (contention). Build a table mapping each test address to the expected single HSEL and check the decoder matches. The rule: exactly one-hot HSEL for any mapped address, and a clean default-slave selection for unmapped addresses.

The check at boundaries and classify: check the decoder's HSEL against the table — especially at region boundaries (where off-by-one bugs bite — the first/last address of each region). Classify the failure: one HSEL, wrong slave → a range/boundary error (the range bounds are wrong); zero HSELs → an unmapped hole (the address isn't covered — and no default caught it); multiple HSELs → overlapping regions (two ranges include the address). So in debug, check (at boundaries) and classify the failure. So it's classification. So that points to the cause.

The trace to the decoder logic: with the failure classified, trace to the specific decoder logic: a range/boundary error → the comparison bounds (the < vs <=, the mask, the base/limit); an unmapped hole → missing region coverage and/or a missing default slave (11.5); overlapping regions → two ranges that include the same address (fix the bounds so they're disjoint). And the fix is in the decoder (the interconnect's address-decode logic — 11.2). An assertion helps: (mapped_address) |-> $onehot(HSEL) (exactly one-hot for mapped) and (unmapped) |-> HSEL_default. So in debug, incorrect HSEL is a map-referenced check (build the table → check the decoder, especially at boundaries → classify wrong/no/multiple → trace to the decoder's range/mask/default logic → fix). So in debug, compare against the map and fix the decoder. So that's the method.

5. System Architecture Perspective

At the system level, an incorrect HSEL is an address-routing failure — the interconnect misrouting a transfer — so it breaks the fundamental "the right transfer reaches the right slave" guarantee; its three modes map to three system consequences (wrong-device corruption, hang, contention), and a default slave is the key robustness mechanism for the no-slave case.

The address-routing failure: the interconnect's job is to route each transfer to the correct slave (based on the address). An incorrect HSEL is a routing failure — the interconnect sends the transfer to the wrong place. So it breaks the fundamental interconnect guarantee. So at the system level, it's a routing bug — the interconnect's core function failing. So it's foundational. So routing must be correct.

The three system consequences: the three modes have distinct system impacts. Wrong slave → silent corruption (the transfer succeeds but at the wrong device — wrong data read/written, quietly). No slave → a hang (nothing responds — the bus waits forever, like a stuck HREADY — 18.1) unless contained. Multiple slaves → contention (two slaves drive HRDATA/HREADYOUT → electrical/logical conflict → corrupt/undefined behavior). So at the system level, incorrect HSEL causes corruption, hangs, or contention — all serious. So the consequences are severe. So decode correctness matters.

The default slave for robustness: the no-slave case is contained by a default slave — a slave the decoder selects for any unmapped address, which returns an ERROR (11.5). So an access to an unmapped hole becomes a clean bus-fault (not a hang). So the default slave is the robustness mechanism for unmapped accesses — a system-design best practice. So at the system level, an incorrect HSEL is an address-routing failure (the interconnect misrouting — breaking its core guarantee), with three consequences (wrong-device corruption, hang, contention), mitigated (for the no-slave case) by a default slave (turning an unmapped-access hang into a clean ERROR — robustness). So incorrect HSEL is where the interconnect's routing — the foundation of "the right transfer reaches the right slave" — can break, with severe consequences, making correct decode (and a default slave) essential. So get the decode right and add a default slave. So routing is foundational.

6. Engineering Tradeoffs

Debugging an incorrect HSEL embodies the map-reference, boundary-check, classify-and-trace approach.

Map-reference vs guess. Comparing the decoder against the address-map reference (the golden answer) localizes the bug; guessing is slow. Build the reference table.
Boundary testing vs random addresses. Testing region boundaries (first/last/just-outside) catches off-by-one decode bugs (where they bite); random addresses often miss the boundaries. Test the boundaries specifically.
Default slave vs unmapped hole. A default slave (ERROR on unmapped) contains the no-slave case (clean fault); an unmapped hole with no default hangs. Add a default slave.
One-hot check vs assume. An exactly-one-hot HSEL assertion (for mapped addresses) catches wrong/no/multiple decodes automatically; assuming one-hot misses overlaps/holes. Assert one-hot.

The throughline: an incorrect HSEL means a transfer hits the wrong slave, no slave, or multiple slaves — HSEL is the per-slave select the interconnect's address decoder generates from HADDR. Wrong slave (neighbor's region → wrong-device access; cause: wrong range/off-by-one); no slave (unmapped hole → hang, or a default slave should ERROR); multiple slaves (overlapping regions → contention). Diagnose by comparing the address map's expected (single, one-hot) HSEL against the decoder's actual output — especially at region boundaries (where off-by-one bugs bite). The causes — wrong range/mask, off-by-one boundary, overlapping regions, missing default slave — are all in the interconnect's address decoder. It's an address-routing failure with three consequences (corruption/hang/contention), mitigated (no-slave case) by a default slave.

Test the REGION BOUNDARIES (first/last/just-outside address of each region) — that's where off-by-one decode bugs hide; random mid-region addresses miss them. The decoder must be exactly ONE-HOT for mapped addresses (none = hole/hang, multiple = contention) — and a DEFAULT SLAVE must catch unmapped addresses, or they hang

Three disciplines make incorrect-HSEL debugging effective: (1) Test the region boundaries, not just mid-region. Off-by-one decode bugs (the most common HSEL bug) only manifest at region boundaries — the first address of a region, the last address, and the addresses just outside. A test using random mid-region addresses misses them entirely: a mid-region address decodes correctly even with an off-by-one boundary (the error is only at the edge). So you must specifically test the boundaries: the first and last address of each region, and the first address of the next region (which an off-by-one might steal). E.g. if region A is 0x0–0x3 and B is 0x4–0x7, test 0x3 (last of A), 0x4 (first of B — the off-by-one target), 0x7 (last of B), 0x8 (first of C). The bug at 0x4 (B mis-decoded to A) is invisible with a random address like 0x6. (2) Assert exactly-one-hot HSEL. For any mapped address, exactly one HSEL must be high. Zero HSELs = an unmapped hole (or missed decode) → nothing responds → hang. Multiple HSELs = overlapping regions → two slaves drive the bus → contention (corrupt/undefined HRDATA/HREADYOUT). An $onehot(HSEL) assertion (for mapped addresses) catches both automatically — a zero or multiple decode fires it. Don't assume one-hot; assert it. (3) Add a default slave for unmapped addresses. An access to an unmapped address (a hole in the map — common in sparse maps — 11.6) selects no slave → nothing responds → the bus hangs (like a stuck HREADY — 18.1). The fix/guard is a default slave: the decoder selects it for any unmapped address, and it returns an ERROR (11.5) — turning a hang into a clean bus-fault. So every robust interconnect needs a default slave. The unifying discipline: test the boundaries (off-by-one bugs hide there), assert one-hot (catch holes and overlaps), and add a default slave (contain unmapped accesses). The tell of a missed HSEL bug: a design that passes mid-region tests but mis-routes at a boundary, or hangs on an unmapped access (no default). (See HSEL Generation, The Address Map, and Illegal Address Behavior.)

7. Industry Example

Debug an incorrect HSEL causing a peripheral to read the wrong device, plus an unmapped-access hang.

A system has two bugs: a CPU read of a timer returns GPIO data (wrong device), and an access to an unused address hangs the bus.

Bug 1 — wrong slave (off-by-one). The CPU reads the timer (mapped at 0x4000_0000), but gets GPIO data (mapped at 0x3FFF_FFFF...0x3000_0000). On the waveform, the transfer to 0x4000_0000 asserts HSEL_GPIO instead of HSEL_TIMER.
Diagnose via the map. The address map says 0x4000_0000 → timer. But the decoder asserted GPIO. The boundary 0x4000_0000 (the first address of the timer region) is mis-decoded — an off-by-one: the GPIO region's upper bound was <= 0x4000_0000 (inclusive) instead of < 0x4000_0000, so it captures the timer's first address. The fix: correct the GPIO region's upper bound (exclusive). (Found by testing the boundary — a mid-region timer address would've decoded fine.)
Bug 2 — no slave (unmapped hole, hang). An access to 0x5000_0000 (an unused/unmapped address) hangs the bus — no HSEL is asserted, so no slave responds, and HREADY never rises (a stuck-HREADY-like hang — 18.1).
Diagnose via one-hot + default. The one-hot check shows zero HSELs for 0x5000_0000 — an unmapped hole. And there's no default slave to catch it. The fix: add a default slave that the decoder selects for any unmapped address, returning an ERROR (11.5) — so the unmapped access becomes a clean bus-fault (not a hang).
Add assertions. You add (mapped) |-> $onehot(HSEL) (catches wrong/no/multiple for mapped addresses) and a default-slave selection for unmapped — catching both bug classes automatically in future.

The example shows both common HSEL bugs and the method: the wrong-slave off-by-one (found by testing the boundary and comparing against the map) and the unmapped-hole hang (found by the one-hot check and fixed with a default slave). The map was the reference; the boundary was where the off-by-one hid; the default slave contained the unmapped case. This is how you debug a routing failure. This is the transfer reaching the right slave.

8. Common Mistakes

Incorrect-HSEL debugging misconceptions

"Test random addresses." No — test the region boundaries (first/last/just-outside). Off-by-one decode bugs (the most common) only bite at boundaries; mid-region addresses miss them.
"Any one HSEL is fine." No — it must be the correct one (per the map). A wrong one-hot is a wrong-slave decode (wrong-device access). Compare against the map.
"No HSEL is harmless." No — zero HSELs = an unmapped hole → nothing responds → hang. Add a default slave to return ERROR.
"Multiple HSELs just pick one." No — multiple HSELs = contention (two slaves drive HRDATA/HREADYOUT) → corrupt/undefined. Fix the overlapping regions; assert one-hot.
"The slave is wrong (it returned bad data)." No — for a wrong-slave decode, the selected slave responded correctly (it was just the wrong slave). The cause is the decoder, not the slave.
"Unmapped accesses can't happen." They can (sparse maps, software bugs). A default slave must catch them (ERROR) — or they hang.

9. Interview Insight

Incorrect HSEL is a solid debug interview topic — the map-vs-decoder method, the boundary-testing insight, and the one-hot/default-slave discipline are the signals.

Figure 4 — a strong answer in one card: HSEL is the address decoder's per-slave select; failures are wrong/no/multiple slaves; diagnose by HADDR → which single HSEL the address map says → compare vs what the decoder asserted; the decoder must be exactly one-hot (mapped) / default (unmapped); causes are wrong range/mask, off-by-one boundary, overlapping regions, no default — all in the decoder. The senior point: compare the map's expected one-hot HSEL vs the decoder's actual output, and fix the decode.

The answer that lands gives the map-vs-decoder method and the boundary insight: "HSEL is the per-slave select the interconnect's address decoder generates from the address — one HSEL per slave, telling each whether it's the one being addressed. An incorrect HSEL means a transfer hits the wrong slave, no slave, or multiple slaves. Wrong slave: the decode picks the neighbor's region, so the transfer reads or writes the wrong device. No slave: the address falls in an unmapped hole, so nothing responds — which hangs the bus, unless a default slave catches it and returns an error. Multiple slaves: two HSELs are asserted, so two slaves drive the bus, causing contention on HRDATA and HREADYOUT. To debug it, I use the address map as the golden reference: I take the address, compute which single slave the map says should be selected, and compare against which HSEL the decoder actually asserted. The decoder's contract is exactly one-hot for any mapped address — the one matching the map — and a default-slave selection for unmapped addresses. The key technique is testing the region boundaries, not random mid-region addresses, because the most common decode bug is an off-by-one at a boundary — say a region's upper bound is inclusive when it should be exclusive, so it steals the first address of the next region. A mid-region address decodes fine even with that bug; only the boundary address exposes it. So I test the first and last address of each region and the first address of the next. I'd also assert exactly-one-hot HSEL, which catches both zero HSELs (an unmapped hole that would hang) and multiple HSELs (overlapping regions that cause contention). And for unmapped addresses, I'd make sure there's a default slave that returns an error, so an unmapped access becomes a clean bus fault instead of a hang. The cause is always in the interconnect's address decoder — wrong range or mask, off-by-one boundary, overlapping regions, or a missing default — so that's where the fix goes, not the slave." The map-vs-decoder method, the boundary-testing insight, and the one-hot/default-slave discipline are the senior signals.

🔍 The discriminator: debug HSEL against the ADDRESS MAP (the golden reference) — compute the expected one-hot HSEL per address and compare; TEST THE BOUNDARIES (off-by-one bugs hide there, not mid-region); assert one-hot (catch holes/overlaps) and add a default slave (unmapped → ERROR, not hang); the cause is the DECODER, not the slave

The discriminator on incorrect HSEL is whether you debug against the address map and test the boundaries. A weak answer says "the wrong slave was selected, I'd check the decode." A solid answer adds the three failure modes (wrong/no/multiple) and that the decoder is the cause. But the senior answer leads with the map-as-reference method: the address map (11.4) defines the correct decode, so you compute the expected HSEL per address and compare against the actual. The standout technique is boundary testing: the most common decode bug is an off-by-one at a region boundary (an inclusive bound that should be exclusive, stealing the next region's first address), and it only manifests at the boundary — a mid-region address decodes fine even with the bug. So test the first/last/just-outside address of each region — random mid-region testing misses off-by-one bugs (the #1 HSEL bug). The other senior signals: (1) assert exactly-one-hot HSEL for mapped addresses — zero = an unmapped hole (→ hang) and multiple = overlapping regions (→ contention) — $onehot catches both; (2) add a default slave for unmapped addresses (→ ERROR, a clean bus-fault, not a hang — 11.5) — the key robustness mechanism; (3) the cause is the decoder, not the slave — for a wrong-slave decode, the selected slave responded correctly (just the wrong one), so debug the decode, not the slave. The framing that impresses: an incorrect HSEL is an address-routing failure (the interconnect's core function), with three distinct consequences (wrong-device corruption, hang, contention), debugged by the golden map reference. A candidate who debugs against the map, insists on boundary testing, asserts one-hot, and adds a default slave demonstrates real interconnect-debug depth — knowing the bug is in the decode and where it hides (the boundaries).

10. Practice Challenge

Build and reason from debugging an incorrect HSEL.

The failure modes. Describe the three HSEL failure modes (wrong/no/multiple slaves) and their consequences.
Map-vs-decoder. Explain how to diagnose by comparing the address map's expected HSEL against the decoder's actual output.
Read the waveform. From Figure 2, explain how the boundary address 0x4 exposes the off-by-one decode (HSEL_A instead of HSEL_B).
Boundary testing. Explain why you must test region boundaries (not mid-region) and why the cause is the decoder, not the slave.
Default slave. Explain why a default slave is essential and how it handles the no-slave (unmapped) case.

11. Key Takeaways

Incorrect HSEL = a transfer hits the wrong/no/multiple slaves — HSEL is the per-slave select the interconnect's address decoder generates from HADDR. Wrong slave (wrong-device access), no slave (hang / default-ERROR), multiple slaves (contention).
Diagnose against the address map — take HADDR, compute which single HSEL the map says, and compare against the decoder's actual output. The map is the golden reference.
Test the region boundaries — off-by-one decode bugs (the most common) hide at region edges (first/last/just-outside); mid-region addresses miss them.
Assert exactly-one-hot HSEL (for mapped addresses) — zero = an unmapped hole (hang); multiple = overlapping regions (contention). $onehot catches both.
Add a default slave — for unmapped addresses → it returns an ERROR (clean bus-fault, not a hang — 11.5). The key robustness mechanism.
The cause is the decoder, not the slave — for a wrong-slave decode, the selected slave responded correctly (just the wrong one). Fix the decoder's range/mask/boundary/default logic (11.2).

12. What Comes Next

You now can debug a routing failure. The next chapters cover the remaining failure modes:

Wrong HRDATA Timing (next) — diagnose read data returned a cycle early or late.
Bad HRESP, Burst Wrap Error, Arbitration Bug, and the rest — diagnose the other failures, building to a general waveform-debug methodology.

To revisit HSEL and the decoder, see HSEL, HSEL Generation, and Address Decoding; for the map and unmapped behavior, see The Address Map and Illegal Address Behavior.