The dashboard showed 100 percent functional coverage at signoff. After tape-out (or in a late system test) a bug appears in a scenario that the coverage report says was covered. You are asked what went wrong with verification, not just with the design.
The signal you would look at: 100 percent coverage on the dashboard, and a failing scenario that the covergroup claims to contain.
Whether you understand that coverage measures what was sampled, not what was checked.
Whether you can list the ways a covergroup reports 100 percent while measuring too little: denominator games, a wrong sample point, a missing cross, weights that remove a coverpoint.
Whether you separate a coverage-model hole from a checker hole.
Follow these steps in order. The order matters: each step narrows the search so that the next one is cheap.
Write down the exact scenario of the escape: values, order and timing.
Ask whether any bin could have been hit by that scenario. If a bin was hit, ask whether anything checked the result (scoreboard or assertion) at that moment.
Audit the denominator: default bins are not scored, ignore_bins remove tuples, auto_bin_max and explicit bins change the count, and weight zero removes a coverpoint from the metric.
Audit the sample point: the sample event, derived clocks that sample updated values, reset-time samples that fill bins with junk, and at_least thresholds set low.
Audit the structure: the bug may need a combination or a sequence, so single coverpoints can be 100 percent while the cross or the transition was never declared.
Close the loop: add the missing bin or cross, write the directed test that triggers the escape, confirm the checker fails on it, and add a review step that reads the report for the denominator, not just the percent.
A model transcript of the first part of the round. Do not memorise the words; copy the order of the moves.
Interviewer: We signed off at 100 percent coverage and still shipped a bug. How is that possible?
Candidate: Coverage only says the bins were sampled. First question: did the escape scenario map to a bin, and if it did, did a checker look at the result?
Interviewer: The scenario was a large transfer right after a reset. Individual coverpoints for size and for reset were both full.
Candidate: Then the bug lives in the combination or the sequence. Two coverpoints at 100 percent say nothing about the cross between them, or about the transition from reset to a large transfer, unless someone declared it.
Interviewer: There was a cross. It reported 100 percent.
Candidate: Then I read the denominator. A default bin is not scored, ignore_bins remove tuples from the count, and a weight of zero removes the coverpoint from the aggregate. Any of those can turn a partial cross into a full number.
Interviewer: And if the bins are all legitimate?
Candidate: Then I look at sampling: a derived clock that samples updated values, or samples taken during reset that fill bins with junk. The bin was hit, but not by the scenario we care about.
Interviewer: What would you change in the process?
Candidate: Review the report with its denominator and exclusions, add the missing cross, write the directed test for the escape with a checker that fails on it, and never treat a coverage percentage as a verdict on checking.Reading the percentage without reading the bins, exclusions and weights behind it.
Assuming a hit bin means the scenario was checked.
Closing individual coverpoints while the bug needs a cross or a transition.
Sampling with the wrong event or clock, so a bin is hit by values that never occurred together.
Work these cold, with the timer, before you rehearse the conversation.
cov-opt-006: option.weight zero removes metric influence (E)
cov-close-003: Sampling on a derived clock sees the updated value (M)