Part 1 answers: What can go wrong?
You cannot look for bugs you cannot imagine. Bugs fall into recognisable classes: corner cases at boundaries, races between events in the same cycle, blocks that pass alone and fail together, configurations nobody tried, designs that are correct but too slow, and specifications that were wrong to begin with.
Each class hides in a different place and is found by a different technique. This part builds the taxonomy the rest of the course uses, then sorts DCRouter's 24 planted bugs into it, with a prediction you will test in every later part: which technique will catch which bug.
Classify a bug by kind and predict where it hides.
Explain why integration, configuration and performance bugs escape block-level tests.
Predict which verification technique is most likely to find a given class of bug.
Answer each in your head before opening it. If two or more feel shaky, revisit Part 0: What Verification Is first.
The number of input sequences grows exponentially with state and time; any practical simulation tries a vanishing fraction of them.
Verification asks whether the design matches its specification; validation asks whether the specification (and product) meets the real need.
Fixing it needs new masks, months of schedule and possibly field recalls, against an edit and a rerun at RTL.
# | Lesson | Level | Status |
|---|---|---|---|
1.1 | W · Working | Ready | |
1.2 | W · Working | Ready | |
1.3 | W · Working | Ready | |
1.4 | S · Senior | Ready | |
1.5 | S · Senior | Ready | |
1.6 | S · Senior | Ready | |
1.7 | S · Senior | Ready | |
1.8 | S · Senior | Ready | |
1.9 | W · Working | Ready | |
1.10 | W · Working | 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.