The ECO Flow,
Explained Simply

By Tabish Iqbal · Published 25 Sept 2026

How to use this guide

Start anywhere, but read part one first

Each section opens with the answer in one line, in a blue card like the one above. Then the explanation. Then a figure, if the idea is easier to see than to read. Then two cards side by side: what you actually do on a real block, and the mistake that catches people. Then one line telling you what to check before you move on.

Every command in this guide is a command the tool really has, and every option really exists. Where a number is an example rather than a measurement, it says so. Where a figure shows layout, it carries a small table of what the technique costs you. A picture of a fix teaches less than a picture of a fix with its price on it.

What you need before you start

A design that is placed and routed, with its clock trees built. Parasitics that carry location information. And the two files that describe the layout: Library Exchange Format (LEF) for the shape of every cell, and Design Exchange Format (DEF) for where everything sits. Part one says where each of those comes from and how to check it.

You do not need to have run an ECO before. You do need to know roughly what setup and hold mean, and to be comfortable reading a Tcl command with options on it. Everything else is explained as it comes up.

The six marks in the margin

Work the numbers. The numbers are worked in front of you, so you can put your own in their place.

Do this. The thing to do. It also marks every line of every checklist.

Do not do this. The thing not to do. It never appears on its own, always opposite a green check, so you see the fix and not just the failure.

The insight. The one sentence in a section worth carrying away. There is at most one per section.

Think about it. A question for you. The answer is in the next paragraph or two, so stop and have a go first.

Hands on. Something to type and run, rather than something to read.

Contents

1A repair, not a rebuild

Imagine a circuit board that is built, soldered and tested. Two resistors are the wrong value. You do not start the board again. You lift those two parts, put the right ones in, and test it again. That is an ECO.

A chip is the same, with one difference. The board is in front of you, and the chip is a database. So the repair has to be written down as a list of instructions, and handed to the tool that can actually move things.

By the time anyone says the word ECO, the design is placed and routed, the clock trees are built, and the parasitics have been extracted. Timing analysis has run, and it has found something wrong. Maybe nine paths fail setup. Maybe a net has a transition time above its limit. Somebody has to fix those without disturbing the other four million cells.

PrimeTime is where the problem is found, so PrimeTime is where the fix is worked out. But PrimeTime does not own the layout. It can tell you that a buffer should go in at a particular place, and it can write that down. Putting the buffer there is somebody else's job.

An ECO is a repair to a finished design, so the smallest change that works is always the best change.

That sentence is the whole discipline. Every option you are about to meet exists to make the change smaller, or to make its side effects smaller. When you are choosing between two fixes, the one that disturbs less of the layout is almost always the one to take.

Part 1 · What an ECO is  ·  fix_eco_drc, fix_eco_timing, fix_eco_power, write_changes

2The three commands

Everything in this guide is those four commands and their options. Learn what each one is allowed to touch and you have most of it.

Notice that none of the three can change what the chip does. They size cells, they add buffers, they take buffers out. A replacement cell always has the same logical function as the cell it replaces. The logic of your design is not on the table.

Notice too that only one command produces a file. The fixing commands change the design inside the PrimeTime session. Until you run write_changes, nothing you have done can reach the layout.

Part 1 · The commands  ·  fix_eco_drc, fix_eco_timing, fix_eco_power, write_changes

3Logic only, or physically aware

A buffer takes up room. If the tool does not know where there is room, it can only tell you that a buffer would help. Somebody then has to find a place for it, and where it ends up changes the delay the buffer actually adds. Sometimes it changes it enough that the fix stops working.

What it costs

What physically aware mode buys you

• Cells and buffers only go where there is actually room.
• The change list carries a location for every change.
• A cell that gets bigger does not have to move far.
• Buffer insertion takes account of free space, density and wire delay.
• Buffers can be put on the route itself, not just at a pin.
• The layout is disturbed less, so the loop closes in fewer turns.

It needs a PrimeTime-ADV license, and it needs you to prepare several files. Both are worth it.

The usual physical input is LEF for the shape of every cell and DEF for where everything sits. There is a second route. If the design is in IC Compiler II, the tool can read that data directly through set_eco_options -physical_icc2_lib and -physical_icc2_blocks, and you never write LEF and DEF at all.

Part 1 · Physically aware ECO  ·  set_eco_options, check_eco, write_changes -format icctcl

4Before you fix anything

Skip any of these and the fixing commands still run. They just run badly, or slowly, or they quietly do less than you asked for. This is the part of the flow that is easy to hurry and expensive to get wrong.

Here is the whole sequence. Most of it you will already have in your analysis script.

read_verilog   design.v.gz
link_design
read_parasitics design.spef.gz
read_sdc        design.sdc

set_app_var timing_save_pin_arrival_and_slack true
update_timing -full

set_app_var read_parasitics_load_locations true
set_app_var eco_allow_filler_cells_as_open_sites true

set_eco_options \
  -physical_tech_lib_path $tech_lef \
  -physical_lib_path      $lef_files \
  -physical_design_path   design.def.gz \
  -log_file               lef_def.log

report_eco_options
check_eco

set_eco_options takes more than the four options above. These are the ones you will reach for:

