ECO Flow in ICC2: A Mentor Guide

Part 1 — What an ECO is, and which flow you are in

The chip is finished. Then something changes.

This is the last chapter of the guide, and it starts from a different place than the other seven. Nimbus‑8 is routed. It is finished. Chapter 6 signed off its density and its fill. Chapter 7 closed its hierarchy and handed off a checkpoint named nimbus8_top_hier_closed_v1. And then a late setup violation shows up on a u_sens_tile boundary path, or a functional bug is found, or a DRC escape turns up in a re-check. The chip has to change, without going back to floorplan and starting over.

The IC Compiler II User Guide defines an ECO — an engineering change order — as an incremental change to a complete or nearly complete design, used to fix functional, timing, noise and crosstalk violations without re-synthesizing, re-placing and re-routing everything. Read that definition twice, because both halves matter. It is incremental: you touch as little as possible. And it fixes real problems: functional bugs, timing violations, noise, crosstalk. An ECO is not a redesign wearing a smaller name.

The spine of this chapter

Every ECO you will ever run answers three questions, in this order, and this chapter is organized around them exactly:

What changed, how little can I disturb, and how do I prove I disturbed nothing else.

• What changed — identifying the delta between what you have and what you need. eco_netlist, netlist editing commands, PrimeTime change lists. Parts 2 through 4.
• How little can I disturb — the whole minimal-impact toolkit: which flow you are in, spare cells, freeze silicon, legalization modes, displacement thresholds. Parts 5 through 9.
• How do I prove I disturbed nothing else — recording, reporting, reverting, re-timing, and the closure gate. Parts 10 through 12.

A reader who finishes this chapter should be able to answer all three questions about any ECO they are handed. Refer back to this spine as each Part opens.

Why this chapter closes the series

Chapter 7 ended by handing off to ECO Flow by name. That was not an accident. Repairing a chip correctly demands everything the previous seven chapters taught. Placement legality comes from Chapter 4. Clock trees you must not disturb come from Chapter 5. Routing you must minimally reroute comes from Chapter 6. Fill and spare cells come from Chapter 7's chip-finishing. Block boundaries that constrain where an ECO may land come from Chapter 7's hierarchical implementation. This chapter makes those callbacks explicit as they come up.

Which of the five flows are you in?

Before you type a single command, answer one question: what are you still allowed to change? That single question, asked correctly, sorts every ECO into one of five flows, and the flow decides every command you type after this page.

Figure 1 — Which ECO flow am I in?

The five ECO flows, at a glance

Flow	When you are in it	First command	Taught in
Generic ECO flow	Pre-tapeout, cells may still be added and moved	eco_netlist	Part 2
Freeze silicon ECO	Taped out, only metal and via layers may change	check_freeze_silicon	Part 6
Signoff ECO	PrimeTime signoff found the violation	fix_eco_drc	Part 7
Incremental signoff ECO	The signoff loop is iterating and re-running it in full is too slow	record_signoff_eco_changes -start	Part 8
ECO Fusion	A one-shot or in-tool fix invoking PrimeTime from inside ICC2	eco_opt	Part 9

The worked ECO this chapter uses throughout

One concrete example runs through every part and every figure: a late setup violation on a u_sens_tile boundary path, found in the func_ss_0p72v_125c scenario at −0.008 ns. The fix is one buffer insert (eco_cell_1) plus one cell upsize (u_sens_tile/U88), alongside a small functional change adding a two-input gate on the sensor-enable path. Small enough to draw completely, real enough to teach the whole flow. Every figure that shows an ECO shows this one.

Is the design ready to take an ECO?

Before the first command in Part 2, a real ECO starts with a readiness check. Is the netlist in sync with the layout? Is there spare capacity nearby? Is the freeze-silicon mode set correctly for the flow you chose in Figure 1? Has the change file been reviewed, and is a baseline timing snapshot archived to compare against later? Dashboard 1 is that check, applied to the worked ECO.

Part 2 — Generic ECO flow

The four-step flow you use before tapeout

The generic ECO flow is the default: use it whenever you can still add cells and move existing ones, which is any time before tapeout. It is four steps, and every other flow in this chapter is a variation built to handle a constraint the generic flow does not have to worry about.

1. Update the netlist. Identify and apply the logical change — Part 3 covers this in depth.
2. place_eco_cells. Place and legalize the new or changed cells.
3. Add filler. Rebuild filler cells around the change so density stays correct.
4. route_eco. Route the new or modified nets.

That is the whole flow. Everything this chapter adds after Part 2 — freeze silicon, the PrimeTime loop, incremental tracking, ECO Fusion — is this same four-step shape, adapted for one added constraint: silicon frozen, a second tool finding violations, or a loop that must run many times cheaply.

Filler cells and -post_eco

Standard-cell rows are packed with filler cells wherever there is no real logic, so the row is continuous for manufacturing and so density stays inside the window Chapter 6 signed off. An ECO opens a gap in that row to make room for a new cell, which means fillers have to come out before placement and go back in after. Doing that for the whole design every time is wasteful: only the touched cells need new fillers and re-checked DRC.

create_stdcell_fillers -post_eco and remove_stdcell_fillers_with_violation both exist to scope this work down to what changed. The -post_eco option tells create_stdcell_fillers to run its DRC checking only on cells placed by the ECO, not on every filler in the design.

Figure 2 — Filler cells around an ECO

Cost ledger — filler cells around an ECO

Fillers removed to open the gap	3
Fillers reinserted	2 (1 site now occupied by the ECO cell)
Cells DRC-checked with -post_eco	1 (the new cell) vs. all cells without it
Density before / after	61.4% / 61.3% M1 (unchanged within rounding)

