Tools
Exhaustive Verification
A corner-case plan, randomised stimulus and a coverage summary you can show someone.
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.
What it adds over Auto-Verify
Auto-Verify answers "does this work?". Exhaustive Verification answers "where would this break?", and it does that by testing far more of the input space than a single directed testbench ever reaches.
| You also get | Why it matters |
|---|---|
| A corner-case plan | The scenarios worth hitting for this kind of design are worked out first and each one is tested by name, so a gap is visible rather than silently absent. |
| An independent view of the expected behaviour | The design is compared against what your specification says it should do, which is what makes it practical to check hundreds of cases instead of a handful. |
| Randomised as well as directed stimulus | Combinations nobody would think to write by hand, run against the same expectations, and reproducible when one of them fails. |
| A coverage summary you can read | Evidence of what was actually exercised, rather than a bare pass at the bottom of a log. |
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.
If something fails, the run treats that as work still to do rather than as a result to hand over. It keeps correcting the design and re-running the suite until the module passes, which is why a thorough run takes longer than a standard one.
Reading the coverage summary
A testbench that prints a pass is not automatically believed. A thorough run only calls itself verified when the evidence supports it, and the strip under the pass or fail line on the turn card is that evidence.
- Checks
- 63
- Random vectors
- 200
- Mismatches
- 0
- Missing scenarios
- none
| On the strip | What it tells you |
|---|---|
| 9 / 9 scenarios | How many of the planned scenarios actually ran. Anything less than all of them is a gap, and the missing ones are named. |
| Checks | How many individual assertions were executed. |
| Random vectors | How many randomised cases were driven on top of the directed ones. |
| Mismatches | How many times the design disagreed with the expected behaviour. This is the number that decides a pass, not the absence of an error message. |
| coverage OK | A green badge means the run met its own bar for calling the result verified. |
When the bar is not met you get the reason in plain words, such as a list of the scenarios that never ran; and that reason is what the next attempt works on, so the testbench gets stronger rather than the bar getting lower.
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 Run defaults 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. A module that instantiates a vendor core cannot be simulated on its own, so the two cannot both apply to the same run.
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.