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.

In the Tiny Calculator Engine, a load failure occurs before start asks the controller to do useful work. That timing makes the ALU and operation decode weak first suspects — neither has run yet when the first mismatch appears.

Lesson 7.6 keeps your own passing Lesson 7.5 design read-only. It opens instead a small tiny_calc_debug_harness that sits between the testbench and your system, and the fault lives on that harness boundary. So the question is not "what is wrong inside my design?" but "does my design receive what the testbench sent?" Compare load_en at the harness input against the value actually forwarded into the learner_design instance.

A strong bug note is short but causal:

The first load stored zero, before the controller had started. The harness was forwarding a constant instead of the incoming load request, so the register file never saw a write enable. Forwarding the real load_en made all five checks pass, so the rerun covers both the original failure and the operations that already worked.

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 one-line wiring bug into a rewrite: the value of the exercise is the reasoning chain from observable evidence to a bounded repair.