What route_eco actually touches

route_eco routes only the nets an ECO created or modified — it does not rip up and reroute the block. Drawing that boundary explicitly is worth doing once, so “minimal” is visible instead of assumed.

Figure 3 — route_eco blast radius

Cost ledger — route_eco blast radius

Nets rerouted	2
Nets left untouched	46 (same region, not shown faint beyond frame)
Vias added	2
DRC markers created	0

Callback: chip finishing planted this for you

Chapter 6 signed off Nimbus‑8's density with a specific fill strategy: track-based fill on M2 through M7, pattern-based on M8 and M9, floating on M2 through M5, tied to VSS on M6 through M9. Every one of those decisions constrains what an ECO may do to fill near a change. Removing and rebuilding fillers with -post_eco respects that strategy by construction: it calls the same fill-generation logic Chapter 6 used, not a new rule for the ECO case.

Part 3 — What changed: identifying the delta

Before you fix anything, know exactly what is different

The first spine question is “what changed.” Answering it well, before you touch anything, is the single best habit this chapter teaches. eco_netlist is the command that answers it formally, by comparing your working design against a golden reference and writing the difference out as a file you can read before you run it.

Comparing against a golden reference

eco_netlist performs a name-based netlist comparison between the working design and a golden input, in one of two ways: -by_verilog_file against a golden Verilog file, or -by_block against a golden block. -golden_lib, -working_block and -working_lib say exactly which design and library each side comes from.

By default, eco_netlist ignores some categories of difference not usually part of a functional ECO: physical-only cells, timing-ECO changes, and power/ground differences. -compare_physical_only_cells and -extract_timing_eco_changes turn that ignoring off — use them when your golden reference might predate a round of changes you want the comparison to see.

Netlist editing commands, for small changes

Not every change needs a golden reference and a formal comparison. For a small, well-understood edit — one gate, one connection — issue the netlist editing commands directly. create_cell instantiates a new cell from a library reference; connect_net and disconnect_net rewire pins; size_cell rebinds a cell to a different library variant (Part 4 covers this one in depth); and change_link swaps what a hierarchical instance points to.

Design-planning ECO scripts

Three commands from the design-planning flow generate ECO scripts for changes that are structural rather than purely logical — moving where a net lives in the hierarchy, or exposing spare capacity as real ports:

Design-planning ECO script generators

Command	What it generates	Typical use
write_split_net_eco	A script that moves the branch-out of a multi-fanout net up to the top level	A net's fanout has outgrown its current hierarchical home
write_push_down_eco	A script that moves a tree of standard cells down from the top physical level into the overlapping blocks below	Logic was placed at the top level but logically belongs inside a block
write_spare_ports_eco	A script that creates dummy feedthrough ports on named cells for future use	Reserving port capacity ahead of an ECO you expect but have not designed yet

What this ECO actually is, inventoried

Once the delta is identified, write it down as a table before you place anything: cells added, removed, resized; buffers inserted; nets touched. Keep functional changes visibly separate from timing changes — Part 8 shows that separation is not optional once incremental signoff tracking is involved.

Part 4 — Making the change: resize, buffer, fanout

Three edits cover almost every ECO you will make

Once you know what changed, most ECOs come down to three kinds of edit: resize a cell, insert a buffer, or split an overloaded fanout. Figure 4 shows the worked ECO's buffer insert as real geometry. This Part gives you the three commands behind it, verified option by option.

Figure 4 — Before and after one buffer insert

Cost ledger — before/after one buffer insert

Cells added	1 (eco_cell_1, a buffer)
Sites consumed	1 (the site empty in both panels)
ECO cell offset	0 µm — placed directly in the free site
Neighbours displaced	0
Wire length delta	+3.4 µm (illustrative)

Resizing: size_cell

size_cell rebinds a leaf cell to a new library cell with a different drive strength, or other properties — the classic upsize-for-setup or downsize-for-power move. The cell being resized must already be in scope, at or below the current instance.

Buffering: add_buffer and add_buffer_on_route

add_buffer adds a buffer cell on the nets connected to specified pins — the simple, pre-route form. add_buffer_on_route does the same thing on nets with real routed geometry, and carries the larger option family, because it has to decide where along the route the buffer lands.

Splitting an overloaded fanout: split_fanout

Some violations are not about one net's routed length but about one driver serving too many loads. split_fanout reduces a driver's fanout by inserting a repeater cell, the standard fix for a max-fanout or max-capacitance violation that a single resize cannot clear.

Naming the results: -cell_prefix and -net_prefix

Every command in this Part that creates a cell defaults to a readable naming convention: new cells get the prefix eco_cell, new nets get eco_net, both followed by a running number. A cell an ECO resizes, by contrast, keeps its original instance name — size_cell rebinds a reference, it does not create a new instance.

Figure 5 — The ECO cell naming convention, on real geometry

Cost ledger — ECO cell naming convention, on real geometry

New cell prefix	eco_cell (default)
New net prefix	eco_net (default)
Resized existing cell	keeps its original instance name

Not every ECO is timing or DRC: a crosstalk fix

Some violations are neither a slack number nor a DRC rule — they are noise. A victim net running too close to a switching aggressor can pick up enough coupled delta delay to fail timing that would otherwise pass, and the fix is not a buffer or a resize but a shield.

Figure 6 — A crosstalk / SI-driven ECO

Cost ledger — a crosstalk / SI-driven ECO

Delta delay before shield	+22 ps (illustrative)
Delta delay after shield	+3 ps
Tracks consumed by the shield	1

Part 5 — Spare cells: the ECO you plan for before you need it