The last row is worth knowing early. If your design is in IC Compiler II, you can point the tool straight at that data with -physical_icc2_lib and -physical_icc2_blocks. You do not have to write out LEF and DEF first.

Why step two matters

timing_save_pin_arrival_and_slack tells the tool to keep the arrival time and the slack at every pin. The fixing commands want those numbers. If they are not there, the commands work them out again, which is a lot of work for an answer you already had.

Why check_eco matters

check_eco reads your LEF and DEF files and tells you what is missing, incomplete or strange. Fix what it reports and run it again. Every minute here saves an hour of wondering why the tool refuses to place anything.

Part 1 · Setting up  ·  set_eco_options, report_eco_options, reset_eco_options, check_eco

5What you are allowed to touch

On a real chip, parts of the design are already signed off, hand-crafted, or owned by somebody else. You have to be able to say "not this". These are the commands that say it.

How the per-block bans stack up

A ban applies downwards through the hierarchy. If you ban a set of cells at the top, every block below inherits that ban. A ban applied lower down replaces the one above it completely. It does not add to it.

These two lines ban high threshold voltage cells everywhere, except inside SLOWBLK, where low threshold voltage cells are banned instead.

set_target_library_subset -top -dont_use */*HVT*
set_target_library_subset -objects {SLOWBLK} -dont_use */*LVT*

An empty list, written -dont_use {}, blocks whatever came from above and bans nothing. These bans apply only to the fix_eco_* commands, and they beat any -buffer_list you give. They also apply only to the logic being optimised, so logic the tool is not touching is unaffected.

If a cell is banned by dont_use, can you still put it in by hand?

Yes. The bans restrict the fix_eco_* commands. They do not stop you running insert_buffer or size_cell yourself, and they do not affect get_alternative_lib_cells or report_alternative_lib_cells. The tool warns you and then does what you asked.

Power management cells are protected by default

Level shifters, isolation cells, retention registers and always-on cells are not considered for resizing unless you say so. That default is there to protect you. Turn it off only when you know why you need to.

set_app_var eco_allow_sizing_with_lib_cell_attributes "is_level_shifter"

Part 1 · Restrictions  ·  set_dont_touch, set_size_only, set_dont_touch_network, set_dont_use, set_target_library_subset

6The order, and why it is the order

Two facts decide everything. Design rule fixing has the highest priority, so it is allowed to move setup and hold slack. And setup fixing is allowed to create hold violations, while hold fixing is not allowed to create setup violations.

What setup and hold actually measure

Before the rest of this part will make sense, one picture. A clock edge launches the data. The next clock edge captures it. Two checks sit around those edges, and every number in this guide is a distance measured against one of them.

Those two windows sit at opposite ends of the clock period. That is the whole reason the order of fixing is not a matter of taste, and figure 7 shows why.

Setup is allowed to break hold because setup is the harder problem to solve, and hold is the easier one to clean up afterwards.

To make a setup path faster you need a bigger cell, a shorter wire or a different route. Your options are limited and they all cost something. To make a hold path slower you add delay, and adding delay is easy. So the flow spends its freedom where it is scarce, and pays for it where it is cheap.

When to break the order up

If a step produces a very large number of changes, those changes can disturb the routing and the legalisation in the layout tool. When that happens, do the steps one at a time, in separate passes, and start with the step that produces the most changes.

When timing matters more than design rules

fix_eco_timing -ignore_drc puts timing first. The command then ignores max_transition, max_capacitance and max_fanout, and it may make them worse. Without that option, fix_eco_timing will not fix a timing violation on a path that already has a design rule violation.

Part 2 · The order of fixing  ·  fix_eco_power, fix_eco_drc, fix_eco_timing, -ignore_drc

7Fixing design rules

A design rule violation is not a timing failure. It is a statement that some signal is outside the range the library was characterised over. Once a signal is outside that range, the delay numbers for it are guesswork. That is why these get fixed first.

The command fixes what these reports complain about:

• report_constraint -max_capacitance
• report_constraint -max_transition
• report_constraint -max_fanout
• report_noise
• report_si_bottleneck
• report_cell_em_violation

By default it does not consider timing at all. It will fix your transition time and let the slack fall where it falls. If you want it to respect timing, give it margins with set_eco_options -drc_setup_margin and -drc_hold_margin. The command then leaves that much slack in hand while it fixes the design rule.

The simplest possible call, and then a fuller one.

fix_eco_drc -type max_transition -methods {size_cell}

fix_eco_drc -type noise \
  -methods {size_cell insert_buffer} \
  -buffer_list {BUFX1 BUFX2 BUFX3} \
  -physical_mode open_site

It goes round more than once

The command runs several fixing passes by itself. It keeps going until every violation is fixed, or until it judges that another pass is not worth the runtime. That judgement uses the current quality of results and the options you set.

When it stops, it tells you how many violations are left and how many it could not fix. -verbose tells you why.

Part 2 · Design rule fixing  ·  fix_eco_drc, -type, -methods, -buffer_list, -verbose

8Crosstalk and delta delay

Two wires running side by side are a small capacitor. When one of them switches, some of that edge appears on the other. If both switch the same way the victim gets faster. If they switch opposite ways it gets slower. Either way the delay is not what the library said.

