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
    • Self-Checking Testbenches
    • Where to Check
    • Assertions as Local Checkers
    • Scoreboards
    • How Precise a Reference Model?
    • Ordering and Timing in Checks
    • End-of-Test Checks
    • False Passes
    • Checking Performance
    • Hunting the Zoo with Checkers
    • Drills: Checking
  • 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 5: Checking
  1. Topics
  2. First Principles of Verification Strategy
  3. Part 5: Checking
  4. Drills: Checking

Part 5 · Checking · All levels

Drills: Checking

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

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 makes a testbench self-checking?

    A reference, a comparison on every output, end-of-test checks, a watchdog, one machine-readable verdict, and evidence the checks can fail.

    Check yourself Assertions or scoreboard?

    Both: assertions for relations and timing where they apply, failing at the cause; scoreboards for results end to end against a reference.

    Check yourself How does a scoreboard work?

    Predict from accepted inputs, match each output against the oldest prediction of its ordering domain, and fail on leftovers at the end.

    Check yourself Should the reference model match cycle by cycle?

    Usually not: match the specification's depth, and add timing only for rules about time, judged only where it is observable.

    Check yourself How do you check reordered outputs?

    Key the scoreboard by the ordering domain the specification promises (flow, ID, address).

    Check yourself How do you catch a lost packet?

    An end-of-test check: drain with a limit, then require every prediction to have been matched.

    Check yourself How do you know your checker works?

    Show it was triggered (cover or count) and that it can fail (planted bug or mutation), and validate it on the clean design across many seeds.

    Check yourself How do you verify performance?

    Specify bounds; timestamp transactions; check tails under the relevant load; report separately from functional failures.

    Whiteboard exercise

    Task. A DMA engine reads descriptors, copies buffers from source to destination memory, and raises an interrupt per descriptor. Design its checking: which rules go to assertions, what the scoreboard predicts and how it matches, what is checked at the end, and how you would show each checker works.

    Check yourself Open a model answer

    Assertions (local, timing): bus protocol rules on both memory interfaces (valid held until ready, no X on control); interrupt is a pulse, or a level until cleared, as specified; no write to the destination outside the descriptor's range; busy status consistent with outstanding work. Scoreboard (end to end): predict from each descriptor accepted that destination memory will hold the source bytes; match by descriptor (descriptors may complete out of order if the engine has several channels, so key by channel or descriptor ID); check one interrupt per completed descriptor; check error status for injected bus errors. End of test: every descriptor completed and its interrupt seen; destination memory compared byte for byte; no extra writes anywhere (a memory model that records every write); status registers and counters read back. Proving the checks: plant faults in a copy of the design or a mutation campaign (an off-by-one length, a dropped interrupt, a wrong byte order) and confirm each is caught; cover the antecedents of the assertions; run the clean design on many seeds.

    Checkpoint: ten questions

    Check yourself 1. In lesson 5.1, how many errors did the checker report on the buggy FIFO, and on the correct one?

    45 on the buggy FIFO; 0 on the correct one.

    Check yourself 2. With assertions added, at what time was BUG_21 reported, against the random hunt's 439,965 ns?

    39,985 ns, about eleven times earlier.

    Check yourself 3. Why did the step-6 assertions catch no new bugs?

    They check rules whose violations the scoreboard already detected later; they detect earlier and more precisely.

    Check yourself 4. Which scoreboard fails the legal interleaving, and which misses a swap within a flow?

    The global-order scoreboard fails the legal run; the unordered (bag) scoreboard misses the swap.

    Check yourself 5. What ordering domain does AXI promise?

    Order within the same ID.

    Check yourself 6. How many of the random hunt's catches came from end-of-test checks?

    Six of fifteen.

    Check yourself 7. What two numbers make a checker trustworthy?

    That it was triggered, and that it fails when the design is wrong.

    Check yourself 8. In the latency model, what was input 3's worst wait with the stuck pointer, against what bound?

    208 cycles against a 16-cycle bound.

    Check yourself 9. Why did the first arbitration checker fail the clean design?

    It assumed packets were granted just before their first flit, but granted packets can wait for credits.

    Check yourself 10. Which two bugs remain uncaught after Part 5, and why?

    BUG_16 and BUG_23: no test clears PKT_CNT3 or disables a port, so they are never reached.

    Revisit

    • 5.1 Self-Checking Testbenches

    • 5.2 Where to Check

    • 5.3 Assertions as Local Checkers

    • 5.4 Scoreboards

    • 5.5 How Precise a Reference Model?

    • 5.6 Ordering and Timing in Checks

    • 5.7 End-of-Test Checks

    • 5.8 False Passes

    • 5.9 Checking Performance

    • 5.10 Hunting the Zoo with Checkers

    Keep going

    Next: Part 6: Coverage. How do we know we have tested enough?

    Previous

    61 / 160

    Next: Part 6: Coverage

    Up next

    Up nextPart 6: Coverage

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Self-Checking Testbenches
    • Where to Check
    • Assertions as Local Checkers