The ECO toolkit that starts before there is anything to fix

Every command in Parts 2 through 4 assumes there is somewhere for a new cell to go. Spare cells make that true ahead of time, planted by Chapter 6's chip-finishing pass and by floorplan design planning: the same discipline that set density is what plants spare capacity.

Three ways to get spare cells into a design

• Manual instantiation — place named spare-function instances by hand, the way you would place any other cell, when you know exactly what function you will need later.
• add_spare_cells — inserts spare cells programmatically, from a named library cell reference and an instance count, or from a raw cell count.
• Programmable spare cells via create_stdcell_fillers — gate-array-style fillers that are not committed to one function until an ECO programs them.

The four criteria that make a cell “spare”

The tool does not treat every idle-looking cell as a spare. A cell is recognized as spare when it meets all four of these:

1. It is not a physical-only cell — a spare has a real logical function waiting to be used, unlike a filler or tap cell.
2. All of its inputs, except a clock pin if it has one, are either unconnected or tied to a constant.
3. Its output is unconnected.
4. It is a real placed instance, occupying real sites, not a paper placeholder.

Figure 7 — A spare cell, close up

Cost ledger — a spare cell, close up

Recognition criteria met	4 of 4
Inputs tied	2 of 2, to VSS
Output	unconnected
Leakage cost of leaving it tied	0.4 µW (illustrative)

Distributing spares: spread_spare_cells

spread_spare_cells spreads spare cells — typically ones that arrived through a Verilog ECO or manual netlist editing, not yet placed — evenly across a rectilinear region, with the same distribution controls as add_spare_cells: -density_aware_ratio, -random_distribution, -boundary, -voltage_areas, -ignore_blockage_types.

Figure 8 — Spare-cell distribution across the die

Cost ledger — spare-cell distribution across the die

Density-aware: spare count	14 (this region, illustrative)
Density-aware: mean spacing	38 µm
Random: mean spacing	51 µm, higher variance
Coverage inside 50um of any cell cluster	density-aware 100% / random 71%

Programmable spare cells: gate-array fillers

A fixed-function spare cell can only ever become the one function it was instantiated as. A programmable spare cell (PSC) is different: it is a gate-array-style filler shape that can be programmed, by metal and via connections alone, into any one of several compatible functions at ECO time. The psc_type_id attribute is what pairs a standard cell with the family of PSC shapes that can realize it — when you place a PSC, you are reserving a function family, not one fixed function.

Figure 9 — Programmable spare cell (gate-array filler)

Cost ledger — programmable spare cell (gate-array filler)

Functions one PSC can realise	up to 4, by psc_type_id family
Functions a fixed-function spare can realise	1
Extra silicon area per PSC vs. fixed spare	~1.15x (illustrative)

Part 6 — Freeze silicon: when only metal may change

The chip has taped out. Silicon is frozen. Metal is not.

Once a design has taped out, the diffusion, poly and contact layers exist in silicon, permanently. A freeze-silicon ECO is what you run when the fix must live entirely in metal and vias — rewiring already-manufactured transistors into a new function, never creating one.

Turning the mode on

design.eco_freeze_silicon_mode is the application option that tells ICC2 it is operating under this constraint. With it set, placement and legalization commands stop assuming they can create new silicon and start assuming every fix has to land on an existing spare.

Checking feasibility before you commit

check_freeze_silicon performs feasibility analysis on ECO-cell-to-spare-cell mapping for the current design, before you place anything. It takes no arguments — it reads the ECO cells and spare cells already present and reports whether a mapping is even possible.

Figure 10 — Freeze-silicon mapping decision

Placing and mapping: place_freeze_silicon

place_freeze_silicon places new ECO cells by swapping out spare cells. Two options let you separate placement from mapping, which is the careful engineer's move: check QoR with cells placed near their targets before committing to which spare each one consumes.

Manual mapping: map_freeze_silicon

When you already know exactly which spare an ECO cell should become, map_freeze_silicon maps it directly: -eco_cell and -spare_cell name the pair, or -map_file reads a whole mapping from a file. -filler_map_strategy chooses how leftover white space packs once cells are mapped — pack_left, pack_right, pack_top, pack_bottom or closest. -advanced_nodes switches on additional rule checking appropriate to advanced process nodes, and can be paired with -skip_rule_check when that checking is not wanted for a specific call.

The LEQ path, when no same-name spare exists

When the mapping decision in Figure 10 lands on “logically equivalent spare,” the command is create_freeze_silicon_leq_change_list. It writes a Tcl change list for ECO cells that need a logic-equivalence match rather than an exact same-name spare. The cells it operates on must be leaf cells with is_fs_eco_add true, and an eco_change_status of create_cell, add_buffer, add_buffer_on_route, change_link or size_cell.

Rules for mapping onto PSCs

set_programmable_spare_cell_mapping_rule creates a mapping rule that governs how place_freeze_silicon is allowed to map onto programmable spare cells. -psc_type_id or -compatible select which PSC id families a rule applies to; further options control power-rail overlap behavior (-dont_overlap_pg_stripe_layer, -partial_overlap_pg_stripe_layer) and multi-height PSC handling (-multi_height_split, -multi_height_merge).

Figure 11 — Freeze silicon: ECO cell mapped onto a spare

Cost ledger — freeze silicon: ECO cell mapped onto a spare

Silicon (diffusion/poly) layers changed	0
Metal/via layers changed	M2, M3 only
Mask layers touched	2 of the full mask set
Mask cost vs. a new tapeout	~1 mask set vs. all layers

Part 7 — Signoff ECO: the PrimeTime loop

This is a two-tool chapter. Here is where the two tools hand off.