There is no constraint on delta delay, so there is no delta delay slack, so you must supply the threshold yourself.

Every other fixing type has a limit to work against. Transition time has max_transition. Setup has the clock period. Delta delay has nothing. So -delta_delay_threshold is not optional. Give it a positive number greater than zero, and the same number is used for both the speed-ups and the slow-downs.

Look before you fix. The bottleneck report shows you which nets the command will go after.

report_si_bottleneck -cost_type delta_delay \
  -min -max -slack_lesser_than 0.0 -all_nets

fix_eco_drc -type delta_delay -verbose \
  -delta_delay_threshold 0.05 \
  -methods {size_cell insert_buffer} \
  -buffer_list {BUFX1 BUFX2 BUFX3} \
  -physical_mode open_site

The cost column in that report is the absolute value of the delta delay. A net sped up by 0.4 ns therefore ranks alongside a net slowed by 0.4 ns. Under distributed multi-scenario analysis, or DMSA, the report merges every scenario into one list.

Which nets get considered

By default, only nets on paths that already have negative slack. -slack_lesser_than changes that. A positive value takes in paths that pass but not by much, which buys you margin. A negative value takes in fewer paths, which does less work.

This feature needs a PrimeTime-ADV-PLUS license.

Part 2 · Crosstalk  ·  fix_eco_drc -type delta_delay, -delta_delay_threshold, -slack_lesser_than, report_si_bottleneck

9Cell electromigration

This is not a timing problem and it is not a noise problem. It is a reliability problem, and it shows up as a design rule violation because that is the only place to put it.

PrimePower does the analysis. PrimeTime does the fixing.

set_app_var power_enable_analysis true
set_app_var power_enable_em_analysis true
update_power

report_cell_em_violation
fix_eco_drc -type cell_em -methods {size_cell insert_buffer}

PrimePower finds the high-risk cells using the library data, the design data and the switching activity. If physical data is loaded it uses that too.

One pass means one pass. If violations remain, run update_power again and then fix_eco_drc -type cell_em again. Three rounds of fixing is three update_power calls, and update_power is not cheap.

This needs a PrimePower license and a PrimeTime-ADV-PLUS license.

Part 2 · Electromigration  ·  fix_eco_drc -type cell_em, update_power, report_cell_em_violation

10Fixing setup

You have to name the type every single time. There is no default, because setup and hold are different problems that happen to share a command.

The two calls you will use most.

fix_eco_timing -type setup

fix_eco_timing -type setup \
  -methods {size_cell insert_buffer} \
  -buffer_list {BUFX2 BUFX4 BUFX8} \
  -physical_mode open_site

Load buffering

A weak driver with a load far away is slow. The tool adds a buffer part way along, so the driver only has to drive as far as the buffer, as figure 11 shows. In physically aware mode it picks the site itself, and it respects placement blockages while it does.

What it costs

Load shielding

Sometimes the driver is fine and the problem is company. A net with one critical load and three loads nobody cares about makes the critical load wait for all four. The tool puts a buffer in front of the ones that do not matter, and the critical load gets a net of its own. That is figure 12.

What it costs

Side-load cell sizing

There is a third trick. size_cell_side_load first makes the cells hanging off a net smaller, which takes capacitance off it. Then it makes the cell in the critical path bigger. You can see both moves in figure 13. It only works with -type setup and -cell_type combinational.

If you use sizing and buffering separately, size first and buffer afterwards. Sizing is the cheaper change, so let it do what it can before you start adding cells.

Setup fixing is allowed to break hold, so expect new hold violations and plan the hold pass that follows.

Part 2 · Setup fixing  ·  fix_eco_timing -type setup, -methods, size_cell_side_load, -cell_type

11Fixing hold

Hold fixing is the easy direction. Adding delay is simple. The difficulty is adding the right amount, because too much delay turns a hold violation into a setup violation.

Those two numbers belong to two different paths. The cell you are about to insert sits on a short path that fails hold by 2 ps. It also sits on a long path that passes setup by 6 ps. Adding delay at that point helps the short path and hurts the long one, by exactly the same amount. That is the whole reason hold fixing has a limit, and figure 15 draws it.

Work it through. The violation is 2 ps. The buffer adds 7 ps, so you end up 5 ps the right side of the hold check and 1 ps the wrong side of the setup check. The load cell adds 3 ps, so you are 1 ps the right side of hold with 3 ps of setup margin left. You needed 2 ps and the buffer gave you 7.

A load cell is a buffer without the output. It slows the net down by loading it, and it costs less area because it only has one pin.

You can use buffer cells and inverter cells as load cells too. When you do, their outputs are left unconnected. A dedicated load cell is smaller and easier to place, and figure 16 lists the attributes it reports.

What it costs

Two ways to run it. Split by slack, or let the tool choose.

# small violations get load cells, the rest get buffers
fix_eco_timing -type hold -methods insert_buffer \
  -load_cell_list $clist \
  -slack_lesser_than 0.000 -slack_greater_than -0.003
fix_eco_timing -type hold -methods insert_buffer -buffer_list $bflist

