AHB Design Checklist

The final module distills everything into sign-off checklists — what to verify before you call something done. This first one is the AHB Design Checklist: the list to walk before submitting an AHB RTL block for review. It turns the protocol rules into a concrete pass/fail sign-off, organized into seven categories: (1) the pipeline capture — register the address-phase control, use the registered copy in the data phase, never the live HADDR (the #1 item); (2) HREADY/wait states — drive HREADYOUT correctly, insert waits when not ready, and always eventually drive it high (no hang); (3) HRESP/errors — the two-cycle ERROR response, only on real faults; (4) decode/HSEL — respond only when selected with a real HTRANS; a default slave covers unmapped addresses; (5) reset — all state to a safe value, comes up idle; (6) bursts — NONSEQ/SEQ and the address pattern; BUSY pauses without breaking the burst; (7) corner cases — back-to-back, alignment, no combinational loops/glitches on HREADY, lint/CDC clean. The single most important item is the pipeline capture — using the live HADDR in the data phase is the most common AHB RTL bug. This chapter walks each item with the check to perform.

1. What Is It?

This checklist is the sign-off list for an AHB RTL block — confirm each item before review. The seven categories:

• (1) Pipeline capture (the #1) — the block registers the address-phase control and uses the registered copy in the data phase, never the live HADDR.
• (2) HREADY/wait states — drives HREADYOUT correctly, can insert waits, and always eventually drives it high (no hang).
• (3) HRESP/errors + (4) decode/HSEL — the two-cycle ERROR (real faults only); responds only when selected (real HTRANS); a default slave for gaps.
• (5) reset + (6) bursts + (7) corner cases — safe reset (comes up idle); NONSEQ/SEQ + pattern (BUSY pauses); back-to-back, alignment, no HREADY glitch, lint/CDC.

So the design checklist is the protocol-to-sign-off translation — every rule you learned becomes a concrete check you perform on the RTL before review. The value of a checklist is completeness under pressure: when you're finishing a block, it's easy to forget a corner (the two-cycle ERROR, a reset value, a BUSY case); the checklist catches what memory misses. And it's ordered by importance: the pipeline capture is first because it's the most common and most damaging bug. So this chapter is the RTL sign-off. So walk the checklist before review.

2. Why Does It Exist?

This checklist exists because memory misses corners under pressure (a checklist ensures completeness) — and because the cost of a missed bug rises downstream (catching it at design sign-off is far cheaper than in integration or silicon) — and it encodes the protocol's hard-won lessons (the common bugs become explicit checks).

The memory misses corners is the root: when finishing an RTL block, you're focused on the main function — it's easy to forget a corner (the reset value of a register, the two-cycle ERROR, a BUSY case). A checklist externalizes the complete set of checks, so nothing relies on remembering. So this checklist exists to ensure completeness. So memory isn't enough. So use a list.

The the cost rises downstream is the economics: a bug caught at design sign-off (a review) is cheap to fix; the same bug caught in integration is costlier (it's buried in a system); in silicon it's catastrophic (a respin). So catching bugs early (at the checklist) saves enormously. So this checklist exists to catch bugs early. So it's the economics. So sign off before review.

The it encodes hard-won lessons is the wisdom: the checklist's items are the common bugs — the pipeline capture (the #1 bug), the hang (HREADY stuck), the missing two-cycle ERROR. So the checklist encodes the protocol's hard-won lessons as explicit checks. So this checklist exists to capture that wisdom. So it's the distilled experience. So check the known traps. So this checklist exists because: memory misses corners (a checklist ensures completeness — the root); the cost rises downstream (catch bugs early — the economics); and it encodes hard-won lessons (common bugs as explicit checks — the wisdom). So the AHB design checklist is the RTL sign-off — ensuring every protocol rule and common bug is checked before review. So this chapter is the design sign-off. So walk it every time.

3. Mental Model

Model the design checklist as a pilot's pre-flight checklist. A pilot doesn't trust memory to confirm the flaps, fuel, instruments, and controls before takeoff — they run a written checklist, item by item, every single flight, no matter how experienced. The checklist exists because the cost of a missed item (at altitude) is catastrophic, because even experts forget under routine, and because each item is there for a reason — some past incident made it a check. The most critical items come first. Running the AHB design checklist before review is the same discipline: you don't trust memory to confirm the pipeline capture, the HREADY behavior, the error response, and the reset — you run the list, item by item, every block, because a missed item costs far more downstream, and the capture (the most common crash) is item one.

A cockpit before takeoff where a pilot runs a pre-flight checklist. The pilot doesn't trust memory to confirm the flaps, fuel, instruments, controls — they run a written checklist, item by item, every single flight, no matter how experienced. The checklist exists because: the cost of a missed item (at altitude) is catastrophic (a missed bug in silicon is a respin); even experts forget under routine (memory misses corners); and each item is there for a reason — some past incident made it a check (each item is a hard-won lesson). The most critical items come first (the pipeline capture is item one). Running the AHB design checklist before review is the same discipline: you don't trust memory to confirm the pipeline capture, the HREADY behavior, the error response, and the reset — you run the list, item by item, every block, because a missed item costs far more downstream, and the capture (the most common crash) is item one.

This captures the checklist: the pilot not trusting memory = not relying on remembering the checks; running the written list every flight = walking the checklist every block; the catastrophic cost at altitude = the rising cost of a missed bug downstream; experts still forgetting under routine = even experienced designers missing corners; each item there for a reason = each check encoding a hard-won lesson; the most critical items first = the pipeline capture as item one. Run the list item by item every time — don't trust memory — because the cost of a miss rises downstream and the most damaging bug is item one.

Here is the #1 item — the pipeline capture — as the check to perform:

The model's lesson: run the list item by item every time — don't trust memory — because the cost of a miss rises downstream and the most damaging bug is item one. In the figure, the #1 check is concrete: confirm the data phase uses addr_q (registered), not the live HADDR. That one check catches the most common AHB RTL bug — exactly the kind of thing a checklist exists to never miss.

4. Real Hardware Perspective

The substance behind each check is the RTL structure from the design module — so each checklist item maps to a chapter, and the check confirms that structure.

The capture, HREADY, and HRESP: the checks — (1) the registered address used in the data phase; (2) HREADYOUT correct and eventually high; (3) the two-cycle ERROR. So the checklist confirms the capture, HREADY, and HRESP structure (see Address/Control Capture, HREADYOUT Generation, Two-Cycle ERROR Response). So they're the core checks. So confirm capture, HREADY, HRESP.

The decode, reset, bursts, corners: the checks — (4) respond only when selected, default slave; (5) safe reset, comes up idle; (6) bursts + BUSY; (7) back-to-back, alignment, no HREADY glitch, lint/CDC. So the checklist confirms the decode, reset, burst, and corner structure (see HSEL, HRDATA Muxing, Write FSM, Read FSM, HTRANS, HBURST). So in practice, the design checklist is the RTL structure turned into checks — confirm each before review. So in practice, know the structure and check it. So that's the sign-off.

5. System Architecture Perspective

At the design-process level, the checklist is a quality gate — it standardizes sign-off (every block checked the same way), catches bugs at the cheapest point (before review/integration), and encodes institutional knowledge (the team's hard-won lessons as reusable checks).

The a standardized quality gate: the checklist standardizes the sign-off — every block is checked the same way, regardless of who wrote it. So quality is consistent, not dependent on individual memory. So at the process level, the checklist is a quality gate. So standardize. So it's consistent.

The catches bugs at the cheapest point + encodes knowledge: the checklist catches bugs at design sign-off (the cheapest point) and encodes the team's hard-won lessons (the common bugs) as reusable checks — so new engineers benefit from past mistakes. So at the process level, the checklist saves cost and transfers knowledge. So catch early, encode wisdom. So it's the cheap gate. So at the design-process level, the checklist is a standardized quality gate (consistent sign-off), catches bugs at the cheapest point (before review), and encodes institutional knowledge (hard-won lessons as reusable checks). So the checklist is where quality is enforced cheaply and consistently — making walking it every block the key to catching bugs early and transferring the protocol's lessons. So walk it every time. So the checklist is the quality gate.

6. Engineering Tradeoffs

Using the design checklist embodies the completeness, early-catch, and capture-first discipline.

• Checklist vs memory. A checklist ensures completeness (nothing forgotten); memory misses corners under pressure. Use the list.
• Sign-off check vs downstream debug. Catching a bug at sign-off is cheap; the same bug in integration/silicon is costly. Check early.
• Capture-first vs feature-first. Confirming the pipeline capture first catches the most common/damaging bug; checking features first risks missing it. Capture is item one.
• Thorough vs perfunctory. A thorough walk (each item actually checked) catches bugs; a perfunctory tick-box misses them. Actually perform each check.

The throughline: the AHB design checklist turns the protocol rules into a concrete RTL sign-off — seven categories: (1) pipeline capture (registered address in the data phase — the #1), (2) HREADY/waits (eventually high), (3) HRESP (two-cycle ERROR), (4) decode/HSEL (respond only when selected; default slave), (5) reset (safe, idle), (6) bursts (NONSEQ/SEQ + pattern; BUSY pauses), (7) corner cases (back-to-back, alignment, no HREADY glitch, lint/CDC). The #1: the pipeline capture (live HADDR in the data phase is the most common bug). At the process level, it's a standardized quality gate that catches bugs early and encodes the team's lessons.

7. Industry Example

A concrete walk — signing off an AHB slave before review.

An engineer finishes an AHB-Lite slave and walks the checklist before submitting it for review.

• (1) Pipeline capture. They trace the data-phase write logic: it uses mem[addr_q], where addr_q is the registered address from the address phase — not the live HADDR. ✓ (The #1 check, passed.)
• (2) HREADY. They confirm HREADYOUT is high for zero-wait responses and goes low only for the bounded memory-latency wait, always returning high. No path hangs. ✓
• (3) HRESP. They check the out-of-range case: it drives HRESP=ERROR with HREADY low then high — the two-cycle sequence — and OKAY otherwise. ✓
• (4) Decode/HSEL. The slave responds only when HSEL is asserted with HTRANS NONSEQ/SEQ, and ignores IDLE/BUSY. The system has a default slave for unmapped addresses. ✓
• (5) Reset. Every register (addr_q, write_q, the state) resets to a benign value; the slave comes up idle with HREADYOUT high. ✓
• (6) Bursts. SEQ beats are handled identically via the capture; BUSY is handled (no real transfer, no wait). ✓
• (7) Corner cases. Back-to-back transfers stream correctly; HSIZE is consistent; HREADYOUT is registered/structured (no combinational glitch); lint and CDC are clean. ✓
• The result. Every item passes — the block is ready for review. The engineer caught one issue while walking it (a register that wasn't reset), fixed it, and re-checked. The checklist did its job: completeness, catching the miss before review.

The example shows the checklist in use: a thorough, ordered walk that confirms each protocol rule and catches a miss before review. This is how you sign off an AHB design.

8. Common Mistakes

9. Interview Insight

The design checklist shows engineering discipline — being able to list what you'd verify before an RTL review signals senior rigor.

If asked what you'd check before signing off an AHB RTL block, recite the checklist: (1) the pipeline capture (registered address used in the data phase — the #1), (2) HREADY (correct, can wait, always eventually high — no hang), (3) HRESP (the two-cycle ERROR on real faults), (4) decode/HSEL (respond only when selected; a default slave for gaps), (5) reset (safe, comes up idle), (6) bursts (NONSEQ/SEQ + pattern; BUSY pauses), (7) corner cases (back-to-back, alignment, no HREADY glitch, lint/CDC). Stress that the pipeline capture is item one (the most common bug). Having a structured, ordered, complete checklist — and knowing why each item matters — signals engineering discipline and senior rigor: you don't hope the block is correct, you verify it systematically.

10. Practice Challenge

Practice the design sign-off.

1. The seven categories. List them in order (capture, HREADY, HRESP, decode, reset, bursts, corners) and the check for each.
2. The capture. Explain how to check the pipeline capture (data phase uses registered signals, not live HADDR) and why it's item one.
3. No hang. Explain how to confirm HREADY can't hang (every wait path terminates; a timeout backstop).
4. The two-cycle ERROR. State the check for the ERROR response (two cycles, real faults only).
5. Reset + corners. List the reset check and the corner-case checks (back-to-back, alignment, no HREADY glitch, lint/CDC).

11. Key Takeaways

• The AHB design checklist turns the protocol rules into a concrete RTL sign-off — confirm each item before review.
• Seven categories — (1) pipeline capture (the #1), (2) HREADY/waits, (3) HRESP/errors, (4) decode/HSEL, (5) reset, (6) bursts, (7) corner cases.
• The #1 item is the pipeline capture — confirm the data phase uses the registered address (addr_q), not the live HADDR. This is the most common and most damaging (silent corruption) bug.
• HREADY must never hang — confirm every wait-state path terminates (with a timeout backstop for downstream dependencies). A hung HREADY locks the bus.
• Perform each check thoroughly — trace the logic, don't tick boxes. A perfunctory walk misses the bug it's meant to catch.
• It's a quality gate — standardizes sign-off, catches bugs at the cheapest point (before review), and encodes the team's hard-won lessons. Walk it every block.

12. What Comes Next

You can now sign off an AHB design. The remaining checklists cover the other phases:

• AHB Verification Checklist (next) — the sign-off list for AHB protocol/functional verification.
• Integration, Waveform, Interview, and Common Mistakes checklists — the rest of the sign-off lists.

To revisit the RTL structure these checks confirm, see Address/Control Capture, HREADYOUT Generation, Two-Cycle ERROR Response, HSEL, and AHB Design Questions.