Course map
- 1 lesson
Starts with How to Use This Course
- 1 lesson
Starts with Reading Paths
- 1 lesson
Starts with Concept Map
- 1 lesson
Starts with Meet DCRouter
- 1 lesson
Starts with Glossary
- 8 lessons
Starts with Verification, Validation and Test
- 11 lessons
Starts with A Taxonomy of Bugs
- 8 lessons
Starts with Intent and the Oracle
- 7 lessons
Starts with Controllability
- 11 lessons
Starts with Directed Tests
- 11 lessons
Starts with Self-Checking Testbenches
- 10 lessons
Starts with What Coverage Measures
- 10 lessons
Starts with What Formal Does
- 8 lessons
Starts with Levels and What They See
- 9 lessons
Starts with The Verification Plan
- 8 lessons
Starts with Why Cycles Matter
- 8 lessons
Starts with Pre-Silicon and Post-Silicon
- 8 lessons
Starts with The Cost of Bugs by Stage
- 7 lessons
Starts with The Debug Loop
- 7 lessons
Starts with What Sign-Off Means
- 8 lessons
Starts with Functional Safety Verification
- 5 lessons
Starts with How to Read an Escape
- 5 lessons
Starts with Write the Plan
- 6 lessons
Starts with The Reasoning Framework
About this course
Most verification courses teach tools: SystemVerilog, UVM, a formal tool. This course teaches the decisions those tools carry out. What exactly are we checking against? Which stimulus reaches the cases that matter? Where should a check sit? When does coverage mean something? When should we prove instead of test? What should we verify first, and when have we done enough?
No team can simulate every case, so verification never proves a chip correct. It gathers evidence, as cheaply and as early as possible, until the risk that remains is one the team can accept. Learn to reason about that evidence and you can plan, review and sign off verification on any design, with any tools.
What you will be able to do
Turn a specification into checkable rules, a reference model and a risk-ranked verification plan.
Choose directed, random, constrained-random or formal methods for each feature, and defend the choice with numbers.
Read coverage and bug-rate data critically, spot false passes, and estimate how many bugs are left.
Debug failures with a method, from a single waveform to a night of regression failures.
Run a sign-off review that states the evidence, the waivers and the residual risk honestly.
Four levels on every page
Badge | Level | Who | What a page gives you |
|---|---|---|---|
F | Foundation | 0–3 years | The problem, the idea, a clear picture, one worked example |
W | Working | 3–6 years | Techniques, pitfalls, runnable code, how to tell if it worked |
S | Senior | 6–10 years | The arithmetic behind the choice, trade-off tables, planning and closure |
P | Principal | 10+ years | Risk, economics, what a sign-off board must ask, how the decision ages |
Each lesson carries its lowest level badge, and every lesson ends its teaching with a Senior or Principal lens. See reading paths for routes by role.
The parts
Part | Title | The question | Lessons | Status |
|---|---|---|---|---|
0 | What does it mean for a chip to work? | 7 | 7 ready | |
1 | What can go wrong? | 10 | 10 ready | |
2 | What exactly are we checking against? | 7 | 7 ready | |
3 | Can we see and steer what matters? | 6 | 6 ready | |
4 | How do we drive the design into the states that matter? | 10 | 10 ready | |
5 | How do we know the output is right? | 10 | 10 ready | |
6 | How do we know we have tested enough? | 9 | 9 ready | |
7 | When should we prove instead of test? | 9 | 9 ready | |
8 | At which level should each thing be verified? | 7 | 7 ready | |
9 | What should we verify first, and how much? | 8 | 8 ready | |
10 | How do we run enough cycles? | 7 | 7 ready | |
11 | What do we do when the chip comes back? | 7 | 7 ready | |
12 | How do we spend verification effort wisely? | 7 | 7 ready | |
13 | How do we find the cause fast? | 6 | 6 ready | |
14 | When are we done? | 6 | 6 ready | |
15 | What changes for safety, security, processors and AI hardware? | 7 | 7 ready | |
16 | What can real projects teach us? | 5 | 5 ready | |
17 | Can you apply all of it? | 5 | 5 ready | |
18 | Can you explain it under pressure? | 6 | 6 ready |
How the course is built
DCRouter and the Bug Zoo. You verify one small router across the whole course. It hides 24 planted bugs; each part applies one technique and records which bugs it catches. See Meet DCRouter.
Measured, not asserted. Every waveform comes from a simulation on the page, every plot from a model on the page, every formal result from a proof that runs, and every bug-catch number from a real run against the Bug Zoo.
Decisions above the tools. Each lesson links to the SystemVerilog, UVM, formal or other course that teaches the syntax, and spends its own time on why.
An evidence ledger. Each part adds one column to a sign-off record for DCRouter, which becomes the sign-off review in Part 14.