# or hand it both lists and let it pick per violation
fix_eco_timing -type hold -methods insert_buffer \
  -load_cell_list $clist -buffer_list $bflist

In the change list, a load cell comes out as three commands: create the cell, connect its pin to the net, and put it somewhere.

create_cell U_LOAD_CAP_CELL_1 CLOAD1
connect_net n231 [get_pins {U_LOAD_CAP_CELL_1/A}]
set_cell_location -coordinates {150.00 30.60} -orientation N

Part 2 · Hold fixing  ·  fix_eco_timing -type hold, -load_cell_list, -slack_lesser_than, -slack_greater_than

12Going into the clock network

This is the most powerful thing in the guide and the most dangerous. One buffer in the right place fixes eight registers. The same buffer in the wrong place breaks eight others.

Before you read the physical data, turn on clock data:

set_eco_options -physical_enable_clock_data ...

Then the two commands take these options:

fix_eco_timing \
  -type setup | hold \
  -cell_type clock_network \
  [-clock_fixes_per_change integer] \
  [-clock_max_level_from_reg integer] \
  [-methods {size_cell | insert_buffer | insert_inverter_pair}]

fix_eco_drc \
  -type max_transition | max_capacitance | max_fanout \
  -cell_type clock_network \
  [-methods {size_cell | insert_buffer | insert_inverter_pair}]

The two restricting options, in plain terms

-clock_fixes_per_change 4 says every change must be worth at least four fixed violations. Set it higher and you get fewer changes, and they happen higher up the tree, closer to the source. The default is 1.

-clock_max_level_from_reg 6 says no change may be more than six buffers away from a register clock pin. Set it to 1 and only the buffer directly driving the register may change. Set it to 0 and there is no limit, which is also the default.

Do all your data path fixing first, then bring the clock network in for what is left. Every clock change moves skew, and skew moves paths you were not looking at.

fix_eco_timing -type setup -cell_type combinational ...
...
fix_eco_timing -type setup -cell_type clock_network ...

There is one more variable worth knowing. If a clock signal is used as data somewhere in your design, hold fixing on those paths is off until you turn it on.

set_app_var eco_enable_fixing_clock_used_as_data true

Part 2 · Clock network fixing  ·  -cell_type clock_network, -clock_fixes_per_change, -clock_max_level_from_reg, -physical_enable_clock_data

13Making one path worse on purpose

By default, no endpoint is allowed to get worse. That rule is safe, and it sometimes blocks a change that would help four registers and hurt one.

Why would you ever want a fix that makes one path worse?

Because you are not paid on the worst path alone. Total negative slack, or TNS, is the sum of every violation. Worst negative slack, or WNS, is the single worst one. A change that takes TNS from -13 to -11 while pushing one endpoint from -3 to -4 has done real work, even though something got worse.

The safety is that WNS is still capped. It either stays where it was, or it goes no further than the limit you name. Figure 18 works one real example through all three settings.

Check the arithmetic yourself. Panel A adds up to -3 -2 -4 -2 -2, which is -13. Panel B is -4 -1 -4 -1 -1, which is -11. Panel C is -5 +0 -4 +0 +0, which is -9. Each panel fixes three endpoints and pays for it at one.

fix_eco_timing -type hold \
  -cell_type clock_network \
  -methods {insert_buffer} \
  -buffer_list {buf1 buf2 buf3} \
  -target_violation_type tns \
  -wns_limit -5

-target_violation_type endpoint is the default and means the same as leaving the option out. You can set -wns_limit above or below the current WNS, and the tool respects it either way. TNS targeting needs a PrimeTime-ADV license.

Part 2 · TNS-driven fixing  ·  -target_violation_type, -wns_limit

14Where a new cell is allowed to go

This one option decides how much your layout is going to move, so it is the option to think hardest about.

The first two are the ones you will use every day, and figure 19 shows what the choice between them costs.

What it costs

Filler cells can become free space

Filler cells fill the gaps between real cells. They do nothing. If you let the tool treat them as free space, it can remove one and use its site.

set_app_var eco_allow_filler_cells_as_open_sites true

The tool learns which cells are fillers from set_eco_options -filler_cell_names. Without that list it cannot tell a filler from a real cell, and the variable above has nothing to act on. Figure 20 shows what the difference is worth.

What it costs

How far the tool will look

When the tool wants to put a buffer somewhere and that place is full, it looks outwards for a free site. How far it looks is set by one variable, counted in site rows, and the default is eight. Figure 21 draws that reach.

set_app_var eco_insert_buffer_search_distance_in_site_rows 8

What it costs

Voltage areas and blockages

If your design has more than one supply, the tool has to know which region runs on which one. It also has to know where nothing may be placed. Both come from a physical constraint file.

What it costs

set_eco_options \
  -physical_design_path    TOP.def \
  -physical_constraint_file TOP_phys_cons.tcl
set_eco_options \
  -physical_design_path    BLOCK.def \
  -physical_constraint_file BLOCK_phys_cons.tcl

Get this wrong and the fix comes back as an electrical rule check violation rather than a timing one, which is a much slower thing to debug.

