Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Paths
  • Concept Map
  • Meet DCRouter
  • Glossary
  • Part 0: What Verification Is8
  • Part 1: What Can Go Wrong11
  • Part 2: Specifications as Checkable Rules8
  • Part 3: Observability and Controllability7
  • Part 4: Stimulus11
  • Part 5: Checking11
  • Part 6: Coverage10
    • What Coverage Measures
    • Code Coverage
    • Functional Coverage Models
    • Crosses and the Combinatorial Explosion
    • Closure Curves
    • Holes and Unreachable Bins
    • Coverage-Driven Stimulus
    • Mutation Testing
    • A Coverage Model for DCRouter
    • Drills: Coverage
  • Part 7: Formal and Simulation10
  • Part 8: Verification Levels and Reuse8
  • Part 9: Planning and Risk9
  • Part 10: Emulation and Prototyping8
  • Part 11: Post-Silicon Validation8
  • Part 12: Bug Economics8
  • Part 13: Debug7
  • Part 14: Sign-Off7
  • Part 15: Verification in Context8
  • Part 16: Case Studies5
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 6: Coverage
  1. Topics
  2. First Principles of Verification Strategy
  3. Part 6: Coverage
  4. Drills: Coverage

Part 6 · Coverage · All levels

Drills: Coverage

Interview questions, a whiteboard exercise and a ten-question checkpoint for Part 6.

On this page

    Answer each question out loud before opening it. If you miss more than three in the checkpoint, revisit the lessons linked at the end.

    Interview questions

    Check yourself What does 100% coverage prove?

    Only that everything the model measures happened at least once; not that it was checked, nor that the model lists what matters.

    Check yourself Why isn't code coverage enough?

    It measures execution of existing code: not values, combinations or missing code.

    Check yourself Design a coverage model for a FIFO.

    From rules and risks: occupancy bins with boundaries apart, push and pop events at empty, middle and full, wrap-around, reset while non-empty, crossed only where logic interacts.

    Check yourself Which crosses would you write?

    Only crosses where the combination exercises logic its parts do not; group values, mark impossible ones illegal, condition on events, pairwise for configurations.

    Check yourself Coverage stopped at 92%. What next?

    Classify the holes (rare, very rare, never generated, unreachable, wrong) and act on each; more seeds barely move a plateau.

    Check yourself How do you handle unreachable coverage?

    Prove it unreachable, preferably with formal, then exclude or mark illegal with the reason; never exclude what is merely rare.

    Check yourself How do you close coverage faster?

    Feed holes back into constraints for part of each test, keep a blind share, and send stubborn holes to directed tests or formal.

    Check yourself How do you measure testbench quality?

    By the bugs it detects: mutation testing or seeded bugs; each survivor names a missing test or check.

    Whiteboard exercise

    Task. An interrupt controller has 32 sources, each with an enable bit and a priority (0 to 3), a mask register, a pending register (write 1 to clear) and one interrupt output. Write the coverage model: coverpoints, bins, crosses, and the events you would cover. Then say which crosses you would not write.

    Check yourself Open a model answer

    Coverpoints: source raised (32 bins); priority of the highest pending source (4); enable and mask state when a source is raised (enabled and unmasked, disabled, masked); pending clear written (per source, and for a source not pending). Events: two sources raised in the same cycle at different priorities and at equal priority; a source raised while its pending bit is being cleared; a higher-priority source arriving while the output is already asserted for a lower one; mask written while an interrupt is pending; reset with sources pending. Crosses: source × enable/mask state (32 × 3 = 96), priority-of-winner × priority-of-loser for simultaneous raises (4 × 4, only the cross that tests arbitration). Not written: source × priority × enable × mask × every other source (explodes to millions of bins and exercises no shared logic); data patterns of registers beyond walking ones and all-ones for stuck bits.

    Checkpoint: ten questions

    Check yourself 1. Which two DCRouter bugs escaped Parts 4 and 5, and which coverage holes named them?

    BUG_23 ("CTRL port k disabled") and BUG_16 ("PKT_CNT3 cleared").

    Check yourself 2. Which code coverage metric would show that no port was ever disabled?

    Toggle coverage on port_en.

    Check yourself 3. Why does DCRouter's length coverpoint keep 0, 1 and 15 as separate bins?

    They are boundaries where bugs concentrate; 2 to 14 behave alike.

    Check yourself 4. How many bins does src × dst × prio × every length × fault (3) × occupancy (9) have?

    13,824.

    Check yourself 5. In the closure model, what was coverage at 200 tests and at 5,000?

    91.8% and 92.4%.

    Check yourself 6. What three endings can a coverage hole have?

    Hit, excluded as unreachable with proof, or waived with a reason and an owner.

    Check yourself 7. On the header cross, how many tests did blind and coverage-driven stimulus need on average?

    54.9 and 12.4.

    Check yourself 8. What mutation score did the weak suite reach, and what did its survivors have in common?

    70%; each was a missing boundary or simultaneous-event test.

    Check yourself 9. How many holes did DCRouter's model show before and after the closing phase (default seed)?

    30 before, 12 after.

    Check yourself 10. With the closing phase, how many Bug Zoo bugs does the step-8 testbench catch?

    All 24.

    Revisit

    • 6.1 What Coverage Measures

    • 6.2 Code Coverage

    • 6.3 Functional Coverage Models

    • 6.4 Crosses and the Combinatorial Explosion

    • 6.5 Closure Curves

    • 6.6 Holes and Unreachable Bins

    • 6.7 Coverage-Driven Stimulus

    • 6.8 Mutation Testing

    • 6.9 A Coverage Model for DCRouter

    Keep going

    Next: Part 7: Formal and Simulation. When should we prove instead of test?

    Previous

    71 / 160

    Next: Part 7: Formal and Simulation

    Up next

    Up nextPart 7: Formal and Simulation

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • What Coverage Measures
    • Code Coverage
    • Functional Coverage Models