Part 8 answers: At which level should each thing be verified?
A block testbench is fast and sees everything inside the block; an SoC test is slow, realistic and sees little. Each feature has a level where it is cheapest to verify thoroughly, and checks written once at block level can travel up the hierarchy.
This part covers what each level can see, assigning features to levels, reusing checkers and coverage, independent models of standard interfaces, software-driven SoC tests, hardware-software co-verification, and verifying performance and power.
Assign each feature to the level where it is verified most cheaply.
Reuse block-level checkers and coverage at higher levels.
Plan SoC and software-driven tests for what block tests cannot see.
Answer each in your head before opening it. If two or more feel shaky, revisit Part 7: Formal and Simulation first.
No assertion can fail within 20 cycles of reset, for any allowed input; nothing beyond that.
Assumptions that rule out legal behaviour, so the proof passes without checking the cases that matter.
Any two of: control logic corners, arbiter fairness, FIFO and counter limits, deadlock, ordering rules.
# | Lesson | Level | Status |
|---|---|---|---|
8.1 | W · Working | Ready | |
8.2 | S · Senior | Ready | |
8.3 | S · Senior | Ready | |
8.4 | S · Senior | Ready | |
8.5 | S · Senior | Ready | |
8.6 | P · Principal | Ready | |
8.7 | 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.