Part 2 · Placement modes  ·  -physical_mode, eco_allow_filler_cells_as_open_sites, eco_insert_buffer_search_distance_in_site_rows

15Cells that are two rows tall

A double-height cell straddles a supply rail. It can only go in rows that were laid out for it. The tool has no way to know which rows those are unless the names line up.

What it costs

Physically aware sizing changes cell widths, never heights. A cell that gets stronger gets wider, and it never grows into the row above.

You can switch the feature on and off between fixing calls, which is how you do the single-height cells first and the tall ones after.

set_eco_options -keep_site_names {2Tunit}
report_eco_options
check_eco

set_app_var eco_physical_match_site_row_names false
fix_eco_timing -type setup -physical_mode open_site -verbose

set_app_var eco_physical_match_site_row_names true
fix_eco_timing -type setup -physical_mode open_site -verbose

Part 2 · Site-aware fixing  ·  eco_physical_match_site_row_names, -keep_site_names, -convert_sites

16When it will not fix

You have to ask for the reasons twice. Once to set how many endpoints get reported, and once to say where the report should go.

set_app_var eco_report_unfixed_reason_max_endpoints 50
fix_eco_timing -type setup -estimate_unfixable_reasons

-estimate_unfixable_reasons works on fix_eco_timing only. It changes nothing in the design. It just tells you what would happen, and it is faster than fixing.

There are nine reasons the tool can give you. Figure 24 sorts them by what you can do about each one.

The nine codes, word for word

A - There are available library cells outside area limit
B - Delay improvement is too small to fix the violation
C - The violation is in clock network
I - Buffer insertion with given library cells cannot fix the violation
S - Cell sizing with alternative library cells cannot fix the violation
T - Timing margin is too tight to fix the violation
U - UPF restricts fixing the violation
V - Net or cell is invalid or has dont_touch attribute
W - Fixing the violation might degrade DRC violations

A pile of I and S codes means your buffer list is wrong. A pile of W codes means you have a design rule problem you have not fixed yet.

You can restrict the estimate to particular paths with -from and -to, the same way you would restrict a timing report. Estimation works with every other option the command takes.

fix_eco_timing -type setup -estimate_unfixable_reasons \
  -from I_ORCA_TOP/I_PCI_CORE/pad_en_reg/Q -to pad[1]

The same idea for power

Power recovery has no violations, so the wording is different. Cells are "unusable" rather than violations being "unfixable".

set_app_var eco_power_report_max_unusable_cells 100
fix_eco_power -verbose

B - Power benefit is too small
L - Physical constraints restrict sizing
S - Cell has no alternate library cell with better power
T - Sizing cell might degrade timing
U - UPF restrictions prevent sizing
V - Cell is invalid or has dont_touch attribute
W - Sizing cell might degrade DRC
X - Cell is unusable for ECO
Z - Cell is sized

Part 2 · Unfixable reasons  ·  -estimate_unfixable_reasons, -verbose, -unfixable_reasons_prefix, eco_report_unfixed_reason_max_endpoints

PnR Flow Mentor GuideEight chapters, library setup through to stream-out.

17Giving power back

Everything before this step made the design bigger and hungrier. This is where you get some of that back, and it is free in the sense that the tool undoes anything that costs you timing.

What it costs

The five ways it can choose

• Smallest area. This is the default.
• Smallest value of a numeric library cell attribute you define, through -power_attribute.
• Best name or attribute string from a list you give, through -pattern_priority.
• Least switching, leakage or total power measured by PrimePower, through -power_mode.
• Remove buffers, through -methods {remove_buffer}.

You can only use one of these at a time. Run the command more than once with different settings if you want more than one.

Five calls, one per method.

fix_eco_power
fix_eco_power -pattern_priority {HVT MVT LVT}
fix_eco_power -pba_mode path
fix_eco_power -pattern_priority {HVT LVT} -pba_mode exhaustive
fix_eco_power -methods {remove_buffer}

How it actually works

It is a loop. The tool makes the changes it wants, then checks the design for new or worsened timing and design rule violations. Where it finds one, it backs the change out. Then it looks for more changes, checks again, and keeps going until further progress is not worth the cost.

A cell is only ever replaced when all three of these hold:

1. The change does not create or worsen any timing or design rule violation.
2. The replacement has the same logical function and passes any restriction you set with eco_alternative_cell_attribute_restrictions or eco_alternative_cell_instance_based_restrictions.
3. The replacement is really preferred. That means less area, a smaller attribute value, a higher priority name, or less power.

Swapping threshold voltage

The commonest use of this command is swapping a fast, leaky cell for a slow, tight one where there is slack to pay for it. That works on the cell name, which has to be a variable part and then a fixed part.

List the lowest-power cells first in -pattern_priority. Get the order backwards and you will swap every cell the wrong way.

If your library does not follow a naming convention, define a string attribute on each library cell instead and give the attribute values in priority order.

define_user_attribute vt_swap_priority -type string -class lib_cell
set_user_attribute -class lib_cell lib/INV1XH vt_swap_priority INV1X_best
set_user_attribute -class lib_cell lib/INV1XN vt_swap_priority INV1X_ok
set_user_attribute -class lib_cell lib/INV1X  vt_swap_priority INV1X_worst

