System verification strategy

Run the plan and make sign-off reviewable

Part 5 · Execution and closure

Translate the plan into regressions and debugging loops, then close coverage, convergence, stability, waivers, and residual risk.

Keep the source of truth, observation path, stress model, and exit evidence explicit so every verification decision can be reviewed.

Execute + close5 focused sectionsNative diagrams + worked reasoning

Operating model

Plan → Execute → Sign-Off.

Treat verification as an evidence system: decide what must be true, build independent ways to observe it, then prove completeness and stability with objective closure data.

01Plan

Turn the specification into ranked risks, explicit ownership, a traceable testplan, and a scalable checking architecture before writing random stimulus.

02Execute

Build a self-checking environment, calibrate trust during directed bring-up, then expand into controlled random stress and coverage-driven regression.

03Sign-Off

Demonstrate completeness, quality convergence, stress stability, and understood residual risk with objective, repeatable evidence.

Plan

Turn the specification into ranked risks, explicit ownership, a traceable testplan, and a scalable checking architecture before writing random stimulus.

Specification deep dive

Decompose the specification into features, interfaces, and behaviors.
Clarify ambiguities with design and record the resolved contract.
Define scope and ownership boundaries, including block-level testing.
Rank control, CDC, power, precision, concurrency, and forward-progress risk.

Testplan authoring

Map features to directed, corner, negative, random, and stress tests.
Balance functional and cross coverage.
Plan performance, power, CDC, and temporal coverage.
Define coverage targets, allowed bug thresholds, implementation status, and regression-stability goals.

Testbench methodology

Draw the architecture: agents, monitors, scoreboards, sequencing, and reusable sub-environments.
Define the correctness model, golden-model boundary, and checker types.
Choose directed, constrained-random, formal, CDC, power-aware, and firmware approaches by risk.
Plan regression infrastructure and discuss tradeoffs explicitly.

Reference-model decision

Choose feature granularity, data structure, timing fidelity, and integration style.
Plan how the model itself will be validated.
State what the model cannot prove and add an independent checker where needed.

Interview questions to rehearse

What are the first things you do when you receive a new specification?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you identify the highest-risk features in a design?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you decide what to verify with directed tests versus random tests?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you write a feature-based testplan?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you capture corner cases for a streaming pipeline?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you plan coverage for a pipeline or streaming subsystem?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you choose the right abstraction for a golden model?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you validate the golden or reference model?

Use the model answer below as the structure, then ground it in the design named by the question.

Which testbench components must be planned ahead?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you decide which assertions are required?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you plan throughput and latency tests?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you plan reset, CDC, and power-on-transition testing?

Use the model answer below as the structure, then ground it in the design named by the question.

Model answer

Dissect the specification, clarify ambiguity, define scope, and rank the highest-risk behavior such as complex control, CDC, power transitions, and numerical precision.
Translate requirements into a traceable testplan that maps directed, corner, negative, random, and stress scenarios to functional and cross coverage plus exit criteria.
Define the verification methodology and architecture: agent structure, scoreboards, golden models, assertions, formal, CDC and power checks, regressions, and the tradeoffs that make the plan scalable.

Execute

Build a self-checking environment, calibrate trust during directed bring-up, then expand into controlled random stress and coverage-driven regression.

Structural foundation

Instantiate the DUT, connect clocks, resets, and interfaces, and invoke the UVM test.
Use one or more agents per interface, optional sub-environments, and a virtual sequencer for cross-interface scenarios.
Make the environment modular, reusable, scalable, and configuration-driven.

Stimulus path

Use directed sequences for known bring-up and constrained random for state-space exploration.
Drivers translate transactions to pin-level timing and handle stalls and backpressure.
Progress from pure directed to mixed directed/random and finally fully constrained-random stress.

Observation and checking

Monitors convert bus and internal observations into high-level transactions.
Assertions check protocols, invariants, handshakes, FIFOs, CDC, power, and reset sequencing.
Scoreboards compare against bit-exact or tolerance-aware Python, C, C++, or SystemVerilog models and handle latency, data massaging, and reordering.

Coverage and observability

Collect feature, mode cross, data-pattern, interface-state, and register-field functional coverage.
Collect line, branch, toggle, and FSM code coverage through the simulator.
Add clocks, reset, delay randomizers, performance counters, seed management, structured logs, transaction traces, selective waves, and test summaries.

Bring-up and trust calibration

Confirm compilation, connectivity, one end-to-end transaction, no floating or X signals, and basic scoreboard behavior.
Bring up features with boundary, reset, and mode-switch directed tests.
Validate the golden model and assertions rather than assuming either is correct.
Classify failures as RTL bugs, testbench bugs, or specification and reference ambiguities.

