Skip to content
VLSI Mentor

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.

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
SYMPTOM  ->  BOUNDARY  ->  INVARIANT  ->  EVIDENCE  ->  ROOT CAUSE

The discipline the whole chapter rests on is a three-way separation people collapse constantly:

what it iswhat it is not
OBSERVATIONa number or a signal value, measuredan explanation
HYPOTHESISa mechanism that would produce ita conclusion
PROOFevidence that eliminates the alternativesa test that now passes

1. The Procedure

Twelve steps. The ones people skip are 5, 7 and 12.

#stepthe failure if skipped
1reproduceyou are debugging a different run
2classify the symptomcompletion, routing, timing, ownership, data, or testbench
3identify the transaction"it fails sometimes" is not a transaction
4state the expected invariantwithout it there is nothing to be violated
5bound the failing regionlast known-good, first known-bad
6list competing hypothesesnaming one is guessing with confidence
7choose discriminating evidenceevidence that cannot separate them is decoration
8find the first causal divergencenot the last visible failure
9prove the mechanism occurredplausible is not proven
10fix the causenot the symptom
11rerun the original failureit must have failed before
12regressand the regression must have failed before too
The debug evidence ladder, drawn from cheapest at the top to most expensive at the bottom, with the cost of reading each tier. A test failure is one line. The identity of the detector that fired is one line. A transaction log is one line per transfer. An event census at each boundary is one table. Boundary probes are tens of rows. A reduced waveform is tens of signals. Reading the RTL is hours. An arrow marked stop as soon as the hypotheses separate points at the census tier, because that is where almost every case in this curriculum was settled.test failedone linewhich detectorone linetransaction logone line per transferboundary censusone tableboundary probestens of rowsreduced waveformtens of signalsRTL inspectionhoursSTOP HEREas soon as thehypotheses separate12

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:

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
=== 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 2

One field, and it does work in both directions:

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
  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.
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
  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:

fieldSIM K rig 1SIM I
final symptom1 scoreboard data mismatchM0 retired 0 of 4 operations
first divergencedelivered mask f where 2 was askedresponse destination ≠ owner
first bad boundaryfabric request pathreturn-path destination steering
root causepartial write widened to the whole wordtermination steered to the non-owner
fixhonour SEL on the way downroute by latched owner
regressionclean, and failed before the fixclean, and failed before

And the ordering rule, checked rather than asserted:

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
root-cause event  ≤  first divergence  ≤  final symptom

A 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:

  1. a mechanism that explains the symptom;
  2. evidence that the mechanism actually occurred;
  3. a first divergence consistent with it;
  4. a correction that removes the divergence;
  5. the original failing test passing;
  6. 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:

fieldwithout it
which target was selected, per transferrouting defects are invisible from the interface
which master owns the bus, per clockprovenance is unprovable
commit events, countedduplicate side effects cannot be seen
unknown-value counters on every observeran 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

idreview questionclassification
DBG-01Are target, owner, commit and unknown counts observable on a port?REVIEW HYGIENE
DBG-02Is the failing run reproducible, bit for bit?VERIFICATION QUALITY
DBG-03Is the test itself deterministic — no unseeded randomness?VERIFICATION QUALITY
DBG-04Was the cheapest discriminating evidence used first?REVIEW HYGIENE
DBG-05Has the symptom been classified into one of the six kinds?REVIEW HYGIENE
DBG-06Have last known-good and first known-bad boundaries been identified?REVIEW HYGIENE
DBG-07Would the observation differ under the competing hypothesis?REVIEW HYGIENE
DBG-08Does the root-cause event precede the first divergence?REVIEW HYGIENE
DBG-09Has "the checker is wrong" been eliminated rather than ignored?VERIFICATION QUALITY
DBG-10Are any unknown values involved in the failing comparison?VERIFICATION QUALITY
DBG-11Does the fix remove the mechanism, or the evidence?REVIEW HYGIENE
DBG-12Did the original failing test fail before the fix, and pass after?REVIEW HYGIENE
DBG-13Did the regression fail before the fix and pass after?REVIEW HYGIENE
DBG-14Is 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

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.