Coverage Sign-Off for a Block

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfBreak ItCompareScale It

1. Coverage Sign-Off for a Block
2. WhyWhy the Bug Rate Belongs in Sign-OffL2 Mid-LevelL3 Senior

   Why look at the bug rate when coverage is already at goal?

   Reveal the Model Answer

   Coverage measures the cases you thought of. The bug rate measures what the design is still doing wrong. If bugs keep appearing at full coverage, the model is missing cases, and the new bugs show where. A flat, low bug rate alongside full coverage is much stronger evidence than either alone.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Coverage measures the cases you thought of. Key point 2 The bug rate measures what the design is still doing wrong. Key point 3 If bugs keep appearing at full coverage, the model is missing cases, and the new bugs show where. Key point 4 A flat, low bug rate alongside full coverage is much stronger evidence than either alone.

   Half-Truth

   "Zero bugs this week means we are done."

   A quiet week can mean the tests stopped changing. Teams expect bugs after rate dips and look for new ways to reach corners.

   Source Spear & Tumbush, SystemVerilog for Verification (3rd ed.), §9.2.3 (PDF p364)

   • Lesson C7Closing Holes
3. Break ItHow a Bad Block Passes Sign-OffL3 Senior

   How could a block pass this review and still fail in silicon?

   Reveal the Model Answer

   The plan can miss a feature, so nothing measures it. A covergroup can sample the stimulus instead of what the design did. A checker can ignore a field, so covered cases pass with wrong results. The failure can also need traffic only the chip creates. Each of these is a review question: what is missing, where is it sampled, who checks it, and what needs the chip?

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 The plan can miss a feature, so nothing measures it. Key point 2 A covergroup can sample the stimulus instead of what the design did. Key point 3 A checker can ignore a field, so covered cases pass with wrong results. Key point 4 The failure can also need traffic only the chip creates. Key point 5 Each of these is a review question: what is missing, where is it sampled, who checks it, and what needs the chip?

   What Interviewers Listen For (Senior)

   A good senior answer turns each way a bug can escape into a checklist item for the next review. It backs this with an example from a real project.

   Wrong Altitude

   "If the review followed the checklist, an escape is bad luck."

   Escapes point to a gap in the checklist or the plan. The fix is to add the missing question for every block.

   Source Mehta, SystemVerilog Assertions and Functional Coverage (3rd ed.), §25.6 (PDF p448)

   • Lesson C1What Coverage Measures
   • Lesson C7Closing Holes
4. CompareBlock Sign-Off vs Chip Sign-OffL3 SeniorL4 Staff

   Compare coverage sign-off for a block with sign-off for the whole chip.

   Reveal the Model Answer

   Block sign-off closes the detailed corners of one design: every mode, boundary and error path. Chip sign-off assumes the blocks are done. It closes what only the chip has: connections, clocks and resets, shared buses, and end-to-end use cases. Its plan is smaller per block and wider across blocks. A chip review that re-checks block corners is wasting its time.

   	Block sign-off	Chip sign-off
   Closes	Every mode, boundary and error path of one design	Connections, clocks, resets, shared buses, use cases
   Assumes	Nothing about other blocks	The blocks are already signed off
   Plan shape	Deep in one block	Wide across blocks

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Block sign-off closes the detailed corners of one design: every mode, boundary and error path. Key point 2 Chip sign-off assumes the blocks are done. Key point 3 It closes what only the chip has: connections, clocks and resets, shared buses, and end-to-end use cases. Key point 4 Its plan is smaller per block and wider across blocks. Key point 5 A chip review that re-checks block corners is wasting its time.

   Misconception

   "Chip sign-off is the block numbers added up."

   Integration bugs live between blocks, where no block bench looks. The chip needs its own plan for them.

   Source Mehta, ASIC/SoC Functional Design Verification, §2.2 (PDF p34)

   • Lesson U12.2Vertical Reuse: A Block Environment Inside a Subsystem
5. Scale ItOne Sign-Off Standard for Forty BlocksL4 Staff

   You lead verification for a chip with 40 blocks and several teams. How do you make every block's sign-off mean the same thing?

   Reveal the Model Answer

   Write the criteria once, before the reviews start. They cover the plan and its checkers, coverage goals, exclusion rules and the bug-rate condition. Give every team the same report template, generated from the regression rather than typed by hand. Have someone from another team join each review. Track every block on one dashboard, so a weak block is visible early.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Write the criteria once, before the reviews start. Key point 2 They cover the plan and its checkers, coverage goals, exclusion rules and the bug-rate condition. Key point 3 Give every team the same report template, generated from the regression rather than typed by hand. Key point 4 Have someone from another team join each review. Key point 5 Track every block on one dashboard, so a weak block is visible early.

   What Interviewers Listen For (Staff)

   A good staff answer publishes the criteria and a report template early, and generates the evidence automatically. It uses reviewers from other teams to keep the standard equal.

   Wrong Altitude

   "Each team knows its block best; let them define done."

   Then "done" means forty different things, and the weakest definition decides chip quality. Teams fill in the criteria; they don't choose them.

   Source Mehta, ASIC/SoC Functional Design Verification, §2.2 (PDF p34)

   • Lesson U15.1Coverage Architecture and Planning
   • Lesson U16.2Seeds, Coverage and Directed Closure
6. What IfA Bug Fix After Sign-OffL3 Senior

   What if a bug fix lands in the block a week after its coverage sign-off? What do you rerun?

   Reveal the Model Answer

   Start with an impact review with the designer: which logic changed and which features touch it. Add a test that reproduces the bug and passes on the fix. Rerun the regression for that block on the new RTL, and replace its coverage with the new runs. Then check that nothing in the plan dropped below goal. Record the change and the evidence in the sign-off.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Start with an impact review with the designer: which logic changed and which features touch it. Key point 2 Add a test that reproduces the bug and passes on the fix. Key point 3 Rerun the regression for that block on the new RTL, and replace its coverage with the new runs. Key point 4 Then check that nothing in the plan dropped below goal. Key point 5 Record the change and the evidence in the sign-off.

   Missed Corner

   "Rerun only the test that found the bug."

   A fix can break nearby cases. Coverage on the new RTL must come from the block's full regression, not one test.

   Source Spear & Tumbush, SystemVerilog for Verification (3rd ed.), §9.1 (PDF p362)

   • Lesson C7Closing Holes