Random activation and regression

Add random data, ordering, jitter, backpressure, and in-flight reset with conservative constraints, then relax them.
Use sanity, nightly, and stress or soak suites.
Replay seeds, cluster failures, refine constraints, add targeted tests, and mine rare corners.
Use regression compression or predictive selection only when it preserves the required evidence.

Interview questions to rehearse

How do you bring up a new testbench from scratch?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you debug a failure in a large regression?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you implement and validate a scoreboard?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you ensure monitors and agents are correct?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you generate high-quality random stimulus without illegal scenarios?

Use the model answer below as the structure, then ground it in the design named by the question.

What is your pipeline bring-up strategy?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you validate throughput and latency in simulation or FPGA?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you use assertions during execution?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you model backpressure correctly?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you find corners missed by random tests?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you validate a Python or C++ model before trusting it?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you test FIFO full, empty, almost-full, and almost-empty boundaries?

Use the model answer below as the structure, then ground it in the design named by the question.

Model answer

Build a structured self-checking environment with hardware top, UVM agents, directed and constrained-random sequences, passive monitors, a scoreboard and reference model, SVA, coverage, clock/reset infrastructure, performance telemetry, seeds, logs, and debug observability.
Stabilize through directed bring-up, then enable controlled randomization and progressively relax constraints while calibrating the testbench, assertions, and golden model against known behavior.
Scale into tiered regressions, use coverage to direct new stimulus, replay and cluster failures, track stability, and keep iterating until the design remains correct under combinations, disruption, and long-running stress.

Sign-Off

Demonstrate completeness, quality convergence, stress stability, and understood residual risk with objective, repeatable evidence.

Functional coverage closure

Confirm every major feature and specification requirement was exercised.
Close mode × feature, feature × corner, rare state, transition, and boundary crosses.
Classify every hole as a real gap, unreachable behavior, or specification oversight.

Code coverage review

Inspect inactive branches, rare FSM states, and dead code paths.
Create targeted tests or directed sequences for meaningful holes.
Fix or formally justify and waive excluded behavior.

Closure actions

Write targeted tests, refine constraints, and fix or waive coverage with rationale.
Repeat Measure → Analyze → Fix → Re-measure until closure is stable.
Keep assertions and checkers enabled throughout the closure regressions.

Convergence and stability

Trend bug arrival, resolution, mean time to fix, and critical-bug recurrence.
Require bug rate to approach zero and no recent critical regressions.
Track pass rate, flaky behavior, corner-case recurrence, and sensitivity to recent changes.

Reliability under stress

Run long stress without degradation.
Keep performance inside the signed-off envelope.
Prove no memory leak, deadlock, race, starvation, drop, duplicate, or buffer leak.

Interview questions to rehearse

How do you know when you are done verifying a block?

Use the model answer below as the structure, then ground it in the design named by the question.

Explain your coverage-closure process.

Use the model answer below as the structure, then ground it in the design named by the question.

How do you measure quality convergence?

Use the model answer below as the structure, then ground it in the design named by the question.

When do you allow a coverage waiver?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you sign off FIFOs, pipelines, CDC paths, and resets?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you prove the golden model is correct before sign-off?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you sign off throughput and latency?

Use the model answer below as the structure, then ground it in the design named by the question.

What documentation do you produce at sign-off?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you sign off a variable-latency pipeline?

Use the model answer below as the structure, then ground it in the design named by the question.

What proves no drops or duplicates under extreme backpressure?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you compare FPGA behavior with RTL simulation before sign-off?

Use the model answer below as the structure, then ground it in the design named by the question.

How do you preserve equivalence across architectural retiming?

Use the model answer below as the structure, then ground it in the design named by the question.

Model answer

Review functional and code coverage, map every remaining gap to a test, unreachable proof, waiver, or specification correction, and keep re-measuring after each closure action.
Track bug trends, regression pass rates, testplan completion, and stability over multiple clean cycles so the evidence shows convergence rather than one lucky pass.
Run disruptive and long-duration stress, preserve performance limits, require all critical checkers, and package the traceability, waivers, residual risks, and targeted regressions needed for an auditable sign-off decision.

Apply the framework

Practice the failure modes behind the plan.

The case-study library shows how resets, power, clocks, CDC, ordering, QoS, errors, IRQs, firmware, liveness, and scale change each component contract.

System verificationVerification Case StudiesThirteen complete examples with tradeoffs, code, native diagrams, stress recipes, and interview follow-ups.Open the library →Practice bankDesign Verification QuestionsApply the strategy to filtered questions on UVM, scoreboards, protocols, coverage, assertions, and debug.Open the filtered bank →