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
  • 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
    • The Debug Loop
    • Reproducing Failures
    • Following the Wait
    • Bisection and Delta Debugging
    • Triage at Scale
    • Is It the Testbench?
    • Drills: Debug
  • Part 14: Sign-Off7
  • Part 15: Verification in Context8
  • Part 16: Case Studies5
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 13: Debug
  1. Topics
  2. First Principles of Verification Strategy
  3. Part 13: Debug
  4. Drills: Debug

Part 13 · Debug · All levels

Drills: Debug

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

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 How do you approach a failing test?

    A loop: observe precisely from the first failure, hypothesise causes including the testbench, run the experiment that separates them, narrow until one cause explains every symptom.

    Check yourself A failure won't reproduce. What do you do?

    Confirm the same seed, build, options and simulator; look for testbench non-determinism; run many seeds with the signature as the stop condition; never close as flaky without a cause.

    Check yourself Walk me through a stuck valid.

    Start at the stuck handshake and ask what it waits for, following one dependency at a time to the logic that should have released it.

    Check yourself How do you find which change broke it?

    Bisection over the history, about log2(n) runs, with reproducible runs.

    Check yourself 500 tests failed overnight. Where do you start?

    Bucket by signature of the first error, debug one representative per bucket, largest first.

    Check yourself How do you know the bug is in the design?

    Rule out the testbench: clean-design comparison, driver protocol, the specification's words, simulator dependence, an independent check.

    Whiteboard exercise

    Task. After a merge, 120 regression runs fail across 8 tests. The first errors include scoreboard mismatches on one output, a protocol assertion on an ingress driver, and many timeouts. Lay out, step by step, how you would get from this to fixed bugs, and what you would automate afterwards.

    Check yourself Open a model answer

    Bucket the 120 by first-error signature: say a scoreboard bucket, a driver-protocol bucket and a timeout bucket. Start with the driver protocol bucket: a testbench driver breaking the protocol makes downstream failures meaningless, and it is probably a testbench bug introduced by the merge; check the clean design fails it too. Bisect the merge range for the first commit where each remaining bucket appears. For the scoreboard bucket, take the earliest failure, reduce it with delta debugging using the signature as the oracle, and follow the wrong value back to its first wrong stage. For timeouts, follow the wait from the oldest stalled handshake; re-bucket after each fix, since timeouts are often consequences. Before reporting, rule out the testbench (clean comparison, specification, independent check). Afterwards automate: signature bucketing on the dashboard, automatic bisection, test reduction with signatures, watchdogs that name the oldest stalled handshake, and protocol assertions on every driver.

    Checkpoint: ten questions

    Check yourself 1. In the opening story of lesson 13.1, what was the real cause of the priority-violation message?

    Lost credits, which made the checker's timing model wrong.

    Check yourself 2. What should every regression log record for reproduction?

    Seed, exact build, options and tool version.

    Check yourself 3. Why can a failing seed stop reproducing after a testbench edit?

    Random stability ties values to the order of random calls; the edit changes it.

    Check yourself 4. In the BUG_21 waveform, which term of in_rdy holds it low?

    sleeping.

    Check yourself 5. Which line of RTL caused the hang?

    wake = |in_vld[2:0], ignoring input 3.

    Check yourself 6. How many runs does bisection need for 64 commits?

    About 6.

    Check yourself 7. How many runs did ddmin need to shrink 200 steps to 3?

    59.

    Check yourself 8. How many buckets did 500 failures with 490 distinct lines fall into?

    6.

    Check yourself 9. Why keep rule names like R13 in signatures?

    They identify the cause; times and values do not.

    Check yourself 10. Which three habits caught all of the course's own testbench bugs?

    Running every new check on the clean design across seeds, against planted bugs, and against an independent check or the intended distribution.

    Revisit

    • 13.1 The Debug Loop

    • 13.2 Reproducing Failures

    • 13.3 Following the Wait

    • 13.4 Bisection and Delta Debugging

    • 13.5 Triage at Scale

    • 13.6 Is It the Testbench?

    Keep going

    Next: Part 14: Sign-off. When are we done?

    Previous

    129 / 160

    Next: Part 14: Sign-Off

    Up next

    Up nextPart 14: Sign-Off

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • The Debug Loop
    • Reproducing Failures
    • Following the Wait