Tools
Auto-Verify
Test plan, self-checking testbench, simulation and the verdict you can trust.
Auto-Verify provides a lightweight sanity check for the generated RTL. It creates 5–6 direct test cases covering the module's core functionality and runs them automatically to confirm that the design behaves as expected. The verdict you see comes from a simulator, not from an opinion.
It corrects itself
If any test fails, the platform analyzes the issue, refines the RTL, and runs the tests again. This loop continues until the module passes the full sanity-check suite, so a green result means the design and its tests agreed without you having to intervene.
The tradeoff is that, because it prioritizes speed and lightweight testing, it is not intended to uncover every possible corner case. For that, see Exhaustive Verification.
Example
You want to generate a simple module that doesn’t have a complex behavior, and a simple sanity check on its functionality gets the job done.
What actually runs
| Stage | What it produces |
|---|---|
| Test plan | A list of the behaviours worth checking, derived from your spec rather than from the code that was just written. |
| Reference behaviour | An independent model of what the module should do, so the testbench has something to compare against. |
| Testbench | Self-checking stimulus and assertions covering the plan; it reports pass or fail rather than dumping waveforms. |
| Simulation | Compilation and execution, with the full log attached to the run. |
Writing the plan before the testbench matters. A testbench written directly from the module tends to test what the module does; one written from the plan tests what you asked for.
Reading the result
# Test 1: reset clears the counter PASS
# Test 2: enable low holds the value PASS
# Test 3: counts 0 -> 255 and wraps FAIL
# at time 4210 ns: expected count = 0, got 256
# ---------------------------------------------------------
# 3 tests, 1 failureA failure like this tells you the counter is one bit wider than it should be, and it tells you before the module reached your project. Most failures are repaired inside the run by the loop above; if one survives to the end, ask for the fix as a follow-up and the next run starts from the failing module and the failing log.
What a pass does and does not mean
- It means the module satisfied a testbench built from your specification, under the stimulus that testbench applied.
- It does not mean the design is exhaustively verified, meets timing, or is correct for a case your spec never mentioned.
- It cannot catch a misunderstanding shared by the module and the testbench, because both were written from the same words. This is the strongest argument for a precise spec.
Cost and time
Auto-Verify roughly doubles the length of a run, because it generates a second artifact and then executes it. It does not cost an extra run against your allowance; it is part of the run you started. Leave it on for anything you plan to use, and off for quick sketches.
Going deeper
When one testbench is not enough, Exhaustive Verification builds a corner-case test plan, an independent reference model and a constrained-random environment on top of this, and holds the result to a coverage guard before it will call the run a pass. It switches Auto-Verify on for you, because it is a deeper version of this same job.
In project mode
Existing projects come with their own conventions, so their testbenches are run as they are and their output is classified as passed, failed, or unknown. An unfamiliar log is reported as unknown rather than optimistically called a pass; see Reading the change report.