Tools
Reflection
A second pass where the model reviews its own RTL before you ever see it.
Reflection adds a review pass. Once the module is written, a second look goes over it hunting for the mistakes that survive a first draft, and rewrites what it finds before you ever see the code.
What it looks for
- Latches inferred by an incomplete case or if statement.
- Reset behaviour that does not match what the spec asked for.
- Signals driven from more than one block, or read before they are assigned.
- Off-by-one boundaries: counters that wrap a cycle late, flags that assert a cycle early.
- Requirements in your spec that the module quietly did not implement.
Reflection and Auto-Verify are different jobs
| Tool | How it decides something is wrong |
|---|---|
| Reflection | Reads the module and reasons about it, the way a colleague reviewing a pull request would. |
| Auto-Verify | Runs the module against a testbench and reports what actually happened. |
Reflection catches things a testbench was never told to look for; Auto-Verify catches things the code does rather than things it looks like it does. They are complementary, and on anything important both are worth the wait.
It has its own model
Reflection uses the Verifier role in the model picker, separate from the one that writes the RTL. A reasoning-heavy model is a good fit here even when you are generating with something faster; see Choosing models.
When to turn it on
- Turn it on for protocol logic, clock-domain crossings, anything with a lot of interacting conditions, and anything going somewhere you cannot easily patch.
- Leave it off while iterating quickly, or for small blocks where the review pass costs more time than reading the module yourself would.
Note
When Reflection is on, the REVIEW step appears in the run progress. On a run with it switched off that step is simply skipped, which is not a failure.