Part 13 answers: How do we find the cause fast?
Most verification time goes to debug: deciding why a test failed, whether the design or the testbench is wrong, and which change caused it. Fast debug is a method, not a talent: observe, form a hypothesis, test it, narrow down.
This part covers the debug loop, reproducing failures, following the wait on a waveform, bisection and delta debugging, triaging thousands of failures by signature, and telling testbench bugs from design bugs.
Debug a failing test with a repeatable method.
Shrink a failing case and find the change that caused it.
Triage a large regression failure by signature.
Answer each in your head before opening it. If two or more feel shaky, revisit Part 12: Bug Economics first.
Either the design is maturing or the current techniques have stopped finding bugs; check which before trusting it.
When the cost per bug found with the current one rises steeply while coverage or risk says bugs likely remain.
Growth-model fits to the discovery curve, or capture-recapture between independent methods.
# | Lesson | Level | Status |
|---|---|---|---|
13.1 | W · Working | Ready | |
13.2 | W · Working | Ready | |
13.3 | W · Working | Ready | |
13.4 | S · Senior | Ready | |
13.5 | S · Senior | Ready | |
13.6 | S · Senior | Ready | |
— | all levels | Ready |
Every lesson in this part is ready. Work through them in order: each one sets up the problem the next one solves.
This course teaches the decisions behind verification. These lessons teach the tools and syntax that carry them out, so this part links to them instead of repeating them.