AHB Integration Checklist

The third checklist is the AHB Integration Checklist: the list to walk when wiring an AHB block into a fabric or SoC. Where the design checklist confirms a block is correct in isolation, integration bugs are about connecting the pieces correctly — the interconnect routing, the address map, the clock/reset distribution. A block that's perfect alone can fail in the system if its HREADY is routed wrong or the read-mux select is misaligned. The checklist has seven categories: (1) address map + decoder — no overlaps or gaps, one-hot HSEL, a default slave for unmapped addresses; (2) HREADY routing — the shared HREADY is the addressed slave's HREADYOUT, routed correctly; (3) HRDATA muxing — the read-data mux uses a registered, data-phase-aligned select; (4) arbitration (if multi-master) — an arbiter granting one master, handover at boundaries; (5) reset + clock — distributed/synchronized to every block, CDC at bridges; (6) tie-offs + unused — ports safely tied off, no floating inputs; (7) bus topology — shared bus vs matrix matches the bandwidth need, bridges isolate slow peripherals. Most integration bugs live in the routing — the HREADY source, the read-mux's data-phase alignment, and the address map. This chapter walks each item with the check to perform.

1. What Is It?

This checklist is the sign-off list for wiring AHB into a fabric — confirm each before integration sign-off. The seven categories:

• (1) Address map + decoder — no overlaps/gaps; one-hot HSEL; a default slave for unmapped addresses (so a stray access errors, not hangs).
• (2) HREADY routing + (3) HRDATA muxing — HREADY is the addressed slave's HREADYOUT (routed correctly); the read-mux select is registered/data-phase-aligned.
• (4) Arbitration + (5) reset/clock — an arbiter (if multi-master); reset/clock to every block, CDC at bridges.
• (6) Tie-offs/unused + (7) topology — no floating inputs; shared bus vs matrix fits the bandwidth; bridges isolate slow peripherals.

So the integration checklist confirms the fabric is wired correctly — the blocks you designed and verified are connected properly. The value is catching the system-level wiring bugs that don't appear in a single block: a HREADY routed from the wrong slave, a read-mux select that's address-phase (not data-phase) aligned, an address-map overlap, a floating input. These are integration bugs — invisible in unit test, fatal in the system. So this chapter is the integration sign-off. So walk the checklist when wiring AHB into a fabric.

2. Why Does It Exist?

