1. How would you verify an asynchronous FIFO and prove there is no data loss?
Answer:
- Verify full, empty, overflow, and underflow conditions.
- Check pointer synchronization across clock domains.
- Use a scoreboard to compare write and read data.
- Add assertions for FIFO properties.
- Run random clock frequency combinations.
- Ensure every written transaction is eventually read exactly once.
2. Why can a CDC synchronizer still fail even when using two flip-flops?
Answer:
A two-flop synchronizer reduces metastability probability but does not eliminate it. Failure can still occur due to extremely rare metastability events, reconvergence issues, or incorrect CDC architecture.
3. What is reconvergence in CDC, and why is it dangerous?
Answer:
When multiple synchronized signals are combined again in destination logic, they may arrive in different cycles, creating inconsistent data and functional failures.
4. How would you debug a simulation that passes but fails in silicon?
Answer:
- Check CDC/RDC reports.
- Review X-propagation issues.
- Analyze reset sequencing.
- Investigate timing violations.
- Check power-up conditions.
- Compare silicon traces against simulation waveforms.
5. What is the difference between deadlock and livelock?
Answer:
Deadlock: No progress is possible.
Livelock: Activity exists, but useful work never completes.
6. How would you verify a cache coherency protocol?
Answer:
- Verify MESI/MOESI state transitions.
- Check cache-to-cache transfers.
- Verify invalidations.
- Test simultaneous accesses.
- Create reference models and assertions.
7. Why can 100% code coverage still miss critical bugs?
Answer:
Code coverage only shows that code executed. It does not prove all functional scenarios were tested correctly.
8. What is the difference between assertion coverage and functional coverage?
Answer:
Assertion Coverage
- Measures whether assertions were exercised.
Functional Coverage
- Measures whether intended design scenarios were exercised.
9. How would you verify a design with multiple asynchronous resets?
Answer:
- Test independent resets.
- Test simultaneous resets.
- Verify reset synchronization.
- Verify reset release ordering.
- Add reset-related assertions.
10. What are the limitations of constrained-random verification?
Answer:
- Rare scenarios may never occur.
- Coverage holes may remain.
- Debugging random failures is difficult.
- Requires strong coverage planning.
11. How would you verify a DUT with out-of-order transactions?
Answer:
Use transaction IDs and an associative-array-based scoreboard to match responses with requests regardless of arrival order.
12. Explain a scenario where a scoreboard reports false failures.
Answer:
A scoreboard may assume ordered responses while the DUT legitimately returns responses out of order.
13. How would you detect and debug intermittent failures occurring once in millions of cycles?
Answer:
- Increase simulation duration.
- Use assertions.
- Enable detailed logging around failures.
- Save random seeds.
- Use waveform checkpoints and debug tools.
14. What challenges arise when verifying clock-gating logic?
Answer:
- Missing clock pulses.
- Glitches on gated clocks.
- Incorrect enable timing.
- Power-saving corner cases.
Assertions and power-aware verification are commonly used.
15. How would you achieve coverage closure when the remaining bins are extremely difficult to hit?
Answer:
- Analyze uncovered bins.
- Create directed tests.
- Relax constraints if needed.
- Add targeted sequences.
- Confirm bins are actually reachable.
- Review coverage model correctness.
0 Comments