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
    • Verification, Validation and Test
    • The Cost of an Escape
    • Intent, Design and Implementation
    • You Cannot Test Everything
    • Confidence, Not Proof
    • The Verification Stack
    • Meet DCRouter
    • Drills: What Verification Is
  • 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
  • Part 14: Sign-Off7
  • Part 15: Verification in Context8
  • Part 16: Case Studies5
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 0: What Verification Is
  1. Topics
  2. First Principles of Verification Strategy
  3. Part 0: What Verification Is
  4. Drills: What Verification Is

Part 0 · What Verification Is · All levels

Drills: What Verification Is

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

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 is the difference between verification and validation?

    Verification: did we build it right, against the specification. Validation: did we build the right thing, against the real need. Manufacturing test checks each fabricated part.

    Check yourself Why spend so much on verification?

    A bug's cost grows by orders of magnitude with how late it is found; a few late escapes dominate total cost.

    Check yourself Can a design pass every test and still be wrong?

    Yes: tests check a reading of the specification; a misreading shared by design and checks, or a specification that misstates intent, passes.

    Check yourself Why not simulate every input?

    States grow as 2^k and input sequences as 2^(i·L); even 48 bits of state exceeds a year of simulation.

    Check yourself When is a design verified?

    When several kinds of evidence agree strongly enough that the stated residual risk is acceptable; never proven correct.

    Check yourself Why verify at more than one level?

    Each level trades speed and visibility against realism; corners at low levels, integration and software at high levels.

    Whiteboard exercise

    Task. A manager asks you to report whether a new DMA block is "verified". Sketch what you would present: the kinds of evidence, how they combine, what is missing, and the residual risk, using illustrative numbers.

    Check yourself Open a model answer

    Evidence: 42 of 45 specification rules have checks (3 waived: reserved debug modes); checks shown to fire in regression (no vacuous assertions); functional coverage 96% of a plan reviewed by the architect, 4% holes on two error-injection crosses; formal proofs of the descriptor FIFO and arbiter; bug trend: 31 bugs, 29 at block level, discovery flattening for three weeks while coverage still rose; independent model written by a second engineer. Missing: the two error crosses, SoC-level interaction with the memory controller. Residual risk: error handling under simultaneous faults (medium likelihood, low impact, firmware can retry) and integration timing (to be covered at subsystem level). Recommendation: ready for integration, not yet for tape-out sign-off.

    Checkpoint: ten questions

    Check yourself 1. Which activity checks each fabricated chip?

    Manufacturing test.

    Check yourself 2. Which activity can catch a specification gap?

    Validation.

    Check yourself 3. In the cost model, why does the late project cost 5.3 times more?

    Its 20 silicon and field bugs, 10% of bugs, are 96% of its cost.

    Check yourself 4. What do passing tests prove?

    That the design and the checks agree on what was run; not correctness.

    Check yourself 5. How many states can 811 bits of state represent?

    2^811, about 10^244.

    Check yourself 6. About how many bits of state outrun a year of simulation at 10,000 cycles per second?

    About 38.

    Check yourself 7. What is residual risk?

    The risk of remaining bugs that a sign-off decision accepts.

    Check yourself 8. Which level finds address-map bugs?

    SoC level (or a subsystem that contains the shared map).

    Check yourself 9. What does a smoke test prove?

    That the design and testbench are alive for a simple case.

    Check yourself 10. How many Bug Zoo bugs does the four-port smoke test catch?

    3 of 24.

    Revisit

    • 0.1 Verification, Validation and Test

    • 0.2 The Cost of an Escape

    • 0.3 Intent, Design and Implementation

    • 0.4 You Cannot Test Everything

    • 0.5 Confidence, Not Proof

    • 0.6 The Verification Stack

    • 0.7 Meet DCRouter

    Keep going

    Next: Part 1: What Can Go Wrong. What can go wrong?

    Previous

    13 / 160

    Next: Part 1: What Can Go Wrong

    Up next

    Up nextPart 1: What Can Go Wrong

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Verification, Validation and Test
    • The Cost of an Escape
    • Intent, Design and Implementation