The Optimization Problem & Where It Runs

Pre-CTS, post-CTS, post-route optimization, useful skew, SI fixes, leakage reduction and ECO closure

Chapter 1 — The Optimization Problem & Where It Runs in the

Flow

Optimization is the beating heart of physical implementation. Synthesis hands you a netlist that is logically correct; placement and routing give that netlist a physical existence on silicon. But correctness on paper and a manufacturable, timing-clean, power-efficient layout are very different things. Optimization is the iterative machinery that closes the gap — and understanding what it does, where it runs, and why the cost of a fix explodes as you move down the flow is the single most useful mental model an implementation engineer can carry into a design-closure war room or an interview. This chapter builds that model from first principles. We will deliberately stay vendor-neutral: there are many implementation tools and many optimization engines, but they all solve the same problem and obey the same physics. We refer to whatever you are running as the implementation tool and to its inner restructuring brain as the optimizer.

What "Optimization" Actually Means

At its core, optimization is a constrained search. The optimizer is handed a design state and a set of targets, and it is allowed to make a bounded set of transforms to the netlist and its physical realization

until the targets are met — or until it gives up and reports what remains. The transforms fall into a small, recurring vocabulary:

• Sizing — swapping a cell for a larger or smaller drive-strength variant, or a higher/lower threshold- voltage (Vt) flavor.
• Buffering / repeater insertion — adding buffers or inverter pairs to drive long nets or split high- fanout loads.
• Restructuring — re-decomposing combinational logic: cloning a driver to relieve fanout, remapping a cone of logic, balancing a tree, pulling logic across a register boundary.
• Pin swapping — commuting equivalent inputs so the late-arriving signal takes the fastest path through a gate.
• Layer / topology adjustment — promoting a critical net to a wider/upper metal layer, or rerouting to reduce coupling.
• Clock adjustment — useful skew (intentionally advancing or delaying a clock edge at a register) and, indirectly, changes that affect the clock tree. Critically, every transform must leave the design legal. A buffer that is inserted must land on a legal placement site; a rerouted net must obey design rules; a resized cell must still fit. Optimization that produces an illegal layout is not optimization — it is a problem deferred. The optimizer therefore always operates as a legality-preserving loop: propose a transform, evaluate its effect on the objectives, accept or reject, repair legality, repeat.

The Objective Functions

Optimization is multi-objective. The five quantities the optimizer is forever juggling:

enough after the edge?

leakage

Area Silicon footprint / cell-area sum Total standard-cell area, utilization −50 ps and TNS of −80 ps has essentially one bad path. A design with the same WNS but TNS of −40 ns has thousands of sick paths and a systemic problem. Interviewers love this distinction because it separates people who chase one path from people who triage a design. A subtle but important point: setup and hold are opposite-edge checks. Setup asks whether data launched on one clock edge arrives at the capture flop before the next capturing edge — it is a check against the slowest path and is verified at the slow (late) corner. Hold asks whether data does not arrive too soon and corrupt the value being captured on the current edge — it is a check against the fastest path and is verified at the fast (early) corner. This is why setup and hold pull in opposite directions: making a path faster helps setup but hurts hold, and vice versa. The DRV (design-rule violation) objectives — transition, capacitance, and fanout — are different in kind: they are not timing checks at all but electrical health limits the library guarantees its cells were characterized within. A net that violates max_transition is not merely slow; its delay and power numbers are untrustworthy because the cell was never characterized at that slew. Fixing DRVs is therefore a prerequisite for believing any timing number, which is why the optimizer typically cleans DRVs alongside, and sometimes ahead of, timing. These objectives trade off against each other, and the optimizer must be told the priority order. The classic tensions:

Objective vs The conflict Objective

Setup ↔ Power/ Upsizing and buffering to fix setup adds capacitance, dynamic power, leakage, and area

Setup ↔ Hold Speeding a path for setup can create a hold violation on a short path sharing logic;

Leakage

The objective-to-lever mapping is worth memorizing, because in an interview you will be asked "the path is failing setup by 200 ps — what do you do?" and a crisp answer walks the levers in order of cost:

restructure logic → useful skew → layer promotion

Hold Insert delay/buffer cells on short paths → downsize aggressive drivers → reroute for added

