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 behaviour 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
The headline	One line for the metric your objective is about, such as LUTs 412 → 337 (−18.2%).
Equivalence	The behaviour verdict, and the bound if the check was bounded.
Measurements	The full before-and-after table for every metric.
Got worse	Regressions, listed separately and shown even when the objective won. Trading depth for area is your decision to make.
Rewrite	The proposal itself: the diff, and the Apply and Not now buttons.
What changed	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 maintain, including an honest note when the result is less readable than the original.
Tried and rejected	Ideas that were considered and turned down, with reasons. Carried into the next turn so a follow-up does not pay to reconsider them.

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

Synthesis estimates, not results from your own toolchain or device.
Resource counts will differ from Vivado/Quartus, and timing is not a
sign-off on your part. 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.