Optimization

Reading the numbers

What cells, LUTs, flip-flops and logic depth mean here, and what they do not mean.

The result opens with one line, such as LUTs 412 → 337 (−18.2%), and a table behind it. This page is about what those numbers are measuring, and about the several things they are not measuring.

What each metric is

MetricWhat it counts
CellsEvery cell in the synthesised netlist. The broadest measure of how much design there is.
LUTsLookup tables for the chosen family. This is usually the number that decides whether a design fits.
Flip-flopsRegisters inferred. A drop here often means a pipeline stage or a holding register went away, which is worth checking against the trade-offs.
Hard blocksDSP slices, block RAM and other dedicated resources; these are scarce in a different way from LUTs.
Wire bitsTotal width of the nets. A rough proxy for routing pressure.
Memory bitsInferred storage. A large change here usually means memory moved between registers and RAM.
Logic depthThe longest chain of logic between registers. A proxy for timing pressure; see below.

LUTs 412 → 337 (−18.2%) · xilinx

MetricBeforeAfterChange
LUTs412337−18.2%
Flip-flops96960.0%
Cells531441−16.9%
Logic depth1417+21.4%
Before and after, with the objective's metric highlighted and any regression shown alongside.

Reading the table

The change column is signed the way you would expect: a shrink reads negative. Whether that direction is good is a separate question, and it is not the same question for every metric, so the colouring reflects improvement rather than sign.

  • The primary row is the metric your objective is about. It is what the verdict is decided on.
  • Regressions are always listed, even when the objective won. Cutting LUTs by a fifth while adding half again as much logic depth is a real result and you have to be able to see it and turn it down.
  • A missing measurement reads as unavailable, never as zero. A metric silently reported as zero would look like a hundred percent improvement, which is the worst possible failure for a feature whose product is a number.

Why the two measurements are comparable

Before and after are measured with an identical script, against the same target, through the same top module. Two details make that work:

  • The design is flattened before it is counted. Module boundaries hide exactly the resource sharing an optimization buys, and an unflattened count also emits per-module figures that cannot be added up without counting things twice.
  • The top module is pinned across the run while the source file list is not; splitting one module into two files is a legitimate rewrite that leaves the design unchanged.

What these numbers are not

Heads up

These are Yosys estimates, not vendor tool results. Cell and LUT counts will differ from what Vivado or Quartus reports for the same design, sometimes substantially, because the mapping and the optimisation passes are not the same.

  • Logic depth is not a timing report. It counts levels of logic; it knows nothing about routing delay, clock skew or your constraints. A depth reduction is a good reason to expect a timing improvement and it is not a measurement of one.
  • There is no fmax figure, and none is implied. A run will tell you that depth fell and that confirming a frequency win needs your own toolchain.
  • There is no power analysis. Fewer cells often means less power; that is an expectation, not a result.

The right way to use this is as a fast, comparable signal: it tells you whether a rewrite is worth taking to your real flow, which is a question that used to cost a full synthesis run to answer.