Common Mistakes Checklist

This is the final chapter — the closing checklist for the whole AHB curriculum: the recurring mistakes to never make, across every phase. It collects the top mistakes from design, protocol understanding, bursts, arbitration, reading, integration, and verification into one list — so you can scan it and never repeat them. Design: never use the live HADDR in the data phase (use the registered address); never let HREADY hang. Protocol: never think address and data are in the same cycle (AHB is pipelined); ERROR is two cycles, not one. Burst/arbitration: a burst is not repeated singles; grant ≠ ownership (and no mid-burst handover). Reading: never pair data with the wrong (live) address; never read HRDATA during a wait state. Integration: never omit the default slave; never use an address-phase read-mux select. Verification: never have only assertions or only a scoreboard (need both); never claim done without coverage closure. And here's the capstone insight: almost every one of these traces back to one thing — not internalizing the pipeline (the address phase one cycle ahead of the data phase). The pipeline is the single root cause of most AHB mistakes — and the single cure. This chapter is the final sign-off, and the closing message of the curriculum.

1. What Is It?

This checklist collects the recurring AHB mistakes — scan it, never repeat them. The mistakes, by phase:

• Design — the live HADDR in the data phase (the #1 bug); a hung HREADY. (Use the registered address; ensure HREADY always eventually goes high.)
• Protocol + burst/arbitration — address+data same cycle (pipelined); ERROR one cycle (it's two); burst = singles (one address phase + pattern); grant = ownership (grant ahead, boundary handover).
• Reading — data with the wrong (live) address; HRDATA mid-wait. (Pair with the previous address; read at HREADY-high.)
• Integration + verification — no default slave (unmapped hangs); address-phase read-mux (use data-phase); only one check (need both assertions + scoreboard); no coverage closure.

So this final checklist is the negative space of the curriculum — not "what to do" but "what to never do", collected so you can guard against the recurring traps. The value is one place to scan the mistakes that actually recur — across all phases — before (or during) any AHB work. And the capstone realization is that they aren't really separate mistakes — most are the same mistake (not internalizing the pipeline) in different guises. So this chapter is the final sign-off and the closing message. So scan the mistakes — and internalize the pipeline.

2. Why Does It Exist?

This checklist exists because the same mistakes recur (across people and projects — worth collecting) — and because a negative checklist is powerful (knowing what to never do is as valuable as knowing what to do) — and because it reveals the root cause (collecting the mistakes exposes that most share one origin: the pipeline).

The the same mistakes recur is the root: across many engineers and many projects, the same AHB mistakes keep happening — the live-HADDR bug, the one-cycle-ERROR error, the missing default slave. They're recurring and predictable. So collecting them is worthwhile — you can guard against known traps. So this checklist exists to collect the recurring mistakes. So they recur. So list them.

The a negative checklist is powerful is the value: knowing what to never do is as valuable as knowing what to do — sometimes more, because avoiding a known trap is concrete and actionable. So a negative checklist (the mistakes) is a powerful complement to the positive ones (design, verification, etc.). So this checklist exists because the negative framing helps. So it's the negative space. So know what to avoid.

The it reveals the root cause is the capstone: collecting the mistakes exposes a pattern — most trace to one origin (the pipeline). So the checklist reveals the root cause, which is the single most valuable takeaway (fix the root, prevent the family). So this checklist exists to reveal the root. So it's the synthesis. So internalize the pipeline. So this checklist exists because: the same mistakes recur (predictable traps — the root); a negative checklist is powerful (knowing what to avoid — the value); and it reveals the root cause (most trace to the pipeline — the capstone). So the AHB common-mistakes checklist is the final sign-off — collecting the recurring mistakes and revealing their shared root (the pipeline). So this chapter closes the curriculum. So scan the mistakes, and internalize the pipeline.

3. Mental Model

Model this checklist as the "lessons learned" wall in a workshop — the list of mistakes someone already made so you don't have to. Every experienced shop has one: "always check the blade guard," "never reach over a running saw," "measure twice." Each line is a scar — a past mistake distilled into a rule. A newcomer who reads the wall inherits years of hard-won caution for free. And a good wall doesn't just list incidents — it reveals the patterns: most accidents trace to a few root causes (rushing, not securing the work, bypassing a guard), so fixing those roots prevents whole categories. The AHB common-mistakes checklist is that wall: the recurring mistakes distilled into rules, so you inherit the caution for free — and the pattern it reveals is that most AHB mistakes trace to one root, the pipeline, so internalizing that one thing prevents whole categories of error.

A workshop with a "lessons learned" wall — the list of mistakes someone already made so you don't have to. Every experienced shop has one: "always check the blade guard," "never reach over a running saw," "measure twice." Each line is a scar — a past mistake distilled into a rule. A newcomer who reads the wall inherits years of hard-won caution for free. And a good wall doesn't just list incidents — it reveals the patterns: most accidents trace to a few root causes (rushing, not securing the work, bypassing a guard), so fixing those roots prevents whole categories. The AHB common-mistakes checklist is that wall: the recurring mistakes distilled into rules, so you inherit the caution for free — and the pattern it reveals is that most AHB mistakes trace to one root, the pipeline, so internalizing that one thing prevents whole categories of error.

This captures the checklist: the lessons-learned wall = the common-mistakes checklist; each line a scar / a past mistake as a rule = each recurring mistake as a rule to never repeat; the newcomer inheriting caution for free = you guarding against known traps without making them yourself; the wall revealing patterns / a few root causes = the checklist revealing that most mistakes trace to the pipeline; fixing the roots prevents whole categories = internalizing the pipeline preventing whole families of error. Read the wall (scan the mistakes), inherit the caution — and fix the root (the pipeline) to prevent whole categories.

Here is the root cause and cure — the pipeline — one last time:

The model's lesson: read the wall (scan the mistakes), inherit the caution — and fix the root (the pipeline) to prevent whole categories. In the figure, the root cause and cure is the same one fact — the pipeline. Internalize it, and the live-HADDR bug, the waveform mispairing, the one-cycle-ERROR error, and grant-vs-ownership confusion all become impossible. That's the closing message of the entire curriculum.

4. Real Hardware Perspective

The substance behind each mistake is a protocol rule you've learned — so each mistake maps to the chapter (and checklist) that prevents it.

The the pipeline-rooted mistakes: the mistakes — the live HADDR, same-cycle address/data, one-cycle ERROR, waveform mispairing, address-phase read-mux, grant-vs-ownership — all trace to the pipeline. So the cure is the pipeline (see Pipelined Operation, Address/Control Capture, Two-Cycle ERROR Response, HRDATA Muxing, Bus Ownership Handover). So they're the pipeline family. So internalize the pipeline.

The the non-pipeline mistakes: a few mistakes have other roots — a hung HREADY (liveness), a burst = singles (burst structure), a missing default slave (address-map completeness), only one verification check (legality/correctness split), no coverage closure (the definition of done). So the cure for those is the relevant rule/checklist (see What HREADY Means, Single vs Burst Transfer, Default Slave, and the Design, Verification, Integration, and Waveform checklists). So in practice, most mistakes are cured by the pipeline, and the rest by the specific rules/checklists. So in practice, internalize the pipeline and use the checklists. So that's the final sign-off.

5. System Architecture Perspective

At the curriculum level, this checklist is the synthesis — it unifies the whole curriculum (every mistake maps to a rule you learned), reveals the central insight (the pipeline as the root), and leaves you with one thing to remember (internalize the pipeline).

The it unifies the curriculum: every mistake on the list maps to a rule (and chapter) you learned — the pipeline, HREADY, bursts, responses, arbitration, integration, verification. So this checklist unifies the whole curriculum into one view (the mistakes and their cures). So at the curriculum level, it's the synthesis. So it ties it together. So it's the unifier.

The one thing to remember: the central insight — most mistakes trace to the pipeline — leaves you with one thing to remember above all: internalize the pipeline. So this checklist distills the entire curriculum to its essence. So at the curriculum level, the takeaway is singular and memorable. So remember the pipeline. So it's the essence. So at the curriculum level, this checklist is the synthesis (unifying the whole curriculum into the mistakes and their cures) and leaves you with one thing to remember (internalize the pipeline). So this final chapter is where the entire AHB curriculum distills to its essence — making the pipeline the one thing that, internalized, prevents most mistakes and signals mastery. So internalize the pipeline. So the curriculum closes on its central insight.

6. Engineering Tradeoffs

This closing checklist embodies the avoid-the-recurring, fix-the-root, internalize-the-pipeline discipline.

• Negative checklist vs positive only. Knowing what to never do (the mistakes) complements knowing what to do (the design/verification checklists). Use both.
• Fix the root vs patch each mistake. Internalizing the pipeline (the root) prevents a family of mistakes; patching each one is fragile. Fix the root.
• Scan before/during work vs trust memory. Scanning the recurring mistakes before (or during) AHB work guards against them; trusting memory lets them recur. Scan it.
• One central insight vs scattered rules. The pipeline (one insight) is more memorable and more powerful than scattered rules. Hold the central insight.

The throughline: the AHB common-mistakes checklist collects the recurring mistakes — design (live HADDR, hung HREADY), protocol (same-cycle, one-cycle ERROR), burst/arbitration (singles, grant=ownership), reading (wrong-address, mid-wait), integration (no default slave, address-phase read-mux), verification (one check, no coverage) — and reveals that most trace to not internalizing the pipeline. The root cause and cure is the pipeline. At the curriculum level, it's the synthesis — unifying everything and leaving you with one thing to remember: internalize the pipeline.

7. Industry Example

A concrete picture — how the recurring mistakes show up, and how the pipeline prevents them.

Across real projects, the same AHB mistakes recur — and an engineer who's internalized the pipeline avoids most of them automatically.

• A new slave corrupts data. A junior engineer's AHB slave writes data to the wrong address — the live-HADDR bug. An engineer who's internalized the pipeline never writes this code: they automatically register the address phase, because they know the data comes a cycle later.
• A waveform is misread. During debug, someone reports a read returning the wrong value — they paired the data with the live HADDR. The pipeline-internalized engineer automatically pairs data with the previous address, so they read the waveform correctly.
• An ERROR is missed. A test passes that should have failed, because the reviewer thought ERROR was one cycle and missed the two-cycle pattern. The pipeline-internalized engineer knows ERROR is two cycles (the next transfer is already issued), so they catch it.
• A bus hangs. Integration testing hangs on a stray access — no default slave. This one isn't pipeline-rooted; it's caught by the integration checklist (always have a default slave).
• Verification ships a bug. A design ships data-corrupt because the testbench had only assertions, no scoreboard. This is caught by the verification checklist (need both checks).
• The pattern. Most of the recurring mistakes — the live HADDR, the misread waveform, the missed two-cycle ERROR — are the same mistake (the pipeline) in different guises. The engineer who internalized the pipeline avoids the whole family. The few that aren't pipeline-rooted are caught by the specific checklists.

The example shows the recurring mistakes in the wild — and that internalizing the pipeline prevents most of them automatically, while the checklists catch the rest. This is the practical payoff of the whole curriculum.

8. Common Mistakes

9. Interview Insight

This checklist is the synthesis — naming the recurring mistakes and the pipeline as their root signals you've mastered AHB, not just learned it.

If asked what the most common AHB mistakes are, name them by phase — design (live HADDR, hung HREADY), protocol (same-cycle, one-cycle ERROR), burst/arbitration (singles, grant=ownership), reading (wrong-address, mid-wait), integration (no default slave, address-phase read-mux), verification (one check, no coverage) — and then deliver the capstone insight: almost all of them trace back to not internalizing the pipeline (the address phase one cycle ahead of the data phase), which is the single root cause and the single cure. Being able to name the recurring mistakes and reveal their shared root signals mastery — you don't just know the rules, you understand why the mistakes happen and how one insight prevents most of them. That's the closing signal of the entire AHB curriculum: internalize the pipeline.

10. Practice Challenge

Practice the final sign-off.

1. The recurring mistakes. List them by phase (design, protocol, burst/arbitration, reading, integration, verification) and the rule for each.
2. The root cause. Explain which mistakes trace to the pipeline, and why they're the same mistake in different guises.
3. The cure. Explain how internalizing the pipeline prevents the pipeline-rooted mistakes (changes your instinct).
4. The non-pipeline mistakes. Identify the ones not explained by the pipeline (hung HREADY, missing default slave, etc.) and their specific cures.
5. The closing message. State the one thing to internalize from the whole curriculum (the pipeline) and why.

11. Key Takeaways

• The AHB common-mistakes checklist collects the recurring mistakes — across design, protocol, burst/arbitration, reading, integration, and verification — scan it, never repeat them.
• The recurring mistakes — live HADDR, hung HREADY; same-cycle address/data, one-cycle ERROR; burst=singles, grant=ownership; wrong-address pairing, mid-wait data; no default slave, address-phase read-mux; one verification check, no coverage closure.
• Almost all trace to the pipeline — the live-HADDR bug, same-cycle misconception, one-cycle-ERROR, waveform mispairing, read-mux misalignment, and grant-vs-ownership are the same mistake (the one-cycle offset) in different guises.
• The single cure is internalizing the pipeline — once the address phase one cycle ahead of the data phase is second nature, the pipeline-rooted mistakes become impossible (your instinct is correct).
• The non-pipeline mistakes — hung HREADY (liveness), burst=singles (structure), missing default slave (map completeness), one check (legality/correctness), no coverage closure (definition of done) — are cured by the specific rules/checklists.
• The closing message — internalize the pipeline. It's the root cause of most AHB mistakes, the single cure, the throughline of the whole curriculum, and the strongest signal of mastery.

12. What Comes Next

This completes the AHB curriculum — from the fundamentals through slave design, verification, debugging, interview mastery, industry case studies, and these final sign-off checklists. You've learned what AHB is, how to build it, verify it, debug it, integrate it, read it, and talk about it — and, throughout, the one fact that anchors it all: AHB is pipelined — the address phase is one cycle ahead of the data phase. Internalize that, and AHB makes sense, the mistakes become impossible, and you'll signal the mastery the whole curriculum built.

To revisit the foundation one final time, see Pipelined Operation. And to put the checklists to use, return to the Design, Verification, Integration, Waveform, and Interview checklists whenever you do AHB work.