Debugging Final RTL Failures

The shortest useful debug loop is:

1. Reproduce the failure without changing anything.
2. Locate the first divergence, not the loudest later symptom.
3. Form one hypothesis that fits the timing and signal path.
4. Change one thing so the rerun can confirm or reject that hypothesis.
5. Rerun the failing case and the full regression.

Lesson 7.6 keeps your own passing Lesson 7.5 design read-only. It opens instead a small tiny_calc_debug_harness between the testbench and your system. The wrapper must pass every input through unchanged and return the system's outputs. Use the observed timing to choose which signal to compare across that boundary. Compare both sides at the same instant; a stored value also depends on the controls and data just before its sampling edge.

Timing narrows a hypothesis; it does not prove a cause. In particular, combinational logic can be active before an FSM accepts a request. Confirm the suspected cause in the RTL and with a rerun.

A strong bug note is short but causal:

For a different design, a countdown might start at 5 rather than its specified reset value of 6. Its next values, 4 and 3, fit decrementing from the wrong starting value. A useful note would connect that first observation to a reset-value hypothesis, name the confirmed reset assignment, and report both the reset rerun and later decrement checks. It would not claim that those cases test every sequence.

Two habits generalize past this lesson. Read the earliest failing line, not the loudest one — later symptoms are usually consequences. And change exactly one thing, so the rerun is an experiment with a single variable rather than a guess. Do not turn a small planted defect into a rewrite: the value of the exercise is the reasoning chain from observable evidence to a bounded repair.