Signoff timing on Nimbus‑8 runs in PrimeTime, not ICC2. When PrimeTime's signoff analysis finds a violation — the worked ECO's −0.008 ns setup path on func_ss_0p72v_125c — the fix has to happen in PrimeTime too, because that is where the timing model lives. But the layout lives in ICC2. This Part is the loop that keeps both tools' pictures of the design true at once.

Figure 12 — The two-tool loop

The three PrimeTime fixing commands

The three core commands, all PrimeTime, all mandatory reading before you run your first signoff ECO:

Exporting the fix: write_changes

write_changes exports whatever fix_eco_drc, fix_eco_timing and fix_eco_power did as a Tcl change list, ready for ICC2 to source. pt_shell> write_changes -output pt_eco.tcl is the file Figure 12 shows crossing from PrimeTime to ICC2.

Logic-only versus physically aware

PrimeTime's ECO fixing can run in two modes. Logic-only works from the netlist and parasitics alone, with no placement awareness. Physically aware mode additionally reads real placement data, so fixes land only where physical room genuinely exists, and the change list records exact coordinates for fast, predictable implementation. Physically aware mode needs set_eco_options pointed at the design's physical data, and offers three placement strategies through -physical_mode:

-physical_mode strategies

Value	Behavior	When to choose it
occupied_site	Aggressive — may place or resize over existing neighbor cells, moving them later	Early-stage, high-utilization ECO where room is scarce
open_site	Conservative — places only where room already exists, avoids moving existing cells	Late-stage, low-utilization ECO where minimal disturbance matters most
freeze_silicon	Places changes only onto pre-placed programmable spare cells	Post-tapeout, when silicon may not change — the Part 6 flow

A preview before committing: estimate_eco

estimate_eco gives a fast, approximate preview of a proposed size or buffer change's timing effect, before you pay for a full incremental update and a real report_timing re-evaluation — not exact, but fast enough to screen candidates before choosing one.

The fixing order, and why it is that order

Power recovery, then DRC and noise, then setup, then hold, then a final leakage-only power recovery — not arbitrary, but following directly from what each step is allowed to break.

Figure 13 — Fix priority order

The ICC2 side of the handoff

Once the change list arrives, ICC2's job is to source it and then place, fill and route exactly as the generic flow does, with one addition: legalization is explicitly told to minimize disturbance.

Part 8 — Incremental signoff ECO: making the loop cheap

The loop from Part 7 works. It does not always work cheaply enough.

A signoff ECO list is rarely one violation; it is often dozens, and running the full Part 7 loop — full extraction, full timing update — for each one is a schedule problem on a design Nimbus‑8's size. Incremental signoff ECO is the same loop, scoped to only what changed each time.

Figure 14 — The incremental loop, against the full loop

Recording, with a signature check: record_signoff_eco_changes

record_signoff_eco_changes records ECO changes for the incremental signoff flow across three calls: -start, an optional -init, and -stop.

Incremental extraction and incremental timing

Once record_signoff_eco_changes -stop has written the incremental design data, StarRC extracts only the changed portion of the design instead of the whole block, and PrimeTime updates timing incrementally against that partial extraction. A full-design extraction and analysis is reserved for the final signoff pass, not repeated on every intermediate iteration.

Part 9 — ECO Fusion: PrimeTime inside ICC2

One command, both tools, no manual handoff

eco_opt is an ICC2 command that invokes PrimeTime timing and PrimeTime ECO under the hood, brings the changes back, and runs incremental place and route — the whole Part 7 loop, in one call. It is worth learning the manual loop first, in Parts 7 and 8, precisely so you can tell whether eco_opt did the right thing.

Setting up the PrimeTime connection: set_pt_options

Before eco_opt can invoke PrimeTime, ICC2 needs to know where PrimeTime lives and how to configure the session it starts. set_pt_options carries that configuration.

StarRC inside the fusion flow

Extraction mode for the fusion flow is controlled by the extract.starrc_mode application option, defaulting to fusion_adv, with in-design and none as alternatives. set_starrc_options -config loads and validates a configuration file for running StarRC signoff extraction inside the PT ECO Fusion flow. The file names the StarXtract executable location, a corner-to-nxtgrd mapping file, a layer mapping file and a command file. -validate true checks that setup is correct before it is used.

The command itself: eco_opt

eco_opt optimizes the current routed design with PrimeTime timing and PrimeTime ECO. Run with no options, it defaults to fixing {setup hold drc total_power buffer_removal} — the full priority order from Part 7, in one call.

Checking the result: check_pt_qor

check_pt_qor checks PrimeTime QoR — timing and power — against the current state. -type scopes the check to global_timing, summary, max_delay, min_delay, max_transition, max_capacitance, power or noise; -reset clears a prior baseline, and -report_script runs a custom reporting script.

The convergence warning: matching postroute settings

ECO Fusion's convenience depends on ICC2's postroute timing settings genuinely matching PrimeTime's. If they diverge, ECO Fusion will converge on a result that looks clean inside the fusion flow and disagrees with a standalone PrimeTime signoff run — which defeats the entire purpose of running signoff in PrimeTime in the first place.

ECO Fusion power integrity

ECO Fusion extends past timing and DRC into voltage-drop-aware ECOs. rail.database is the application option pointing at a RedHawk-generated rail analysis database. analyze_rail -voltage_drop dynamic_vcd | dynamic_vectorless runs the drop analysis, and eco_opt -type power_integrity fixes what it finds — a fixing type that cannot be combined with the ordinary setup/hold/DRC types in the same call.

Part 10 — How little can I disturb: ECO placement

The heart of the chapter

