The Default Slave

Chapters 11.1–11.2 showed the decoder asserting one-hot HSEL — but what happens when HADDR matches no mapped region? Without a fallback, the decoder would assert no HSEL, no slave would drive HREADY, and the master would hang forever waiting for a response. The default slave is the fix: the decoder selects it for any address that matches no real region, so the decode becomes total — every address selects exactly one target (a real slave or the default). The default slave always responds — typically with the two-cycle ERROR response for a real transfer to an unmapped address (telling the master the access is illegal), and a zero-wait OKAY for IDLE/BUSY (which aren't real accesses). So an unmapped access becomes a defined error the master can handle, not a silent deadlock. This chapter covers the default slave's role (completing the decode), its responses (ERROR vs OKAY), and why it's essential for bus liveness.

1. What Is It?

The default slave is a slave the decoder selects for any address that falls outside every mapped region. Its job:

• Catch unmapped addresses. When HADDR matches no real slave's region, the decoder asserts the default slave's select instead of leaving HSEL all-zero.
• Always respond. The default slave drives a defined response, so the transfer completes and the master doesn't hang.
• Flag the error. For a real transfer (NONSEQ/SEQ) to an unmapped address, it returns the two-cycle ERROR response — telling the master the access was illegal.
• Pass IDLE/BUSY. For IDLE/BUSY transfers, it returns a zero-wait OKAY (these aren't real accesses, so they're not errors).

So the default slave is the else branch of the decode: if no region matches, select the default. It completes the decode (makes it total) and guarantees a response for every access. The error response it returns turns an unmapped access into a defined, reportable event — the master (and the software/CPU behind it) learns the access was illegal, rather than the system silently hanging. So the default slave is the safety net that makes the address space total and the bus live.

2. Why Does It Exist?

The default slave exists because an address map can have gaps (unmapped addresses), and an access to a gap must still get a response — or the master hangs. The default slave provides that guaranteed response, turning a potential deadlock into a defined error.

The gap problem is the root cause: an address map rarely covers the entire address space — there are unmapped regions (reserved ranges, holes between peripherals, the vast unused space in a 32-bit address range). So a master can issue an access to an unmapped address (a software bug, a wild pointer, a misconfiguration). When it does, the decoder finds no matching region → no real slave's HSEL is asserted. Now: who responds? In AHB, the selected slave drives HREADY (and HRESP, read data). If no slave is selected, no slave drives HREADY — so HREADY is never asserted for this transfer. The master, waiting for HREADY high to complete the transfer, waits forever — a deadlock. So the gap problem is: an unmapped access has no responder → the master hangs. So something must respond to unmapped accesses. That something is the default slave. So the default slave exists to respond to the otherwise-unhandled unmapped accesses — preventing the hang.

The reason it returns an ERROR (not OKAY) for real transfers is to report the illegal access: an access to an unmapped address is a bug (the software/master shouldn't be accessing there). Returning OKAY would hide the bug — the master would think the (nonexistent) access succeeded, reading garbage or silently dropping a write. Returning ERROR surfaces the bug: the master sees the error, and typically the CPU takes a bus-fault exception (or the master flags the error to software). So the error response makes the unmapped access visible and debuggable rather than silently wrong. So the default slave returns ERROR to report the illegal access, not just to avoid the hang. So it both prevents the hang (responds) and reports the bug (with ERROR).

The reason it returns OKAY for IDLE/BUSY is that IDLE/BUSY aren't real accesses: an IDLE transfer means "no transfer this cycle," a BUSY means "master pausing." These can occur with the default slave selected (HADDR in an unmapped region during an IDLE). They're not illegal accesses — they're non-accesses. So flagging them as errors would be wrong (a spurious error). So the default slave, like any AHB slave, returns a zero-wait OKAY for IDLE/BUSY — not an error. So the default slave returns ERROR only for real transfers to unmapped addresses, and OKAY for non-transfers — the correct, discriminating behavior. So the default slave exists to guarantee a response to every access (preventing the hang), report unmapped real accesses as errors (surfacing the bug), and correctly pass IDLE/BUSY (no spurious errors).

3. Mental Model

Model the default slave as the "return to sender / undeliverable" desk at a post office — every letter that doesn't match a real address gets routed here, and instead of vanishing into a void (a lost letter, a hang), it gets a stamped "no such address" notice sent back (an ERROR response), so the sender learns the address was bad; but a blank envelope with no real letter inside (an IDLE) is just quietly set aside, not stamped undeliverable.

At a post office, most letters go to real addresses (mapped slaves). But some letters have addresses that don't exist (unmapped addresses). Without a plan, these letters would vanish — lost, with the sender never knowing (the master hangs, never learns). So the post office has an "undeliverable" desk (the default slave): every letter with no real address gets routed here. The desk doesn't just discard them — it stamps "no such address" and sends the notice back to the sender (the ERROR response), so the sender learns the address was bad and can fix it (the master takes a bus fault, software debugs). This is far better than the letter vanishing silently. But there's nuance: a blank envelope with no actual letter inside (an IDLE/BUSY — a non-access) shouldn't be stamped "undeliverable" — there's nothing to deliver; it's just quietly set aside (the zero-wait OKAY). So the undeliverable desk returns a notice for real bad-address letters, but quietly passes blank envelopes. Every letter is accounted for, bad addresses are reported, and non-letters aren't flagged.

This captures the default slave: the undeliverable desk = the default slave; letters with no real address = unmapped accesses; the "no such address" notice sent back = the ERROR response; the sender learning = the master taking a bus fault / reporting the error; the letter vanishing silently (without the desk) = the master hanging; the blank envelope quietly set aside = IDLE/BUSY getting a zero-wait OKAY. The catch-all desk that reports bad addresses and never lets an access vanish.

Watch the default slave's two-cycle ERROR response cycle by cycle:

The model's lesson: the undeliverable desk sends back a "no such address" notice — the access is reported, never lost. In the waveform, the unmapped access gets the two-cycle ERROR (not a hang): the master is told the access failed and the transfer completes.

4. Real Hardware Perspective

In hardware, the default slave is often not a separate block but a function of the decoder/interconnect: when no region matches, the interconnect itself drives the default (ERROR) response back to the master, behaving like a minimal slave that only generates responses.

The default-as-decoder-function is the common implementation: rather than instantiating a full separate slave, the interconnect's decode logic detects "no region matched" and drives the response signals (HREADY, HRESP) directly with the default behavior. So the "default slave" is logic inside the interconnect: a small response generator that produces the two-cycle ERROR for real transfers and zero-wait OKAY for IDLE/BUSY. It needs no address-decode of its own (it's the fallthrough), no storage, and drives no meaningful read data (read data is don't-care on an ERROR). So in hardware, the default slave is typically a few states and some response-driving logic in the interconnect — minimal. (Some designs do instantiate a real default-slave module for modularity; functionally it's the same.)

The two-cycle ERROR mechanics are standard AHB ERROR (chapter 7.x): a slave (here the default) cannot signal ERROR in a single cycle, because the master needs a cycle's warning to cancel any following pipelined transfer. So the ERROR response is two cycles: first cycle drives HRESP = ERROR with HREADY low (the warning — "error coming, and I'm extending the data phase a cycle"); second cycle drives HRESP = ERROR with HREADY high (completing the transfer with the error registered). The master samples HRESP = ERROR with HREADY high and knows the transfer failed. So the default slave implements the same two-cycle ERROR protocol as any slave — it's not a special error mechanism, just the standard ERROR response driven by the default. So in hardware, the default slave reuses the standard two-cycle ERROR response handshake.

The read-data and write behavior: on an ERROR, the read data is meaningless (the master discards it — it knows the access failed). The default slave drives no real data; it just completes the response. For a write to an unmapped address, the data is simply not stored (there's no real slave) — the ERROR tells the master the write didn't land. So the default slave performs no actual data transfer; it only generates the response that reports the access as illegal. So in hardware, the default slave is a minimal response-generator (often folded into the interconnect) implementing the standard two-cycle ERROR for real unmapped transfers and zero-wait OKAY for IDLE/BUSY, with no real data path.

5. System Architecture Perspective

At the system level, the default slave is what makes the address space total and safe — it guarantees the bus is live (no hang on any access) and that illegal accesses are observable (reported as errors), which is essential for robust SoCs and for software debugging.

The liveness guarantee is the default slave's core system contribution: a multi-slave bus must never deadlock on an access, no matter what address the master issues (including buggy ones). The default slave provides this: because the decode is total (every address selects a target), every access gets a response, so the master always makes progress (the transfer completes, with OKAY or ERROR). So the default slave is a liveness mechanism — it ensures the bus can't hang on an unmapped access. In a system where a master might issue a wild access (a software bug, an uninitialized pointer, a corrupted descriptor), this is critical: without the default slave, one bad access deadlocks the whole bus (and likely the whole SoC). So the default slave is the bus's protection against access-induced deadlock. So at the system level, the default slave guarantees liveness.

The observability / debuggability is the second contribution: by returning ERROR (not OKAY) for unmapped real accesses, the default slave makes illegal accesses observable. The CPU typically takes a bus-fault exception on an ERROR response, so an errant access surfaces as a fault (with the faulting address often captured) — invaluable for debugging (catching wild pointers, MMU/MPU misconfigurations, driver bugs). Without the ERROR (if unmapped accesses returned OKAY or hung), these bugs would be silent (garbage reads, dropped writes) or fatal-but-uninformative (a hang with no clue). So the default slave's ERROR response is a debugging and safety feature — it turns silent corruption / mysterious hangs into clear, attributable faults. This is why default slaves are sometimes enhanced to log the faulting address/master (a "fault capture" register) for diagnostics. So at the system level, the default slave makes illegal accesses observable and debuggable.

The safety/robustness view ties these together: in safety-critical or high-reliability systems, the default slave is part of the fault-handling architecture — it ensures that an out-of-bounds access (which could be a fault, an attack, or a bug) is contained (doesn't hang the bus) and reported (raises a fault for the system to handle, e.g. resetting a task, logging, entering a safe state). So the default slave is a building block of robust, fault-tolerant bus behavior. So at the system level, the default slave makes the address space total (liveness — no hang), illegal accesses observable (debuggability — reported as faults), and the system robust (safety — contained and reported faults). It's the small but essential piece that turns "an unmapped access" from a catastrophic silent failure into a defined, handleable event. The address map plus the default slave together give a complete, safe address space.

6. Engineering Tradeoffs

The default slave embodies the total-decode, fault-reporting design.

• Default slave (total decode) vs gaps that hang. A default slave makes every access get a response (no hang) at the minor cost of the default-response logic. Without it, an unmapped access hangs the bus. The default slave is essential — non-negotiable for a robust bus.
• ERROR vs OKAY for unmapped. Returning ERROR reports the illegal access (debuggable, faults the CPU) at no extra cost. Returning OKAY would hide the bug (silent garbage read / dropped write). ERROR is the correct choice — surface the bug.
• Folded-into-decoder vs separate module. Implementing the default as interconnect logic is minimal (a few states) and standard; a separate default-slave module is more modular but slightly more area. Most designs fold it in.
• Plain ERROR vs fault-capture. A plain default slave just returns ERROR (cheap); a fault-capture default slave also logs the faulting address/master (better diagnostics, slight cost). Safety/high-reliability systems often add fault capture.

The throughline: the default slave is the catch-all the decoder selects for any unmapped address, making the decode total (every access has a target → no hang) and returning the two-cycle ERROR for real unmapped transfers (reporting the illegal access) and zero-wait OKAY for IDLE/BUSY. It guarantees liveness (no deadlock on any access), observability (illegal accesses reported as faults), and robustness (faults contained and handleable). It's typically minimal logic folded into the interconnect, reusing the standard two-cycle ERROR response.

7. Industry Example

Trace the default slave catching a wild access.

A microcontroller has RAM, flash, and peripherals mapped; large ranges are unmapped. A driver bug produces a wild pointer.

• Normal access (mapped). The CPU reads 0x2000_0100 (RAM). The decoder selects the RAM, which returns the data with OKAY. Normal operation — the default slave isn't involved.
• Wild access (unmapped). The driver bug dereferences an uninitialized pointer: the CPU reads 0xE000_0000, which is unmapped. The decoder finds no matching region → selects the default slave. The default slave returns the two-cycle ERROR: HRESP = ERROR with HREADY low, then HRESP = ERROR with HREADY high. The transfer completes (no hang).
• The CPU faults. The CPU, seeing the ERROR response, takes a bus-fault exception. The fault handler runs, often with the faulting address captured — so the developer sees "bus fault at 0xE000_0000" and can trace it to the wild pointer. The bug is surfaced and debuggable.
• Contrast: no default slave. Had there been no default slave, the read to 0xE000_0000 would assert no HSEL, no slave would drive HREADY, and the CPU would hang on that load instruction — freezing the system with no diagnostic. The developer would see a dead board and have to painstakingly track down the hang. The default slave turned this into a clean, attributable fault.
• IDLE handling. Between transactions, the master drives IDLE while HADDR happens to point to an unmapped range — the default slave is selected but returns a zero-wait OKAY (IDLE isn't a real access), so no spurious fault is raised. Only real unmapped accesses fault.

The example shows the default slave's value: the wild access is caught, completed with an ERROR, and surfaced as a CPU bus fault with the faulting address — turning a potential silent hang into a debuggable fault. Meanwhile, normal accesses and IDLEs are unaffected. This is why every robust SoC has a default slave: it's the safety net for the inevitable stray access.

8. Common Mistakes

9. Interview Insight

The default slave is a robustness-focused interview topic — the total-decode role, the ERROR response, and especially the no-default-slave-hangs-the-bus consequence are the signals.

The answer that lands gives the role, the response, and the consequence: "The default slave is the slave the decoder selects for any address that matches no mapped region. It makes the decode total — every address selects exactly one target, a real slave or the default — so every access gets a response. It returns the two-cycle ERROR response for a real transfer (NONSEQ/SEQ) to an unmapped address: HRESP = ERROR with HREADY low, then HRESP = ERROR with HREADY high, completing the transfer with an error. This tells the master the access was illegal — typically the CPU takes a bus-fault exception, so the bad access is surfaced and debuggable. For IDLE/BUSY transfers it returns a zero-wait OKAY, since those aren't real accesses. The reason it's essential: without a default slave, an unmapped access asserts no HSEL, so no slave drives HREADY, so the master hangs forever waiting for the transfer to complete — a bus deadlock, often freezing the whole SoC with no diagnostic. The default slave turns that potential silent hang into a clean, reported error. It's usually minimal logic folded into the interconnect, reusing the standard two-cycle ERROR response." The total-decode role, the ERROR (not OKAY) response, and the hang-prevention/liveness consequence are the senior signals.

10. Practice Challenge

Reason from the default slave.

1. Role. Explain what the default slave is and how the decoder uses it to make the decode total.
2. The hang. Trace exactly what happens, signal by signal, if there's no default slave and a master accesses an unmapped address.
3. Read the waveform. From Figure 2, identify the two cycles of the ERROR response and what HREADY does in each.
4. ERROR vs OKAY. Explain why the default slave returns ERROR for real transfers but OKAY for IDLE/BUSY.
5. Observability. Explain how the ERROR response makes a wild access debuggable (what the CPU does).

11. Key Takeaways

• The default slave is the catch-all the decoder selects for any address that matches no mapped region — making the decode total (every address selects exactly one target, real or default).
• It always responds — the two-cycle ERROR response for a real transfer (NONSEQ/SEQ) to an unmapped address, and a zero-wait OKAY for IDLE/BUSY (not real accesses).
• ERROR (not OKAY) reports the illegal access — the master/CPU takes a bus fault (often capturing the address), surfacing the bug instead of hiding it (silent garbage read / dropped write).
• Without a default slave, an unmapped access hangs the bus — no HSEL → no HREADY → the master waits forever (deadlock, often freezing the whole SoC with no diagnostic). The default slave is mandatory.
• It guarantees liveness and observability — every access completes (no hang), and illegal accesses are reported as faults (debuggable, safe).
• It's typically minimal — a small response generator folded into the interconnect, reusing the standard two-cycle ERROR response, with no real data path.

12. What Comes Next

You now understand the default slave — the catch-all that makes the decode total, returns the ERROR response for unmapped accesses, and guarantees the bus never hangs. The next chapters complete the addressing picture:

• The Address Map (next) — defining an SoC address map (disjoint regions, alignment, the default region) that drives the decoder.
• Illegal Address Behavior — what happens on access to an unmapped region, in more detail.
• Sparse Memory Maps — decoding for sparse, non-power-of-two regions.

To revisit the decode and HSEL, see Address Decoding and HSEL Generation; for the ERROR response itself, see The ERROR Response.