Tools
Exhaustive Verification
Test plan, golden reference model and a coverage guard that has to be satisfied.
Auto-Verify writes one testbench and runs it. Exhaustive Verification builds a whole verification strategy around the module instead: a plan of the corner cases worth hitting, an independent model of what the design should do, a constrained-random environment for each scenario, and a coverage guard that has to be satisfied before the run is allowed to call itself a pass.
How a thorough run is put together
The extra work happens before a single line of stimulus is written. Your specification is read again on its own terms, with the question "where does this kind of design usually break?" rather than "what does this module do?"
- 1
A corner-case test plan
The prompt is analyzed for potential corner cases, and those become a 12-scenario verification plan; each scenario carries an id, the stimulus to drive and the behaviour that must follow. The categories it works through are the ones that catch real bugs: reset and power-on, boundary and overflow values, back-to-back transactions with no idle gap, handshake edges such as stalls and single-cycle pulses, illegal inputs, and hold behaviour between operations.
- 2
A golden reference model
A second, independent description of the expected behaviour is written from the specification, not from the RTL. The testbench compares the design against this model rather than against hand-written expected values, which is what makes it practical to check hundreds of vectors instead of a handful.
- 3
A constrained-random environment
Every planned scenario gets directed stimulus, and on top of that the testbench drives 200 constrained-random vectors against the reference model. The seed is fixed, so a failure you see once you can see again.
- 4
Simulate, analyse, refine
The generated RTL is simulated automatically to detect functional bugs, protocol violations and unexpected behaviour. When something fails, the failing scenario and the mismatching values go back to the model that wrote the RTL so it can reason about the root cause and correct the design; then the suite runs again. That generate, simulate, analyse, refine loop continues on its own until the module passes the complete verification suite.
The coverage guard
A testbench that prints a pass is not automatically believed. A thorough run only counts as verified when three separate things hold at once, and any one of them failing turns the run back into a failure with an explanation attached.
- Every planned scenario actually ran. Each one reports its own result line, so a scenario that was planned and then quietly skipped shows up as missing rather than simply being absent.
- At least eight checks executed. This is the floor that stops a thin testbench from passing itself off as a thorough one.
- Zero mismatches against the reference model. Not "no errors printed"; zero disagreements between the design and the golden model.
- Checks
- 63
- Random vectors
- 200
- Mismatches
- 0
- Missing scenarios
- none
If the guard is not met you get the reason in plain words, such as a list of the scenarios that never ran. That reason is also what the next refinement attempt is handed, so the testbench gets strengthened rather than the bar getting lowered.
Note
Reading the strip: 9 / 9 scenarios is coverage of the plan, checks is how many individual assertions ran, and mismatches counts disagreements with the reference model. A green coverage OK badge means all three conditions above were satisfied.
When it is worth the wait
Use Exhaustive Verification when correctness and comprehensive testing matter more than generation speed. It performs significantly deeper testing than Auto-Verify, but this additional coverage comes at the cost of a longer generation and verification time: there are more artifacts to write, and the whole suite may be executed several times as the design is refined.
| Reach for it when | Why |
|---|---|
| The module has a real interface | Handshakes, backpressure and streaming are where directed tests tend to be thin and random vectors earn their keep. |
| Rare corner cases are plausible | Wraparound, sign flips, a simultaneous full-and-push, single-cycle pulses; the plan goes looking for these on purpose. |
| The design is going somewhere you cannot easily patch | Another twenty minutes now costs nothing next to finding this on a board. |
| You are handing the module to someone else | The coverage summary is evidence you can show, not just a claim that it works. |
Example
Your module includes a complex interface and may experience rare corner cases. That is exactly the shape of design this was built for; a single directed testbench will typically exercise the happy path and stop there.
Switching it on
The toggle sits next to Auto-Verify in the Tools menu, in the Run setup panel, and in Settings under Setup if you want it on for every new chat. Two rules are applied for you when you flip it:
- Turning it on turns Auto-Verify on as well. It is a simulation strategy, so without simulation there is nothing for it to do. Turning Auto-Verify off again takes it back down with it.
- Turning it on turns the IP Core Library off. Vendor cores are referenced but not present in the run directory, so a module that instantiates one cannot be compiled and simulated on its own.
Heads up
Exhaustive Verification applies to Plan mode only. Agent mode runs its own tool loop and decides for itself how to verify, so the switch is greyed out there rather than being accepted and then ignored.
What a thorough pass still does not prove
It is a much stronger claim than a standard pass, and it is still a claim about simulation. The plan and the reference model were both written from your specification, so a requirement you never stated cannot be tested, and a misunderstanding shared by the spec and the model gets tested consistently and wrongly. For the failure modes that only appear between simulation and silicon, see Static checks.