Optimization
Optimize mode
Make a working design smaller or shallower, with a proof that it still behaves the same.
Optimize mode takes a design that already works and makes it cost less: fewer resources, or less logic depth, depending on what you ask for. What comes back is a rewrite of your source that you can still read and maintain, the measurements that show it is smaller, and a proof that it still does the same thing.
What comes back
Three things, and each one is there because the other two are not enough on their own.
| Part of the answer | What it is |
|---|---|
| A rewrite of your source | Readable, maintainable RTL in the same style as the original; not a flattened netlist. You have to live with this code afterwards, so it comes back as code. |
| Measurements | Before and after, on the same yardstick and for the device family you chose, so the improvement is a number rather than a claim. |
| A behaviour check | Evidence that the rewrite still does what the original did. A smaller design that is also a different design is not an optimization. |
Note
A synthesis tool optimises the netlist it builds from your Verilog, not the Verilog itself; its output is a wall of gates locked to one target and impossible to maintain. That is why this mode rewrites the source instead, and uses synthesis only to measure and to check.
The kinds of change it makes
The rewrites that pay off in RTL are unglamorous, and they are the ones an experienced engineer would reach for: sharing an expensive operator across branches that cannot happen at once, flattening a priority chain into a parallel one where the conditions really are exclusive, dropping registers and logic that no longer feed anything, narrowing datapaths that are wider than their range needs, and replacing expensive arithmetic with cheaper equivalents.
What you will not get is a clever trick you cannot follow. The rewrite has to survive your review as much as it has to survive the measurement, and a change nobody on your team can maintain next year is not a win.
What it is not allowed to do
The obvious way to make a design smaller is to make it do less. That risk is handled mechanically, not by asking nicely.
- The interface never changes. Port names, widths and directions stay exactly as they are, because everything that instantiates the module depends on them.
- No check, assertion or test is removed or weakened, and the change is examined for that independently of what the run reports.
- The testbench is not edited. It is the measuring instrument; if it has to change, the rewrite was not behaviour-preserving.
- No vendor primitives are hand-instantiated unless you asked for them. Trading portability for a number is your decision, not the run's.
- Nothing unrelated is reformatted or renamed. Every extra diff line is a line you have to review.
Two ways in
- 1
From an existing chat
Once a chat has produced code, an Optimize toggle appears next to the composer. It carries the module across for you and keeps the conversation going, so the run knows what the design is meant to do.
- 2
From a cold start
Pick the Optimize tab on the New chat screen and upload the project as a zip. Include the testbench if you have one; it is not required for the proof, and it is what makes a fallback possible when the proof cannot be run.
Nothing lands until you accept it
Like Debug mode, your files are left alone and the result is a proposal. You read the diff, look at the numbers, and decide. See Applying a proposed fix; the same card and the same apply behaviour are used, with wording that reflects that this is a choice rather than a repair.
Requirements and limits
| Requirement | Detail |
|---|---|
| Language | Verilog and SystemVerilog. VHDL is not supported in Optimize mode. |
| Mode | Agent mode, for the same reason as Debug; the pipeline flow cannot run this. |
| A working design | This mode preserves behaviour, so it starts from behaviour you are happy with. If the design is wrong, debug it first. |
| Credit | Optimize runs ask for the same higher minimum balance as Debug, because measuring the original design uses real work before a single change is tried. |
| Tools | An optimize run selects its own tools; the Tools switches are shown disabled with the reason. |
These are estimates, not vendor results
Every number this mode produces is a synthesis estimate. Cell and LUT counts will differ from what Vivado or Quartus reports for the same design, logic depth is a proxy for timing pressure rather than a timing report, and there is no power analysis at all. An improvement here is a strong signal; confirming a timing win still needs your own toolchain.