Wishbone · Module 30
Debug Checklist
A twelve-step procedure that ends in a proven mechanism, the evidence ladder that keeps you off the waveform, and three fixes that are not fixes.
Debugging without a procedure is browsing. Module 27 built the method; this chapter is the reviewable form of it.
SYMPTOM -> BOUNDARY -> INVARIANT -> EVIDENCE -> ROOT CAUSEThe discipline the whole chapter rests on is a three-way separation people collapse constantly:
| what it is | what it is not | |
|---|---|---|
| OBSERVATION | a number or a signal value, measured | an explanation |
| HYPOTHESIS | a mechanism that would produce it | a conclusion |
| PROOF | evidence that eliminates the alternatives | a test that now passes |
1. The Procedure
Twelve steps. The ones people skip are 5, 7 and 12.
| # | step | the failure if skipped |
|---|---|---|
| 1 | reproduce | you are debugging a different run |
| 2 | classify the symptom | completion, routing, timing, ownership, data, or testbench |
| 3 | identify the transaction | "it fails sometimes" is not a transaction |
| 4 | state the expected invariant | without it there is nothing to be violated |
| 5 | bound the failing region | last known-good, first known-bad |
| 6 | list competing hypotheses | naming one is guessing with confidence |
| 7 | choose discriminating evidence | evidence that cannot separate them is decoration |
| 8 | find the first causal divergence | not the last visible failure |
| 9 | prove the mechanism occurred | plausible is not proven |
| 10 | fix the cause | not the symptom |
| 11 | rerun the original failure | it must have failed before |
| 12 | regress | and the regression must have failed before too |
DBG-04. Was the cheapest evidence that could discriminate actually used?
Two cases from this module where a counter beat a waveform outright.
The duplicate commit. Three rigs, identical termination counts, identical stored values in two of them. A waveform of any one rig looks perfect. One counter separates them: commits 2 / 2 / 8.
The misrouted response. Every port protocol-shaped, every handshake legal, a full waveform dump entirely unremarkable. One field separates it: the owner at phase start, recorded beside the recipient — 133 misdeliveries, first at cycle 6.
In both, the waveform contains the answer and does not contain a way to find it.
2. Discriminating Evidence
DBG-07. Would this observation have come out differently under the other hypothesis?
If not, it is not evidence — it is confirmation. Worked, from an ambiguous symptom:
=== SIM K - DEBUG REVIEW ===
SYMPTOM
scoreboard reports 1 data mismatch on a partial write;
protocol violations 0; assertions 0; unknowns 0.
HYPOTHESES
H1 the slave merged the lanes wrongly
H2 the fabric delivered the wrong byte mask
H3 the monitor recorded the wrong value
H4 the reference model expected the wrong value
DISCRIMINATING OBSERVATION - the delivered mask
rig 1: asked 2, delivered f
rig 2: asked 2, delivered 2One field, and it does work in both directions:
ELIMINATION
rig 1 delivered mask differs from the mask asked for,
so H2 survives and H1 is not yet needed.
rig 2 delivered mask is correct, so H1 and H2 are both
rejected and the divergence is downstream of the
design entirely. ROOT CAUSE
rig 1 a DESIGN defect: the partial write was widened.
rig 2 a TESTBENCH defect: the reference model ignores
the byte selects. The design was correct.Two identical symptoms. Same count, same kind, same transfer. One is the design and one is the testbench, and the only thing that separates them is a field no protocol checker computes.
DBG-09. Has the possibility that the checker is wrong been eliminated, or merely not considered?
Rig 2 is the case people do not look for. A scoreboard mismatch is a statement that two things disagree; the instinct to indict the design first is a bias, and in this module's evidence it is wrong about a third of the time.
3. First Divergence, And Causal Ordering
DBG-08. Is the claimed root cause earlier than the symptom it explains?
Every worked debug review records six fields:
| field | SIM K rig 1 | SIM I |
|---|---|---|
| final symptom | 1 scoreboard data mismatch | M0 retired 0 of 4 operations |
| first divergence | delivered mask f where 2 was asked | response destination ≠ owner |
| first bad boundary | fabric request path | return-path destination steering |
| root cause | partial write widened to the whole word | termination steered to the non-owner |
| fix | honour SEL on the way down | route by latched owner |
| regression | clean, and failed before the fix | clean, and failed before |
And the ordering rule, checked rather than asserted:
root-cause event ≤ first divergence ≤ final symptomA claimed cause that happens after its symptom is a coincidence with a story attached. Sort divergences by first occurrence, never by count — the boundary with the largest count is usually the furthest downstream, and therefore the least likely to be the cause.
4. Two Fixes That Are Not Fixes
DBG-11. Does the fix remove the mechanism, or the evidence of it?
Raising the timeout. Symptom: transfers do not return. Chapter 27.1 measured what doubling the patience buys when a return path drops acknowledgements — twice the wait and the same one completion, while the slave answered on every one of those clocks. A timeout is a policy for surviving a missing response. It repairs nothing.
Avoiding the failing address. Symptom: a readback is wrong. Change the test to stop reading that location and the suite goes green with the decoder exactly as broken as before. Chapter 27.6 ran that experiment: 4 operations retired, 0 mismatches, 0 violations, defect untouched.
A third, and the one this module adds: widening the tolerance on a scoreboard comparison because "the model is probably wrong". Sometimes it is — SIM K rig 2 — but that is a conclusion you reach by looking at the delivered mask, not by relaxing the check. Relaxing it destroys the evidence for both cases at once.
The six conditions a root-cause fix must meet, of which "the test passes now" is the fifth:
- a mechanism that explains the symptom;
- evidence that the mechanism actually occurred;
- a first divergence consistent with it;
- a correction that removes the divergence;
- the original failing test passing;
- a regression that failed before the fix and is clean after.
Condition 6 is the one that gets dropped. A regression that passed before proves nothing about the fix.
5. Debug Readiness
DBG-01. Can this system be debugged at all?
This is a design review item, not a debug one, and it is cheapest to fix before anybody needs it. Four fields, each free at design time and unrecoverable afterwards:
| field | without it |
|---|---|
| which target was selected, per transfer | routing defects are invisible from the interface |
| which master owns the bus, per clock | provenance is unprovable |
| commit events, counted | duplicate side effects cannot be seen |
| unknown-value counters on every observer | an X silently becomes a pass |
Chapter 27.4 found a checker that reported zero misdeliveries on a rig built to misdeliver every response, because it was watching the one boundary the defect removes the evidence from. Place the probe where the evidence still exists, and expose it on a port so a reviewer can ask for it.
6. False Confidence
"The waveform looks right." Proves: nothing that was looked at was obviously wrong. Does not prove: that what was wrong was on the screen. The misrouted-response rig is protocol-shaped on every port. Missing evidence: a census of something the waveform does not display — owner, target, commit count.
"The test passes now." Proves: the observable changed. Does not prove: that the mechanism was removed. Both non-fixes above produce passing tests. Missing evidence: conditions 1, 2, 3 and 6.
7. The Debug Checklist
| id | review question | classification |
|---|---|---|
| DBG-01 | Are target, owner, commit and unknown counts observable on a port? | REVIEW HYGIENE |
| DBG-02 | Is the failing run reproducible, bit for bit? | VERIFICATION QUALITY |
| DBG-03 | Is the test itself deterministic — no unseeded randomness? | VERIFICATION QUALITY |
| DBG-04 | Was the cheapest discriminating evidence used first? | REVIEW HYGIENE |
| DBG-05 | Has the symptom been classified into one of the six kinds? | REVIEW HYGIENE |
| DBG-06 | Have last known-good and first known-bad boundaries been identified? | REVIEW HYGIENE |
| DBG-07 | Would the observation differ under the competing hypothesis? | REVIEW HYGIENE |
| DBG-08 | Does the root-cause event precede the first divergence? | REVIEW HYGIENE |
| DBG-09 | Has "the checker is wrong" been eliminated rather than ignored? | VERIFICATION QUALITY |
| DBG-10 | Are any unknown values involved in the failing comparison? | VERIFICATION QUALITY |
| DBG-11 | Does the fix remove the mechanism, or the evidence? | REVIEW HYGIENE |
| DBG-12 | Did the original failing test fail before the fix, and pass after? | REVIEW HYGIENE |
| DBG-13 | Did the regression fail before the fix and pass after? | REVIEW HYGIENE |
| DBG-14 | Is there a prevention item — a check or probe that would catch it next time? | REVIEW HYGIENE |
8. What To Carry Forward
- Observation, hypothesis, proof. Collapsing any two is how a week goes missing.
- Climb the ladder from the top and stop where the hypotheses separate. Every case here settled at a census.
- Evidence that cannot come out the other way is confirmation.
- Sort by first occurrence, never by count.
- Check causal ordering mechanically. A cause later than its symptom is a story.
- A regression that passed before the fix proves nothing.
- Debug observability is a design-review item. Four fields, free before tape-in, unrecoverable after.
Chapter 30.6 turns the same discipline on the thing you say out loud.
Continue learning
Related tutorials
- Related topic
Missing ACK
A request is presented and nothing comes back. Ten mechanisms produce that symptom; a suppressed decode and a dropped return look identical at the master port and diverge at cycle 10 in different places.
- Related topic
Waveform Analysis
Not a viewer manual. Which signals prove or eliminate a hypothesis, why twelve experiments were settled without a waveform, and a blind debug worked end to end from symptom to regression.
- Related topic
Data Flow
One Wishbone access, followed through every block in both directions: what the master drives, where the address changes form, which signals are broadcast and which are decoded, and how read data and termination find their way back to exactly one requester.
- Related topic
DAT_O
Both masters and slaves have a DAT_O, and they mean opposite things. What each must drive, when it must be valid, and why a master may legally leave stale write data on the bus during a read.
Standards & specifications
- Governing standard
- Wishbone SoC Interconnection Architecture (OpenCores)(opens OpenCores in a new tab)
Defines the Wishbone signal set, the bus cycles built from it and the interface rules a portable IP core must follow. It deliberately leaves interconnect topology, address map and arbitration policy to the integrator, so those are system decisions rather than requirements of the specification.
This page also covers RTL structure, verification approach and debugging technique. Those are engineering practice built on the standard, not requirements the standard itself imposes.
Where this fits
Part of the Wishbone curriculum.
