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. The Cost of Bugs by Stage

Part 12 · Bug Economics · Working (W)

The Cost of Bugs by Stage

A bug costs more the later it is found, so verification pays for itself, up to a point. A model of one block with 60 bugs shows total cost (verification plus escapes) against verification effort: too little effort costs ten times the optimum, and past the optimum each extra week costs more than the escapes it prevents. Where the optimum sits, and what moves it.

On this page

    Note

    Level: Working (W) · Answers: How do we spend verification effort wisely?

    Before this: Part 12 overview, The Cost of an Escape

    Lesson 0.2 showed that a bug costs more the later it is found: minutes in a designer's test, weeks in the lab, a respin at a customer. The natural conclusion is "verify as much as possible". A manager with a budget asks the sharper question: how much verification is worth paying for? Every engineer-week costs money too, and at some point another week finds less than it costs.

    Why find bugs early, and how much verification is enough, in money?

    The obvious answer, and why it breaks

    One obvious answer is "never stop": escapes are so expensive that more verification is always justified. The other is "verify until the schedule ends". The first ignores that each extra week finds fewer bugs (lesson 12.3); the second ignores the bugs left behind. Expected cost has two parts, the verification spent and the escapes not prevented, and their sum has a minimum.

    The idea: verification cost plus escape cost

    • Verification cost rises steadily with effort.

    • Escape cost falls with effort, because each week finds some of the remaining bugs; each escaped bug costs the weighted average of where it would be found later.

    • Total cost is high with too little verification, lowest at an optimum, and rises again slowly with too much.

    • The optimum moves with the cost of an escape: safety-critical or high-volume parts push it far to the right.

    Build it: one block, 60 bugs

    An illustrative block with 60 bugs; effort finds each bug with a probability that rises with engineer-weeks; escaped bugs are found later at emulation, lab or customer costs.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    """Cost of bugs by stage: how much verification is worth paying for?
    
    A block holds 60 bugs (illustrative). Verification effort E (engineer-weeks) finds each bug
    with probability 1 - exp(-E / 40). Every bug not found pre-silicon is found later, at a
    stage-dependent cost: 70% in emulation or system validation ($20k each), 25% in the lab on
    silicon ($200k each, including workarounds and debug), 5% at customers ($2M each, including a
    respin share and reputation). Verification costs $5k per engineer-week. The model prints
    total expected cost against effort and the effort that minimises it.
    """
    import math
    
    BUGS, SCALE, WEEK = 60, 40.0, 5_000
    escape_cost = 0.70 * 20_000 + 0.25 * 200_000 + 0.05 * 2_000_000
    
    def costs(e):
        escaped = BUGS * math.exp(-e / SCALE)
        return e * WEEK, escaped * escape_cost, escaped
    
    efforts = [0, 25, 50, 100, 150, 200, 300, 400]
    print("effort (eng-weeks)  verification $   escapes   escape cost $     total $")
    rows = []
    for e in efforts:
        v, x, n = costs(e)
        rows.append((e, v, x, v + x))
        print(f"{e:18d}  {v:14,.0f}  {n:8.1f}  {x:14,.0f}  {v + x:12,.0f}")
    best = min(range(0, 601), key=lambda e: sum(costs(e)[:2]))
    v, x, n = costs(best)
    print(f"average cost of an escaped bug: ${escape_cost:,.0f}")
    print(f"cheapest total at {best} engineer-weeks: ${v + x:,.0f}, with {n:.1f} bugs escaping")
    assert 100 < best < 300 and rows[0][3] > 3 * (v + x)
    print(f"PASS: under-verifying costs more than three times the optimum; past {best} engineer-weeks each extra week costs more than the escapes it prevents")

    It prints:

    Diagram
    effort (eng-weeks)  verification $   escapes   escape cost $     total $
                     0               0      60.0       9,840,000     9,840,000
                    25         125,000      32.1       5,266,972     5,391,972
                    50         250,000      17.2       2,819,207     3,069,207
                   100         500,000       4.9         807,716     1,307,716
                   150         750,000       1.4         231,415       981,415
                   200       1,000,000       0.4          66,301     1,066,301
                   300       1,500,000       0.0           5,442     1,505,442
                   400       2,000,000       0.0             447     2,000,447
    average cost of an escaped bug: $164,000
    cheapest total at 156 engineer-weeks: $979,180, with 1.2 bugs escaping
    PASS: under-verifying costs more than three times the optimum; past 156 engineer-weeks each extra week costs more than the escapes it prevents
    The model's numbers: total cost falls from $9.8M with no verification to about $1M near 150 engineer-weeks, then rises to $2.0M at 400.

    How to read it: with no verification all 60 bugs escape and cost $9.8M. Fifty engineer-weeks still leave 17 escapes and $3.1M. The minimum, about $0.98M, is at 156 engineer-weeks, with about one bug expected to escape. Beyond it, verification keeps finding bugs, but each extra week costs more than the escapes it prevents. Every number here is illustrative; the shape is not.

    What moves the optimum

    Change

    Effect on the optimum

    Higher cost per escape (safety, automotive, high volume)

    Moves right: more verification pays

    Better techniques (faster discovery per week)

    Moves left and lowers total cost

    More bugs in the design (new architecture, new team)

    Moves right

    Software workarounds available for many bugs

    Lowers escape cost; moves left

    Reuse of a proven block

    Fewer bugs; moves left

    How real teams use cost thinking

    Practice

    Purpose

    Escape costs estimated per project and market

    Verification budget argued from consequences

    Investment in early techniques (designer formal, block verification)

    Bugs found where they are cheapest

    Discovery curves tracked against cost (lessons 12.2, 12.3)

    Diminishing returns detected and acted on

    What breaks

    A team (illustrative) cut block-level verification by half to meet a schedule, reasoning that chip-level tests would catch what was missed. Chip-level debug of block bugs took three times longer per bug, and two bugs reached silicon, each needing a software workaround that cost performance. The model's left side is this decision: saving verification weeks that the escapes cost back many times over.

    Why this matters

    Principal lens. Argue verification budgets from expected cost, not from habit: estimate the cost of an escape for this product, track discovery against effort, and invest where bugs are cheapest to find. The optimum is rarely where the schedule happens to end.

    Interview

    Asked: "Why find bugs early?"

    Weak answer: Because late bugs are bad.

    Strong answer: Because the cost of a bug grows by orders of magnitude with the stage: minutes at block level, days in emulation, weeks and workarounds in the lab, a respin or field recall at customers. That makes early verification pay for itself, up to an optimum where an extra week costs more than the escapes it prevents. In an illustrative model of a 60-bug block, no verification cost about ten times the optimum, and the optimum left about one bug escaping. The optimum moves right for safety-critical or high-volume products and left with better techniques.

    Follow-ups: (1) What moves the optimum? (2) Why does total cost rise again past the optimum?

    Check yourself In the model, why does total cost rise again after 156 engineer-weeks?

    Few bugs remain, so each extra week prevents less escape cost than its own $5,000 verification cost.

    Check yourself How would the optimum move for an automotive safety chip with a $20M average escape cost?

    Far to the right: more verification is worth paying for, because each prevented escape is worth much more.

    Key takeaways

    • Total cost is verification spent plus escapes not prevented; it has a minimum.

    • Too little verification costs many times the optimum; too much costs more than it prevents.

    • The optimum moves with escape cost, technique quality and the number of bugs.

    Keep going

    Next: Lesson 12.2, Bug-Discovery Curves. Bugs found per week: rise, peak and tail.

    Related topics

    • Part 12 overview: Bug Economics

    Previous

    115 / 160

    Next: Bug-Discovery Curves

    Up next

    Up nextBug-Discovery Curves

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Diminishing Returns
    • Triage and Severity
    • Root Cause and Fix Quality