Target-Based & Rapid Optimization

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

Optimizing Toward a Target, Not Just "As Good As Possible"

Left unconstrained, an optimizer tries to push every metric as far as it can, which wastes runtime and power chasing slack you do not need and area you cannot afford. Target-based optimization flips this: you tell the tool the specific endpoint you want — a frequency, a slack figure, a power ceiling, a list of paths to fix — and it works to reach that target and stop, spending effort only where the target is not yet met. This matters for three reasons: it bounds runtime (no endless polishing of already-passing paths), it avoids over-optimization (cells stay no bigger than needed, protecting power and area), and it makes results predictable and reproducible.

Generating and Using a Target File

The instructions for a target-based run are usually captured in a target file — a structured description of what to fix and to what level. It can list specific failing paths, endpoints, or path groups and the slack each must reach. The big advantage is focus: instead of re-optimizing the whole block, the tool concentrates on exactly the items in the file. There are a few ways to produce one:

• From a timing-debug session: after analyzing where the design fails, export the offending paths/ endpoints into a target file so the next optimization pass attacks precisely those.
• From a generation step: the tool can generate a target file from current violations automatically.
• By hand: a designer can author or trim the list to prioritize what matters. # Generate a target file from the current violations # illustrative — generic, not tool-specific generate_target_file -from_violations -out close.tgt # Optimize against that target and stop when met # illustrative — generic, not tool-specific optimize_timing -target_file close.tgt -stop_when_met true A consistent naming convention for the objects in the target-based flow (paths, groups, generated nets/cells) keeps large runs auditable — you can tell which fixes came from which target list, and re- run a subset cleanly.

Rapid Optimization for Prototyping

Early in a project you do not want a full-effort, hours-long optimization — you want a fast, approximate answer to questions like "is this floorplan feasible?" or "roughly where does timing land?" Rapid (prototype) optimization trades accuracy for speed: lighter effort, coarser analysis, fewer passes, so you get directional QoR in a fraction of the time and can iterate on big decisions before committing to full closure.

# Quick, low-effort pass for design-space exploration
# illustrative — generic, not tool-specific
optimize_timing -mode rapid -effort low
report_qor -brief

The mental model: rapid mode is for decisions (which floorplan, which budget), full mode is for closure. Acting on rapid-mode numbers as if they were signoff-accurate is the classic misuse.

Footprints and the Footprintless Flow

Optimization constantly swaps one cell for another — a different size or Vt. For a swap to be safe late in the flow it must be footprint-compatible: same physical area and pin layout, so it drops in without disturbing placement or routing.

• Using cell footprints: the library declares which cells are interchangeable (same footprint), and the optimizer restricts late-stage swaps to those groups, keeping changes non-disruptive.
• The footprintless flow: where the library does not provide formal footprint groupings, the tool infers compatibility on the fly (matching area and pin geometry), so footprint-aware optimization still works without a curated footprint definition. This removes a library-prep dependency at the cost of relying on inferred equivalence. # Restrict swaps to footprint-compatible cells # illustrative — generic, not tool-specific set_optimization_swap_scope -footprint_compatible true # Let the tool infer compatibility when footprints are not declared # illustrative — generic, not tool-specific set_optimization_swap_scope -infer_footprints true Flow Needs library footprint groups? Trade-off Footprint-based yes curated, predictable swaps Footprintless no inferred equivalence, less prep

Interview Q&A

Because open-ended optimization wastes runtime polishing passing paths and over-sizes cells, hurting power and area. Target-based optimization reaches a stated goal and stops, giving predictable runtime, controlled power/area, and reproducible results.

(often from a timing-debug session) and point the optimizer only at them, so effort concentrates on the real problem instead of re-churning the whole block — faster and less disruptive.

design-space decisions (floorplan feasibility, rough budgets) where you need directional QoR quickly. The danger is treating its approximate numbers as signoff-accurate; use full effort for actual closure.

disturbing placement/routing. The footprintless flow infers that compatibility from cell area and pin

geometry when the library has no declared footprint groups, enabling footprint-safe optimization without that library-prep step.

Key Takeaways

• Target-based optimization drives to a stated goal and stops — bounding runtime and protecting power/area versus open-ended pushing.
• A target file (from timing debug, auto-generation, or by hand) focuses optimization on exactly the paths that matter; consistent naming keeps runs auditable.
• Rapid/prototype optimization is for fast, directional decisions; never mistake it for signoff accuracy.
• Late swaps must be footprint-compatible; the footprintless flow infers that compatibility when the library lacks footprint groups.