Level 2: Construction & Debugging

Intermediate PnR (Place & Route) Interview Questions

Learn pre-floorplan sanity checks, structural netlist integrity, SDC application, clock definitions, and floorplanning tradeoffs.

0 of 222 marked complete

Want all 1109 answers offline as 4 PDF books?

See the 4-book bundle · ₹349 Physical Design & Planning Handbook Complete library

What to practise at this level

Learn pre-floorplan sanity checks, structural netlist integrity, SDC application, clock definitions, and floorplanning tradeoffs.

01 Why are input and output delays needed, and what do min and max mean?Intermediate: Input and output delays exist because your block doesn't operate in isolation — timing "outside the box" (the external device driving into your input, or the external device receiving from your output) has to be modeled relative to your reference clock, or the block-level timing analysis is meaningless. An input delay says "here's when data launched externally can reach my input pin" — think of it as pre-paid budget already spent before the signal even crosses your boundary, leaving less time for your internal logic to work with.
02 What clock information must be available before physical design?Intermediate: Before PD can start, you need a complete "clock passport" for the design: every real clock source (PLL outputs, crystal-derived clocks, external clock pins), every generated clock (dividers, multipliers) and its exact relationship to its master clock, and the waveform/uncertainty assumptions that apply in each operating mode. A **generated clock** isn't automatically asynchronous to its parent just because it's divided — the master/source/edge relationship has to be explicitly declared (`create_generated_clock -source -divide_by`, etc.) so STA compares the right launch and capture edges; get this wrong and you'll either miss real timing paths or create phantom violations on paths that are actually safe.
03 What are TLUPlus and RC technology files, and why is a layer map needed?Intermediate: Cell timing models tell you how a gate behaves, but they say nothing about the wires connecting gates — and wire geometry adds both delay and load, so you need a separate model for that. A wire's electrical behavior depends on its shape and its neighbors: a long, thin wire behaves very differently from a short, wide one, and a nearby parallel conductor changes its effective capacitance.
04 How is an RC technology file different from SPEF?Intermediate: Think of an RC technology file (like TLUPlus) as a recipe for calculating parasitics, reusable across any design on that process — SPEF is the finished dish: the actual extracted parasitic values for one specific design's nets. The extractor combines the technology recipe with your design's real layout geometry to produce that design-specific result, complete with net names, connections, and R/C values in whatever naming and unit convention the receiving timing flow needs to interpret correctly.
05 What are PVT corners, modes, and MMMC scenarios?Intermediate: A mode describes *how* the design is operating (functional, scan-shift, test); a corner describes the *analysis conditions* (process/voltage/temperature plus the RC model); a scenario is simply one mode paired with one corner. Process, voltage, and temperature all shift cell delay, but interconnect matters too — a corner setup needs matching cell models, matching parasitic assignments, and whatever OCV/derating methodology the signoff plan requires.
06 What should an initial floorplan input contain?Intermediate: Think of the initial floorplan DEF/script as the physical envelope and ground rules that everything downstream (placement, routing) has to operate inside — it's the "site plan" before any construction begins. Typical contents: die and core geometry, legal standard-cell rows and sites, the routing track grid, macro positions and orientations, port/pin locations, and any relevant placement or routing blockages.
07 What files and information are required for SRAMs and other hard macros?Intermediate: A macro handoff isn't one file — it's a package: physical abstraction (size, pin shapes, obstructions) for placement/routing, timing views for interface behavior across every required operating condition, and a functional model for simulation or equivalence checks. A netlist black box with no supporting views is not a complete handoff — it's a placeholder that will silently break downstream analysis the moment someone assumes it's real data.
08 What does UPF contain, and why is it separate from the netlist?Intermediate: UPF captures power *intent*, not connectivity — which logic belongs to which power domain, how supplies and power states are modeled, and what protection strategies (isolation, retention) are required. When a power-gated block shuts off, its outputs can float to invalid values, so neighboring always-on logic needs isolation cells; a crossing between two different voltage domains needs a level shifter; registers that must remember their state through a shutdown need retention.
09 What scan and DFT information is needed for physical design?Intermediate: Scan chains exist to make internal registers reachable during manufacturing test — data shifts serially through them during scan-shift and exercises the circuit during capture. A scan-inserted netlist only tells you *that* registers are connected in a chain; SCANDEF is what actually supplies the chain's physical structure and the reordering constraints the physical-optimization flow is allowed to use.
10 Are VCD or SAIF files mandatory inputs to place and route?Intermediate: Switching-activity files are conditional, not mandatory — you can import and place a design without them, but you lose accuracy on anything activity-dependent, mainly dynamic power estimation and optimization. Dynamic power depends on how often a node switches, its capacitance, supply voltage, and frequency; VCD records every value change over time while SAIF summarizes activity over an interval — either way, the tool still has to successfully map that recorded activity onto the implemented netlist.
11 How do you check consistency across all input files?Intermediate: Checking each input file in isolation isn't enough — the real bugs live in the *relationships* between files, where each one is individually valid but they collectively describe different designs. Start with identity: does the top module, hierarchy, netlist revision, macro configuration, library release, and process/metal stack all point to the same intended design? A valid SDC for last week's netlist revision can be silently wrong for today's.
12 How do you debug unresolved references or missing library cells?Intermediate: "Unresolved reference" just means one thing: an instantiated design or cell name couldn't be bound to any actual definition — your job is to find out why, not to make the error message disappear. Start by pinning down the exact instance and the exact referenced name from the diagnostic, then classify it: is it supposed to be a standard cell, a hard macro, a hierarchical sub-block, or a deliberate black box?
13 How do you find missing constraints and unsafe timing exceptions?Intermediate: A clean slack summary can lie to you — paths that were never checked (missing clocks, missing I/O delays) or paths that got exception'd out of analysis entirely both disappear from the report without ever actually passing. Walk representative input-to-register, register-to-register, and register-to-output paths by hand, and confirm generated clocks actually reach their intended registers and that case analysis matches whatever mode is active.
14 In what order should inputs be loaded into ICC2?Intermediate: The core rule isn't a rigid fixed sequence — it's dependency order: nothing that annotates or constrains an object can be applied before that object exists and is identifiable. Start with library and technology context — create/open the design library with the correct reference libraries and technology file, since everything else depends on this foundation being right.
15 Which files are inputs, outputs, or conditional restart data?Intermediate: A file's role isn't fixed by its extension — it depends entirely on what stage you're at. A routed DEF or an extracted SPEF can be the *output* of one run and turn right around as the *input* to the next restart or analysis step. For a fresh implementation start, the core handoff is a mapped netlist plus approved library, technology, timing, and (where applicable) power data — the floorplan can be generated locally or imported, scan data matters only if scan optimization is required, and activity data matters only for the power tasks you're actually running.
16 The design loads and timing looks clean. Why can the inputs still be wrong?Intermediate: "It loaded" and "timing looks clean" are both weaker claims than they sound — loading only proves the tool accepted the data syntactically, and clean timing only proves the paths that *were* analyzed passed. Neither proves the files represent the chip you actually intend to build, and neither proves every case that needs checking was actually checked. Missing coverage is the most common trap: a missing generated clock means whole downstream paths never receive the clock-based checks they need — they just silently don't show up as violations because they were never analyzed at all. Similarly, an inactive slow-corner scenario can hide the exact violation that scenario would have caught.
17 What is a strong final input-readiness checklist for physical design?Intermediate: A real readiness review isn't a file checklist — it's asking whether the next stage can start *reproducibly*, with complete and internally consistent intent, and recording evidence and ownership wherever something's still unresolved. Check identity and connectivity first: approved top module and revision, matching libraries and macros, all references actually resolved, design counts as expected, and every connectivity warning explained rather than ignored.
18 What do routing-track pitch and offset mean?Intermediate: A track grid is just a simple arithmetic sequence: `coordinate = offset + k × pitch`, where k is an integer within the track count — pitch sets the spacing, offset sets where the very first line sits. That means a coordinate can be arbitrarily close to a track without actually landing on one — e.g. a value like 100 µm isn't automatically centered on a track just because it "looks round."
19 What are a placement site, a standard-cell row, and cell height?Intermediate: A placement site is the smallest reusable unit of legal placement geometry — a row is just that unit tiled repeatedly across the floorplan, and a standard cell has to occupy a whole number of compatible sites, in a legal orientation. For a simple single-height library, every cell shares the same row-compatible height but varies in width (e.g., roughly 0.192 µm site-width increments) — that width quantization is exactly what lets the placer snap cells onto a clean, regular legal grid.
20 How do manufacturing, placement, routing, and FinFET grids differ?Intermediate: These four grids each constrain a different thing, and satisfying one doesn't automatically satisfy the others: the manufacturing grid quantizes what coordinates are even representable, placement sites constrain legal cell origins, routing tracks suggest wire centerlines, and the FinFET grid constrains cell/boundary alignment to the fin pitch. The manufacturing grid is usually the finest of the four — being on it only means a coordinate is a legal, representable geometric step, not that it's a legal cell origin, and being on a legal placement site doesn't prove a pin is routable or that a macro boundary satisfies every device-alignment rule.
21 What are fin pitch, gate pitch, and contacted gate pitch in a FinFET technology?Intermediate: These three numbers all sound similar and all get reported in nanometers, but they're measuring completely different physical directions and features — mixing them up is a common and costly mistake when reading a process datasheet. **Fin pitch** measures center-to-center spacing between neighboring fins — the vertical silicon "fins" that run in one direction across the device.
22 Why is FinFET transistor width quantized by fin count?Intermediate: In a planar transistor, you can dial in channel width to almost any continuous value just by drawing it wider or narrower. FinFETs don't work that way — width comes in discrete steps because each additional "fin" (a thin vertical silicon fin) adds a fixed increment of effective channel width, and you can't have a fractional fin. A useful (simplified, teaching-level) approximation: effective width per fin ≈ 2 × fin height + fin top width — because the gate wraps around and controls both sidewalls of the fin plus its top surface, so all three contribute to the effective channel width.
23 How do you inspect and debug the FinFET placement grid in ICC2?Intermediate: Before touching any geometry, find out what grid is actually active — `report_grids -type finfet` shows the pitch, offsets, and whether a FinFET grid is even defined for your technology, and `check_finfet_grid` tells you exactly which violations exist. Read the violation carefully: an error on a macro boundary doesn't necessarily mean the macro's origin is wrong — a macro can have a perfectly legal origin and still fail because its width pushes the far edge off-grid.
24 How can a placement be legal on one grid but fail another grid or pin access?Intermediate: "Legal" isn't one property — it's the intersection of several independent grids and rules, and a cell/macro can satisfy some while quietly violating others. Think of it like a parking spot: fitting inside the painted lines (site grid) doesn't guarantee your door can open (pin-access grid) or that you're not straddling a fire lane (FinFET boundary rule).
25 What command order preserves the meaning of failures?Intermediate: Every sanity check depends on facts established by the check before it — run them out of order and a later "pass" can be meaningless, because it was built on unverified ground. Start with identity and libraries: confirm you're on the right design and the right library set before doing anything else.
26 How do you make a sanity script version-conscious?Intermediate: Don't hardcode command names or default behaviors into a sanity script — both can silently change between tool releases, and a script that assumes yesterday's defaults can pass or fail for the wrong reasons. A dependable script asks the installed tool what it actually supports before running: use `get_design_checks` to confirm which check bundles exist in this release.
27 What does dp_pre_floorplan actually prove?Intermediate: It's tempting to treat `dp_pre_floorplan` as a green light that says "your design is floorplan-ready" — it isn't. It's a narrow, specific technology-readiness check, and confusing "passed dp_pre_floorplan" with "ready to floorplan" is a common and costly mistake. Concretely, it checks technology-file information and routing-layer directions — including confirming that both horizontal and vertical routing layers actually exist in your tech setup.
28 How should ICC2 inventory be reconciled with synthesis reports?Intermediate: Don't compare one giant total from synthesis against one giant total from ICC2 and call it a day — that hides exactly where the discrepancy is coming from. Compare like-for-like scope and object class: registers against registers, combinational logic against combinational logic, memories against memories, macros against macros.
29 Why separate sequential, combinational, memory, and macro inventories?Intermediate: A single "total cell count" number hides a lot — 50,000 total cells could be almost all combinational logic, or it could include a handful of huge memory macros that dominate area and power while contributing almost nothing to that count. Splitting into sequential, combinational, memory, and macro inventories lets you catch specific problems: a suspiciously low sequential count might mean a missing scan chain or an unlinked clock domain; a memory count that doesn't match the architecture spec might mean a missing or duplicated memory instance.
30 How do you distinguish an intentional open from broken connectivity?Intermediate: Not every unconnected pin is a bug — some are deliberately left open by design intent, a tie-off policy, or a black-box boundary that simply doesn't drive that signal in this configuration. The test isn't "is it open?" — it's "can I trace this open back to a documented, recorded reason?" An intentional open should have a paper trail: interface documentation, a tie-off strategy, or a synthesis log entry explaining why that pin is unconnected.
31 What evidence makes a black-box waiver defensible?Intermediate: A "waiver" to keep a macro as a black box isn't just a verbal agreement — it needs to produce concrete artifacts that another engineer could pick up and verify independently. At minimum you need: approved pin identity (an agreed, versioned pinlist — not a draft that might still change), a documented timing-boundary treatment (how the interface is constrained — as a real .lib, an estimated wireload, or a placeholder budget), and confirmation of which logical/physical views the next stage actually requires (do you need a .lib only, or also a LEF/abstract for placement?).
32 How do you detect the wrong same-named library cell?Intermediate: Trusting an instance's reference-cell text string ("this is a NAND2X4") is not the same as verifying it's actually pointing at the NAND2X4 you think it is — the same name can resolve differently depending on reference-library search order. Correlate the actual reference-library resolution order used at the time this instance was placed/optimized — a change in `search_path` or `set_ref_libs` order between two runs can cause the same cell name to bind to a different library version.
33 How do you find unit mismatches across SDC and libraries?Intermediate: Unit mismatches are a sneaky bug class because everything still "runs" — the tool doesn't error out, it just silently computes with the wrong scale factor, and you only notice when timing numbers look absurdly good or absurdly bad. Start at the source: check `set_units` in the SDC (time, capacitance, resistance, voltage, current, power) against the corresponding unit declarations in each Liberty (.lib) file — SDC commonly uses nanoseconds while some libraries are characterized in picoseconds, and a 1000x factor slipping through unnoticed is exactly the kind of thing that turns a real violation into apparent huge positive slack (or vice versa).
34 Which constraints belong to modes, corners, scenarios, or the netlist?Intermediate: This is really about knowing the MCMM (multi-mode multi-corner) vocabulary well enough to file each constraint in the right bucket — get the bucket wrong and you either apply a constraint where it shouldn't count, or fail to apply it where it should. **Modes** capture functional intent — things like clock definitions, generated-clock relationships, I/O timing, and functional exceptions (false paths, multicycle paths) that describe *what the chip is doing* in this operating state (functional, test, low-power, etc.).
35 Why inspect active analysis types in each scenario?Intermediate: A scenario is just the active pairing of one mode with one corner — but the scenario existing in the database says nothing about whether it's actually doing useful work. Setup, hold, or other required analysis can be individually turned off inside a scenario that otherwise looks perfectly configured and named correctly.
36 What should be reviewed after read_sdc applies a file?Intermediate: Parsing success is the first gate, not the finish line — an SDC file with zero syntax errors can still leave the design under-constrained or misconstrained. Review the errors and warnings first, then dig into the object-resolution messages specifically — those tell you whether every `get_pins`/`get_clocks`-style selector actually found real objects, or silently matched nothing.
37 How do renamed or optimised-away objects break constraints?Intermediate: The hierarchy and instance names you see after synthesis can drift meaningfully from the original design intent — modules get flattened, renamed, or merged during optimization. When a constraint selector (like a wildcard `get_cells` pattern) was written against the intent-source names, it can silently resolve to the wrong objects — or to nothing at all — after that renaming happens.
38 How do you audit wildcard selectors safely?Intermediate: A wildcard's whole appeal is convenience — one pattern can select many objects at once — but that same convenience is exactly what makes it dangerous when the pattern quietly grows past the boundary you actually intended. Before applying a constraint through a wildcard, measure the resulting collection size — don't just trust that the pattern "looks right."
39 How do you validate clock period and waveform?Intermediate: Two clocks can have the exact same period and still be completely different signals — the **waveform** (where the rising and falling edges actually sit inside that period) is what determines when your active clock edge really happens. Start with the period: compare what's reported (from `create_clock -period`) against the interface spec for every mode the chip supports — functional, test, low-power, etc. A clock that's correct in functional mode but wrong in scan mode will pass some checks and silently break others.
40 How do you debug a generated clock's source and master?Intermediate: A generated clock's SDC declaration is only as trustworthy as the real logic it claims to describe — everything you report about it (its master, its source pin, its target pin, its divide/multiply factor, its phase, its edge mapping) has to actually match what the netlist implements. Start by confirming the declared master clock is the genuine upstream clock this signal is derived from — not a plausible-sounding but incorrect clock that happens to share a similar name.
41 How do you prove clocks reach sequential clock pins?Intermediate: This is fundamentally a connectivity-proof exercise: you're not asking "is timing good?" yet — you're asking the more basic question "does every flip-flop that's supposed to be clocked actually have a clock signal reaching its CP/CK pin at all?" The standard tool for this is a **no_clock check** — most STA/PD tools flag any register whose clock pin has no active clock propagating to it, which usually means either a genuine connectivity bug (a broken net, an unintended tie-off) or a legitimate case like a register that's intentionally clocked by a gated/disabled clock in the current mode.
42 What does multiple clocks at one register clock pin mean?Intermediate: Seeing two clocks land on one register's clock pin isn't automatically a bug — it can be a completely valid mode-multiplexed design (e.g. a MUX choosing between a functional clock and a test clock). But it can just as easily mean the tool genuinely believes two clocks are simultaneously active at that pin — which is a real problem, not a modeling quirk.
43 How do you audit clock groups and inter-clock relationships?Intermediate: Every `set_clock_groups` declaration (asynchronous, exclusive, or logically_exclusive/related) directly determines which clock-domain crossings the tool will even attempt to analyze — get this wrong and you're not analyzing what you think you're analyzing. An "asynchronous" group declaration tells the tool two clocks have no fixed phase relationship, so it won't check timing across that boundary at all — appropriate for a genuine CDC crossing with proper synchronizers, completely wrong if the two clocks actually do have a real timing relationship in some mode.
44 Why are clocks normally ideal before floorplanning?Intermediate: Before a clock tree is actually built and routed, there's simply nothing to measure — no buffers, no real wire delay, no real skew between branches, because CTS hasn't happened yet. Treating the clock as "ideal" (zero or user-specified latency, no built-in skew) isn't a shortcut or a cop-out — it's an honest reflection of what's actually known at that stage of the flow.
45 How do source and estimated network latency differ pre-floorplan?Intermediate: Think of clock latency as having two legs of a journey: **source latency** is the trip *before* the clock even reaches your block — from the true clock origin (PLL, oscillator, or an off-chip source) to the point where your design's clock port sees it. **Network latency** is the trip *inside* your block — from that entry point through the clock tree to each flip-flop's clock pin.
46 How should pre-floorplan clock uncertainty be reviewed?Intermediate: Clock uncertainty is a margin, and margins are easy to double-count if you're not disciplined about what each piece is actually covering — so the review is really about making sure every dollar of margin is spent exactly once. Break it into its real components: **jitter** (cycle-to-cycle timing noise from the clock source/PLL), **modeling/methodology margin** (a deliberate pad added because pre-CTS estimates are inherently imprecise), and the **setup vs. hold split** — many methodologies apply different uncertainty values for setup checks versus hold checks, since hold margin needs are structurally different.
47 Why check clock transition before CTS?Intermediate: Clock transition (slew) is just the rise/fall time at a clock pin — how fast the signal ramps from low to high or high to low — and it directly drives cell delay calculation for every gate the clock touches. Before CTS exists, there's no real clock tree with real buffers driving real wire capacitance, so any transition value you see pre-CTS is an **assumed input**, typically set via `set_clock_transition`, not something measured from actual routed geometry.
48 How do you audit input-delay min and max completeness?Intermediate: Every timed input port needs both a min and a max input delay — skipping one isn't "conservative by default," it just leaves that side of the timing check unconstrained. Max input delay models the latest possible external arrival, which drives setup analysis at the internal capture flop; min input delay models the earliest possible arrival, which drives hold analysis.
49 Why should input delay not be applied indiscriminately to clock ports?Intermediate: A clock port isn't ordinary launched data — it's the time reference that every other path in the design is measured against, so treating it like any other input is a category error, not just a minor constraint mistake. `set_input_delay` says "this signal arrives relative to some clock, with this much delay" — but applying that to the clock signal itself creates a circular, nonsensical statement: you'd be defining the clock's arrival relative to itself (or another clock) as if it were ordinary data.
50 How do you audit output-delay constraints?Intermediate: `set_output_delay` describes what happens *outside* your block's boundary — specifically, the receiving device's early and late timing requirements relative to its own reference clock. Min and max values aren't interchangeable defaults — they represent the receiver's best-case and worst-case requirement, and both need to be explicitly verified, not just one "typical" number.
51 When should a driving cell be used instead of set_input_transition?Intermediate: Both options exist to answer the same question — "how fast is the signal arriving at this port?" — but they answer it in fundamentally different ways, and picking the wrong one for your methodology creates inconsistent, hard-to-debug timing. A driving cell (`set_driving_cell`) tells the tool "model the source as if a real library cell of this type is driving this port," which lets the timing engine compute a realistic, load-dependent output slew from that cell's own characterized behavior.
52 How do you verify output loads?Intermediate: An output load value represents what your block has to drive once its signal leaves the boundary — the receiver's input capacitance plus whatever the package/board adds on top. A realistic number comes from the actual receiver device and package assumptions, not a rule-of-thumb default carried over from a different interface.
53 How do you audit false paths without masking real timing?Intermediate: A false path declaration is a powerful tool — and like any powerful tool, it's easy to misuse as a way to make an inconvenient timing violation disappear rather than to correctly describe a functionally impossible path. Start by checking exact membership: does the `-from`/`-through`/`-to` specification match precisely the path that's actually functionally impossible, or is it broader than intended and quietly swallowing real paths along with it?
54 How do you audit multicycle setup and hold intent?Intermediate: A multicycle path is one that's functionally allowed more than one clock cycle to complete — but `set_multicycle_path` is not a tool for making slow logic pass; it only encodes a cycle relationship that has to be true by design. Start by confirming the functional cycle relationship itself — how many cycles is this path actually allowed, and why, based on the real protocol (e.g., a configuration register that only changes every N cycles)?
55 How do you select target utilisation without using a universal percentage?Intermediate: Treat target utilisation as a hypothesis you test, not a rule of thumb you copy from the last project — "70% because that's what we always use" is exactly the trap this question is probing. Start from actual counted standard-cell area, then layer on everything that eats into usable space: macro footprint and its dead channels, expected late-stage cell-count growth, physical-only cells (tap/endcap/filler), hold and clock buffering headroom, spare-cell allocation for ECO, and PG-grid reservation.
56 Why does a macro-dominated block need different area reasoning?Intermediate: Once a handful of large hard macros dominate a block, the floorplan is no longer an area math problem — it's a packing/geometry problem, and treating it like the former is how blocks come back "infeasible" after synthesis-level area budgeting looked fine. Think of it like trying to pour sand (standard cells) around bricks (macros) already sitting in a box — the bricks' exact shape, legal rotations, which side their pins face, and the channels you must leave for routing determine the box size, not some average density number.
57 How do you test floorplan sensitivity to cell-area growth?Intermediate: The real question engineers ask is: "if the netlist grows by X%, does my floorplan still work?" — this is about turning that worry into a number, not a guess. Take the current counted standard-cell area and apply the growth assumption (an RTL change, a late feature add, a resynthesis with a less-friendly library). Example: 600,000 um² growing 8% becomes 648,000 um².
58 How do you compare equal-area floorplans with different aspect ratios?Intermediate: Equal area is a trap if you stop there — two floorplans with identical core area can behave completely differently in routing and timing, because area only tells you total *capacity*, not *geometry* (how far things actually have to travel). Set up a fair experiment: same macro set, same constraints (SDC, PG assumptions), same evaluation settings, and only the aspect ratio (width:height) varying between the two shapes you're testing — anything less controlled and you can't attribute differences to the shape itself.
59 How do you calculate and round a core and die consistently?Intermediate: Rounding core/die dimensions isn't a cosmetic formatting step — every snap to a legal grid or row/site multiple is a real physical decision that shifts area and utilisation, so it has to be done deliberately, not left to whatever the tool defaults to. Start with the ideal core dimensions from your area math, then snap width and height to legal manufacturing grid values and to whole row/site multiples — you can't have a half-row hanging off the edge.
60 How do you debug rows created with the wrong site?Intermediate: A "site" defines the legal placement grid a row is built on — its width, height, and which cell classes can sit there. If the row's site doesn't match what your target cells expect, the tool will refuse to legalize them even though the row visually looks fine. Start narrow: pick one cell that's failing to legalize and one row it's supposed to sit in, then directly compare their site names — this is almost always where the mismatch is hiding, rather than some deeper floorplan issue.
61 How do you decide whether a row fragment is useful?Intermediate: A row fragment reported by the tool is only "usable capacity" if a real cell can actually legally land there — the tool counting it toward total row area doesn't mean it's actually placeable. Check four things together: the fragment's legal length (can even the smallest library cell fit plus required end spacing?), its site alignment, which voltage area it belongs to, and whether nearby keepouts or halos block access to it.
62 How do you diagnose a row rail-orientation problem?Intermediate: Row orientation can look perfectly regular visually — alternating up/down like it should — and still be wrong for the library, because the thing that actually matters is whether VDD/VSS land on the correct rail for each row, not just whether the pattern alternates. A standard-cell library has a fixed power-rail convention baked into every cell (which rail is VDD on an "N" orientation vs. a flipped "FS" row); if the floorplan's row settings don't match that convention, cells will short or float their supply on abutment.
63 How do connectivity and timing guide macro placement?Intermediate: Macro placement isn't a puzzle of minimizing every pairwise distance — it's about arranging macros so the actual **dataflow** through the chip is short, routable, and timing-friendly, which is a different (and sometimes conflicting) goal. **Flylines** (the rat's-nest connectivity lines the GUI draws between related instances) are your first diagnostic tool — they visually show you which macros are heavily connected and should sit near each other, versus which ones barely talk and can be placed further apart without penalty.
64 When should macros be edge-biased versus placed internally?Intermediate: There's no universal right answer here — it genuinely depends on where the macro's pins, its logical neighbors, and its routing needs actually point, so the decision has to be made from the connectivity data, not a rule of thumb. Edge placement tends to simplify external access (bringing signals in/out from I/O, or connecting to neighboring blocks) and keeps the central core area free and continuous for standard-cell rows — good when the macro mostly talks to the outside world.
65 How do rotation and mirroring change macro dataflow?Intermediate: Orientation isn't just how the macro looks on screen — rotating or mirroring it physically moves where its pins sit relative to its neighbors, which directly changes route entry points and can quietly blow up wirelength even though the macro's outline stays perfectly legal. A macro can remain fully legal (on-grid, correct footprint, no overlap) after a flip and still end up with dramatically longer routes because its pins now face away from the logic that needs them.
66 How do you verify macro and block-grid alignment?Intermediate: "Inside the core boundary" and "on a legal coordinate" are two different things — a macro can sit entirely within the die and still be parked on an illegal manufacturing-grid or block-grid location. Verification means checking the macro's origin, its boundary, its orientation, its designated alignment point, and the applicable grid (manufacturing grid, or a stricter block/FinFET grid) all together — checking any one alone isn't enough.
67 How do you estimate whether a macro channel is wide enough?Intermediate: Start from usable routing layers and their track pitches — that's your raw supply of routing resource through the channel, per layer, per direction. Then subtract everything that eats into that raw supply before any signal net gets to use it: power/ground strap width and spacing, placement/routing blockages, via keepout margins around those straps, and any shielding requirements on sensitive nets.
68 Why are notches and narrow channels risky?Intermediate: A narrow passage between macros can be geometrically "open" and still be effectively useless if every entry into it is blocked — an open channel with no legal access is not usable routing/placement space. These regions concentrate routes and pins into a small area, which fragments standard-cell rows, complicates power/ground continuity, and often leaves dead space that neither cells nor wires end up using well.
69 How do you choose a macro keepout type?Intermediate: The keepout type you choose expresses *which objects* get excluded and *at which stage* — the numeric margin value (how far the exclusion extends) is a completely separate decision from the type. Use `hard` when you need broad placement exclusion around the macro for essentially everything — this is the strictest, most conservative choice.
70 How do hard, soft, partial, and macro-only placement blockages differ?Intermediate: A hard blockage is the strictest: nothing gets placed inside it, period — no standard cells, no macros, honored through coarse placement, optimization, legalization, and CTS. A soft blockage is a "please don't, unless you really need to" — it stops cells during initial (coarse) placement, but later optimization/legalization steps are allowed to place inside it if that's what's needed to fix a violation.
71 How do you plan boundary cells around rows and voltage areas?Intermediate: Boundary-cell planning means selecting, for each edge type your floorplan actually has, the correct library-approved cell: left end-cap, right end-cap, top/bottom boundary cells, inside-corner cells, and outside-corner cells. These cells are selected based on the *actual* row and voltage-area geometry you have — not a generic assumption. A rectangular core needs only 4 outside corners; a core with voltage areas carved out of it needs both outside corners (at the die boundary) and inside corners (at the voltage-area notches).
72 How should I/O guides and place_io be used?Intermediate: I/O guides reserve legal regions for I/O driver cells, while constraints describe package, protocol, power, and matching intent. place_io applies those rules to the intended guides.
73 How should hierarchical block pins be placed?Intermediate: A block pin is a doorway shared between the parent design and the child block — both sides need usable, legal access to it, not just the child block's own internal convenience. Placement needs to respect legal sides, legal layers, on-track positions, and correct offsets, all driven by how the top-level dataflow actually approaches that pin — not just "whatever side has room."
74 How do buses and differential pairs change pin planning?Intermediate: A bus isn't just "a bunch of individual pins" — related signals need to reach the block boundary in an order the router can continue naturally, meaning bit 0 through bit N should land in a sequence that doesn't force the router to cross wires just to sort them out downstream. Bit ordering matters concretely: if bus bits arrive at the boundary scrambled relative to their destination order inside the block, you get extra jogs, more vias, and congestion right at the pin — exactly the kind of local congestion that's expensive to fix later.
75 When is a feedthrough better than routing around a block?Intermediate: The naive instinct is "shortest path wins," but a feedthrough is a system-level tradeoff, not a pure geometry problem — the straight line through a block can beat the detour on distance while still being the wrong engineering choice. A feedthrough is worth it when the top-level distance and timing benefit it buys clearly outweighs what it costs the block it passes through — pin budget, routing capacity, voltage-area compatibility, buffering needs, and future ECO flexibility.
76 How do you interpret feedthrough reports?Intermediate: A feedthrough report's raw counts are just a starting point — they tell you *how many* feedthroughs exist, not whether that's good, bad, or expected, so don't stop at the numbers. Classify every entry first: original vs. created, buffered vs. unbuffered, reused vs. redundant, pure vs. mixed, unused. Each category tells a completely different story about design health.
77 How do you create a repeatable early-congestion estimate?Intermediate: The whole point of an early congestion check is to compare alternatives fairly — and that's only possible if every alternative is measured with the exact same yardstick. Keep the floorplan version fixed across all comparisons — if you tweak the floorplan between runs, you can no longer tell whether congestion changed because of your real variable or because of an incidental floorplan drift.
78 What is the correct order for fixing an early congestion hot spot?Intermediate: Resist the urge to jump straight to "make the die bigger" — that's the most expensive fix and often masks (rather than solves) the actual root cause, so it should be close to your last resort, not your first move. Step 1: **confirm the data itself is trustworthy** — check that the netlist, constraints, and PG assumptions feeding the congestion estimate are actually current and correctly loaded; a stale or misconfigured input can produce a phantom hotspot that doesn't really exist.
79 How do pitch, offset, direction, and width define routing tracks?Intermediate: Pitch controls repetition, offset sets the first coordinate, direction selects X or Y track lines, and width can reserve a wire width. Technology rules decide legality.
80 How do you debug an off-track or blocked pin?Intermediate: A pin sitting right at the edge of a cell or macro can still have zero legal, track-centered way to approach it — "on the boundary" and "reachable" are different claims. Debugging means pulling the pin's exact layer, side, and offset and comparing that against the track pattern (pitch/offset/direction), any blockages nearby, PG shapes in the area, spacing rules, and neighboring pins that might be crowding the same tracks.
81 How do you test a power-grid reservation against signal-routing capacity?Intermediate: Power and signal nets are competing for exactly the same finite set of routing tracks — reserving generous PG rings/straps without checking their impact on signal capacity is a common way to create congestion you don't discover until much later. The test is to overlay the proposed ring, strap, rail, and via corridors onto the same channel/congestion model you use for signal routing, then look at how many tracks and pin approaches remain once PG has taken its share.
82 How do you plan a usable voltage area?Intermediate: Shape and size it for assigned cells, expected growth, legal rows, boundary cells, isolation/level-shifter/retention zones, switch corridors, macro compatibility, and supply access.
83 How do you compare timing between two floorplan alternatives?Intermediate: A slack number is meaningless in isolation — before comparing anything, lock down everything except the floorplan itself: same netlist, same SDC, same scenarios/corners, same libraries, same pre-CTS clock latency/uncertainty assumptions, same coarse placement effort, and the same parasitic estimation method for both runs. Once the environment is controlled, compare the **same named paths** across both floorplans — pick a handful of representative register-to-register and I/O paths (especially known-critical ones) and track how their slack changes, rather than just comparing aggregate WNS/TNS, which can hide which specific paths got better or worse.
84 What should a reproducible floorplan evidence package contain?Intermediate: The goal of this package is simple to state and easy to get wrong in practice: another engineer, with no other context, should be able to recreate the exact same physical state and understand why every decision was made. Cover both provenance and content — the exact input files and tool version used, the area assumptions behind the floorplan, the boundaries, rows/sites/tracks, macro and pin constraints, voltage areas, and every keepout/blockage placed.
85 How do modern analytical and force-directed global placement algorithms work?Intermediate: Picture every connected pair of cells joined by a rubber band — that's the wirelength force. The tighter the connectivity, the harder cells get pulled toward each other, because minimizing total quadratic wirelength directly reduces interconnect delay: `Φ = ½ Σ c_ij[(xi−xj)² + (yi−yj)²]`. Pulled that hard on its own, every cell would collapse into one overlapping point at the center of the die — obviously unplaceable — so there needs to be an opposing force.
86 What is High-Fanout Net Synthesis (HFNS), and how does it differ from CTS?Intermediate: HFNS builds balanced buffer/inverter trees for high-fanout non-clock control signals (asynchronous resets, scan-enables, chip enables) during placement to fix max-transition and max-capacitance DRC violations. Unlike CTS, HFNS focuses on slew compliance rather than skew balancing.
87 Why must clock networks remain ideal during placement and pre-CTS optimization?Intermediate: During placement, registers are still moving around the floorplan constantly — you simply can't have a real, physically-routed clock tree yet, because the endpoints it would feed haven't settled into their final locations. Because of that, the timing engine models clocks as "ideal": every register's clock pin is assumed to transition at the same instant (often modeled as t=0 or a flat virtual-source latency), with clock uncertainty standing in as a placeholder margin (commonly around 100 ps) for the skew CTS will eventually introduce.
88 How does Scan Chain Re-ordering work, and why is ScanDEF necessary during placement?Intermediate: Synthesis stitches scan flip-flops together purely by RTL naming order (reg_a[0] → reg_a[1] → ... → reg_b[0]) with zero awareness of where those flops will eventually sit on the die. Once placement happens geographically, that naming-order chain can become a routing nightmare — reg_a[0] might land top-left while reg_a[1] lands bottom-right, forcing the scan chain to criss-cross the entire die.
89 What design rules and site constraints does Placement Legalization verify?Intermediate: Legalization snaps floating continuous cells onto discrete row site grids, eliminates all instance overlaps, enforces row orientation flipping (N/FS) for power rail abuttal, aligns multi-height cell tracks, and ensures DRC pin-access clearance.
90 What are Decap Cells, and how are they budgeted during placement vs post-route?Intermediate: Decap (decoupling capacitor) cells act like tiny local batteries sitting right next to your power-hungry logic — when thousands of cells switch at once and draw a sudden current surge, the decap discharges its stored charge locally instead of making that current travel all the way back through the power grid, which is what causes dynamic IR drop. Physically, a decap cell is usually just an empty inverter shell wired backwards as a capacitor — PMOS gate tied to VSS, NMOS gate tied to VDD — so it behaves as a parallel-plate capacitor rather than an active logic gate.
91 What is Multi-Bit Flip-Flop (MBFF) Banking, and why is it performed during placement?Intermediate: Multi-Bit Flip-Flop (MBFF) banking merges multiple independent single-bit registers (e.g., 2-bit, 4-bit, or 8-bit) into a single standard cell that shares an internal clock inverter and power structure, reducing clock tree pin capacitance by 40% to 50% and cutting total CTS dynamic power.
92 What is Relative Placement (RP), and when should it be used for datapath logic?Intermediate: Analytical placement is great at scattering random control logic to minimize wirelength, but it's actually the wrong tool for a highly regular datapath — a 64-bit ALU's bit-0 through bit-63 all follow the identical structure, and letting the placer treat each bit independently scatters them unevenly, creating uneven wire delays and real clock skew. Relative Placement fixes this by letting the designer lock the datapath into an explicit matrix grid — say, 64 rows by 4 columns — with each instance assigned an exact relative row/column offset to its neighbors.
93 How do you analyze and debug placement routing congestion heatmaps?Intermediate: Congestion debugging starts with a fast global-routing trial over a grid of G-cells (think of it as running a rough traffic simulation before building real roads) to estimate routing demand versus available capacity. The core metric is overflow: `Overflow = Demand − Supply` per G-cell, where supply is how many tracks that tile actually has (layers × tile height ÷ (width+spacing)) and demand is how many nets need to cross it.
94 What optimization techniques does `place_opt` apply to close setup timing pre-CTS?Intermediate: Pre-CTS optimization (`place_opt`) closes WNS and TNS setup slack by executing gate sizing (upsizing drive strength), buffer insertion (splitting long RC nets), logic restructuring (pin swapping, cloning/de-cloning), and multi-threshold voltage (Multi-Vt) swapping under ideal clock assumptions.
95 What are the five stages of place_opt, and what does each one actually do?Intermediate: place_opt is not one operation -- it's five named stages run in sequence: initial_place (merge clock-gating logic, coarse-place, scan chain optimization if SCANDEF is present), initial_drc (remove existing buffer trees, high-fanout-net synthesis, electrical DRC fixing), initial_opto (timing/area/congestion/leakage-power optimization), final_place (incremental placement to improve timing/congestion, then legalize), and final_opto (further optimization and legalization). You can run any contiguous slice with -from/-to -- the stage names are the actual debug handles.
96 What must be true before a design is ready to hand off from placement to CTS?Intermediate: Before CTS: no outstanding timing violations and no DRV violations from placement, derived clocks correctly expanded and understood, critical clock transitions/capacitance/fanout/congestion areas identified, high-fanout nets already driven with correct drive strength, and any logic areas needing shielding or max-capacitance limits already flagged. CTS is not a fresh start -- it inherits every unresolved placement problem and makes debugging them mixed up with genuine clock-tree problems.
97 What's the structural difference between a Sum and a Pi clock tree, and why do most modern designs default to Sum?Intermediate: A Sum tree's total buffer count is the sum of buffers per level (n_level0 + n_level1 + ... ), producing an unbalanced tree where skew is minimized by delay matching along each path -- which makes it more process-corner-dependent. A Pi tree's total buffer count is a product across levels (n_level0 x n_level1 + n_level1 x n_level2 + ...), producing a balanced, symmetrical tree where skew depends on process uniformity rather than corner. Pi uses more buffers for the same structure. With dynamic power now a first-order concern, Sum configurations are used far more often, regardless of clock domain count, simply because they need fewer total buffers.
98 Why does inserting buffers along a long clock wire actually reduce delay instead of just adding more delay?Intermediate: A long wire's propagation delay is dominated by RC and grows with the square of length: t = rcL^2/2. Splitting that wire into N equal segments with a buffer between each one reduces the wire-delay term quadratically -- t = rc(L/N)^2 + (N-1)*t_b -- so even though you're adding N-1 buffer delays, the L^2-to-(L/N)^2 reduction more than pays for it once N is large enough. Setting the derivative to zero gives the optimal buffer count: N = L*sqrt(rc/t_b).
99 What does clock_opt actually do, stage by stage, in ICC2?Intermediate: clock_opt runs CTS end to end through named stages you can target with -from/-to: build_clock builds the tree structure, route_clock routes the built tree, and final_opto is a post-build optimization pass. `clock_opt` alone runs the full flow; `clock_opt -from build_clock -to route_clock` builds and routes without the final optimization pass; `clock_opt -from route_clock -to route_clock` only routes clocks that are already built; `clock_opt -from final_opto` runs only post-build optimization on an already-built, already-routed tree.
100 How does post-CTS STA differ from pre-CTS STA now that a real clock tree exists?Intermediate: Before CTS, STA times against ideal clocks -- user-specified set_clock_latency and set_clock_uncertainty values standing in for a tree that doesn't exist yet. After CTS, the tool switches to propagated clocks: real, computed insertion delay and real skew from the actual built tree, not an estimate. This is why a design that looked clean pre-CTS can show new setup or hold violations post-CTS -- it's not that the design got worse, it's that STA is finally measuring the real thing instead of a placeholder.
101 What is a boundary cell in CTS, and what are you not allowed to do to it?Intermediate: A boundary cell is a fixed buffer inserted immediately after a block or module's boundary clock pin, to preserve the boundary conditions of that pin for hierarchical CTS. Two hard rules: a boundary cell cannot be moved or resized, and no cells may be inserted between a clock pin and its boundary cell -- both rules exist to keep the hierarchical boundary's timing contract intact.
102 What does a "don't-touch subtree" constraint actually protect during CTS, and when would you use it?Intermediate: The don't-touch subtree constraint selectively preserves a portion of the clock tree at a particular clock pin -- useful, for example, at a mux between two clocks feeding different downstream paths, where you want CTS free to optimize everywhere except that specific already-correct structure. It's a scoped protection, not a whole-tree freeze.
103 What's the practical difference between positive and negative clock skew, and why would you deliberately choose negative?Intermediate: Positive clock skew routes the clock in the same direction as data flow, improving performance with tighter setup margin -- most CTS algorithms default to this. Negative clock skew routes the clock opposite to data flow, virtually eliminating the setup skew requirement but tending to degrade hold time. To get negative skew deliberately, you set the clock delay/latency to a negative number, which makes leaf registers connect to lower levels of the tree (closer to the source).
104 What does report_ccd_timing actually show you by default, and how do you dig deeper into one specific decision?Intermediate: By default, report_ccd_timing reports setup/hold slack of the worst capture (D-slack) and launch (Q-slack) paths for the 5 most critical endpoint registers. -type stage shows previous/current/next stage info for a specific pin; -type chain shows the full previous/current/next chain (multiple stages back and forward); -prepone/-postpone with -pins lets you analyze the effect of shifting clock arrival at a specific endpoint before committing to it.
105 Why would you need copy_useful_skew instead of just trusting CCD ran the same everywhere?Intermediate: copy_useful_skew copies CCD offsets to new scenarios for consistent timing/QoR reporting when CTS balance-point offsets were derived in only a subset of active scenarios. It also ensures set_clock_latency constraints are set on all pins/scenarios by computing the average offset across active scenarios and scaling it back per corner -- without it, scenarios that never got their own CCD run would report inconsistent, incomparable timing.
106 How do you actually invoke split_clock_cells, and what are the two ways to specify what gets split?Intermediate: You can split by cell (-cells [get_cells U1/ICG*]) to target specific clock cells directly, or by load (-loads {list1 list2}) to specify which load groups should end up on which resulting split cell -- two different entry points into the same underlying operation, chosen based on whether you're thinking in terms of cells or in terms of load distribution.
107 What does mark_clock_trees actually let you control beyond just "this tree is done"?Intermediate: mark_clock_trees can scope to specific clocks (-clocks, default is all clocks/modes/active scenarios), mark a tree synthesized (-synthesized, the default) or clear that (-clear), apply or remove dont_touch, propagate non-default clock routing rules or clock cell spacing rules, mark clock sinks fixed, and freeze routing of clock nets. It's a multi-purpose flagging command, not just a single boolean toggle.
108 If you need to rebuild a clock tree from scratch, what does remove_clock_trees actually preserve versus remove?Intermediate: remove_clock_trees traverses root to sinks, removing buffers and inverters except dont_touch/size_only ones -- but several object types survive by design: don't-touch cells, fixed cells, generated clocks defined on a buf/inv pin, ICGs (traversal continues past them), block abstraction models, isolation cells, and level shifters. Inverters are only removed in pairs, and a three-state buffer stops traversal entirely rather than being removed.
109 How do you constrain which metal layers a clock tree is allowed to route on, and can you be more specific than "the whole tree"?Intermediate: set_clock_routing_rules -min_routing_layer M4 -max_routing_layer M7 applies to all clock trees by default, but you can scope it to specific clocks (-clocks), or to specific net types within the tree using -net_type root|sink|internal -- root nets run from the clock root to the first branch, internal nets run from there toward sinks, and sink nets connect directly to leaf sinks.
110 What's the actual structural difference between a regular and a structural multisource clock tree?Intermediate: A regular MSCTS has local subtrees driven by predefined tap drivers connected to the mesh, built with the normal synthesize_clock_trees/clock_opt flow. A structural MSCTS has subtrees driven directly from multiple mesh points, preserving a user-defined structure that's optimized by merging/splitting/sizing rather than built fresh by the standard CTS algorithm -- the choice determines whether you're letting the tool build subtrees or preserving a structure you already designed.
111 How do a clock mesh, an H-tree, and a spine differ as clock distribution structures?Intermediate: A clock mesh is a 2D grid of horizontal and vertical straps joined by vias at intersections -- the global structure in a multisource clock tree. An H-tree is the typical topology for the global tree feeding that mesh. A spine is a 1D or 2D set of straps; a 2D spine connects multiple 1D spines to multiple orthogonal stripes, with the minimum distance between different spines' stripes called the backoff.
112 What does create_clock_drivers actually do, and what step do you always have to run afterward?Intermediate: create_clock_drivers inserts clock driver cells at specified loads, using either -boxes (a grid over the core or a bounded area) or -location (exact locations) for placement, with -lib_cells specifying the driver library cells. Critically, the command does NOT legalize -- you must run legalize_placement after every create_clock_drivers call, since the inserted drivers are marked fixed/dont-touch but not automatically legalized into the design.
113 Where does voltage optimization actually sit relative to place_opt and clock_opt, and why does order matter here?Intermediate: The voltage_opt flow runs place_opt and clock_opt first at the original voltage, then defines a scaling library group and a voltage range/target (set_vopt_range, set_vopt_target) before running voltage_opt itself -- routing and postroute optimization then happen at the newly optimized voltage. Running voltage optimization before placement/CTS are stable would mean optimizing against a design that's still going to change, wasting the analysis.
114 In report_clock_power, what's the actual difference between a "segment" and a "subtree"?Intermediate: A segment is the clock buffer tree from one ICG cell to the next ICG cells or sinks in its fanout -- a local slice. A subtree is the clock tree from an ICG cell all the way to the sinks -- the full downstream structure. report_clock_power -type per_segment gives you the local slice view; -type per_subtree gives you the full downstream view from that ICG onward.
115 Why do clock buffers specifically need equal rise and fall delay, and what's the practical fallback when that's hard to guarantee?Intermediate: Buffers used to taper clock paths need equal rise and fall delay time to maintain the original duty cycle and prevent clock signal overlap from differing propagation delays -- critical for very high-speed designs. Because perfect rise/fall balance is genuinely hard to achieve in a real buffer, a common remedy is to use inverters instead of buffers for clock tapering; incorrectly selected clock buffers with unequal rise/fall cause clock pulse width degradation as the signal propagates.
116 How does drive strength actually scale across levels of a tapered clock buffer chain?Intermediate: Tapering buffers don't have to be identical size -- they can increase drive strength monotonically by a factor alpha per clock tree level: alpha^0*d, alpha^1*d, alpha^2*d, and so on. This matches drive strength to the growing load as the tree fans out level by level, rather than using one fixed buffer size everywhere regardless of how much load it's actually driving at that point.
117 When placing clock drivers with -boxes, how does -boundary actually change what gets built?Intermediate: -boxes alone lays out an X-by-Y grid of driver positions over the entire core area. Adding -boundary constrains that grid to a specific bounded region instead of the whole core -- useful when you only want drivers distributed across part of the floorplan (e.g. one voltage area or one physical section) rather than uniformly everywhere.
118 What's the practical difference between symmetric and user-controlled tap driver configuration in an H-tree?Intermediate: cts.multisource.tap_selection defaults to user, meaning tap positions follow what you specify. Setting it to symmetric produces a symmetric tap configuration automatically instead -- useful when you want the tool to enforce structural symmetry across the H-tree rather than trust manually-specified tap boxes to be symmetric themselves.
119 How do dont_touch cells, fixed cells, and boundary cells differ in how remove_clock_trees treats them?Intermediate: All three are preserved by remove_clock_trees, but for different underlying reasons: a dont_touch cell is preserved because optimization is explicitly excluded from touching it; a fixed cell is preserved because its placement is locked, independent of dont_touch; a boundary cell is preserved specifically because it protects a hierarchical timing contract, and additionally cannot be moved or resized even outside the context of tree removal.
120 How does the optimization tool actually decide which timing violations to fix first?Intermediate: The tool fixes the Worst Negative Slack (WNS) path first; once that path meets timing it moves to the next-worst, stopping when it hits a path it can't fix. To avoid the tool exhausting all effort chasing one dominant path group, paths are grouped into cost groups -- sets of critical paths with an assigned priority/weight -- so effort gets balanced across groups instead of consumed entirely by one group's single worst path.
121 By default, does STA assume every path is single-cycle, and what happens if a genuinely multicycle path isn't declared?Intermediate: Yes -- by default STA assumes single-cycle for ALL paths. A path that's actually allowed multiple cycles to reach its capture flip-flop (e.g. a configuration-register-driven enable stable across several clocks) still gets checked as if it needed to close in one cycle unless explicitly declared with set_multicycle_path. Without that declaration, the tool over-constrains the path and misreports it as violating, when it actually has legitimate extra cycles to work with.
122 What's the precise OCV rule ICC2 applies differently for setup checks versus hold checks?Intermediate: For setup checks: worst PVT for the clock and data (launch) paths, best PVT for the reference clock (capture) path. For hold checks: best PVT for the clock and data paths, worst PVT for the reference clock (capture) path -- the launch/capture PVT assignment flips entirely between the two check types, which is exactly what makes setup and hold pull a design in opposite directions.
123 How does AOCV actually reduce pessimism compared to flat OCV derating, and what's the real cost of using it?Intermediate: Flat OCV derating applies one derate factor to every cell/net delay in the early direction (hold) and one in the late direction (setup), regardless of path depth or distance -- simple but pessimistic, since it assumes worst-case variation compounds identically everywhere. AOCV (Advanced OCV) instead makes the derate factor a function of logic depth and/or physical distance, since variation statistically partially averages out over more stages/more distance -- less pessimistic, but it requires real AOCV characterization data (depth/distance-vs-derate tables) the library has to actually supply.
124 Why can't you just close timing mode by mode independently and call the design done?Intermediate: SoCs operate in multiple modes (active, sleep, test) sharing the same logic, each needing its own constraints -- sleep mode may use a different supply voltage or clock frequency, for instance. Fixing timing in one mode can genuinely reopen violations in another, because the same physical cells and paths are shared across modes -- a fix that helps mode A's timing can change delay in a way that hurts mode B's, since they're not independent designs, they're the same design analyzed under different constraint sets.
125 When a timing path shows a large negative slack, what are the two canonical fixes, and how do you choose between them?Intermediate: For a violating R2R path, the two canonical fixes are: swap to faster cells along the path (if faster library variants exist), or split the path by inserting a register partway through, creating a new, shorter R2R endpoint. Either fix requires re-running LEC between the modified netlist and the golden RTL to confirm functional equivalence -- this same swap-vs-split methodology is the core approach used in post-PD ECO timing closure generally, not just this one worked example.
126 What's the difference between route_opt and hyper_route_opt, and what does Targeted Endpoint Optimization actually let you do?Intermediate: route_opt is the standard post-route optimization command -- up/down-sizing drive strength along failing paths without disturbing other placement. hyper_route_opt is a distinct, more intensive variant. Targeted Endpoint Optimization (set_route_opt_target_endpoints) lets you work on a specific SUBSET of endpoints rather than optimizing the whole design -- useful when only a known set of endpoints are actually violating and you want to avoid disturbing everything else's already-closed timing.
127 What are the key options for controlling how add_spare_cells distributes spare logic across a design?Intermediate: add_spare_cells takes -cell_name (naming prefix) plus either -lib_cell with -num_instances (same count per cell type) or -num_cells {CELL count ...} (different counts per type). -repetitive_window {w h} repeats a window of spare cells throughout the placement area at that pitch. Distribution control includes -hier_cell, -boundary, -voltage_areas, -random_distribution (ignore cell density), and -density_aware_ratio (default 100% density-based placement).
128 How does the tool know which programmable spare cell a given standard cell can actually be swapped into during a freeze-silicon ECO?Intermediate: Programmable spare cells (gate array filler cells) are matched to real standard cells via a shared psc_type_id attribute set on both the fill library cell and the standard cell library cells it can represent -- set_attribute [get_lib_cells ...] psc_type_id <N> on both sides. During the ECO flow, the tool swaps an ECO cell with a programmable spare cell based on matching psc_type_id, cell width, and voltage area -- all three have to match, not just the type id alone.
129 When would you use add_buffer instead of add_buffer_on_route for a post-CTS ECO fix?Intermediate: add_buffer inserts a buffer on a net by specifying the net and library cell directly (-object_list, -lib_cell), letting the tool determine placement -- appropriate for a net that isn't already routed, or where preserving exact existing routing topology doesn't matter. add_buffer_on_route (ABOR) specifically adds buffers based on the EXISTING routing topology, minimizing disturbance to routes that are already in place -- the right choice post-route specifically, when you don't want to risk re-routing everything.
130 What problem does split_fanout actually solve during a timing ECO, and how do you tell it what to split on?Intermediate: split_fanout optimizes net fanout during a timing ECO by inserting buffers to break up a high-fanout net -- specified either by -net/-driver plus -max_fanout (a numeric limit) or -load (an explicit list of pins/ports, optionally -hierarchy-aware). -on_route adds the buffers on the existing route topology (like ABOR); -max_distance_for_incomplete_route handles splitting fanout of a net that isn't fully routed, within a max distance, and errors if 0 or more than 1 routed segment is found in that distance.
131 What is a virtual connection in ECO placement, and why would you create one that doesn't correspond to a real net?Intermediate: create_virtual_connection -pins {pin1 pin2} defines a connectivity relationship for placement guidance purposes only, with an optional -weight to control how strongly it pulls cells together -- it does NOT create a real electrical connection. This is useful when you want an ECO cell placed near a specific pin for a reason (e.g. anticipated future connectivity, or minimizing eventual routing distance) without actually wiring them together yet.
132 What does logic restructuring actually do during global placement, and what's cloning specifically for?Intermediate: Physical synthesis tools combine several primary logic functions into few standard cells, decompose functional gates into equivalent primary gates, and/or duplicate combinational logic (cloning) -- all focused on reconstructing critical paths that are missing timing. Cloning specifically means duplicating a piece of combinational logic so different downstream paths can each get their own copy, rather than sharing one instance whose fanout is spreading the load (and the delay cost) across all of them.
133 How do the congestion-driven and timing-driven placement styles actually trade off against each other?Intermediate: Congestion-driven placement relaxes cell density at the cost of slightly higher interconnect length and silicon area -- it prioritizes routability. Timing-driven placement chases the best timing, possibly leaving congestion issues unresolved. Neither is strictly better; the choice depends on which risk (a routing-incomplete design, or a timing-failing design) is the bigger concern for a given block.
134 What does it actually mean for gain-based (logical effort) optimization to "maintain equal gain per stage," and why is that the goal?Intermediate: During gain-based optimization, the algorithm computes the gain of each cell along the critical path and tries to maintain equal gain for each stage -- equal gain per stage is optimal timing, a real result from logical effort theory, not an arbitrary heuristic. If an instance needs more gain because of increased output load, its input capacitance is increased to maintain the original gain, rather than just accepting a slower stage.
135 What does the dynamic power formula actually tell a placement engineer to control, and what's the real area cost of doing so?Intermediate: Dynamic power: Pd = V^2 * sum(fi * Ci) -- summed over nodes, frequency times loading capacitance. Reduce it by lowering supply voltage and/or reducing nodal loading capacitance, which in placement practice means limiting max allowable load capacitance. The real cost: limiting load capacitance has a negative area impact from the excess buffering that becomes necessary to keep individual net loads under that limit.
136 How does the static/leakage power formula translate into an actual placement-stage optimization technique?Intermediate: Static (leakage) power: Ps = V * sum(Ij) -- supply voltage times the sum of per-component leakage currents, characterized per cell in the library. The practical optimization: replace low-Vt cells on non-critical paths with high-Vt cells, since high-Vt cells leak less. Excess static power is a limiting factor in high-performance deep-submicron CMOS, which is exactly why placement algorithms need to be leakage-aware, not just timing- and congestion-aware.
137 What do the different create_placement variants actually change about how coarse placement runs?Intermediate: create_placement (plain) does coarse placement and scan chain optimization if SCANDEF is present. -timing_driven adds timing awareness to the coarse pass. -buffering_aware_timing_driven additionally considers high-fanout/long nets and buffers to be added during placement itself. -congestion with -congestion_effort high biases toward routability. -congestion_driven_restructuring runs several iterations of placement plus restructuring together. -floorplan is used specifically in the RP (relative placement) plus hard-macro flow.
138 How do you control how aggressively congestion-driven restructuring runs during placement, and what's the depth_aware safeguard for?Intermediate: place.coarse.cong_restruct_effort (low|medium|high|ultra, default medium) sets how aggressively the tool restructures nets to reduce congestion during coarse placement. place.coarse.cong_restruct_depth_aware, when true, limits path depth growth to 3 logic levels -- a safeguard against restructuring so aggressively that it adds excessive logic depth to a path, potentially trading a congestion win for a new timing problem.
139 What do optimize_orientations and stream_place each actually change about how legalization moves cells?Intermediate: place.legalize.optimize_orientations, when true, flips cells to reduce displacement -- sometimes a flipped orientation lands a cell on a legal site much closer than any unflipped position would. place.legalize.stream_place, when true, moves MANY cells a small amount each rather than one cell a long distance -- tunable via stream_effort and stream_effort_limit. Both target the same underlying goal (minimize disruptive displacement) through genuinely different mechanisms.
140 What's the actual difference between GRLB and RDE for preroute parasitic estimation, and when does each apply?Intermediate: GRLB (Global-Route-Layer-Based) improves preroute/postroute correlation, controlled by opt.common.use_route_aware_estimation -- auto (enabled only when per-unit resistance varies across layers), true (always), or a command to remove all global-route-based estimation before routing. RDE (Route-Driven Estimation) performs actual global routing plus extraction from those routes, auto-enabled for technologies below 16nm (otherwise opt.common.enable_rde must be set). Critically, when RDE is enabled, the GRLB setting is IGNORED -- they aren't both active at once.
141 What does set_isolate_ports actually do, and which ports does it deliberately skip?Intermediate: set_isolate_ports inserts a buffer/inverter pair at specified ports for model accuracy -- {in3 out1} isolates those two ports; -driver LIBCELL_BUFF picks a specific driver cell; -type inverter picks an inverter pair instead. It is NOT applied to bidirectional ports, ports defined as clock sources or power pins, or ports connected to dont_touch nets -- these are deliberate, documented exclusions, not gaps to work around.
142 What does place.coarse.icg_auto_bound actually automate, and what's the default fanout cap on it?Intermediate: place.coarse.icg_auto_bound, when true, auto-generates group bounds for ICGs and the sequential cells they drive -- created at the START of placement and removed at the END, excluding cells already in another group bound. place.coarse.icg_auto_bound_fanout_limit caps the fanout considered for an automatic bound, defaulting to 40 -- an ICG driving more than that many sequential cells doesn't get this automatic grouping treatment.
143 What exactly does check_routability check, and what are its defaults?Intermediate: `check_routability` checks that every pin can actually be reached and that the routing setup is legal before any routing starts. By default it checks blocked standard cell ports, blocked macro and top-level ports, out-of-boundary pins, minimum grid, via definitions, via cut blockages and minimum width settings. The two defaults worth remembering are the search ranges: twice the layer pitch for standard cell pins and ten times the pitch for macro and top-level pins.
144 How do you debug a congestion hotspot after global routing?Intermediate: First find it and measure it: which GCells, which layers, which direction and by how much. Then work out why: too many pins in a small area, a narrow channel between macros, too much wrong-way demand, or tracks lost to blockages or PG. The fix depends on the cause, so the diagnosis is most of the work.
145 Which routing guide do you use for which problem?Intermediate: Routing guides steer Zroute in an area without forbidding routing outright. Use preferred-direction-only or switch-preferred-direction guides to control direction, max-patterns guides to limit non-preferred-direction edges, track utilization guides to control density, access preference guides to prioritize areas, and river routing guides for tight channels. Zroute honours them, but they are softer tools than blockages.
146 What is a routing corridor, and how strictly is it honoured?Intermediate: A routing corridor restricts specific nets to a region made of connected rectangles, optionally with a min and max layer per rectangle. Global routing treats it as a hard constraint, but track assignment and detail routing treat it as soft, so they may step slightly outside to fix a DRC. If a routing guide conflicts with a corridor, the corridor wins.
147 How do soft and hard net layer constraints differ?Intermediate: A hard layer constraint is never broken: the router will not use a layer outside it. A soft one can be broken at a cost if that helps routing. For net-specific constraints set with `set_routing_rule`, the default is min layer soft and max layer hard, and you can change either default or set the mode per constraint.
148 For a clock net, when do you choose a wide and spaced NDR over shielding?Intermediate: For most clock nets, a double-width, double-spacing NDR is the better trade. It lowers resistance, lowers sidewall capacitance and keeps neighbours away, without the capacitance shields add. Shielding is kept for the most sensitive clock nets, where you need the strongest isolation from coupling and can afford the tracks and the extra load.
149 Postroute, concurrent or near-100% redundant vias: how do you escalate?Intermediate: Start with postroute insertion, which almost every block uses. If that reaches about 80% and you need more, move to concurrent soft-rule insertion, which reserves space for second cuts while routing. Only if you already reach about 90% and still need more should you use near-100% insertion, because higher rates make DRC convergence and runtime worse.
150 Why and how do you route a subset of nets first?Intermediate: You route critical nets first so they get clean, direct paths on the layers you want before thousands of other nets fill the tracks. Clocks are the usual example, but timing-critical signals, buses and nets with special rules benefit too. In ICC2 you give the nets their rules, route them with `route_group -nets`, and can lock them so later routing does not touch them.
151 Single-layer vs accumulated antenna ratio: which is stricter, and why?Intermediate: Accumulated modes are stricter than single-layer, because they count metal on the current layer plus every layer below it, while single-layer counts only the current layer. ICC2 has six antenna modes, combining how area is measured (surface or sidewall) with how layers are counted (single-layer, accumulated-ratio or accumulated-area). The foundry rule decides which mode you must use.
152 How does crosstalk change delay, not just add noise?Intermediate: When the aggressor and victim switch at the same time, the coupling capacitance changes how much charge the victim's driver must move. If they switch in opposite directions, the victim sees roughly its own capacitance plus twice the coupling, so it slows down. If they switch the same way, it speeds up, so crosstalk can hurt setup on one path and hold on another.
153 How do you make postroute optimization SI-aware?Intermediate: Turn on signal integrity analysis in the timer before postroute optimization, so extraction keeps coupling capacitance and timing includes crosstalk delta delay. `route_opt` then fixes the paths that actually fail with crosstalk instead of the ones that only look bad without it. You then re-check timing and noise with SI still enabled.
154 After optimization changes nets, how do you reroute without disturbing clean routing?Intermediate: Use ECO routing limited to the changed nets; for a small ECO that is `route_eco -reroute modified_nets_only`. It connects open nets first and then fixes DRCs in the ECO area, leaving everything else as it was. Remember that incremental detail routing does not fix opens, so after netlist changes `route_eco` is the right tool, not `route_detail -incremental`.
155 Detail routing DRCs won't converge. What do you check?Intermediate: First look at the DRC count per iteration to confirm it has really stopped falling. Then group the violations by type and location, because the pattern tells you the cause: a cluster at pins points to pin access, a dense area points to local density, macro edges point to access or blockages, and NDR nets point to rules. Fix that cause and rerun; more iterations rarely help once the curve is flat.
156 Why do hard macro pins fail access at smaller nodes, and how do pin access guides help?Intermediate: Hard macros and IP are often reused from older designs, and at smaller nodes their pins can sit too close to the macro edge, to each other or to blockages for the router to reach cleanly. `derive_pin_access_routing_guides` fixes this by creating routing guides, metal blockages around the macro with cutouts at each pin, and via blockages on the adjacent via layers. The cutouts give every pin a clear, rule-legal path in.
157 What are RC extraction corners (Cworst, Cbest, RCworst, RCbest), and why do you need several?Intermediate: RC corners describe how manufacturing variation in metal width and thickness changes wire resistance and capacitance. Because the same variation pushes resistance and capacitance in opposite directions, no single corner is worst for every path. Cworst maximizes capacitance, RCworst maximizes the resistance-capacitance product, and the best corners are their opposites, used mainly for hold.
158 What is inside a SPEF file, and what do you check in it?Intermediate: SPEF (Standard Parasitic Exchange Format, IEEE 1481) holds the extracted resistance and capacitance of every net. It has a header with the design name and units, a ports section, and one `D_NET` block per net with its connections, capacitors and resistors, including coupling capacitors to other nets. Before trusting one, check its units, that it covers every net, and that it came from the netlist you are timing.
159 Why can hold violations appear after routing, and how are they fixed?Intermediate: Routing changes both clock and data timing. A clock branch that picked up extra delay moves the capture edge later, and a data path sped up by same-direction crosstalk or a short route arrives earlier, so hold margin shrinks. Postroute hold is fixed by adding delay to the data path near the capturing flop, usually with delay cells or buffers, and then re-checking setup.
160 What are dangling and floating shapes, and how do you clean them up safely?Intermediate: A dangling shape is a piece of wire attached to a net at one end that goes nowhere; a floating shape belongs to a net but touches nothing of it. Both are usually left behind by rerouting and ECOs, and they add capacitance and can cause DRCs. `remove_redundant_shapes` deletes them without changing connectivity, but it skips open nets and nets with DRCs, so you re-check afterwards.
161 What changes when routing across voltage areas?Intermediate: Signals crossing between voltage areas must go through the right isolation cells or level shifters, and the router must not create physical paths that break the power intent. Voltage area rules control whether nets may pass through an area and whether buffers can be added there. Cells with secondary power pins, such as always-on buffers, also need those pins routed to the correct supply.
162 How does electromigration constrain routing, and what does Black's equation tell you?Intermediate: Electromigration is metal atoms being pushed along a wire by current over years of operation, which eventually forms voids that open the wire or pile-ups that short it. Black's equation says lifetime falls with the square of current density and falls quickly with temperature. In routing, current density is what you control, so high-current nets get wider wires and more vias.
163 In what order do you try setup fixes, and why that order?Intermediate: Start with the fix that costs least and disturbs the layout least, and climb only when the cheaper rung runs out. The usual order is Vt swap, cell sizing, buffering or fanout split, logic restructuring or cloning, useful skew, and finally placement or floorplan changes. Each step up moves more cells, touches more nets and puts more already-closed timing at risk, so you stop at the first rung that clears the path.
164 How do you fix hold without creating new setup violations?Intermediate: Add delay where the data path has setup margin to spare, not simply where the hold violation shows up. Delay added at a pin helps hold on every path through that pin and costs setup on the same paths, so the right pin is the one whose worst setup path still passes after the delay goes in. For very small violations, around 5 ps or less, a load cell adds just enough delay without the overshoot of a whole buffer.
165 What does fix_eco_timing do by default for setup vs hold?Intermediate: `fix_eco_timing` (PT) will not run without `-type setup` or `-type hold`, because the two problems need opposite changes. By default, setup fixing uses cell sizing alone to cut data path delay, and hold fixing uses sizing plus buffer insertion to add delay. Both work only on data paths, not clock networks. Setup fixing avoids new DRC violations but may create hold violations, while hold fixing avoids creating either setup or DRC violations.
166 What can fix_eco_drc fix, and why does delta-delay fixing need a threshold?Intermediate: `fix_eco_drc` (PT) fixes what `report_constraint` (PT) reports for max capacitance, max transition and max fanout, noise violations from `report_noise` (PT), crosstalk delta delay found by `report_si_bottleneck` (PT), and cell electromigration from `report_cell_em_violation` (PT). It sizes cells and inserts buffers or inverter pairs while keeping area low, and by default it ignores timing. Delta delay needs a threshold because no constraint limits it, so there is no delta delay slack to fix against.
167 How does fix_eco_power recover area and leakage, and what selection modes exist?Intermediate: `fix_eco_power` (PT) swaps cells for cheaper ones on paths with positive setup slack, or removes buffers on paths with positive hold slack, and backs out any change that creates or worsens a timing or DRC violation. What counts as cheaper depends on the mode: smallest area by default, a numeric library attribute with `-power_attribute`, a name or string priority list with `-pattern_priority`, or PrimePower data with `-power_mode`. You choose one mode per run and run the command again for another.
168 Why does the recommended ECO order run power recovery, then DRC, then setup, then hold, then leakage recovery?Intermediate: The order follows which step is allowed to hurt which. Power recovery goes first because it never creates a violation and frees room; DRC and noise come next because DRC fixing has the highest priority and may move setup and hold slack. Setup follows because it honours DRC but may spend hold margin, then hold, which honours both, and finally a leakage-only Vt swap that changes no layout.
169 What's the difference between occupied_site, open_site and freeze_silicon physical ECO modes?Intermediate: The `-physical_mode` setting decides where PrimeTime may put a new or resized cell. occupied_site places or resizes even with no free site, so it fixes more but leaves ICC2 legalization to push neighbours; open_site uses only free sites, so it fixes less but moves almost nothing; freeze_silicon places new cells only on spare cells so the silicon layers stay the same. All three belong to the physically aware ECO flow, which requires a PrimeTime-ADV license.
170 What is DMSA, and why fix ECOs across all scenarios at once?Intermediate: Distributed multi-scenario analysis runs one PrimeTime manager and several workers, each worker analyzing one scenario, where a scenario is one combination of operating condition and mode. The manager sets up, hands out tasks and merges results, but does no timing analysis itself. ECOs are fixed across all scenarios together because a change that fixes setup in the slow corner can break hold in the fast corner or timing in test mode, and only a run that sees every scenario can refuse that change.
171 What does merged reporting in DMSA give you, and what can't be merged?Intermediate: Merged reporting lets you run a report once at the manager and get one answer across every scenario in command focus, with duplicates removed, results sorted by slack and each line labelled with its scenario. It works with `report_timing` (PT), `get_timing_paths` (PT), `report_constraint` (PT), `report_analysis_coverage` (PT), `report_si_bottleneck` (PT), `report_clock_timing` (PT) and `report_min_pulse_width` (PT). The main exception is cover-design reporting: `report_timing -cover_design` (PT) runs at the workers but cannot be merged at the manager.
172 Why do two runs of the same design report different TNS?Intermediate: TNS depends on how an endpoint that sits in more than one path group is counted. With `timing_report_union_tns` (PT) at its default of true, each violating endpoint adds its worst slack once; with false, it adds once for every path group it violates in. Two runs with different settings, or with different path groups, report different TNS for exactly the same slacks.
173 How does report_bottleneck find high-leverage fixes?Intermediate: `report_bottleneck` (PT) ranks leaf cells by how many violating paths pass through them, so a cell with a cost of 20,000 sits on 20,000 failing paths. Fixing that one cell can improve many endpoints in one change, which is often better than grinding on the few worst paths. It needs `timing_save_pin_arrival_and_slack` (PT) set to true before the first timing update.
174 When do you run exhaustive PBA, and how do you keep it affordable?Intermediate: Run exhaustive PBA when graph-based violations are close enough that removing pessimism could clear them, and always for final signoff numbers. Keep it affordable by scoping it: search only failing paths with `-slack_lesser_than`, check with `-pba_mode path` first, and narrow to the groups or endpoints you need. Never waive a violation on `ml_exhaustive` results, because ML-PBA can miss worse paths and extra failing endpoints.
175 How do you prove no timing check is silently untested?Intermediate: Run `check_timing` (PT) first to fix missing clocks, missing I/O constraints and loops, then run `report_analysis_coverage` (PT) and account for every untested check. With `-status_details {untested}` the report lists each untested check and the reason, such as no_clock, constant_disabled or no_paths. You have proof when every untested check is either tested in another scenario or has a reason you deliberately created.
176 How does the incremental ECO flow avoid a full extraction on every iteration?Intermediate: ICC2 records only what the ECO changed, StarRC extracts only those changes, and PrimeTime applies them to a saved session instead of reloading the design. `record_signoff_eco_changes` (ICC2) tracks the edits, StarRC runs in ECO mode, and PrimeTime reads them with `read_eco_changes` (PT) and `read_parasitics -eco` (PT) before an incremental timing update. Final signoff still needs a full extraction and a full timing run.
177 How does size_cell behave in freeze-silicon mode?Intermediate: With `design.eco_freeze_silicon_mode` (ICC2) set to true, `size_cell` (ICC2) first looks for a compatible spare cell within five times the unit site height of the cell being sized, and if none exists it refuses to size. When it finds one, the original cell becomes a spare renamed with a _Spare suffix, and a new cell with the original name, connections and new library cell is placed over the matched spare. `-max_distance_to_spare_cell` changes the search radius and `-not_spare_cell_aware` switches the check off.
178 How do you try an ECO in PrimeTime before committing to it?Intermediate: PrimeTime lets you edit its in-memory netlist, see the timing effect, and only then write the change out for ICC2. Use `estimate_eco` (PT) to rank the options quickly, commit the one you like with `size_cell` (PT) or `insert_buffer` (PT), and check it with `report_timing` (PT). The timing update stays incremental, and therefore fast, only while you stick to the edit commands PrimeTime supports for what-if analysis.
179 How do you detect and undo an ECO that displaced too much?Intermediate: After an ECO change list is applied and legalized, run `report_eco_physical_changes` (ICC2) to see how far each sized or added cell moved and how much its nets grew. Cells that landed far from their connections usually cost more delay than they saved. Undo them with `revert_eco_changes -cells` (ICC2), which removes the added buffer or inverter pair, or restores the original cell, location and orientation.
180 When would you use legalize_eco_cells instead of hand-tuning place_eco_cells?Intermediate: `legalize_eco_cells` (ICC2) is a short form of careful minimum-impact legalization: you give it the ECO cells and a tolerance level, low or high, instead of exact displacement numbers. Use it when the ECO cells already have good locations and you only need them made legal with as little disturbance as possible. Hand-tuned `place_eco_cells` (ICC2) is still the tool when you need control over placement itself, exact rejection thresholds or filler removal.
181 How do you check there's physical room for ECO cells before fixing?Intermediate: Run `report_cell_feasible_space` (ICC2) on the region around your violations before PrimeTime adds any buffers. It reports free placeable sites, grouped by width, after subtracting existing cells, placement blockages and macros. If there are no gaps wide enough for the cells you plan to add, fix with sizing, use PrimeTime's open-site mode, or make room first.
182 How does PrimeTime ECO fix timing inside the clock tree, and what limits it?Intermediate: By default PrimeTime ECO only touches data paths. With physical clock data enabled through `set_eco_options -physical_enable_clock_data` (PT) and `-cell_type clock_network` on `fix_eco_timing` (PT), it can size and insert buffers in the clock tree to shift arrival times. Two options limit it: `-clock_fixes_per_change` sets how many violations each change must fix, and `-clock_max_level_from_reg` sets how far from the register clock pin a change may go.
183 What is TNS-driven fixing, and why allow some endpoints to get worse?Intermediate: TNS-driven fixing lets `fix_eco_timing` (PT) make a clock network change that helps several endpoints even though it makes one worse, as long as total negative slack goes down and WNS stays within a limit. By default no clock change may worsen any violating endpoint, so one shared clock buffer that would fix many paths is rejected. You accept a few worse endpoints because less TNS means less total fixing left, and the WNS cap keeps the trade bounded.
184 How do you find and fix the nets that cause the most crosstalk delay?Intermediate: Start with `report_si_bottleneck -cost_type delta_delay` (PT) to rank victim nets by the crosstalk delay they add on failing paths. Then fix them with `fix_eco_drc -type delta_delay -delta_delay_threshold <v>` (PT), which sizes drivers and inserts buffers on victims whose delta delay exceeds the threshold. A threshold is needed because there is no delta delay constraint, and so no delta delay slack to drive the fixing.
185 A hold violation turns out to be a missing multicycle hold. Why must you not fix it with buffers?Intermediate: When a path has `set_multicycle_path 2 -setup` (SDC) but no matching hold exception, the hold check moves forward with the setup check and PrimeTime reports a hold violation close to one clock period. That is a constraint bug, not a silicon problem. Fix the SDC with `set_multicycle_path 1 -hold` (SDC); buffering it wastes area, spends setup margin and leaves the wrong constraint in every later run.
186 Before fixing a violation, how do you prove it's real?Intermediate: Before you spend an ECO on a violation, walk a short checklist. Confirm the constraints are complete, the clocks and their relationship are right, no exception is missing or ignored, the derates are the intended ones, the path still fails under exhaustive PBA, and it fails in a scenario you sign off. Only a violation that survives every step earns a fix.
187 How do you cap LVT usage, and why set it early?Intermediate: Tag the LVT library cells as a threshold-voltage group, declare it low-Vt with `set_threshold_voltage_group_type -type low_vt LVT` (ICC2), and cap it with `set_multi_vth_constraint -low_vt_percentage <p>` (ICC2), by cell count or by area. `place_opt` (ICC2), `clock_opt` (ICC2) and `route_opt` (ICC2) then honour the cap on data-path cells. Set it early, because `route_opt` (ICC2) deliberately limits this optimization to avoid disturbing QoR.
188 Walk through a functional ECO from RTL fix to implemented layout.Intermediate: Fix the RTL, produce a golden ECO netlist, and prove it matches the new RTL in Formality. In ICC2, `eco_netlist -by_verilog_file` (ICC2) compares that netlist with the layout netlist and writes the edits as Tcl, which you source, place with `place_eco_cells -eco_changed_cells` (ICC2) and route with `route_eco` (ICC2). Then prove the layout netlist again in Formality and close timing in PrimeTime.
189 How does ICC2 know which cells an ECO touched?Intermediate: Each changed cell carries the `eco_change_status` (ICC2) attribute, and its value says what kind of edit touched it. `place_eco_cells -eco_changed_cells` (ICC2) works on cells whose status is create_cell, change_link, add_buffer, size_cell or add_buffer_on_route. After legalization the status becomes eco_legalized, so the same cells are not picked up again.
190 Why is hold checked at several corners, and how do you fix it across all of them at once?Intermediate: Each corner scales cell and wire delays differently, so hold slack, which depends on the difference between data delay and clock skew, can be worst in more than one corner. A delay cell that fixes hold in the fast corner adds even more delay in the slow corner and can break setup there. Run the fix in DMSA with every signoff scenario in focus, `current_scenario -all` (PT) then `fix_eco_timing -type hold` (PT), so each change is checked against all of them.
191 Postroute: what should route_opt fix and what should PrimeTime ECO fix?Intermediate: `route_opt` (ICC2) does the bulk of postroute fixing: setup, hold, area and logical DRC on data paths, with legalization and ECO routing in the same step. PrimeTime ECO handles what is left at signoff: violations only the signoff timer sees, with full extraction, SI, exhaustive PBA and every scenario. If ICC2 can see a violation, `route_opt` (ICC2) should fix it; PrimeTime should get a short list.
192 What breaks when an ECO adds cells across voltage areas, and how is it repaired?Intermediate: An ECO buffer on a net that crosses domains can land in a voltage area whose power domain does not match, get the wrong supply, sit on the wrong side of an isolation cell, or use a single-rail cell where a dual-rail cell is needed. Repair it with `fix_mv_design -buffer` (ICC2) for buffer trees and `fix_mv_design -diode` (ICC2) for diodes, and connect the supplies of new ECO cells with `eco_update_supply_net` (ICC2). Then check again, since the fixes are not guaranteed placement or timing legal.
193 How do you debug an LVS short?Intermediate: Fix power-to-ground shorts first, then power-to-signal, then signal-to-signal, and only then look at label and text shorts. A short merges two schematic nets into one extracted net, so a single bad jog can produce hundreds of unmatched devices. Use the LVS Short Finder output from IC Validator to see the exact polygon path between the two labels, and confirm routing-level shorts in ICC2 before you stream out again.
194 How do you debug LVS opens and floating shapes?Intermediate: An open means the pins of one net are not connected by its shapes, so one schematic net extracts as two or more layout nets. A floating shape is a piece of a net that touches none of its pins. Find both in ICC2 with `check_lvs` (ICC2) using full error counts and detailed open locations, fix power nets before signal nets, then confirm in IC Validator.
195 Why do port-label and text problems cause LVS failures?Intermediate: LVS uses text labels to give extracted nets their names and to anchor the top-level ports to the schematic. If a label lands on the wrong layer, misses its shape or sits on a shape of another net, the compare starts from a wrong or missing anchor. The result is a text open, a text short or unused text, and the rest of the compare often fails around it.
196 How are hard macros black-boxed in LVS, and what's the risk?Intermediate: A black box tells LVS to treat a macro as a cell with pins only, so the compare checks how the top level connects to those pins and skips the macro contents. IC Validator declares black boxes through the `lvs_black_box_options()` (ICV) runset function, which you can also add from a file with `-e` (ICV). The risk is that anything wrong inside the macro, including a stale GDS version, is never checked by your run.
197 What are equivalence points in hierarchical LVS?Intermediate: An equivalence point is a pairing of a schematic cell with a layout cell that LVS compares as its own unit. Hierarchical LVS compares these pairs separately, so an error is reported against a small cell instead of the whole chip. IC Validator takes pairs from `equiv_options()` (ICV), from a file passed with `-e` (ICV), or generates its own, and writes the list it used to `equiv.run` (ICV).
198 When is hierarchical DRC/LVS better than flat, and when do you flatten?Intermediate: Hierarchical verification checks each repeated cell once and reports its errors once, so it is the default for full-chip DRC and LVS. Flat verification sees every shape in its final context but costs far more runtime and memory and repeats every error per instance. You flatten selectively: a cell whose checks depend heavily on its surroundings, a small block where optimization is not worth it, or a debug run.
199 How do you speed up IC Validator runs?Intermediate: Give IC Validator more CPUs and let it decide how to use them. Standalone runs take hosts and CPU counts through `-host_init` (ICV) and can take more mid-run through `-host_add` (ICV). ICC2 In-Design runs use one process by default, so you set `set_host_options -target ICV` (ICC2) before running signoff DRC.
200 Which cell views does `signoff_check_drc` read, and why can that hide errors?Intermediate: By default `signoff_check_drc` (ICC2) reads the design view for the top-level block and standard cells, but only the pin information from the frame view for macros and I/O pads. The frame view is an abstraction, so shapes inside a macro that a top-level route could violate against are not there to check. You swap in real data through merged stream files, layout views or design views, in that order of precedence.
201 What does the In-Design layer mapping file do?Intermediate: The layer mapping file tells IC Validator In-Design which runset layer each ICC2 technology layer becomes. You point to it with `signoff.physical.layer_map_file` (ICC2). For `signoff_check_drc` (ICC2) it is needed whenever the technology file and the foundry runset use different layer numbers, and Live DRC requires it.
202 How does incremental signoff DRC work, and when does it fall back?Intermediate: `signoff_check_drc -auto_eco true` (ICC2) checks only the areas changed since the previous signoff DRC run. It works only after a previous run and only while the change is below `signoff.check_drc.auto_eco_threshold_value` (ICC2), which defaults to 20 percent. Above that you are back to a full-block run, and final signoff is always a full run.
203 What does `signoff_fix_drc` do by default?Intermediate: `signoff_fix_drc` (ICC2) has Zroute fix signoff DRC violations found by IC Validator, then rechecks with IC Validator. By default it runs an initial signoff check, two repair loops, skips rules with more than 1000 violations, runs five detail-route iterations after fixing, and saves the result as a design view named `block_ADR_#` (ICC2). It writes `result_summary.rpt` (ICC2) to the working directory.
204 Why set `signoff.check_drc.ignore_child_cell_errors true` before auto-fixing?Intermediate: Zroute can fix only top-level violations, so the check that feeds auto-fix should report only those. Setting `signoff.check_drc.ignore_child_cell_errors` (ICC2) to true makes `signoff_check_drc` (ICC2) write only top-level errors to the error data. Child-cell errors still exist and need their own check and owner.
205 How are double-patterning odd-cycle violations fixed at signoff?Intermediate: An odd cycle is a loop of an odd number of shapes, each too close to the next to share a mask, so no two-colour assignment works. At signoff you fix all other routing rules first with the double-patterning rules unselected, then run a separate fix pass on only the double-patterning rules with `signoff.fix_drc.custom_guidance` (ICC2) set to dpt. A final full signoff check confirms both.
206 What is Live DRC in ICC2, and when is it useful?Intermediate: Live DRC runs IC Validator with the foundry runset on what is displayed in the ICC2 layout window, so you can check a hand edit or ECO area in seconds. It needs IC Validator P-2019.06 or later, a runset in `signoff.check_drc_live.runset` (ICC2) and a layer map in `signoff.physical.layer_map_file` (ICC2). It is a local debug tool, not a replacement for full signoff DRC.
207 How does the DRC heat map help triage thousands of violations?Intermediate: A heat map shows where violations are dense instead of listing them one by one, so thousands of errors turn into a few clusters with a likely shared cause. In ICC2 you turn it on with `signoff.check_drc.enable_icv_explorer_mode` (ICC2) before `signoff_check_drc` (ICC2); it needs IC Validator P-2019.06 or later and an IC Validator NXT licence. Standalone, IC Validator Explorer DRC runs the high-priority checks first and opens its results with a heat map in VUE.
208 How are known, accepted DRC violations waived without hiding new ones?Intermediate: In IC Validator you classify each accepted error once, export the classifications to an error classification database (cPYDB), and import that database into later runs through the `match_errors` (ICV) argument of `error_options()` (ICV). An error comes back pre-classified only when it matches an entry in the cPYDB, so anything new or changed still shows up unclassified. For hierarchical matching, run with `-pec EXPLODE` (ICV), especially on the run that creates the cPYDB.
209 How do you remove only the fillers that cause DRCs?Intermediate: Use `remove_stdcell_fillers_with_violation` (ICC2), which checks filler instances against routing and deletes only the ones with violations. Run it first with `-check_only true` (ICC2) to see what it would remove, then in removal mode, and repeat until it reports that it deleted 0 cell instances. Removing one filler can expose a violation on its neighbour, so one pass is often not enough.
210 What is threshold-voltage-based filler insertion?Intermediate: It is a filler flow in which ICC2 picks the filler for each gap from the threshold-voltage types of the cells on its left and right. You label VT types with `set_cell_vt_type` (ICC2), write rules with `set_vt_filler_rule` (ICC2) and insert with `create_vtcell_fillers` (ICC2). The guide says this flow is typically used only for established foundry nodes; the other method is the standard `create_stdcell_fillers` (ICC2) flow.
211 How do you control the decap mix and leakage when inserting fillers?Intermediate: Decap fillers add decoupling but also leak, so you decide how much of the empty space becomes decap and which VT flavour it uses. `create_stdcell_fillers -type_utilization` (ICC2) sets an insertion percentage per filler group, `-fill_remaining` (ICC2) fills what is left from the `-lib_cells` (ICC2) cells that are not in those groups, and `-leakage_vt_order` (ICC2) makes the tool choose the lowest-leakage filler that legalizes.
212 A late ECO lands after fill. How do you remove and repair fill safely?Intermediate: Remove and refill fill only where the ECO touched, then re-check DRC, density and timing. `signoff_create_metal_fill -auto_eco true` (ICC2) does this automatically when less than 20 percent of the block changed since the last fill run, and `-remove_by_rule drc_auto` (ICC2) removes track-based fill that now causes DRC violations. A plain `-mode remove` (ICC2) takes out all fill, TCD structures included, unless you restrict it with `-select_layers` (ICC2).
213 Why extract parasitics with real metal fill before final STA?Intermediate: Metal fill sits beside and above your signal wires, so it adds capacitance that routing-stage extraction did not see. Before fill you estimate that effect with emulation TLUPlus or virtual metal fill; after fill, the real shapes are what will be on silicon. Final timing should use extraction that includes them, which in ICC2 means non-emulation TLUPlus plus `set_extraction_options -real_metalfill_extraction floating` (ICC2).
214 What are MiM capacitors, and how are they inserted?Intermediate: A MiM capacitor is two special conducting plates with an insulator between them, built between two regular metal layers such as M8 and M9, and usually connected between power and ground to steady the supply. Because it sits in the upper stack, it adds decoupling without using standard-cell row area. In ICC2, `create_mim_capacitor_array` (ICC2) places an array of a MiM library cell at a fixed x and y pitch, and by default it ignores standard cells, macros, placement blockages and voltage areas.
215 How do you run IR/EM analysis from inside ICC2 with RedHawk Fusion?Intermediate: Point ICC2 at the RedHawk or RedHawk-SC executable with `rail.product` (ICC2) and `rail.redhawk_path` (ICC2), set the rail input options, create taps, and run `analyze_rail -voltage_drop static -nets {VDD VSS}` (ICC2). ICC2 writes the GSR and run script, RedHawk does extraction, power and the solve, and results return to the rail database, where `open_rail_result` (ICC2) loads maps and `report_rail_result` (ICC2) writes text. EM follows on the final grid with `analyze_rail -voltage_drop static -electromigration -nets {VDD VSS}` (ICC2).
216 What is the standalone RedHawk static IR/EM flow?Intermediate: In the RedHawk TCL shell you import the design through a GSR file, build the database with `setup design` (RH), calculate power with `perform pwrcalc` (RH), extract the power and ground networks with `perform extraction -power -ground` (RH), and solve with `perform analysis -static` (RH). EM is a separate step, because RedHawk does not check it during simulation unless the ENABLE_AUTO_EM keyword is set, and `perform emcheck` (RH) reports it. Standalone RedHawk needs an Ansys licence.
217 Vectorless vs VCD-based dynamic IR: what does each assume?Intermediate: Vectorless analysis has no simulation vectors: RedHawk builds a realistic worst-case switching scenario from toggle rates, timing windows and the known average power, so it covers cases you never simulated but rests on those settings. VCD-based analysis replays switching from a gate-level simulation with timing, so it is exact for that activity and blind to activity the testbench missed. Standalone RedHawk runs them with `perform analysis -vectorless` (RH) and `perform analysis -vcd` (RH); in ICC2 the modes are `analyze_rail -voltage_drop dynamic_vectorless` (ICC2) and `analyze_rail -voltage_drop dynamic_vcd` (ICC2).
218 What does minimum path resistance analysis reveal that IR drop doesn't?Intermediate: IR drop is resistance times current, so a badly connected cell that happens to draw little current can pass an IR check. Minimum path resistance ignores current and reports the resistance of the least-resistive path from each pin to its taps, which exposes structural weaknesses such as a missing via or a single thin connection. It runs with `analyze_rail -nets {VDD VSS} -min_path_resistance` (ICC2) in Fusion, and with `perform min_res_path` (RH) or `perform gridcheck` (RH) in standalone RedHawk.
219 How do you run and read power-grid EM analysis?Intermediate: PG EM analysis compares the current density in every power and ground segment and via against the layer limits in the technology file and reports it as a ratio. In ICC2 you set `rail.tech_file` (ICC2) and run `analyze_rail -voltage_drop static -electromigration -nets {VDD VSS}` (ICC2); in standalone RedHawk you run `perform emcheck` (RH) after the analysis in AVG, RMS or PEAK mode. Anything over 100% needs wider metal, more vias, or less current through that segment.
220 The grid is too weak in one region. What fixes exist?Intermediate: You either lower the resistance between the taps and the weak cells or lower the current they draw at once. The grid options are wider straps, extra straps or via stacks, and PG augmentation, where `signoff_create_pg_augmentation` (ICC2) uses a RedHawk Fusion voltage drop result to add PG shapes in free space through IC Validator. In standalone RedHawk, `mesh fix` (RH) and `mesh optimize` (RH), driven by GSR keywords, work out new strap widths and write an ECO file that still has to be implemented in the layout.
221 Why do clustered clock buffers create dynamic IR hotspots?Intermediate: Clock buffers switch on every clock edge, within a narrow time window, and usually drive large loads, so they draw big current pulses at the same moment. Packed into one small area, they pull that charge through the same rails, vias and local decap, and the local supply dips far more than the block average suggests. Spreading clock buffers evenly, and placing decap next to the ones that must stay close, keeps the drop down.
222 How is thermal analysis run in ICC2?Intermediate: ICC2 runs Kelvin thermal analysis with `analyze_thermal` (ICC2) after you open the block and set the thermal application options. Most options have defaults, but `thermal.tech_file` (ICC2) must be provided in the basic flow, while power and metal profiles are generated in memory if you do not supply them. You then view the temperature map in the GUI and use `report_thermal_qor -threshold 35.9` (ICC2) to list results above a temperature in Celsius.

Preparing for a physical design interview? Take the answers with you.

All 1109 questions and answers as 4 PDF books: PnR, STA, MMMC and Low Power.
A clickable table of contents, so you can search and jump offline.
Delivered by email within seconds of payment. Full refund if the files fail to arrive or open.

See what is inside the bundle · ₹349 Physical Design & Planning Handbook Complete library