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

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
    • Low-Power RTL Hub
    • DFT and Scan Hub
    • Physical Awareness Hub
    • Waveform Debug Hub
    • STA and ECO Hub
    • RTL-to-Implementation Closure
    • DFT-Ready RTL
    • Capstone: Resilient Streaming Peripheral
      • Stage 1: Specification
      • Stage 2: CSR and Control
      • Stage 3: Buffered Streams
      • Stage 4: CDC and Reset
      • Stage 5: Arithmetic and Reliability
      • Stage 6: Verification
      • Stage 7: Constraints and Implementation
      • Stage 8: Signoff Review
    • Principal Design Review
    • Senior RTL Interview Questions & Model Answers
  • Glossary and Notation
Loading lesson

‹Capstone: Resilient Streaming Peripheral
  1. Topics
  2. RTL Design
  3. Senior & Interview
  4. Capstone: Resilient Streaming Peripheral
  5. Stage 6: Verification

Part 9 · Senior · Senior

Stage 6: Verification

Build independent models, transaction scoreboards, assertions, coverage, fault injection, and mutations tied to requirements.

On this page

    Why this matters

    A scoreboard keyed by tag alone matches an old reply to a reused tag and reports a pass. A testbench that only passes the correct design proves little.

    After this lesson you can: key a scoreboard by epoch, operation, tag and beat, write the conservation equation, and list the mutations that must fail.

    The plan on one screen

    Stage 6 proves CP-1 with six evidence layers, one conservation rule checked end to end, and a list of mutations that must each fail.

    Layer

    Evidence

    CSR

    Access-type model, byte strobes, collisions, adapter protocol VIP

    Streams/FIFOs

    Conservation/order scoreboard and stall assertions

    Arithmetic

    Bit-exact and high-precision reference models

    CDC/reset

    Structural checks, hostile clocks, one-sided reset scenarios

    Reliability

    Every single-bit and representative/exhaustive double-bit injection

    System

    Random commands, packets, backpressure, interrupts, aborts, and recovery

    The rule, per epoch: accepted = delivered + explicitly_discarded + in_flight.

    CP-1 is one-to-one: each accepted input produces exactly one output, including a poisoned delivered beat, unless coordinated reset explicitly cancels it. Graceful abort drains and has discarded = 0; shared reset classifies each remaining owner once before closing the epoch.

    Mutations the bench must catch, each for its intended reason:

    • Wrong pointer wrap.

    • Dropped valid delay.

    • Clear-dominant IRQ.

    • One bad ECC syndrome.

    • Missing reset handshake.

    • A stale-epoch reply.

    • Unauthorized discard.

    • Poisoned-last metadata misalignment.

    Scoreboard flow

    Flow: the input monitor sends each accepted beat to an independent bit-exact model, which writes an expected queue keyed by epoch, operation, tag and beat. The output monitor's handshake is compared with the oldest expected entry: a match adds one to delivered, a miss reports a mismatch with key and queue. An authorized cancel event removes an entry and adds one to discarded.
    One accepted beat becomes one expected entry; it leaves the queue only on an output handshake or an authorized cancel, so in_flight is simply what remains queued.

    Read it as the life of one expected entry. Every path out of the queue updates exactly one term of the rule.

    • The key is (recovery_epoch, operation, packet_tag, beat_index), never the tag alone.

    • The expected entry holds the numeric result, keep/last and expected status, in order.

    • Delivered counts only on the actual output handshake; discard counts only on an authorized cancellation event with owner and reason.

    Layer monitors explain mismatches without replacing this end-to-end check.

    Worked scoreboard events

    Worked scoreboard event

    Accepted / delivered / discarded / in-flight

    Epoch7/op3 accepts A, B, C

    3 / 0 / 0 / 3

    A output handshake

    3 / 1 / 0 / 2

    Graceful abort alternative: B/C eventually transfer

    3 / 3 / 0 / 0; no expectation deleted merely because abort was requested

    Shared-reset alternative: authorized cancellation of B/C

    3 / 1 / 2 / 0; archive epoch7 and its reasons

    Epoch8/op4 reuses tag0 and accepts D

    Epoch8: 1 / 0 / 0 / 1; a late epoch7 B is unexpected and cannot retire D

    D output handshake

    Epoch8: 1 / 1 / 0 / 0; final queues empty

    Each row is one event; the four numbers always satisfy the rule. The two alternatives after A show that abort never deletes an expectation, while shared reset moves owners to discarded with a reason.

    Assertions, coverage and the drain check

    • Assertions: bounds, stability through the accepting edge, no overflow/underflow acceptance, command priority, and response deadlines under explicit service assumptions.

    • Coverage: full/empty, simultaneous operations, nearest-even ties and saturation, CE/UE, abort with an open packet or stalled output, both idle toggle polarities, clock ratios. Add each selectable arithmetic mode only when its extension is implemented.

    • Drain check: stop new offers without withdrawing a pending offer, finish an open packet, then drain under a finite watchdog. PASS requires all expected owners delivered or justified cancelled, no pending offers/responses and all epoch equations closed.

    The watchdog diagnostic must list epoch, operation, oldest outstanding key, queue location, accepted/delivered/discarded totals, pending command/snapshot acknowledgement and readiness/fault states. Choose its bound from legal service gaps and clock/CDC budgets; do not merely wait forever for equal counts. Report an expected stalled-peer timeout as the fault scenario's outcome, not normal operation success.

    Optional depth: epochs and the framed MAC

    Epochs and tag reuse. A CE correction is not another input/output transaction; a poisoned UE delivery is not a discard. Tags restart only after old ownership retires or is cancelled, with a new operation/epoch key; old replies must be rejected, not matched to a reused tag.

    Framed MAC extension. An optional framed MAC is not one-to-one. Independently count accepted contributing samples, complete frames, emitted frame results, cancelled partial frames and cancelled completed results. For fixed frame length N, split accepted samples into N*completed_frames + current_partial_samples + explicitly_discarded_partial_samples; separately conserve completed result owners. Do not compare sample count directly to output-frame count or borrow CP-1's scoreboard without changing its cardinality.

    Tip

    A testbench is credible when named mutations fail for the intended reason. Passing only the correct design is not enough evidence.

    Check yourself Why keep the arithmetic model independent from RTL helper functions?

    Reusing implementation code can reproduce the same bug in both DUT and reference, creating false agreement.

    Remember

    • The key is (recovery_epoch, operation, packet_tag, beat_index), never the tag alone.

    • Per epoch: accepted = delivered + explicitly discarded + in flight.

    • A testbench is credible when each named mutation fails for the intended reason.

    Rule of thumb: do not reuse the implementation code as the reference, or both sides share the same bug.

    How this was checked

    The harness requirements and scoreboard traces on this page are worked expectations. They are not an executed full capstone regression.

    Keep going

    • Practice: Arbiter fairness verification with a scoreboard and monitors

    • Interview: run a mock interview on this topic

    Related topics

    • Assertions in RTL

    • Stage 7: Constraints and implementation

    Previous

    308 / 350

    Next: Stage 7: Constraints and Implementation

    Up next

    Up nextStage 7: Constraints and Implementation

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Stage 1: Specification
    • Stage 2: CSR and Control
    • Stage 3: Buffered Streams