Tools
Auto-Verify
Test plan, self-checking testbench, simulation and the verdict you can trust.
Auto-Verify is the sanity check on a generated module. It writes a small set of direct tests covering the module's core behaviour and runs them automatically, so what you get back is a design a simulator agreed with rather than one that merely looks right.
It corrects itself
If a test fails, that is treated as work still to do rather than as a result to hand over: the design is corrected and the tests are run again. A green result therefore 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 you get
| Artifact | What it is |
|---|---|
| Testbench | A self-checking testbench built around your specification, not around the module that was just written. It reports pass or fail rather than leaving you to read waveforms. |
| Simulation log | The full output of the run, with every check that passed or failed and a summary line at the end. |
| Synthesis report | A resource estimate for the device family you selected, so an accidental latch or an oversized counter shows up immediately. |
The distinction that matters here is which document the tests came from. Tests derived from the module tend to confirm what the module does; tests derived from your request check what you actually 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. That additional work may use more credit. 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.