fix_eco_power -pattern_priority {best ok worst} \
  -attribute vt_swap_priority

Leakage during setup fixing

Making cells bigger for setup makes leakage worse. By default fix_eco_timing minimises the area it adds and ignores leakage entirely. If leakage matters more than area on your project, give it a leakage attribute to minimise instead.

define_user_attribute leak_attr -type float -class lib_cell
set_user_attribute -class lib_cell \
  [get_lib_cells LIB_H/INV1X_HVT] leak_attr 1.0
set_user_attribute -class lib_cell \
  [get_lib_cells LIB_L/INV1X_LVT] leak_attr 10.0

fix_eco_timing -power_attribute leak_attr

Using real power numbers

-power_mode takes dynamic, leakage or total, and uses data from PrimePower rather than a proxy like area. With total, the tool picks whichever action saves most power at each place in the design.

Where slack is tight it has to choose. High switching activity favours making the cell smaller, because that cuts switching power. Low switching activity favours raising the threshold voltage, because that cuts leakage. Where there is plenty of slack it does both.

-power_mode cannot be combined with -power_attribute or -pattern_priority.

The whole flow for total power recovery in a single session.

restore_session Session1
set_app_var power_enable_analysis true
set_app_var power_clock_network_include_register_clock_pin_power false
read_saif  activity.saif
update_power
report_power

fix_eco_power -power_mode total
report_power

Under DMSA

Dynamic power data comes from exactly one scenario, and leakage data from exactly one scenario. You name them. Pick the scenario with the worst dynamic power and the one with the worst leakage. They can be the same scenario or two different ones. Every scenario is still checked for timing and design rules.

fix_eco_power -power_mode total \
  -leakage_scenario S1 \
  -dynamic_scenario S3

Leaving the input and output paths alone

-start_end_type reg_to_reg restricts recovery to paths that go from a register to a register. It needs path-based analysis, and reg_to_reg is the only value this command accepts.

fix_eco_power -start_end_type reg_to_reg -pba_mode exhaustive

A cell counts as internal when no path at all, constrained or not, reaches it from a port. Case analysis and disabled arcs are taken into account. Under DMSA, a cell is left alone if it reaches a port in any scenario, and it turns up with reason code V.

Part 2 · Power recovery  ·  fix_eco_power, -pattern_priority, -power_attribute, -power_mode, -start_end_type, report_power

18Teaching it to be faster

Power recovery is slow because the tool has to look at the timing, the topology and the power around every candidate cell. If it has seen the same situation before, it can skip that work.

set_app_var training_data_directory ./train_dir

That is the whole setup. The first run gains nothing, because there is no training data yet, and it writes a file when it finishes. Every run after that reads every file in the directory and writes a new one. Figure 27 reads the coverage the run reports back.

The saved decisions include the decisions not to replace a cell, which is where most of the analysis time goes.

Training coverage is trained cells divided by eligible cells. In this report that is 4 106 599 over 4 788 129, which is 85 per cent. The remaining 15 per cent were analysed in full, exactly as they would have been with no training data at all. The run took 998 seconds against 4 280 seconds for the untrained one.

When it helps and when it does not

The best benefit comes from coverage between 90 and 100 per cent. Below 50 per cent you will see very little.

Why you may as well leave it on

It cannot hurt. If the tool cannot use the data it ignores it and does the analysis properly, and it still records what it learns for next time. The overhead of reading and writing the files is negligible, and the quality of the result is the same either way.

This feature needs a PrimeTime-ADV-PLUS license.

To cover the whole design cycle, save a session at each stage and train from each one on a separate host.

update_timing
save_session after_update
fix_eco_drc
save_session after_drc_fix
fix_eco_timing -type setup
save_session after_setup_fix
fix_eco_timing -type hold
save_session after_hold_fix

# then on four hosts, each restoring one session
set_app_var training_data_directory ./all_training_data
restore_session after_setup_fix
fix_eco_power

Training from your own script

If you have written your own power optimisation script, the tool can learn from that instead.

record_training_data
source my_eco_changes.tcl
write_training_data -output my_training.td

# later
fix_eco_power -training_data my_training.td

The tool does not judge your script. It accepts the changes as good and records the conditions around them. If your script was wrong, it has learned to be wrong faster.

Part 2 · Machine learning  ·  training_data_directory, -training_data, record_training_data, write_training_data

19Blocks that appear more than once

A multiply instantiated module, or MIM, is one design used in several places with the same physical implementation. You cannot change one copy without changing the others, because there is only one layout.

Turn it on, optionally group the instances, fix, then write.

set_app_var eco_enable_mim true

set_eco_options -mim_group {CPU1 CPU2}
set_eco_options -mim_group {CPU3 CPU4}
report_eco_mim_instances

fix_eco_timing -type setup ...
write_changes -format icctcl -output pteco.tcl

That produces three files. pteco.tcl for the top level, CPU_pteco.tcl for CPU1 and CPU2, and CPU_0_pteco.tcl for CPU3 and CPU4. By default, without the grouping, all the changes in the CPU module go into one file.

Grouping costs runtime and memory, because each group is analysed on its own. Use it only when the instances really do need different changes.

