Optimization
Reading the result
Verdicts, trade-offs, regressions, and why a claimed win is sometimes withheld.
The optimization panel is where the measurement, the proof and the rewrite are brought together. Its verdict is computed from that evidence rather than accepted from the run, which is why it sometimes disagrees with the summary written above it.
The four outcomes
| Verdict | What it means |
|---|---|
| Improved and proved | The objective's metric moved the right way and behaviour was proved preserved after the last edit. The only verdict that claims a verified win. |
| Nothing worth changing | The design was examined and no worthwhile improvement was found. This is a real and useful answer; a well-written design that resists optimization is good news. |
| Unverified, review before applying | There is a rewrite, and the evidence does not support calling it a win. The reasons are listed and are worth reading before you touch Apply. |
| Needs more from you | Something was missing, most often which module to treat as the top. The summary says what. |
When a claimed win is withheld
If the run reports a win but the evidence does not support it, the verdict is lowered and the reasons are shown to you word for word. Those reasons are the most useful thing on the panel when it happens, because they say precisely what is missing.
- The objective's metric did not actually improve, or improved only within noise.
- The equivalence check did not run, did not settle, or ran before the final edit.
- A regression on another metric is large enough that the trade-off has to be your call.
- The change set contains a weakened check, which is disqualifying on its own.
Note
A downgraded result still gives you everything: the diff, the numbers and the analysis. It is not an error. It is the panel declining to describe something as verified when it is not.
What else is on the panel
| Section | What it holds |
|---|---|
| Headline | The one-line summary of the primary metric, such as LUTs 412 → 337 (−18.2%). |
| Comparison | The full before-and-after table, with regressions listed separately. |
| Equivalence | The verdict, the method used, and the bound if the check was bounded. |
| Changes | What was rewritten and why, in the run's own words. Read this next to the diff. |
| Trade-offs | What got worse or harder to read. Stated plainly so the decision is yours to make. |
| Not attempted | Ideas that were considered and rejected, with reasons. Carried into the next turn so a follow-up does not pay to reconsider them. |
| Readability impact | An honest note when the result is harder to maintain than the original. |
Deciding whether to apply
- 1
Check the verdict and the badge
Improved and proved, with an unbounded proof, is the strongest position you can be in. Anything else is worth slowing down for.
- 2
Read the regressions, not just the headline
A win on your objective can still be the wrong trade for your project. This is the part only you can judge.
- 3
Read the diff as code you will maintain
A fifteen percent LUT saving that nobody on the team can follow next year is sometimes a bad deal, and the readability note exists so you can weigh it.
- 4
Confirm in your own flow
Apply, download the project, and run your real synthesis. These numbers are a comparable estimate; the tool you ship with is the one that decides.
Applying works exactly as it does for a fix: all files or none, with a warning if anything moved since the measurement. See Applying a proposed fix.
The caveat travels with the result
Yosys estimates, not vendor tool results. Cell and LUT counts will
differ from Vivado/Quartus, and logic depth is a proxy for timing
pressure, not a timing report. Real fmax needs your own toolchain.It is printed on every result on purpose. The value of this mode is that it tells you within minutes whether a rewrite is worth taking to your real flow; it is not a replacement for that flow, and it never claims to be.