place_eco_cells derives each ECO cell's placement from connectivity and delay, then legalizes it to the closest unoccupied site, leaving existing cells untouched by default. Every option this Part covers is a way of relaxing or tightening that default, and every one is a real trade between disturbing more and failing to place at all.

Choosing which cells to place

Three mutually exclusive ways to select the target cells: -cells names a specific collection; -unplaced_cells takes every cell with no location yet; -eco_changed_cells takes every cell whose eco_change_status attribute is create_cell, add_buffer, change_link, size_cell or add_buffer_on_route. That third option is exactly the set of edits Parts 3 and 4 taught you to make.

The three legalize modes, as a spectrum of disturbance

-legalize_mode takes one of three values, and the TCR's own description of each is worth reading verbatim, because it corrects a natural assumption: the default is not a fourth mode sitting alongside the other three. It is one of the three, named free_site_only.

The three legalize modes

Mode	Behavior	Notes
free_site_only (default)	Legalizes ECO cells on free sites only, without moving any other existing cell	Combine with -displacement_threshold to reject cells whose displacement would be too large rather than force a placement
minimum_physical_impact	Tries free_site_only first; for any cell exceeding -displacement_threshold, falls back to moving existing cells for just that cell	Requires -legalize_only; the practical middle ground for most signoff ECOs
allow_move_other_cells	Legalizes every ECO cell on its nearest legal location, moving whatever existing cells are in the way	Cannot be combined with -displacement_threshold — there is no threshold to reject against, because moving cells is always allowed

Figure 15 — The three legalize modes, same ECO cell

Cost ledger — the three legalize modes, same ECO cell

A: default + threshold	0 placed, 1 rejected (epl_legalizer_rejected_cells)
B: minimum_physical_impact	1 placed, ECO cell offset 2.1 µm, 0 neighbours displaced
C: allow_move_other_cells	1 placed, 1 neighbour displaced 0.6 µm

Displacement thresholds, drawn as bands

-displacement_threshold sets the distance, in microns, beyond which the command will not legalize a cell — it keeps the cell's pre-legalization location instead and reports the rejected cell count. -max_displacement_threshold must be paired with it, and must be greater than or equal to it: it builds a collection, epl_max_displacement_cells, of ECO cells whose displacement exceeds even that outer band. That collection is a subset of the broader epl_legalizer_rejected_cells collection every rejected cell lands in.

Figure 16 — Displacement threshold, drawn

Cost ledger — displacement threshold, drawn

ECO cell offset (ideal location to actual site)	2.1 µm
-displacement_threshold	3.0 µm (this ECO)
-max_displacement_threshold	8.0 µm (this ECO)
Result	inside threshold — placed, not rejected

Finding room before you need it: report_cell_feasible_space

report_cell_feasible_space reports feasible site spaces, scoped by -voltage_areas or -boundary, and can ignore specific filler references with -ignore_filler_references. Run it before committing to a change, to know whether the local neighborhood even has room, rather than discovering the answer from a rejected-cell report after the fact.

Shaping the coarse placement: net weight and virtual connections

Before legalization, place_eco_cells does a coarse, connectivity-based placement that decides roughly where each ECO cell should land. Three mechanisms let you shape that coarse placement:

• -fixed_connection_net_weight — weights nets connected to a fixed point (an I/O pad or macro) more heavily, so the coarse placement pulls the ECO cell closer to that fixed point.
• -honor_user_net_weight, paired with set_eco_placement_net_weight -nets ... -weight ... (and inspected with report_eco_placement_net_weight) — lets you set arbitrary per-net weights yourself before placement runs.
• -use_virtual_connection, paired with create_virtual_connection -name ... -pins ... — lets you define connections that do not exist in the real netlist, purely to bias the coarse placement, for cases where the real connectivity does not reflect the physical proximity you actually want.

All three support -channel_aware coarse placement, which additionally accounts for routing channels when deciding where an ECO cell should land.

Two more options round out the toolkit. -remove_filler_references tells legalization it may ignore and overlap unfixed filler cells of the named references, opening room without treating filler as an obstacle. And set_eco_placement_net_weight -reset clears any user net weights left over from a previous ECO, so they do not silently bias the next one.

Part 11 — How do I prove I disturbed nothing else

The third spine question, answered with evidence

Parts 1 through 10 taught you how to make a minimal change. This Part is about proving, in numbers, that it stayed minimal. The commands here answer the chapter's third and final spine question directly.

Check before you place, not after: report_eco_physical_changes

report_eco_physical_changes reports the cell displacements and individual net-length changes resulting from size_cell, add_buffer and add_buffer_on_route. Run it before placement, on the change list you are about to source, not after placement has already happened. That ordering is deliberate: a report run after the fact can only tell you what already happened, while a report run before tells you what is about to.

Figure 17 — report_eco_physical_changes as a displacement histogram

Cost ledger — report_eco_physical_changes as a displacement histogram

Cells screened	34
Inside displacement_threshold (0-2µm)	23 cells
Between the two thresholds (2-6µm)	8 cells
Beyond max_displacement_threshold (>6µm)	3 cells -- rejected, not placed

Backing out a nonoptimal change: revert_eco_changes

revert_eco_changes -cells reverts ECO changes made by size_cell, add_buffer and add_buffer_on_route on the specified cells. Once report_eco_physical_changes or the displacement report from place_eco_cells itself flags a change as too costly, this is how you take it back cleanly, rather than hand-editing the netlist to undo it.

Keeping supply connections current: eco_update_supply_net

