Part 10 answers: How do we run enough cycles?
Booting an operating system takes billions of cycles; a whole-chip RTL simulation runs around a thousand cycles per second (fact V12). Some bugs only appear after long runs or with real software, so verification needs faster platforms: emulators, FPGA prototypes and virtual platforms.
This part explains why cycles matter, what limits simulation speed, what emulation and FPGA prototyping each trade away, virtual and hybrid platforms, debugging at scale, and how to match the platform to the question.
Estimate whether a goal needs simulation, emulation or a prototype.
Explain the speed, fidelity and debug trade-offs of each platform.
Plan debug for failures found after billions of cycles.
Answer each in your head before opening it. If two or more feel shaky, revisit Part 9: Planning and Risk first.
By risk: likelihood of bugs times impact, weighted towards new and complex features.
Tests can pass because they check little, or because the hard tests were removed or never written.
What runs on every change, nightly and weekly, so failures are caught quickly while runs stay affordable.
# | Lesson | Level | Status |
|---|---|---|---|
10.1 | W · Working | Ready | |
10.2 | W · Working | Ready | |
10.3 | S · Senior | Ready | |
10.4 | S · Senior | Ready | |
10.5 | S · Senior | Ready | |
10.6 | S · Senior | Ready | |
10.7 | P · Principal | 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.