Verification Regressions at Scale
Running UVM and cocotb regressions of thousands of random seeds a night: tiers, coverage closure, failure bucketing by signature, seed reproduction, flake handling and scheduling on LSF, Slurm or Grid Engine.
Overview
Why this topic
Verification is the largest share of the engineering effort on a modern chip, and most of the compute. A single SoC team can run tens of thousands of simulations every night, each one a test with a random seed. The farm that runs them, the triage that sorts the failures, and the dashboard that says whether the design is getting better are owned by infrastructure and verification engineers together.
The interview questions here are about scale and signal: how to run 20,000 jobs overnight, how to turn 900 failures into 6 bugs, how to reproduce one of them exactly, and how to tell a design bug from a farm problem.
Interview questions
- Design a nightly regression system for 25,000 simulations that must finish before 07:00.
- 900 tests failed last night. Walk me through turning them into actionable bugs.
- A failure does not reproduce when you rerun its seed. What could be going on?
- How do you schedule a regression fairly on a shared LSF farm, and how does it compare with Slurm and Grid Engine?
- How do you drive and report coverage closure across thousands of runs?
- What does a good regression dashboard show, and what do you alert on?
Sign up free to read the full topic
More AI Infrastructure topics
Start free on Cariara · Coding problems · System design studio