1. What is the verification gap? why does verification consume 70% of the ASIC development ASIC development cycle?
The verification gap is the disparity between design complexity and verification productivity.
verifiation consumes up to 70% of the cycle because it is fundamentally an ubbounded problem.
Designers build one specific path of intend funcionality. Verification engineers must prove that all other infinite paths do not result in catarophic failures. Finding bug is easy, proving the absence of bug is mathmatically impossible for large designs.
2. Contrast Directed Testing with Constrained Random Verification(CRV). When does CRV fail?
| Directed Testing | CRV | |
|---|---|---|
| Approach | Engineer manually writes stimulus for specific senarios | Testbench generates randomized stimulus |
| Effort | Low setup, High test-writing effort | High setup, low test writing effort |
When CRV fails: CRV is inefficient at hitting highly specific, deep-state corner case.
Solution: In these case, engineers use directd-random tests or Formal Verification
3. What is Formal Verification? How does it differ from Simulation?
Formal Verification uses mathematical proofs(model checking) rather than simulation logic
Simulation: Injects specific vectors(00, 01, 11) and checks the output. it can easily miss a bug if that exact vector sequence wasn't generated
Formal: Asserts that "output Must equal A+B" The formal solver exploers the entire mathmatical state space simultaneously.
Follow up Q: Can Formal Verification completely replace simulation?
No, Formal works best on control- heavy logic with a bounned state space. Data path heavy blocks and full SoC intergration still require simulation-based CRV.
4. The verification lifecycle
- Specification Review
- Verification plan
- environment Bring-up
- Developing the UVM agents, scoreboards and virtual sequene
- Sanity/Smoke testing
- Running basic directed test(reset test, register read/write) to ensure the DUT is alive
- Feature Extraction(CRV)
- unleashing crv test
- Coverage Closure
- Anlying coverage holes
- Gate-Level Simulation(GLS)
- Running the testbench against the synthesized netlist
- Tapeput/Sign-off
5. What makes a good Verification Plan (vPlan)? What should it contain?
A vPlan is the contract between verification and design. A poor vPlan leads to missing features and silicon bugs. A good vPlan is extractable, measurable, and maps directly to coverage.
Feature Description
Stimulus Strategy
Checking Strategy
Coverage Mapping
6. Describe the lifecyle of a bug. What details are crucial when filing a JIRA/Bugzilla ticket?
New -> assigned -> in progress -> resolved(code fix) -> verified(test pass) -> closed
Title
Reproduction steps
Log/Waveform
Root cause analysis
Severity/priority
7. What is a Continuous Intergration(CI) and Regression framework?
CI is the automated process of running verfication checks every time a designer commits new RTL code.
Sanity regression: fast 30min suite of tests on every pull request
Nightly Regression: massive suite of thousands of randomized tests
Weekly Regression: slow, exhaustive test like Gate level simulation
8. What is the difference Simulation, Emulation, and FPGA prototyping?
| Simulation | Emulation | FPGA protyping | |
|---|---|---|---|
| speed | 10-100 HZ | 1-5 MHz | 10-50MHz |
| Visibility | 100% | Moderate | Low |
| Compile time | Minutes | Hours to Days | Day to weeks |
| primary use | RTL function bug hunting | OS booting, Firmware development, IP intergration | Real-world interface testing |
Why we need Emulation:booting an OS like linux on an SoC via RTL simulation sould take years of real world time. Emulation runs it in hours
9. What happens when a bug escapes into Silicon? (Post-Silicon Validation)
A silicon bug is the worst case scenario. if a bug escapes the front-end verification team:
1. Silicon Bring-up
2. Failure Detected
3. Reproduction
4. Metal Spin / FIB
5. Coverage Hole Analysis
10. A test in the nightly regrssion failed randomly. When you rerun the exact same test with the exact same seed on your local machine, it passes. What are the potential causes?
This is a calssic "non=deterministic" failure. causes include:
1. uninitialized variables
- A variable or register dosen't have a reset alue. on the server farm, simulator memory allocated it as 1, causing failure. on your machine, it allocated as 0 passing by luck.
- Race conditions
- Two initial blocks or always blocks are executing in the same tiem-step delta cycle. different server architectures or simulator loads might schedule them in a different order.
- File/OS dependencies
- The test on the server might be picking up a different version of a shared library, DPI-C code, or reading an uninitialized file.
- Tool Version Mismatch
11. You join a team and coverage dashboard shows 100% Code coverage and 100% Functional Coverage. Is the design bug free?
Absolutely not
- 100% Code Coverage merely means every line of RTL was executed. It does not mean the RTL did the correct thing.
- 100% Functional Coverage means the testbench exercised everything specified in the verification plan.
If the Verification Plan is missing a feature, or if a specific combination of concurrent events wasn't defined as a cros-coverage bin, a critical bug can easily hide behind 100% coverage numbers. Coverage is only as good as the imagination of the engineer who wrote the bounds.
12. What is a systematic approach to debugging a failing test?
Effective debugging follows a structured process rather than trial and error:
- Isolate
- Determine if the failure is in the DUT, the testbench, or the test stimulus.
- Reproduce
- Find the Exact seed and the minimum test configuration that triggeers the failure consistently
- Localize
- Use $display, waveform dumps, or assertions to find the exact clock cycle
- Hypothesize & Prove
- Form a theory and add a targeted. assertion
- Root Cause Analysis
- Determine whether the bug is in the RTL oor if the sppecifiation itself is ambiguous
- Fix & Regress
- Apply the fix and run a targeted regreession to ensure no new failures are introduced
13. How are AI and LLMs being used in verification today?
AI tools are increasingly used as productiviy aids in verification work-flows
- Code generation: LLMs can generate boilerplate UVM components and automation scripts
- Coverage Analysis: AI-driven tools can analyze coverage holes and suggest constraint modifictions to reach uncovered bins.
- Legacy Code Understanding: LLMs help engineers quickly understand unfamilirar or poorly documented legacy testbench.
