At principal level the hard questions are not about syntax. They are about why a bug got through, whether a failure is real, whether a number can be trusted, and where the next week of effort should go. This topic works through those calls with illustrative cases and small benches you can run and break.
Every case here is a made-up scenario built to teach a pattern. None of them describes a real product or company.
THE QUESTIONS A VERIFICATION LEAD ANSWERS
"A bug reached silicon." -> which gap let it through? escaped-bug-analysis
"It fails on 1 seed in 40." -> real bug, TB bug, or race? intermittent-failures
"Coverage is 100%." -> 100% of what? metrics-that-lie
"We have 6 months and 1 SoC." -> where does each check run? scaling-verification
"How would you verify X?" -> plan, env, checks, closure system-design-interviewsLesson | What it covers |
|---|---|
Tracing an escape back to plan, stimulus, coverage and checking gaps, and fixing the class of bug, not one instance. | |
Seed- and race-dependent failures, from the first report to the root cause, with a seed-sweep bench. | |
Coverage at 100% with a live bug, flat bug curves and pass-rate traps. | |
IP versus SoC, reusing checks upward, emulation hand-off, and when gate-level and X-propagation runs pay off. | |
Walkthroughs for an AXI interconnect, a cache and a DMA engine, with the follow-up questions. |
The coverage model may measure what the stimulus or RTL does rather than the features in the spec, so 100% says nothing about the missing corner. And a checker may be blind to the symptom: a scenario can be covered while nothing compares the result against an independent expectation.