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
    • The Cost of Bugs by Stage
    • Bug-Discovery Curves
    • Diminishing Returns
    • Triage and Severity
    • Root Cause and Fix Quality
    • Estimating Remaining Bugs
    • Investing in Infrastructure
    • Drills: Bug Economics
  • 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 12: Bug Economics
  1. Topics
  2. First Principles of Verification Strategy
  3. Part 12: Bug Economics
  4. Drills: Bug Economics

Part 12 · Bug Economics · All levels

Drills: Bug Economics

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

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 Why find bugs early?

    Bug cost grows by orders of magnitude with stage; verification pays for itself up to an optimum where an extra week costs more than it prevents.

    Check yourself What does a flattening bug curve mean?

    Fewer bugs left, an exhausted technique, or less effort; check effort, fit a growth model with its range, try another technique.

    Check yourself When do you stop running random?

    When its cost per bug climbs; switch to techniques with a different pool and keep random as cheap regression.

    Check yourself How do you prioritise bugs?

    Cross-functional triage on severity, likelihood, detectability and workaround; silent high-severity bugs first.

    Check yourself How do you verify a fix?

    Root cause first; then the failing test, the rule itself, the neighbouring paths and the regression, and a sweep for the same mistake.

    Check yourself How many bugs are left?

    Estimate with independent methods (capture-recapture) and growth models, as ranges, knowing their assumptions.

    Check yourself Where would you invest next quarter?

    In infrastructure that multiplies: environments, shared checkers, coverage models, regression speed, debug and triage tools.

    Whiteboard exercise

    Task. Twelve weeks before tape-out a block shows: bugs found per week 9, 8, 6, 5, 3, 2, 2, 1; random regression doubled in the last four weeks; coverage stuck at 88%; 14 open bugs, 3 marked critical by their finders; one late fix to the arbiter landed last week. Decide what to do next and how you would report the state.

    Check yourself Open a model answer

    Read the curve with effort beside it: effort doubled while finds fell, so random is exhausted (rising cost per bug), not the design proven clean. Fit a growth model and run capture-recapture between random and a second technique to estimate what is left, as ranges. Move effort: triage the 12% coverage holes by cause (lesson 6.5) and send them to directed tests, coverage-driven stimulus and formal; keep random as cheap nightly regression. Re-triage the 14 open bugs in a cross-functional meeting on severity, likelihood, detectability and workaround; confirm or downgrade the 3 'critical' ones. Verify the arbiter fix properly: root cause, the fairness and priority rules (formal properties or checkers), neighbouring paths and the regression. Report: features with evidence against the plan, open bugs by triaged severity, holes by cause with owners, the estimate of remaining bugs with its range, and the arbiter fix's verification status.

    Checkpoint: ten questions

    Check yourself 1. In the cost model, where was total cost lowest, and how did no verification compare?

    At 156 engineer-weeks (about $0.98M); no verification cost about $9.8M, ten times more.

    Check yourself 2. What is the Goel-Okumoto model's expected cumulative count?

    m(t) = a(1 − e^(−bt)).

    Check yourself 3. In 300 simulated projects, what was the 10–90% range of the week-16 estimate for a true 80 bugs?

    About 68 to 98.

    Check yourself 4. What does a growth model assume about testing?

    That it stays the same; new techniques or effort changes break the fit.

    Check yourself 5. In the returns model, how many bugs did random alone and random-then-targeted find?

    48.6 and 59.3 of 65.

    Check yourself 6. What signals that a technique is exhausted?

    Its cost per bug (effort per bug found) climbs.

    Check yourself 7. Why are silent bugs ranked above loud ones of similar severity?

    Loud bugs announce themselves; silent ones escape and corrupt.

    Check yourself 8. Why is guarding the FIFO push a symptom fix for BUG_1?

    full is still late, so in_rdy accepts a flit the FIFO then drops.

    Check yourself 9. What check exposes the wrong BUG_9 fix?

    A throughput check: credits are conserved but the output stops sending whenever a credit returns.

    Check yourself 10. Which DCRouter infrastructure made every later testbench a few dozen lines?

    The shared environment, dcr_env.svh.

    Revisit

    • 12.1 The Cost of Bugs by Stage

    • 12.2 Bug-Discovery Curves

    • 12.3 Diminishing Returns

    • 12.4 Triage and Severity

    • 12.5 Root Cause and Fix Quality

    • 12.6 Estimating Remaining Bugs

    • 12.7 Investing in Infrastructure

    Keep going

    Next: Part 13: Debug. How do we find the cause fast?

    Previous

    122 / 160

    Next: Part 13: Debug

    Up next

    Up nextPart 13: Debug

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • The Cost of Bugs by Stage
    • Bug-Discovery Curves
    • Diminishing Returns