Tools
Auto-Verify
Test plan, self-checking testbench, simulation and the verdict you can trust.
Auto-Verify is the switch that turns generated code into checked code. It writes a test plan, turns the plan into a self-checking testbench, compiles both, and runs the simulation. The verdict you see comes from a simulator, not from an opinion.
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. Ask for the fix as a follow-up; 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.
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.