Loading page…
Your next page is on its way.
Your next page is on its way.
Design verification / A field guide
Send traffic. Break an assumption. See what the checker catches.
Teaching fixture: epoch-tagged responses; reset cancels outstanding work.
Send a request to begin.
This fixture holds one current request and one old response. It carries trustworthy epoch provenance on each response. Real untagged interfaces need an agreed cancellation or drain contract; a checker cannot invent that provenance.
Reset cancels current expectations. Only a response with matching ID and epoch may retire new work. The deliberately broken ID-only mode demonstrates a false match.
Open the full reset lab ↗The case library
Pick a mechanism. Open an experiment.
13 case studies
A driver completes a stale handshake or leaves valid asserted across reset.
Enter the lab ↗An output is not clamped while its source island is off.
Enter the lab ↗The gated clock continues toggling after the IP satisfies its idle threshold.
Enter the lab ↗A same-ID response returns in the wrong order.
Enter the lab ↗A low-priority request waits beyond its allowed starvation bound.
Enter the lab ↗An expected CRC or ECC rejection appears as a false data mismatch.
Enter the lab ↗An event is dropped and the expected IRQ never arrives.
Enter the lab ↗Items remain in flight while the completion counter does not change for the watchdog window.
Enter the lab ↗An override is installed after creation and has no effect.
Enter the lab ↗One or more agents miss the global event and retain stale state.
Enter the lab ↗The design passes functionally but misses sustained bandwidth or latency targets.
Enter the lab ↗Request changes again before acknowledgement and the destination loses or duplicates an event.
Enter the lab ↗A firmware-equivalent sequence no longer matches the current software driver or header definitions.
Enter the lab ↗One request. Two lifetimes. Six responsibilities.
Reset defines the lifetime boundary.
A request accepted before reset must either complete in its epoch or be explicitly cancelled by the reset contract. First state what the design promises, and under which conditions.
Define risk and evidence ↗Five foundations
Turn requirements and architectural risks into features, scenarios, assertions, coverage goals, and ownership.
Tools you will useSeparate stimulus, protocol driving, observation, prediction, and checking so components can be reused and debugged independently.
Tools you will useGenerate legal, meaningful traffic that reaches boundaries without hiding intent inside opaque randomization.
Tools you will useState temporal contracts directly and use proofs where simulation would struggle to cover every relevant trace.
Tools you will useMeasure what was exercised, understand what was checked, triage failures, and close meaningful gaps rather than chasing percentages.
Tools you will useLearn ASIC design verification with verification planning, SystemVerilog, UVM, assertions, formal methods, functional coverage, and regression debug.
Plan verification around risk, build reusable checking infrastructure, and know what coverage closure actually means.
Design verification builds evidence that an implementation matches its specification across normal operation, corner cases, and failure conditions. The strongest environments connect every stimulus, checker, assertion, and coverage point to a specific risk.
The engineering practice
Start with a product risk. Build the experiment that could prove you wrong.
Start with risk and evidence ↗
Explain your decisions
Prepare for UVM, scoreboards, coverage, assertions, and formal reasoning.
Verification from intent to closure
Strong design verification ties stimulus, scoreboards, assertions, and coverage to explicit product risk. Reusable UVM infrastructure matters because it makes failures easier to reproduce, localize, and explain.
Review planning, constrained-random stimulus, reference models, formal properties, regression triage, and coverage closure as parts of one evidence system rather than isolated techniques.