Verification Concepts — End-to-End
The end-to-end functional-verification cycle interviewers expect you to reason about: writing a verification plan, architecting a layered testbench, choosing directed vs constrained-random stimulus, checking with scoreboards and reference models, understanding simulation scheduling and races, and closing coverage through regressions and triage.
By the end you can
- Turn a spec into a verification plan with coverage and sign-off criteria
- Architect a layered, reusable testbench
- Check DUT behavior with a reference model and a scoreboard
- Reason about the SV event scheduler and close coverage via regressions
0 / 9 assignments done
Move each assignment through the stages — progress saves automatically.
Verification planning & testbench architecture
0/3Start from the spec: extract features into a verification plan with coverage and sign-off criteria, then design the layered testbench that will exercise them.
Write a verification plan from a spec
Take a short DUT spec (e.g. a FIFO or a simple bus slave) and produce a verification plan: a feature list, the stimulus needed for each, the checks that prove it, and the functional-coverage items that show it was exercised.
Requirements
- A feature list traced back to spec statements
- Per-feature stimulus, check and coverage entries
- Corner cases and error scenarios called out explicitly
- A short prioritization (must-verify vs nice-to-have)
You'll be able to
- Translate a spec into a testable feature matrix
- Tie each feature to stimulus, checking and coverage
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Define coverage and sign-off criteria
For the same DUT, define what 'done' means: the functional-coverage goals, the code-coverage expectation, the pass/fail gates, and the waiver policy. State how you'd argue the DUT is verified enough to sign off.
Requirements
- Explicit functional and code coverage goals
- A clear pass/fail (zero scoreboard errors) gate
- A waiver policy for unreachable/irrelevant coverage
- A one-paragraph sign-off argument
You'll be able to
- Distinguish code coverage from functional coverage
- Define objective sign-off criteria
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Layered testbench architecture
Draw and describe a layered testbench for the DUT: signal layer (interface), transaction layer (item), component layer (driver/monitor/agent/scoreboard/coverage), and test layer. Define the transaction and where each check lives.
Requirements
- A labelled block diagram of the layers and data flow
- A transaction definition (fields + meta)
- Where stimulus, checking and coverage each sit
- A note on what makes the env reusable across tests
You'll be able to
- Explain a layered, reusable testbench
- Place responsibilities in the right component
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Stimulus strategy & checking
0/4Choose and combine directed and constrained-random stimulus, and prove correctness with a reference model and a scoreboard — including the ordering problem.
Directed vs constrained-random strategy
For a chosen feature, write a directed test that nails a specific corner and a constrained-random sequence that explores broadly. Explain what each is good at and how you'd combine them.
Requirements
- A directed test hitting a named corner deterministically
- A constrained-random sequence covering a range
- A short comparison of reach vs control
- A plan to seed randomness with directed corners
You'll be able to
- Choose the right stimulus style per goal
- Blend directed and random for reach plus control
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Coverage-driven closure loop
Set up the coverage-driven loop: run random tests, read the functional-coverage report, find the holes, and add targeted constraints or directed sequences to close them. Document one hole you closed.
Requirements
- A covergroup with a visible hole after initial runs
- An analysis of why the hole exists
- A targeted constraint/sequence that closes it
- Before/after coverage numbers
You'll be able to
- Run the coverage-driven verification loop
- Turn coverage holes into targeted stimulus
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Scoreboard with a reference model and predictor
Build a checking path: a reference (golden) model computes expected results from observed inputs, and a scoreboard compares DUT outputs against it. Handle the case where the model must predict state, not just transform inputs.
Requirements
- A reference model separate from the DUT internals
- A scoreboard comparing expected vs actual with an error tally
- Correct handling of stateful behavior (predict then check)
- A clear report of the first mismatch's context
You'll be able to
- Separate the reference model from the checker
- Predict stateful behavior correctly
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
In-order vs out-of-order checking
Extend the scoreboard to a DUT that may return responses out of order (tagged by ID). Match responses to outstanding requests by ID instead of by arrival order, and detect missing or duplicate responses.
Requirements
- Outstanding requests tracked by ID (associative array)
- Responses matched by ID, not arrival order
- Detection of missing, duplicate or unexpected responses
- A note on how depth/backpressure affects the check
You'll be able to
- Check out-of-order, ID-tagged protocols
- Track outstanding transactions robustly
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Simulation semantics, debug & regression
0/2Understand the event scheduler well enough to avoid races, then close the loop with regressions, seeds, triage and coverage merging.
Event regions and race avoidance
Construct a small example that shows a driver/DUT race, then fix it using the SystemVerilog scheduling regions (understanding Active/NBA and program/clocking-block sampling). Explain why the fix removes the race.
Requirements
- A reproducible race (wrong value sampled)
- A fix via nonblocking assignments and/or clocking-block skews
- An explanation referencing the scheduling regions
- Deterministic results across runs after the fix
You'll be able to
- Explain the SV event regions at a working level
- Remove driver/sampling races
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Regression, seeds, triage & coverage merge
Define a small regression: a test list run across multiple seeds, with a triage flow for failures and a coverage-merge step. Show how you'd tell a real RTL bug from a testbench bug and produce a sign-off summary.
Requirements
- A multi-seed test list
- A triage flow (reproduce with the seed, minimize, classify)
- A coverage merge across runs
- A sign-off summary: pass rate + merged coverage
You'll be able to
- Run and read a regression
- Triage failures and merge coverage for closure
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Put it to work
Drill the matching interview questions, then see where this module sits in the full Design Verification roadmap.