Transition/ Upsize driver → insert buffer → split fanout → reduce wire length

power

Area Downsize slack-rich cells → remove redundant buffers → remap logic Optimization does not run once. It runs in distinct modes at distinct points in the flow, and each mode operates under a fundamentally different model of reality. The defining variable is how the clock is modeled, because the clock determines how much freedom the optimizer has and how much damage it can do.

PRE-CTS — IDEAL CLOCK, MAXIMUM FREEDOM

Before clock-tree synthesis (CTS), there is no physical clock network. The optimizer assumes an ideal clock: zero skew, an idealized insertion delay, and a single estimated clock uncertainty that stands in for skew and jitter you haven't built yet. This is the optimizer's playground. It can restructure aggressively, clone registers, retime across boundaries, and move logic freely, because nothing downstream depends on a clock tree that doesn't exist yet. Setup is the dominant target here. Hold is largely deferred — fixing hold against an ideal clock is wasted effort, since the real skew from CTS will reshape every hold relationship.

POST-CTS — PROPAGATED CLOCK, TREAD CAREFULLY

After CTS, the clock is propagated: real buffers, real insertion delay, real skew, real clock-network power. The optimizer now sees true launch/capture relationships. Both setup and hold become firstclass objectives — this is where the bulk of hold fixing happens, against the actual skew. But freedom is curtailed: the optimizer must avoid transforms that disturb the clock tree's balance. Moving a flop changes its clock latency; cloning a register adds a clock sink the tree wasn't built for. So post-CTS optimization leans on the datapath — sizing, buffering, useful skew within the budget the tree already provides — and treats the clock network as something to protect, not rebuild.

POST-ROUTE — REAL PARASITICS & SI, SURGICAL ONLY

After detailed routing, you finally have extracted parasitics (real R and C from real wires) and signal- integrity (SI) effects: crosstalk-induced delay and noise from coupling between adjacent nets. This is the most accurate — and most constrained — world. Every change risks ripping up routes, disturbing neighbors, and creating new SI victims. Optimization here is surgical: localized resizing, spot buffering with minimal reroute, layer/spacing tweaks on the few remaining offenders, targeted hold fixes. You do not restructure cones of logic post-route; you fix what is left with a scalpel.

Why the Same Fix Is Cheap Early and Expensive Late: Blast Radius

Here is the central intuition the whole chapter has been building toward. Consider one fix — say, upsizing a critical buffer.

• Pre-CTS: placement is coarse, nothing is routed, the clock isn't built. Upsize the cell, nudge a few neighbors to make room, re-estimate. The blast radius — the set of design objects disturbed by the change — is tiny and cheap to repair.
• Post-CTS: now the cell sits in a placed, clock-aware design. Upsizing may shove a neighbor whose clock latency then shifts, perturbing the carefully balanced tree. The blast radius now includes clock timing.
• Post-Route: the cell is routed, surrounded by routed neighbors, with extracted parasitics and coupling. Upsizing forces a reroute, the reroute disturbs adjacent nets, those nets' SI changes, their delays change, and you may have created new violations while fixing one. The blast radius is enormous.

The cost-by-stage table that every closure engineer carries in their head: Cost of a

Stage Why

The practical lesson: push fixes as far left in the flow as you possibly can. A budget problem solved pre-CTS by restructuring is nearly free; the same problem dragged to post-route may cost days and still not close. This is why senior engineers obsess over front-loading effort and arriving at CTS with healthy slack. There is a second, more insidious dimension to blast radius: convergence risk. A pre-CTS fix that fails simply leaves you where you started — the design is still flexible and you try again. A post-route fix that fails can spawn new violations faster than it closes old ones: you reroute net A to fix its timing, the reroute couples into net B, B's crosstalk delay now violates, you fix B and disturb C, and the design "chases its tail" without ever converging. Experienced engineers watch the trend of WNS/TNS and violation count across optimization passes, not just the absolute numbers — a design where each pass trades one violation for another is telling you the problem is structural and belongs upstream, no matter how surgical your edits are. Recognizing non-convergence early, and having the discipline to escalate it to a budgeting or floorplan decision rather than grinding on local fixes, is one of the clearest markers of a senior implementation engineer.

Prerequisites Before You Optimize