This checklist exists because integration bugs are different from design bugs (a correct block can fail in the system) — and because the interconnect routing is subtle (the HREADY source and the data-phase-aligned read-mux are easy to get wrong) — and because integration bugs are expensive (they appear late, in the system, where they're hard to localize).

The integration bugs are different is the root: a block can be perfectly correct in isolation (passes its unit tests) yet fail in the system — because the failure is in how it's wired, not in the block. So integration needs its own checks (the connections, not the blocks). So this checklist exists to cover the wiring. So integration is distinct. So check the connections.

The the interconnect routing is subtle is the focus: the interconnect's jobs — decode, read-mux, HREADY routing — have subtle correctness requirements (the read-mux must use the data-phase select; HREADY must come from the addressed slave). These are easy to get wrong. So this checklist focuses on the routing. So it exists to catch routing bugs. So it's the routing focus. So check the routing carefully.

The integration bugs are expensive is the economics: an integration bug appears late (during integration, not unit test) and is hard to localize (it's in the system, not a block). So catching it at integration sign-off (with the checklist) is far cheaper than debugging it later. So this checklist exists to catch integration bugs early. So it's the economics. So check before integrating. So this checklist exists because: integration bugs are different (a correct block fails in the system — the root); the interconnect routing is subtle (the HREADY source and data-phase read-mux — the focus); and integration bugs are expensive (late, hard to localize — the economics). So the AHB integration checklist is the fabric-wiring sign-off — catching the connection bugs that unit test misses. So this chapter is the integration sign-off. So walk it when wiring AHB.

3. Mental Model

Model the integration checklist as wiring up a home theater from components you've already tested. Each component works on its own — the TV, the receiver, the speakers, the player all passed their own checks. But the system can still fail entirely from wiring: the speakers wired to the wrong channels (left and right swapped — like HREADY routed from the wrong slave), the video cable plugged into the wrong input so you select the wrong source (like a misaligned read-mux select picking the wrong slave's data), two devices assigned the same remote code so they conflict (like an address-map overlap), a cable left unplugged (a floating input), or the surround processor on a different power circuit that isn't switched on (an unclocked block). None of these are component faults — they're wiring faults, and you find them with an integration checklist: confirm every cable goes to the right place, every input is selected correctly, no addresses conflict, nothing is left floating. The integration checklist is the wiring check, not the component check.

A home theater you're wiring up from components you've already tested. Each component works on its own — the TV, receiver, speakers, player all passed their own checks (each block is designed and verified). But the system can still fail entirely from wiring: the speakers wired to the wrong channels (left/right swapped — like HREADY routed from the wrong slave); the video cable in the wrong input so you select the wrong source (like a misaligned read-mux select picking the wrong slave's data); two devices on the same remote code so they conflict (like an address-map overlap); a cable left unplugged (a floating input); the surround processor on a different power circuit that isn't switched on (an unclocked block). None of these are component faults — they're wiring faults, and you find them with an integration checklist: confirm every cable goes to the right place, every input is selected correctly, no addresses conflict, nothing is left floating. The integration checklist is the wiring check, not the component check.

This captures the checklist: the tested components = the designed/verified blocks; speakers wired to the wrong channels = HREADY routed from the wrong slave; the wrong input selected = a misaligned read-mux select; two devices on the same remote code = an address-map overlap; a cable left unplugged = a floating input; a block on an unswitched circuit = an unclocked/unreset block; confirming every cable/input/code = walking the integration checklist; wiring faults, not component faults = integration bugs, not design bugs. The components work; the integration checklist confirms they're wired together correctly — right cables, right inputs, no conflicts, nothing floating.

Here is the interconnect — where most integration checks land:

The model's lesson: the components work; the integration checklist confirms they're wired together correctly — right cables, right inputs, no conflicts, nothing floating. In the figure, the integration-critical check is the read-mux select: it must be registered (data-phase-aligned), not the live address-phase select — else the mux returns the wrong slave's data. That is a wiring bug a single block can't reveal — exactly what the integration checklist catches.

4. Real Hardware Perspective

The substance behind each check is the interconnect structure you've learned — so each checklist item maps to a chapter, and the check confirms that wiring.

The decode, HREADY routing, HRDATA muxing: the checks — (1) one-hot HSEL + default slave; (2) HREADY from the addressed slave; (3) the registered read-mux select. So the checklist confirms the interconnect routing structure (see Address Decoding, HSEL, HRDATA Muxing, Default Slave, What HREADY Means). So they're the routing checks. So confirm decode, HREADY, read-mux.

The arbitration, reset/clock, tie-offs, topology: the checks — (4) arbiter (multi-master); (5) reset/clock to every block + CDC; (6) no floating inputs; (7) topology fits the bandwidth. So the checklist confirms the arbitration, clock/reset, and topology structure (see Why Arbitration, Bus Ownership Handover, CDC Bridges, Shared Bus vs Interconnect, Bus Matrix Concept, Microcontroller Bus Fabric). So in practice, the integration checklist is the interconnect/fabric structure turned into checks — confirm each before integrating. So in practice, know the fabric structure and check the wiring. So that's the sign-off.

5. System Architecture Perspective

At the integration level, the checklist is the fabric quality gate — it catches the connection bugs that unit verification misses, standardizes the wiring sign-off, and focuses attention on the routing (where integration bugs concentrate).

The catches what unit verification misses: unit verification confirms each block; it can't catch a wiring bug (a HREADY from the wrong slave). So the integration checklist catches the connection bugs — the gap between unit and system. So at the integration level, the checklist fills that gap. So check the connections. So it's the gap-filler.

The focuses on the routing: integration bugs concentrate in the interconnect routing (decode, read-mux, HREADY). So the checklist focuses attention there — the highest-yield checks. So at the integration level, the checklist directs effort to the routing. So focus on routing. So it's the high-yield focus. So at the integration level, the checklist is the fabric quality gate (catches connection bugs unit verification misses) and focuses on the routing (where integration bugs concentrate). So the integration checklist is where the system's wiring is verified — making the routing checks (HREADY source, data-phase read-mux, address map) the keys to a correctly-wired fabric. So walk it, focus on the routing. So the checklist is the fabric gate.

6. Engineering Tradeoffs

Using the integration checklist embodies the wiring-not-blocks, routing-focus, catch-late-bugs-early discipline.

• Integration checks vs trusting unit tests. Unit tests confirm blocks; integration checks confirm connections. A correct block can be wired wrong. Check the wiring.
• Routing focus vs uniform attention. Most integration bugs are in the routing (HREADY, read-mux, decode); focus there. Don't spread attention thin.
• Data-phase alignment vs address-phase. The read-mux select must be data-phase-aligned (registered); the live address-phase select returns the wrong slave's data. Confirm the alignment.
• Default slave vs unmapped hang. A default slave makes unmapped accesses error cleanly; without it, a stray access hangs the bus. Confirm the default slave.

The throughline: the AHB integration checklist turns fabric wiring into a concrete sign-off — seven categories: (1) address map + decoder (one-hot HSEL, default slave), (2) HREADY routing (addressed slave's HREADYOUT), (3) HRDATA muxing (registered/data-phase select), (4) arbitration (if multi-master), (5) reset/clock (every block, CDC), (6) tie-offs (no floating inputs), (7) topology (shared bus vs matrix, bridges). Most bugs are in the routing. At the integration level, it's the fabric quality gate that catches connection bugs unit verification misses.

7. Industry Example

A concrete walk — integrating an AHB slave into an MCU fabric.

An engineer adds a new AHB peripheral-controller slave to an existing MCU fabric and walks the integration checklist.

• (1) Address map + decoder. They assign the new slave a region that doesn't overlap any existing slave, confirm the decoder produces a one-hot HSEL (the new region selects only the new slave), and verify the default slave still covers the gaps. ✓
• (2) HREADY routing. They confirm the interconnect routes the shared HREADY from whichever slave is addressed — including the new one's HREADYOUT when it's selected. ✓
• (3) HRDATA muxing. They check the read-data mux includes the new slave's HRDATA and selects it with the registered (data-phase) select, so a read of the new slave returns its data a cycle later. ✓ (The subtle routing check.)
• (4) Arbitration. The fabric is multi-master (CPU + DMA); the new slave doesn't change arbitration (it's a slave), and the arbiter is unaffected. ✓
• (5) Reset + clock. They confirm the new slave gets the clock and a synchronized reset, and comes out of reset idle. ✓
• (6) Tie-offs. Any unused signals on the new slave's interface are tied off; no inputs float. ✓
• (7) Topology. The new slave is low-bandwidth, so it sits behind the existing bridge on APB (not on the fast AHB) — matching the topology. ✓
• The result. Walking the checklist caught one issue — the read-mux for the new slave was initially wired with the address-phase select, which would have returned the wrong data; they fixed it to use the registered select. The checklist did its job: catching a routing bug that unit test of the slave couldn't reveal.

The example shows the checklist in use: a thorough walk of the wiring that caught a routing bug invisible to unit test. This is how you sign off AHB integration.

8. Common Mistakes

9. Interview Insight

The integration checklist shows system-level rigor — being able to list the fabric-wiring checks signals you understand integration, not just blocks.

If asked what you'd check when integrating AHB into a fabric, recite the checklist: (1) the address map + decoder (no overlaps/gaps, one-hot HSEL, a default slave), (2) HREADY routing (the addressed slave's HREADYOUT), (3) HRDATA muxing (a registered, data-phase-aligned select), (4) arbitration (if multi-master), (5) reset + clock (every block, CDC at bridges), (6) tie-offs (no floating inputs), (7) topology (shared bus vs matrix, bridges isolate slow peripherals). Stress that integration bugs are wiring bugs — concentrated in the interconnect routing (the HREADY source, the data-phase read-mux, the address map) — invisible to unit test. That signals system-level rigor: you understand that a correct block can be wired wrong, and you check the connections.

10. Practice Challenge

Practice the integration sign-off.

1. The seven categories. List them (address map/decoder, HREADY routing, HRDATA mux, arbitration, reset/clock, tie-offs, topology) and the check for each.
2. The read-mux. Explain why the read-mux select must be data-phase-aligned and what breaks if it's address-phase.
3. HREADY routing. Explain why HREADY must be the addressed slave's HREADYOUT.
4. The default slave. Explain why a fabric needs a default slave and what hangs without one.
5. Wiring vs blocks. Explain why integration bugs are wiring bugs invisible to unit test.

11. Key Takeaways

• The AHB integration checklist turns fabric wiring into a concrete sign-off — integration bugs are wiring bugs (connections), not design bugs (blocks).
• Seven categories — (1) address map + decoder, (2) HREADY routing, (3) HRDATA muxing, (4) arbitration, (5) reset/clock, (6) tie-offs, (7) topology.
• Most bugs are in the routing — the HREADY source (the addressed slave's HREADYOUT), the read-mux data-phase alignment (registered select), and the address map (one-hot, no gaps).
• The read-mux select must be data-phase-aligned — registered, not the live address-phase select. The live select returns the wrong slave's data (a silent integration bug).
• A default slave is mandatory — it makes unmapped accesses error cleanly; without it, a stray access hangs the bus.
• Integration bugs are invisible to unit test — they're in the connections; the integration checklist catches them. Focus on the routing.

12. What Comes Next

You can now sign off AHB integration. The remaining checklists cover review and revision:

• AHB Waveform Checklist (next) — what to verify on every AHB waveform you review.
• Interview and Common Mistakes checklists — the last-mile revision lists.

To revisit the fabric structure these checks confirm, see Address Decoding, HSEL, HRDATA Muxing, Default Slave, What HREADY Means, and Microcontroller Bus Fabric.