A buffer inserted by a timing ECO needs a real power and ground connection, and eco_update_supply_net is what keeps that connection current as ECO buffer trees grow. It covers cells added by add_buffer, add_eco_repeater, split_fanout and add_buffer_on_route — the same family of commands Part 4 taught. Left unspecified, -cells defaults to updating every cell any timing ECO command has added; specified, it updates just the named cells and the “ECO buffer tree” connected to them — a group of connected timing-ECO cells, bounded by any cell of a different type.

Recording exact layout changes: record_layout_editing

record_layout_editing records changes to the layout for a restricted set of objects and writes them to a Tcl script file. It is specifically documented as a command for final tapeout DRC fixing, not general ECO placement — which is why it belongs in this Part's evidence toolkit rather than earlier ones.

The worked ECO, followed end to end

Every number this Part has introduced — identified, placed, cell offset, routed, slack — is a column in the same status strip, tracked across one region through the whole lifecycle of the worked ECO from Part 1. Five panels, same coordinate frame, same u_sens_tile boundary and the same SRAM0 macro in every one, so the only thing that changes panel to panel is the thing the caption says changed. Read the five status strips left to right and you are reading the chapter's whole spine acted out on one net.

Figure 18A — the worked ECO, panel 1 of 5: the violation

Cost ledger — 18A: the violation

Scenario	func_ss_0p72v_125c
Slack	-0.008 ns
Change / placed / cell offset / routed	- / - / - / -

Figure 18B — the worked ECO, panel 2 of 5: change identified

Cost ledger — 18B: change identified

Change file	pt_eco.tcl: add_buffer, size_cell
Placed / cell offset / routed	no / - / no

Figure 18C — the worked ECO, panel 3 of 5: cells placed

Cost ledger — 18C: cells placed

Legalize mode	minimum_physical_impact
ECO cell offset	1.8 µm
Neighbours displaced	0

Figure 18D — the worked ECO, panel 4 of 5: rerouted

Cost ledger — 18D: rerouted

Nets rerouted	1, into 2 segments
Vias added	1

Figure 18E — the worked ECO, panel 5 of 5: re-timed and closed

Cost ledger — 18E: re-timed and closed

Final slack	+0.004 ns, func_ss_0p72v_125c
Total ECO cell offset	1.8 µm (1 cell)
Neighbours displaced	0

The evidence set: what a clean ECO looks like in numbers

Bring every number this Part produces together, and a clean ECO has a specific shape: displacement inside the threshold band, zero rejected cells, supply nets current on every new buffer, and a layout-editing record that lets a later engineer reconstruct exactly what happened. Dashboard 5, the blast radius board, is this Part's numbers assembled into one table.

Part 12 — Stage exit: what leaves this chapter, and the guide

The closure gate for an ECO, and for the series

This Part closes two things at once: the worked ECO, and the eight-chapter guide it was chosen to demonstrate. Both close against the same gate, because an ECO's closure criteria are, in miniature, the same criteria the whole guide has been building toward since Chapter 1.

The closure gate for an ECO

• Timing re-verified on both scenarios. Not just the scenario that found the violation — func_ss_0p72v_125c and func_ff_0p88v_m40c both, because a setup fix can shift hold, as Part 7's small-hold-violation lesson already warned.
• DRC clean. The fixing order in Part 7 guarantees setup and hold fixes cannot reopen DRC — confirm that guarantee held, do not just assume it.
• Density unchanged. Chapter 6's signed-off fill and density windows, re-checked after the ECO's filler rebuild.
• Displacement inside budget. Every number Dashboard 5 tracked, still inside the thresholds set before placement.
• Change list archived. The PrimeTime change file, the layout-editing record, and the readiness and inventory dashboards, all kept together as one ECO record.

What the reader now knows, end to end

Eight chapters ago, this guide started with an empty library and a netlist. Floorplan shaped that netlist. Placement and optimization filled it with legally placed cells. Clock tree synthesis gave those cells a trustworthy clock. Routing and postroute optimization connected everything with real, rule-clean metal. Chip finishing and design for manufacturing made that metal signoff-clean and manufacturable. Hierarchical implementation showed how to do all of that at a scale too large for one flat run. And this chapter, ECO Flow, is what you do the day after all of that is declared done and something still needs to change.

That last sentence is the whole point of this being the final chapter and not an appendix. Every fact this chapter used, it borrowed from somewhere earlier: placement legality from Chapter 4 is what makes place_eco_cells's legalize modes meaningful. The clock trees Chapter 5 built are what Part 9's clock-network ECO fixing is careful not to disturb. The routing rules Chapter 6 signed off are what route_eco's blast radius in Figure 3 respects. The fill and spare cells Chapter 6's chip-finishing planted are what Part 5's cost ledger reconciles against, cell for cell. And the block boundaries Chapter 7's hierarchical implementation drew are the constraint a freeze-silicon or signoff ECO on a partitioned design must respect.

A reader who has followed this guide from Chapter 1 to here has built a chip and repaired it, in that order, with the same vocabulary and the same discipline throughout. That is what “end to end” means for this series, and this Part is where it closes.

Part 13 — Knowledge reinforcement and interview bank

45 questions, tiered, every answer grounded in this chapter

Forty-five questions across four tiers: 16 beginner, 15 intermediate, 9 advanced, and 5 senior/architect (16+15+9+5 = 45). Every answer draws only on what this chapter taught; illustrative numbers are labelled as such, and no command appears in an answer that was not verified in the body text. At least six questions cross back to earlier chapters, marked ↩ earlier chapter.

Beginner, 16 questions

1. What is an ECO?

An incremental change to a complete or nearly complete design, used to fix functional, timing, noise and crosstalk violations without re-synthesizing, re-placing and re-routing the whole design.

2. What is a spare cell?