The optimizer is only as good as the inputs you feed it. Garbage prerequisites produce confidently wrong results — the worst kind. Before any optimization run, confirm:

• Legal placement (and, for late stages, legal routing). The optimizer extends a legal state; it cannot start from an illegal one.
• Valid, complete constraints. All clocks defined, I/O delays set, false paths and multicycle paths declared, exceptions sane. An unconstrained path is invisible to the optimizer; an over-constrained one wastes effort chasing impossible targets.
• Clean libraries. Correct, characterized timing/power libs for every cell, with no missing arcs and matching the corners you intend to sign off on.
• Defined modes and corners. The set of operating modes (functional, test, etc.) and PVT corners must be declared so the optimizer optimizes for the right worst case, not a single nominal point.
• Trustworthy parasitics for the stage. Estimated (virtual route) pre-route; extracted post-route. Optimizing post-route against estimated parasitics is self-deception. A useful interview line: "I never trust an optimization result until I've confirmed the constraints and corners that produced it — a beautiful WNS against a broken SDC is worse than an honest violation."

Generic Command Sketch of Running Optimization at Each Stage

Below are illustrative flows. SDC constraint commands are industry-standard and portable; the optimization invocations are generic pseudo-commands that stand in for whatever your tool calls them.

Notice how the effort knobs shift across stages: setup and restructuring dominate pre-CTS; hold and useful skew enter post-CTS; SI and minimal-reroute surgery define post-route. The constraints (clocks, exceptions, DRV limits) stay constant — what changes is the model of reality and the permitted aggressiveness.

Interview Q&A

non-invasive: pin-swap so the late input takes the fast arc, and downsize off-critical loads on the path to lighten capacitance. Then upsize the critical cells and spot-buffer any long nets. If still short, consider useful skew — borrow time by advancing the capture clock or delaying the launch, within the tree's budget — and layer-promote the dominant net to cut wire RC. I keep restructuring off the table post-route because of the blast radius; if 200 ps genuinely needs restructuring, that's a signal the fix belonged pre-CTS and I'd flag the budgeting upstream.

zero real skew. Hold relationships depend on the actual clock-arrival difference between launch and capture flops, which only exists after CTS builds the tree. Fixing hold against an ideal clock optimizes for the wrong skew — CTS will then change every hold relationship, wasting your inserted delay cells and possibly creating new violations. Hold is therefore primarily a post-CTS and post-route job.

does your strategy change? A: WNS is the single worst path; TNS is the aggregate violation across all failing endpoints. Same WNS with vastly larger TNS means one design has a systemic, broad failure — thousands of sick paths — versus a single outlier. Strategy absolutely changes: the low-TNS design needs a surgical fix on one path; the high-TNS design points to a structural cause — a bad budget, a missing constraint, a slow region, an under-sized clock — that I'd attack at the source rather than path-by-path.

The prerequisites. Most likely the constraints or corners were wrong — a missing or mis-set exception (false/multicycle path) hiding a real path, an unconstrained path the optimizer never saw, or sign-off against the wrong PVT corner. Next suspect is stale or estimated parasitics standing in for the real extracted ones, or a library mismatch. A clean WNS is only as trustworthy as the SDC, libs, and corners behind it — I'd re-audit those before believing the number.

Key Takeaways

• Optimization is a legality-preserving, multi-objective search: it sizes, buffers, restructures, pin- swaps, and skews the design to meet setup, hold, DRV, power, and area targets while keeping the layout legal.
• The clock model defines the mode. Pre-CTS assumes an ideal clock and grants maximum freedom; post-CTS works against a propagated clock and must protect the tree; post-route adds real parasitics and SI and demands surgical edits.
• WNS vs TNS distinguishes a single bad path from a systemic problem — and dictates whether you reach for a scalpel or a root-cause investigation.
• Objectives trade off: every setup fix costs power and area; every hold fix can threaten setup; leakage and dynamic power pull in opposite directions. Know the lever order.
• Blast radius grows down the flow. The same fix is cheap pre-CTS and expensive post-route — so push fixes as far left as possible and arrive at CTS with healthy slack.
• Trust nothing without prerequisites: legal placement/route, valid constraints, clean libs, and defined modes/corners. A clean WNS against a broken setup is worse than an honest violation.