How a group is recognised

In physically aware fixing, instances belong together when they share a DEF file. In logic-only fixing, when they share a parasitics file, as set by the -path option of read_parasitics.

Two more controls. eco_mim_preserve says whether groups are kept when eco_enable_mim is true. And the -all_mim_instances option of size_cell, insert_buffer and remove_buffer overrides eco_mim_preserve false.

One ECO on a module used four times is four changes to the netlist and one change to the layout. Count both when you are judging how big the ECO is.

Part 2 · Repeated modules  ·  eco_enable_mim, -mim_group, eco_mim_preserve, -all_mim_instances, report_eco_mim_instances

20The change list

Nothing you do inside PrimeTime reaches the design until you write this file. It is the only output of the whole exercise.

Only the eco format can be read back into PrimeTime, and only icctcl and aprtcl carry the placement locations.

A physically aware change list looks like this. Notice that every line that adds something carries a coordinate.

size_cell U1 AND2X
insert_buffer U2/Z BUF1X -location {212.3 753.2}
add_buffer_on_route net1 BUF2X -location {215.0 853.2} -no_legalize

Two libraries with the same file name

If you have two libraries whose files are named the same, the tool needs to know which one a cell came from. Two variables control that, and both are false by default.

• eco_write_changes_prepend_libname_to_libcell
• eco_write_changes_prepend_libfile_to_libcell

They affect every change list format.

Part 3 · Change lists  ·  write_changes, -format, -output

21Replaying changes

This is how a change made by one person on one block ends up in somebody else's top-level run, possibly on a different version of the tool.

The recommended flow for replaying in PrimeTime.

# in the original session
write_changes -format eco -output my_changes

# in a new or restored session
restore_session ...
set_eco_options ...
check_eco
read_eco_changes my_changes

# assess, fix more if you need to, then write for implementation
write_changes -format icctcl new_change_list

The point of the middle step is that you can look at the result before you commit to it. Assess it, run more ECO commands if it needs them, and only then write the file the layout tool will run.

From a block to the top

In a hierarchical flow, blocks are fixed separately and then assembled. The block writes its changes, and the top level reads them in against the module name.

# at the block level
write_changes -format eco -output changesBlkA

# at the top level
read_eco_changes -design_name BlkA changesBlkA

The name is the Verilog module name of the block. For a repeated module it can be the reference name, and then the changes go to every instance in the group.

Different teams can fix different blocks, on different versions of the tool, and the top level can still put the result together.

Part 3 · Replaying changes  ·  read_eco_changes, -design_name, write_changes -format eco

22Handing over to a third-party tool

The name is short for automatic place and route. Anything not listed below comes out the same as it would in the IC Compiler II format.

A single location is a buffer. Two locations on one line is an inverter pair, and the two coordinates are where each inverter goes.

The file header carries a version string, and the only value it can have at the moment is 1.0. Whoever writes the parser should check it, so that a later change to the syntax fails loudly rather than quietly.

# aprtcl_file_syntax_version : 1.0

Reading a buffer tree out of the file

The order of the insertions and the list of load pins on each one together rebuild the tree. Read them in order and the shape comes out.

current_instance
current_instance {blk/subblk3}
insert_buffer -on_route BUFFD4 \
  -new_net_names {net1} -new_cell_names {BUF1} \
  -location {x1 y1} -route_cut_location {x1' y1'} \
  {sink1/I sink2/I sink3/I sink4/I}
insert_buffer -on_route BUFFD2 \
  -new_net_names {net2} -new_cell_names {BUF2} \
  -location {x2 y2} -route_cut_location {x2' y2'} \
  {sink1/I sink2/I sink3/I}
create_cell {U_LOAD_CAP_CELL_1} {CLOAD1_LVT} \
  -location {150.6320 61.8640} -orientation N
connect_net {design_ack_signal} {U_LOAD_CAP_CELL_1}

Part 3 · Third-party handover  ·  write_changes -format aprtcl, -on_route, -route_cut_location, -inverter_pair

23Implementing in Synopsys tools

This is the bottom half of the loop from section 1, written out as commands rather than as a picture.

1. In PrimeTime, write_changes -format icctcl new_change_list.
2. In IC Compiler II, source the change list, then place_eco_cells, then create_stdcell_fillers, then route_eco.
3. In StarRC, extract the parasitics.
4. Back in PrimeTime, read the updated netlist and parasitics.
5. Run timing analysis again and check the quality of results.
6. Repeat if you need to.

In the older IC Compiler tool the middle step is eco_netlist to read the file, then place_eco_cells, legalize_placement and route_zrt_eco.

Step 3 is not optional. New wires mean new parasitics, and the delay numbers you had before the change no longer describe the design.

With a PrimeECO license, implementation, extraction and signoff timing can all happen in one shell instead of three tools.

Part 3 · Implementation  ·  place_eco_cells, create_stdcell_fillers, route_eco, eco_netlist, legalize_placement, route_zrt_eco

24The incremental flow

On a large block, writing the netlist, extracting every net and updating every path takes hours. If you changed eleven cells, almost all of that work was wasted. Figure 30 puts the two loops side by side.

Two steps per loop