A real, placed cell that is recognized as available for future use: it is not physical-only, all of its non-clock inputs are tied or unconnected, and its output is unconnected. It has a real logical function waiting to be wired in.

3. What does “freeze silicon” mean?

A constraint, active after tapeout, under which the diffusion, poly and contact layers may not change at all — only metal and via layers may. A freeze-silicon ECO realizes its fix entirely by rewiring existing, already-manufactured transistors.

4. Which command places ECO cells?

place_eco_cells. It performs coarse placement from connectivity, then legalizes to the closest unoccupied site.

5. What does -post_eco save, on create_stdcell_fillers?

It scopes the filler DRC check to only the cells the ECO placed, instead of checking every filler cell in the design, which saves real runtime on a large design.

6. Name the five ECO flows.

Generic ECO flow, freeze silicon ECO, signoff ECO, incremental signoff ECO, and ECO Fusion.

7. What is the first question that decides which flow you are in?

What are you still allowed to change — silicon and metal, or metal only — and whether the design has taped out at all.

8. Which command compares a working design against a golden reference?

eco_netlist, using either -by_verilog_file or -by_block.

9. What is eco_cell and eco_net?

The default name prefixes add_buffer and add_buffer_on_route use for new cells and new nets they create.

10. What are the three legalize modes for place_eco_cells?

free_site_only (the default), allow_move_other_cells, and minimum_physical_impact.

11. What is a displacement threshold?

A distance, in microns, beyond which place_eco_cells will not legalize a cell — it keeps the cell at its pre-legalization location instead, and reports it as rejected.

12. Which PrimeTime command exports an ECO's changes for ICC2 to apply?

write_changes.

13. What does fix_eco_timing's -type option require?

It is mandatory: you must specify setup or hold. There is no combined default that fixes both at once.

14. What is a programmable spare cell (PSC)?

A gate-array-style filler shape that can be programmed, by metal and via wiring alone, into one of several compatible functions at ECO time, rather than being committed to a single fixed function the way an ordinary spare cell is.

15. Which shell does fix_eco_drc run in?

PrimeTime's pt_shell, not ICC2's icc2_shell.

16. What is the worked ECO used throughout this chapter?

A late setup violation on a u_sens_tile boundary path, fixed with one buffer insert (eco_cell_1) and one cell upsize (u_sens_tile/U88), alongside a small functional change adding a two-input gate.

Intermediate, 15 questions

17. Why does place_eco_cells leave existing cells untouched by default?

Its default legalize mode, free_site_only, is built for minimal disturbance: it places ECO cells on free sites and never moves anything else, on the theory that the cheapest ECO is one that changes nothing beyond what it strictly needs to.

18. What is in a change file, and why read it before sourcing it?

Plain Tcl — ordinary netlist editing commands like create_cell, connect_net, change_link. Reading it before sourcing is the single best habit this chapter teaches: it is the only way to confirm the change matches what you expect before it is applied to the design.

19. Why must you tie a spare cell's inputs to a rail?

A floating CMOS input is not electrically inert — it can drift near the switching threshold, causing leakage current and, under noise, oscillation. Tying unused inputs to a defined rail keeps an unmapped spare quiet until it is mapped.

20. What stops incremental signoff ECO tracking?

A functional ECO change. Additional timing ECO changes may continue while record_signoff_eco_changes is active, but a functional change ends the recording session.

21. Why is -respect_blockages not the default on add_buffer_on_route?

Because respecting every blockage can push the search much further from the net's real route, making the wire longer instead of shorter. It trades placement legality against displacement distance, and the default leaves that trade to the engineer.

22. What happens to a cell a freeze-silicon ECO “deletes”?

It is not removed from the design — silicon cannot be removed after tapeout. It is retired back to spare status and stays in the design, tied off, available for a future ECO.

23. What is the difference between logic-only and physically aware PrimeTime ECO fixing?

Logic-only works from netlist and parasitics alone, with no placement awareness. Physically aware mode reads real placement data, so fixes land only where physical room genuinely exists, and the change list records exact coordinates.

24. Why is -max_displacement_threshold different from -displacement_threshold?

-displacement_threshold decides what gets legalized versus rejected. -max_displacement_threshold builds a separate collection, epl_max_displacement_cells, of changes disruptive enough that the right response may be rejecting the ECO change itself, not just its placement.

25. What does -post_eco actually change about how create_stdcell_fillers runs?

It scopes the DRC check step to the ECO-placed cells only, leaving the rest of the design's fillers unchecked because nothing about them changed.

26. Why must eco_netlist -write_changes or -write_changes_per_module be specified?

The command requires exactly one of them: they are how the comparison result gets written out at all, and they are mutually exclusive because they represent two different output shapes — one combined file versus one file per module with a dependency-ordered source sequence.

27. What is a “buffer tree” in the context of eco_update_supply_net?

A group of connected timing-ECO cells — added by add_buffer, add_eco_repeater, split_fanout or add_buffer_on_route — bounded by any cell of a different type, treated as one unit when supply-net connections are updated.

28. Why does -displacement_tolerance_level high tolerate more ECO-cell displacement?

Because it inverts the usual preference. Instead of minimizing how far the ECO cell itself moves, at the cost of moving more existing cells to make room, it minimizes how much existing cells move — even if the ECO cell lands further from its ideal location.

29. What is the difference between a filler cell and a spare cell?

A filler cell has no logical function — it exists to keep a standard-cell row continuous and hold density. A spare cell has a real function, simply unused, its inputs tied off until an ECO maps it. Neither is ever selected as an ECO target cell.

30. Why does fix_eco_power's default selection method minimize area rather than power directly?

