Module 2: Logic Synthesis · 2.2 Yosys in OpenLane

Running the Same Design Two Ways

Enough theory about the area-versus-delay trade. This article makes one happen and looks at the numbers: alu8 through synthesis twice, changing one config field between runs.

Run 1: area-optimised

Starting config, designs/alu8/config.json:

{
  "DESIGN_NAME": "alu8",
  "VERILOG_FILES": "dir::src/alu8.v",
  "CLOCK_PORT": "clk",
  "CLOCK_PERIOD": 10.0,
  "SYNTH_STRATEGY": "AREA 0"
}
openlane --flow Classic --run-tag alu8_area designs/alu8/config.json --to Synthesis

The synthesis log ends with a summary like this (illustrative, in the shape of a real Yosys stat plus OpenSTA summary, not a guaranteed literal output):

Yosys stat report:
  Number of cells:                146
  Chip area for module '\alu8':   1512.67

OpenSTA synthesis-stage timing:
  Startpoint: b[7]
  Endpoint:   result_reg[6]
  Path Group: clk
  Worst slack (MET):              5.75 ns

Run 2: delay-optimised

Change exactly one line and keep everything else, same RTL, same period, same I/O delays:

{
  "DESIGN_NAME": "alu8",
  "VERILOG_FILES": "dir::src/alu8.v",
  "CLOCK_PORT": "clk",
  "CLOCK_PERIOD": 10.0,
  "SYNTH_STRATEGY": "DELAY 1"
}
openlane --flow Classic --run-tag alu8_delay designs/alu8/config.json --to Synthesis
Yosys stat report:
  Number of cells:                189
  Chip area for module '\alu8':   1968.45

OpenSTA synthesis-stage timing:
  Startpoint: b[7]
  Endpoint:   result_reg[6]
  Path Group: clk
  Worst slack (MET):              7.42 ns

Side by side

Metric AREA 0 DELAY 1 Change
Cell count 146 189 +29%
Estimated chip area (µm²) 1512.67 1968.45 +30%
Worst slack +5.75 ns +7.42 ns +1.67 ns better

Same RTL, same clock target, same library. A roughly 30 percent larger netlist bought about 1.67 ns of margin. Neither row is the correct result. They are two points on the same trade curve, and which you would ship depends on the project’s constraints. If alu8 sits where area is tightly budgeted and 5.75 ns of slack against a 10 ns period is comfortable, AREA 0 is the better choice. If the block is on a tight critical path elsewhere in a larger chip, the extra 1.67 ns from DELAY 1 may be exactly the margin needed to survive the delay placement and routing will add later, a point the module returns to at the end of Section 2.4.

Production flows rarely settle on one strategy chosen once. It is common to sweep several SYNTH_STRATEGY values (OpenLane exposes a range from aggressive area strategies through several delay strategies), especially on a borderline design, and pick whichever result best balances the real area and timing budgets. And when comparing runs, hold everything else identical: a number that looks like a strategy effect is meaningless if the clock period, I/O delays or RTL also changed. Change one variable at a time.

Practice Exercise

A third engineer reruns alu8 with SYNTH_STRATEGY set to "AREA 2", a more aggressive area strategy, and reports 121 cells and a worst slack of +3.10 ns. Where does this sit relative to the two runs above, and is it strictly worse than AREA 0?

Solution

AREA 2 (121 cells, +3.10 ns) sits further along the same curve than AREA 0 (146 cells, +5.75 ns): smaller still, with even less margin. It is not strictly worse. It is a legitimate further point on the curve, better on area and worse on timing, just as DELAY 1 was better on timing and worse on area relative to AREA 0. Whether +3.10 ns is “worse” depends on whether that margin stays comfortably positive once real placement and wire delay are added, which is the question Section 2.4 takes up, and which a synthesis-stage number alone cannot answer.

You have now watched synthesis choose different real cells for the same logic. In the next article, Section 2.3 looks at what those cells contain, starting with the Liberty file, the timing menu synthesis reads to make these decisions.

← SYNTH_STRATEGY: Area Versus Delay The Liberty File →