First you establish the reference, once. Then you go round.

# step 1, once
icc2_shell> record_signoff_eco_changes -init -def

# step 2, every iteration
icc2_shell> record_signoff_eco_changes -start
icc2_shell> ...  implement the ECO  ...
icc2_shell> record_signoff_eco_changes -stop

record_signoff_eco_changes saves the design, writes the Verilog netlist and writes the DEF. At the end of the implementation step you get an incremental database for StarRC and an incremental change list for PrimeTime.

Setting the flow up, across all three tools.

# IC Compiler II
open_lib Design.nlib
copy_block -from_block Block -to_block Block_pre_eco
open_block Block_pre_eco
record_signoff_eco_changes -init -def

# StarRC command file
NDM_DATABASE: Design.nlib
BLOCK:        Block_pre_eco
ECO_MODE:     YES
GPD:          Block_pre_eco.gpd

# PrimeTime
read_verilog ndm_path/design.full.v.gz
link_design
read_parasitics Block_pre_eco.gpd
read_sdc Block.sdc
update_timing -full
save_session eco_session1
set_eco_options -physical_design_path ndm_path/design.full.def.gz
fix_eco_timing ...
fix_eco_drc ...
write_changes pt-eco_inc1.tcl

And then each iteration looks like this.

# IC Compiler II
copy_block -from_block Block_pre_eco -to_block Block_eco1
open_block Block_eco1
record_signoff_eco_changes -start -input pt-eco_inc1.tcl
...  implement, using the minimal physical impact flow  ...
record_signoff_eco_changes -stop -def

# PrimeTime
restore_session eco_session1
read_eco_changes ndm_path/design.incr.pt
read_parasitics -eco Block_eco1_inc.gpd
update_timing
save_session eco_session2
report_timing ...

Hierarchical designs

IC Compiler II and StarRC usually run once per block and once for the top. PrimeTime assembles everything and analyses it as one thing, so you read each block's incremental data in turn.

restore_session eco_session1
read_eco_changes ndm_path_Top/design.incr.pt
read_eco_changes ndm_path_Blk1/design.incr.pt
read_eco_changes ndm_path_BlkN/design.incr.pt
read_parasitics -eco Top_eco1_inc.gpd
read_parasitics -eco Blk1_eco1_inc.gpd
read_parasitics -eco BlkN_eco1_inc.gpd
update_timing

read_eco_changes and read_parasitics -eco apply the hierarchy information themselves, so you do not need current_instance or read_parasitics -path.

Under DMSA, start from a standard script and use create_scenario -image to read the incremental information at the worker level, then update incrementally.

Part 3 · Incremental flow  ·  record_signoff_eco_changes, read_eco_changes, read_parasitics -eco, create_scenario -image

25Doing the ECO in a smaller machine

This feature is deprecated and will stop working in a future release. The tool warns you when you use it, and points at the Hybrid timing view in PrimeECO instead. It is here because you will meet it in existing scripts.

The numbers are worth sitting with. Sixteen scenarios in the full flow need sixteen machines with 100 GB each. In the reduced flow, two machines at 100 GB build the reduced designs, and then sixteen machines at 10 GB do the fixing. That is 1600 GB of machine against 200 GB plus 160 GB.

What goes in the reduced design

Only the design data related to the constraints you say you want to fix. The more constraint types you ask for, the bigger it gets. You can also restrict which path endpoints are considered.

The reduced design may not show every possible violation, so it is for fixing and never for signoff. Always finish with a full analysis.

Swapping the hosts partway through is where the saving comes from.

create_scenario ...
set_host_options -num_processes 20 \
  -submit_command "bsub [mem=100G] ..."
start_hosts
current_session -all
report_global_timing

write_eco_design

stop_hosts
remove_host_options
set_host_options -submit_command "bsub [mem=10G] ..."
start_hosts

read_eco_design
fix_eco_timing

Across saved sessions

It is common to save a session per corner and do the ECO later from a manager session. For that to work with reduced resources, each analysis session has to save the extra endpoint information.

set_app_var eco_save_session_data_type timing
save_session ./corner01

Outside DMSA you can merge the failing endpoints from several standalone sessions into one reduced design.

write_eco_design $rreco_db/FF -merge_sessions $my_sess_list

A trick with negative margins

If a scenario only matters for setup, you can tell the tool not to bother with hold there, and the other way round. A large negative margin means the check is effectively switched off.

# worst case corner: check setup, ignore hold
set_eco_options -timing_hold_margin -100.0 -timing_setup_margin 0.050

# best case corner: check hold, ignore setup
set_eco_options -timing_hold_margin 0.000 -timing_setup_margin -100.0

Part 3 · Reduced resources  ·  write_eco_design, read_eco_design, eco_save_session_data_type, -merge_sessions, -timing_setup_margin, -timing_hold_margin

26Freeze silicon

New masks for the implant, diffusion and poly layers cost a great deal of time and money. If the change can be made in metal alone, those masks do not have to be made again.

Freeze silicon changes wires, not transistors. That is the whole idea, and every restriction in the flow follows from it.

In figure 32 the same region appears twice, before and after, and nothing in the silicon has moved between the two.