Because minimizing measured power requires PrimePower data from update_power first, via -power_mode; area minimization needs no such prerequisite and is available immediately, which is why it is the default rather than the more precise but more setup-dependent power-mode option.

31. Why does editing an instance inside a multiply instantiated block uniquify it?

So the edit applies only to that one instance's behavior, not to every sibling instance of the same module. The tool creates a private copy of the module, and its ancestors up to the first singly instanced level, specifically to contain the change.

Advanced, 9 questions

32. When do you choose minimum_physical_impact over allow_move_other_cells?

Choose minimum_physical_impact whenever a free site exists close enough to be acceptable — it tries free-site placement first and only falls back for the cells that need it. Reach for allow_move_other_cells only when the design genuinely has no room and failing to place is the worse outcome; it always succeeds, but every cell it moves is a disturbance you did not intend.

33. Why is the fix order power → DRC → setup → hold → leakage?

Because DRC fixing is allowed to degrade timing, while setup and hold fixing are guaranteed never to degrade DRC. Fixing DRC before timing means a later timing fix cannot silently reopen a DRC violation you already closed; reversing the order risks exactly that.

34. When is a load-capacitance cell the right hold fix instead of a buffer?

For a very small hold violation, on the order of five picoseconds or less. A buffer adds a full logic stage of delay, which typically over-fixes a violation that small and can turn it into a new setup violation on the same path. A load cell adds just enough capacitance without adding a stage.

35. When do you reject an ECO change rather than the placement?

When report_eco_physical_changes, before placement, or epl_max_displacement_cells after it, shows a displacement so large it is telling you something about the change itself, not just this placement attempt. At that point, revert_eco_changes and re-deriving the fix is the right move, not tuning the legalize mode further.

36. Why can't -displacement_threshold be combined with -legalize_mode allow_move_other_cells?

Because allow_move_other_cells is defined to always find a legal location by moving whatever is in the way — there is no concept of “too far, so reject it” in that mode, since the mode's entire purpose is to never reject. A threshold has nothing to check against.

37. Why does ECO Fusion need check_consistency_settings specifically, and not just a clean eco_opt run?

Because ECO Fusion's convenience depends on ICC2's postroute timing settings genuinely matching PrimeTime's. A clean eco_opt run only proves the fusion flow's own view is self-consistent, not that it matches a standalone PrimeTime signoff run, which is the actual signoff authority.

38. Why does the LEQ path exist, if same-name spare mapping is simpler?

Because a same-name spare of the exact cell type is not always nearby, but a different-named cell computing the same logical function often is. create_freeze_silicon_leq_change_list lets a freeze-silicon ECO succeed without an exact type match, at the cost of an extra generation step.

39. What makes a PSC reduce mask cost compared to a fixed-function spare?

A PSC's transistor-level shape is fixed at tapeout, same as any other cell; only the metal and via layers above it change when it is programmed. That metal-only change is exactly what a freeze-silicon ECO can make without a new mask set; a different fixed-function spare's silicon might force one.

40. Why is eco.placement.optimized_legalization relevant even if you never set it directly?

Because setting -displacement_tolerance_level on place_eco_cells forces this application option to true regardless of its prior value. A change made through one command's option can silently change a different command's default behavior later in the same session — which is why this chapter's command-verification discipline checks the full argument description, not just the option's name.

Senior / architect, 5 questions

41. How do you decide between a freeze-silicon ECO and a new mask set?

Run check_freeze_silicon first: if every ECO cell maps, same-name or by logic equivalence, the freeze-silicon path is almost always cheaper than a new mask set. The decision tips toward a new mask set when a meaningful fraction of cells come back unmapped — an engineering and cost decision, not a tool command.

42. Who owns the decision that an ECO is too disruptive?

The person who receives the epl_max_displacement_cells report should not unilaterally push through with allow_move_other_cells. That decision belongs to whoever owns the schedule and physical-verification risk for the block — a disruptive change deserves design-review visibility, not a placement-option choice made alone at a terminal.

43. How do you keep a signoff ECO loop from iterating forever?

Fix in the documented priority order every time, so earlier steps cannot be silently reopened later. Use estimate_eco to screen candidates before a full incremental update, and track convergence explicitly — Dashboard 4's iteration-by-iteration WNS and TNS shows whether the loop is closing or oscillating, not just one final number.

44. What do you archive so a later engineer can reconstruct what this ECO did and why?

The PrimeTime change file (pt_eco.tcl), the layout-editing record from record_layout_editing -stop -output, the readiness and change-inventory dashboards from before the ECO started, and the blast-radius numbers from after. Together these let a later engineer reconstruct not just what changed, but why it was judged acceptable at the time.

45. What did this chapter, and this guide, teach end to end?

The guide taught how to build a chip: floorplan shapes it, placement and optimization fills it, clock tree synthesis gives it a trustworthy clock, routing and postroute optimization connects it, chip finishing makes it manufacturable, and hierarchical implementation shows how to do all of that at a scale too large for one flat run. This chapter taught what happens the day after that is declared done and something still has to change, using a fact one of the earlier chapters established at every step. Building and repairing a chip, in this guide, were never two separate skills.

Cross-chapter questions, gathered

Six questions above cross back to earlier chapters explicitly. Q19 depends on Chapter 6's chip-finishing fill discipline for why tied inputs matter electrically. Q29 depends on the filler/spare distinction Chapter 6 established during density signoff. Q32 and Q35 depend on the placement-legality vocabulary Chapter 4 built. Q41 depends on the block-boundary constraints Chapter 7's hierarchical implementation drew. And Q45 depends on all seven chapters at once, by design, as this chapter's closing question.