Part 9 answers: What should we verify first, and how much?
Verification time is always shorter than the space it could cover, so planning is a decision about risk: which features matter most, which are most likely to be broken, and which are new. A plan turns the specification into features, checks, coverage and priorities everyone can see.
This part covers the verification plan, feature extraction, risk-based prioritisation, effort estimation, metrics and the ways they mislead, regression strategy and managing late changes, ending with a full plan for DCRouter.
Write a verification plan from a specification.
Rank features by risk and allocate effort accordingly.
Choose metrics that show real progress and recognise misleading ones.
Answer each in your head before opening it. If two or more feel shaky, revisit Part 8: Verification Levels and Reuse first.
Simulation is slow and visibility poor; corners are far cheaper to reach and debug at block level.
Checkers (assertions, bound monitors), coverage models and reference models.
Integration: connectivity, address maps, interactions between blocks and with software.
# | Lesson | Level | Status |
|---|---|---|---|
9.1 | S · Senior | Ready | |
9.2 | W · Working | Ready | |
9.3 | S · Senior | Ready | |
9.4 | P · Principal | Ready | |
9.5 | S · Senior | Ready | |
9.6 | S · Senior | Ready | |
9.7 | P · Principal | Ready | |
9.8 | 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.