Part 4 answers: How do I reason my way to the cause instead of trying things?
Once the search space is small, debugging becomes science: a hypothesis that predicts something you have not seen yet, an experiment that splits the suspects, and the discipline to change one thing at a time and write down what each result ruled out.
Write a hypothesis that makes a testable prediction.
Design the one experiment that splits several suspects.
Keep a debug log that someone else could pick up.
6 lessons, about 60 min
The part on one page, taken from each lesson's Remember box.
A Hypothesis Must Predict
A hypothesis names a mechanism: which signal, which value, which path. "The DMA is flaky" names a place, not a mechanism.
Write the prediction before the run: a cycle, a seed, a value or a count you have not seen yet. Predicting what you already saw tests nothing.
Ask of every hypothesis: what result would kill it? If no result would, it is not a hypothesis yet.
Rule of thumb: no experiment without a written prediction that could have come out wrong.
The Experiment That Splits Suspects
Fill in the table first: one row per suspect, one column per candidate run, the predicted result in each cell. A column with one value everywhere is worth nothing.
Split the probability, not the count. If two suspects are far likelier, the run that separates those two often beats a 2:2 split.
Suspects may both be true. A result that convicts one does not acquit the other.
Rule of thumb: fill in the suspects-by-outcomes table before you run anything, then run the column that splits it best per minute.
Keeping Several Hypotheses Alive
The same message is not the same cause. Symptoms are many-to-one: two mechanisms can end in the same scoreboard line.
Score evidence by what it separates. A clue both hypotheses predict proves nothing; look for one that one predicts and the other forbids.
A fix that clears some failures confirms one hypothesis for those failures only. Predict exactly which ones should remain before you rerun.
Rule of thumb: never file a failure under an explanation until you have checked a feature that the explanation predicts and its rival does not.
Confirmation Bias and Blaming the Tool
Ask what you would see if you were wrong, then go and look for exactly that. Results that fit your idea are cheap; one that could break it is worth ten.
Two simulators that disagree are usually both right: a four-state one shows the X, a two-state one picks a value. Random start values show which the chip resembles.
Call it a tool bug only with a program of a few lines, the rule it breaks, and the output of two tools and their versions.
Rule of thumb: before you blame the tool, shrink the design until the difference fits on one screen and name the rule the tool breaks.
One Change at a Time
One change per run, against the same baseline command. A seed, a simulator, a test length or a bench edit is a change too.
A new failure message after a change means the change altered what the test measures. Find out why before you relax a check.
Two changes need four runs: neither, each alone, both. It costs minutes and tells you what each one did.
Rule of thumb: if a run changed two things, it answered no question: split it before you believe it.
The Debug Log
One line per event, written as it happens: time, kind (hypothesis, prediction, run, ruled out, note), and the words.
Log the exact command and its result line, not just pass or fail. Log what each result ruled out: that is the part memory loses first.
End every session with where you are: open hypotheses, the next experiment, the state of the tree.
Rule of thumb: if a result is not in the log, the next person will run it again.
Practice question: Reset strategies in RTL
Code lab: DFF with asynchronous reset
Practice question: Counter with wrap and saturate modes
Practice question: FSM incomplete case and simulation vs synthesis mismatches
Code lab: Round-robin arbiter
Interview: run a mock interview on this topic