Level 4: Signoff Reasoning
Expert PnR (Place & Route) Interview Questions
Master scenario-based readiness decisions, conflicting evidence triage, floorplan DRC/congestion closure, and proceed-or-stop reviews.
0 of 161 marked complete
Want all 1109 answers offline as 4 PDF books?
See the 4-book bundle · βΉ349Physical Design & Planning HandbookComplete libraryWhat to practise at this level
Master scenario-based readiness decisions, conflicting evidence triage, floorplan DRC/congestion closure, and proceed-or-stop reviews.
- 01 Thousands of registers show no_clock after SDC load. What do you do?Expert: When thousands of registers suddenly report `no_clock`, don't reach for a targeted patch β treat it as a hard stop and a readiness check on the whole handoff, because a fix at this scale that "just" attaches clocks locally is very likely to be masking a real upstream problem. Systematically test the competing root causes rather than guessing: wrong current mode active in the tool, an empty or misconfigured clock-source selector, a broken generated-clock or gated-clock path somewhere upstream, or a hierarchy mismatch between the SDC's object names and the actual netlist.
- 02 A generated clock exists by name but has no valid path from its master. How do you diagnose it?Expert: The existence of an object named as a generated clock in your database proves only one thing β that the object was created. It says absolutely nothing about whether it's electrically or logically valid, and treating "it exists" as "it's correct" is exactly how this bug slips through review. A properly formed generated clock has to be derived from another clock through *real* logic β a divider, a MUX, some genuine circuit path β its source and master relationship must trace back through actual netlist connectivity, not just a name someone typed into an SDC command.
- 03 Why can a very low unconstrained-endpoint count coexist with poor coverage?Expert: A low unconstrained-endpoint count sounds like good news, but "unconstrained" and "well-covered" are answering different questions β an endpoint can have *some* constraint applied and still be poorly covered by real timing analysis. False paths silently remove endpoints from meaningful analysis without making them "unconstrained" β the constraint exists (`set_false_path`), so the endpoint doesn't show up as missing anything, but it's also not being genuinely checked.
- 04 Timing becomes clean after a broad false path. What is the correct response?Expert: Don't celebrate yet β a broad false-path declaration removing a lot of violating paths from the report is exactly as likely to mean "we hid a real bug" as "we correctly excluded impossible paths." Clean timing alone doesn't tell you which. The correct response is to treat the improvement as unproven until you've verified exact path membership β pull up precisely which paths the false-path constraint removed and check each one individually, not just trust the wildcard pattern you used.
- 05 A case-analysis constraint removes many paths. How do you decide whether it is valid?Expert: `set_case_analysis` pins a control signal to a constant (0 or 1) to model one functional mode β the validity question is really "does this constant actually match a mode this chip will really operate in?" Trace the constant back to its source object β is it a real strap pin tied at the board level, a fuse/OTP bit, a scan-mode signal, or something else? Each source type has different confidence: a board-level strap is usually solid; a scan/test-mode signal being case-analyzed in the *functional* SDC is a red flag.
- 06 A register behind a clock MUX sees multiple clocks. Is that always an error?Expert: No β seeing two different clocks arrive at one clock pin isn't automatically a bug. It's exactly what you'd expect at a **clock MUX** (functional clock vs. test clock, or two PLL outputs for different performance modes), where only one input is actually selected at a time in any given operating mode. The tool, though, doesn't know your chip's functional intent by default β it just sees a pin with two active clock definitions and will report it, sometimes as a DRC-style warning, sometimes just noise in the report.
- 07 How do you triage a combinational loop before floorplanning?Expert: Not every reported "loop" is a mistake β some designs genuinely have intentional feedback (a self-enabling latch structure, a deliberate oscillator-like element, certain memory model constructs), so the first job is figuring out which kind you're looking at. Pull the actual netlist path the tool flagged and trace it by hand: does the signal genuinely loop back through purely combinational logic with no register in between (a real, accidental loop β usually from a synthesis or RTL bug), or does it pass through something the tool is mis-modeling as combinational when it's actually a latch or intentional feedback structure?
- 08 Ignored exceptions appear in the report. What does that mean?Expert: Just because an exception (a false path, multicycle path, or case-analysis setting) is sitting in your SDC doesn't mean it's doing anything β the tool can load it, parse it fine, and still never apply it to a single path. One common reason: it's overridden. SDC exceptions have precedence rules, and a more specific or more recently applied exception on the same path segment can silently take priority over an earlier, broader one.
- 09 Setup improves after a multicycle exception but hold becomes strange. Why?Expert: This is one of the classic SDC traps: declaring a multicycle path fixes the setup check you were chasing, but if you don't also derive the matching hold relationship, hold checking silently goes wrong on the same path. A multicycle path is one that's functionally allowed more than one clock cycle to complete β but `set_multicycle_path` by default only shifts the setup check; the hold check still assumes the *original* single-cycle relationship unless you explicitly tell it otherwise with the hold-side multicycle specification.
- 10 A disabled timing arc removes a clock path. How do you find ownership?Expert: A "disabled arc" just means STA has been told to stop propagating timing through a specific point in a cell or net β and when that happens on a clock path, an entire downstream clock tree can silently go unanalyzed, which is a lot scarier than a disabled arc on a random data path. The first job isn't to re-enable it blindly β it's ownership hunting: figure out *who* disabled it and *why*, because the fix is completely different depending on the source.
- 11 Functional constraints were loaded into test mode. What evidence exposes it?Expert: This is a debugging exercise, and the way you catch it is by comparing what a scenario *actually contains* against what it *should* contain for its declared mode β a mislabeled scenario usually leaves fingerprints across several categories at once. Start with **scenario-mode association**: does `report_scenarios` or the equivalent actually show test mode pointing at the SDC file/constraints intended for functional mode? This is often the most direct smoking gun β a filename or mode tag mismatch.
- 12 One required mode/corner combination is missing. Can floorplanning start?Expert: The right question isn't "is one scenario missing" β it's "does the missing scenario change what we believe about logical or timing readiness." If yes, that missing coverage is a hard stop, full stop, regardless of how much other work seems ready to start. This is fundamentally a readiness check on the coverage matrix (modes x corners x scenarios), not a floorplan-specific problem β floorplanning just happens to be the stage where the gap becomes consequential.
- 13 How do you compare functional and test-mode readiness?Expert: Functional mode and test mode are not interchangeable checks of the "same thing twice" β they're genuinely different operating conditions with different clocks, different constants, and different expected behavior, and a clean result in one mode tells you nothing conclusive about the other. Compare clock definitions separately per mode β test mode very often uses different clock sources, different frequencies, or scan-clock muxing that functional mode never exercises, and vice versa.
- 14 ICC2 and PrimeTime disagree. How do you test a unit hypothesis?Expert: Before assuming a real timing bug, rule out the boring explanation first: are both tools even reporting in the same units? A slack reported in "ns" versus "ps" without noticing looks like a 1000x discrepancy that isn't a timing bug at all. Pull each tool's reported units directly β clock period units, delay units, slew units, capacitive load units β and compare them side by side rather than assuming they match by convention.
- 15 How do you test whether ICC2 and PrimeTime use different libraries?Expert: A library mismatch between two tools is one of the sneakiest correlation bugs, because both tools can report plausible-looking numbers while quietly reading different characterization data underneath. First confirm the resolved library *version* each tool actually loaded β not just the library name, but which release/revision β since the same library name can point to different `.db`/`.lib` files across environments if search paths differ.
- 16 How do you correlate clock differences between ICC2 and PrimeTime?Expert: Two tools disagreeing on timing is almost never a "which tool is buggy" question β it's an "are they analyzing the same thing" question, and clocks are one of the richest places for silent mismatches to hide. Start with clock creation itself: same `create_clock` period/waveform, same source pin, and check any generated clocks (`create_generated_clock`) are derived identically in both environments.
- 17 A bulk input-delay command constrained the clock port. What is the impact?Expert: A bulk `set_input_delay [all_inputs]`-style command is a footgun on any design where the clock is also a top-level port, because it accidentally treats the clock pin as ordinary data. The clock port is supposed to be excluded from data-path constraints β it defines the timing reference itself, it isn't a signal that arrives relative to that reference.
- 18 A negative output minimum delay appears. Is it automatically wrong?Expert: No β a negative minimum output delay is not automatically a bug; the sign can legitimately follow the receiving interface's own hold convention, so seeing a minus sign shouldn't trigger an automatic "fix" reflex. What actually matters is whether the value was deliberately derived from the interface spec and correctly associated with the right clock and clock edge β a negative number that's correctly derived is fine; a negative number that just fell out of a copy-pasted constraint template is not.
- 19 Many constraints target objects optimised away by synthesis. Who owns the fix?Expert: When a pile of SDC constraints reference objects that synthesis already optimized away, the underlying problem is that the applied SDC and the delivered netlist have drifted out of sync β and that's a mapping/regeneration problem, not something PD should be quietly patching around. The instinct to write local wildcard fixes ("just widen the pattern match so the constraint applies to *something*") is exactly the wrong move β it papers over a real handoff defect instead of fixing it.
- 20 How do you approve an intentional undriven or unloaded object?Expert: Signing off a waiver on an undriven/unloaded net or pin is a real engineering decision, not a rubber stamp β treat it with the same rigor as any other design-affecting approval. Require named-object evidence first: exactly which net, pin, or port is being waived β never approve a waiver at the level of "there are 40 undriven pins in this category," because that hides individual cases that might not actually be safe.
- 21 A macro remains a black box one day before floorplanning. Proceed or stop?Expert: Default answer: stop β unless you can point to the specific approved abstraction and confirm the next stage's interface requirements are actually satisfied, and the project has explicitly signed off on accepting that model state. A black box is fine on purpose β that's the whole point of abstraction, hiding internal logic you don't need to see yet. The problem isn't the black box itself; it's an *unverified* black box.
- 22 Why is zero reported timing violations insufficient for readiness?Expert: Zero violations only tells you the paths that were actually analyzed, in the scenarios that were actually active, came back clean β it says nothing about paths the tool never looked at. A clean report can hide missing clock definitions, exceptions that were never written (so paths are silently over- or under-constrained), tied-off constants that eliminate paths from analysis, inactive modes that weren't checked, or entire absent paths that should exist but don't.
- 23 Must every sanity warning be zero?Expert: No β the goal isn't a warning count of zero, it's that every remaining warning has been actually looked at and understood, which is a very different bar. Each warning needs to be sorted into one of two buckets: a real defect that needs fixing, or a justified, intentional structure that happens to trigger the check β and that sorting decision has to be made explicitly, not assumed.
- 24 When should PD return the handoff instead of editing locally?Expert: The dividing line is authority, not difficulty: if the defect lives in functional connectivity, synthesis structure, the library release, interface timing intent, or mode definitions, PD editing it locally is out of scope even if PD technically *could* patch around it. A local PD-side fix to one of these categories risks quietly diverging from the design's actual golden intent β the netlist or constraint set PD is working from stops matching what synthesis/RTL/architecture actually meant.
- 25 How do you make the final proceed-or-stop decision?Expert: This is a broader version of the floorplan gate decision β it applies whenever a stage handoff (SDC readiness, linking, structure review) needs an accountable "go / no-go" rather than just a pile of passed checks. Proceed only when provenance genuinely matches β the constraints, netlist, and libraries you're reviewing actually correspond to the version you think they do, not a stale or mismatched set.
- 26 All floorplan legality checks pass, but congestion is unacceptable. What do you do?Expert: Legality and quality are two separate questions, and passing one tells you nothing about the other β a legal street map can still route you into an impossible traffic jam at one intersection. Keep the legal baseline as-is β don't start ripping up the whole floorplan just because congestion is bad in one area; isolate the problem first.
- 27 Average utilisation is good, but one region is locally impossible. How do you prove it?Expert: Chip-average utilization is a useless number here β it's like saying a city has plenty of parking on average while one block is gridlocked. You have to zoom into the specific region and measure *its* usable area, not the die's. Usable area in that region = the physical area of standard-cell rows minus everything that eats into it: macro keepout halos, hard/soft placement blockages, voltage-area guardbands, fixed cells, and row fragments left by macro edges. Report that number with `report_design`/effective-utilization math, not the naive rectangle area.
- 28 Two equal-area aspect ratios disagree on timing and congestion. Which wins?Expert: Neither wins automatically β no single metric decides a floorplan aspect-ratio tradeoff, which is exactly why this question trips people up when they reach for "just pick whichever number is better." It's entirely normal for the two shapes to disagree in opposite directions: one aspect ratio shortens critical paths (better timing) while concentrating pins into a smaller region (worse congestion), and the other does the reverse.
- 29 A macro array is legal, but its allowed orientations create pin-access failure. How do you respond?Expert: Legality defines the *space* of allowed solutions (which orientations, which spacings are geometrically valid) β it doesn't guarantee every point in that space is actually routable, and a macro array is a classic place this bites you. Never force an illegal orientation just to fix pin access β that trades one hard failure (geometry/legality) for a different kind of hard failure that's equally unacceptable.
- 30 A macro channel routes before PG reservation but fails after straps are planned. What is the correct fix?Expert: The real story here isn't "the channel broke" β it's that the earlier estimate was optimistic because it didn't yet account for PG straps that hadn't been planned when that first route succeeded. The channel's physical capacity didn't change; your model of it just became accurate. The fix is to recompute usable signal-track capacity honestly, now including PG strap widths, their spacing rules, the vias needed to connect them, and any blockages the straps introduce β this gives you the real post-PG-planning capacity, not the pre-PG estimate you were working from before.
- 31 One macro has a huge halo; another has pin-access failure from a small halo. How do you size them?Expert: A single uniform halo number applied to every macro is lazy and wrong β macros aren't symmetric, and a halo is a personal-space bubble that should only be as big as each side actually needs. Look at each macro edge independently: where are the pins concentrated, how many routing tracks/vias does that side need, are optimization cells (buffers, tap cells) expected to land there, and is there PG-shape traffic hugging that edge?
- 32 Boundary or corner cells are missing or wrongly oriented around a voltage area. What do you check?Expert: Start by checking the geometry of the voltage area itself β its boundary shape, whether it's rectangular or rectilinear, and whether it overlaps or nests with other voltage areas in a way that creates unusual corner cases. Check row orientation at each edge β remember standard-cell rows alternate orientation (flipped/rotated) every other row so adjacent rows share power rails, and boundary/corner cells must match that alternating pattern or they'll be flagged as wrongly oriented.
- 33 Fixed package pins fight the logical dataflow. What can floorplanning change?Expert: The package pin locations are usually a hard external constraint β you can't wish them away, so the real question is what floorplanning *can* still adapt to make the best of a fixed doorway. Macro locations are still yours to move β position macros to minimize the mismatch between where the package pins land and where your logical dataflow naturally wants to go.
- 34 A feedthrough improves top-level timing but harms the block interface. How do you decide?Expert: This is a classic local-vs-global optimization conflict: the top-level integrator sees a timing win, the block owner sees a cost they didn't budget for, and neither party alone has enough information to make the call correctly. A faster route isn't automatically the right decision β "shorter and faster at the top level" has to be weighed against what it actually costs the block: pin count consumed, pin alignment disruption, routing capacity used up, buffering burden, voltage-area compatibility, and future ECO flexibility lost.
- 35 A block pin is legal but off-track, stacked, or on an unusable layer. What is the response?Expert: Passing legality checks proves the pin satisfies placement/geometry rules β it says nothing about whether a router can actually get a wire into it, and those are genuinely different questions. Treat this explicitly as a pin-access defect, not a legality problem, and start by reporting the pin's actual geometry alongside the nearby track grid and available routing resources on that layer.
- 36 Congestion becomes severe only after PG-resource reservation. What does that prove?Expert: It proves your earlier "signal-only" congestion estimate was optimistic, not that power planning is somehow the enemy β power/ground routing consumes real tracks too, and any congestion estimate that ignores PG reservation is only looking at part of the picture. Once PG straps, rings, and rails claim their share of routing resources on certain layers, the remaining capacity for *signal* routing shrinks β sometimes dramatically in specific directions or on specific layers β and that's exactly when previously-invisible congestion hotspots surface.
- 37 A voltage-area boundary strands cells or creates an unusable sliver. How do you diagnose it?Expert: The core trap here: a voltage-area polygon can report plenty of raw area on paper while containing far too little actually-usable placement space β polygon area and usable area are not the same number. Diagnosis starts by comparing the assigned cell area (plus its expected growth) against what's legally placeable once you subtract legal rows, guard bands, enclosure margins, boundary-cell requirements, and isolation/level-shifter zone reservations.
- 38 Early timing improves while congestion worsens. How do you choose the next move?Expert: Identify which named paths improved and which local resources failed, then test a change that preserves the timing benefit while relieving concentrated demand.
- 39 Two engineers report different results for the same floorplan. How do you isolate the cause?Expert: "Same floorplan" is a claim, not a fact β a screenshot looking identical tells you nothing about whether the underlying analysis state (tool version, options, scenario, library) actually matches. Start with provenance before comparing any numbers: was the floorplan written out from the same checkpoint, using the same tool version, and loaded with the same app options on both sides?
- 40 initialize_floorplan produces an invalid or unexpected boundary. What do you check?Expert: `initialize_floorplan` has several ways to describe the outline (fixed size, aspect ratio + utilization, explicit boundary points), and mixing incompatible assumptions across these options is the single most common cause of a surprising result. Check the control type first β are you specifying a fixed die size, a target utilization + aspect ratio, or explicit polygon coordinates? Each interprets the same numbers completely differently.
- 41 A macro is inside the core but off-grid or illegally oriented. Is this a minor warning?Expert: No β this is not a minor warning, and treating it as one is a common but costly mistake. "Inside the core boundary" tells you nothing about whether the macro is sitting on a legal manufacturing/block-grid coordinate. An off-grid or illegally-oriented macro can break several things at once: manufacturing/block-grid requirements, pin access, array-alignment relationships with neighboring instances, and power connectivity β any one of which is a signoff blocker on its own.
- 42 Power or pin checks report missing or wrong routing tracks. How do you proceed?Expert: Routing tracks are defined by real technology-layer rules β they're not decorative grid lines you can regenerate arbitrarily just to make a check pass. The right first move is confirming the technology-layer definitions themselves: preferred routing direction, pitch, offset, width, whether the track set covers the full core, any restricted regions, and β importantly β whether the tracks were deliberately regenerated at some point in the flow (which can be a legitimate reason for a mismatch).
- 43 Macros overlap or extend outside the parent boundary after refinement. What is the correct debug path?Expert: Whatever overlap or out-of-bounds condition you see visually is just the symptom β the actual bug is whichever constraint or transformation caused it, and debugging means finding that cause, not just nudging the macro back inside the boundary. Work systematically through the likely causes: stale constraints left over from an earlier floorplan iteration, a macro's fixed/movable status being wrong, orientation-dependent dimensions changing after a rotate/mirror, an unintended snap movement, a relative-location constraint pulling it out of place, a voltage-area conflict, or simply having loaded the wrong floorplan version.
- 44 Rows remain under macros or blockages. Why is that dangerous?Expert: Think of it like a painted parking space directly underneath a building β it still shows up as a marked space on the map, but no car can ever actually park there. Rows left under a macro or blockage are the placement-area equivalent. The danger is concrete: these rows inflate the nominal row-area / placeable-capacity number, which can mislead early utilisation and legality checks into looking healthier than the design actually is.
- 45 Pin constraints conflict with routing blockages or PG shapes. Who owns the fix?Expert: The uncomfortable reality of this conflict is that both constraints can be individually valid and still be jointly impossible to satisfy at the same location β this isn't a case of one side simply being wrong. Ownership resolution starts by figuring out which constraint is actually authoritative here: package/interface intent, the block pin constraint itself, the routing blockage, or the PG reservation β and that's a negotiation between whoever owns each of those, not a unilateral PD call.
- 46 check_feedthroughs reports unused, reused, and constraint violations together. How do you triage them?Expert: The report bundling everything into one total count is the trap here β "unused," "reused," and "constraint violation" are three completely different situations lumped into a single number, and treating them as one problem leads to the wrong fix. Separate the classifications before you do anything else β an unused feedthrough is wasted resource, a reused one is often intentional efficiency, and a constraint violation is an actual correctness bug. Mixing them means you might "fix" something that was never broken.
- 47 The floorplan has no credible space for the proposed power grid. Can macro placement proceed?Expert: No β a floorplan that only "works" if you ignore the power grid isn't actually a working floorplan, it's a floorplan with a deferred failure baked in. Power planning isn't an afterthought layered on top of a finished floorplan β rings, straps, rails, macro pin access, power-switch corridors, and via paths all need real reserved space, and that reservation has to happen before (or concurrently with) macro placement, not after.
- 48 A critical path detours around a macro despite acceptable centre-to-centre distance. What should you inspect?Expert: This is a classic trap: the straight-line, center-to-center distance between two macros can look perfectly reasonable while the *actual legal route* between their real pins is much longer β because timing follows routable geometry, not a ruler line drawn between abstract macro centers. Start with the real pin locations, not the macro centers β if the relevant pins sit on the far sides of each macro relative to each other, the effective route is already longer than the naive center-to-center number suggested.
- 49 How do you compare two floorplans without cherry-picking metrics?Expert: The core discipline here is simple to state and easy to violate under deadline pressure: decide what you're measuring and how you're measuring it *before* you look at which floorplan wins on that metric β otherwise you'll unconsciously pick the metrics that favor whichever option you already prefer. Build one scorecard with declared, written-down definitions for area/utilization, usable-row count, macro legality, channel feasibility, pin constraints, congestion, PG reservation, voltage-area legality, early timing, and change risk β and apply the exact same measurement method to both floorplans.
- 50 How do you make the final floorplan proceed, iterate, waive, or return decision?Expert: This is the moment where a pile of reports has to become one owned engineering decision β the gate isn't about running more checks, it's about someone actually deciding what happens next and being accountable for that call. **Proceed** only when the fundamentals are physically credible and reproducible: boundaries, rows, macro legality, feasible channels, constrained pins, feedthrough classification, tracks, PG reservation, voltage-area legality, congestion, and early timing all have to hold up, not just look fine at a glance.
- 51 Why does setup timing slack (WNS/TNS) frequently degrade after Legalization, and how is it resolved?Expert: Global placement is a somewhat idealized floating-point world β cells can overlap slightly and sit at fractional coordinates. Legalization is where reality hits: every cell has to snap onto a real, non-overlapping row site, and that snapping can shove cells noticeably far from where the timing-optimized global placement wanted them. In dense regions (say, 90% local utilization), several timing-critical cells are all competing for the same handful of legal sites, forcing the legalizer to displace some of them outward β sometimes 5 to 20 Β΅m β just to resolve the overlap.
- 52 How do sub-7nm FinFET pin-access design rules impact standard cell placement and legalization?Expert: Below about 7nm, the lower metal layers (M1, M2, M3) are typically built with multi-patterning lithography (LELE or SADP) and strict unidirectional routing tracks β which means simply landing a via on a cell pin is no longer trivial the way it used to be. The core pin-access problem: connecting a via down to a tiny M1 pin stub has to simultaneously satisfy on-grid via center landing, minimum end-of-line enclosure on M1, and minimum cut-to-cut spacing across different lithography masks β three constraints that can easily conflict with each other on a dense cell.
- 53 How do multi-voltage power domains (UPF) constrain standard cell placement and level-shifter positioning?Expert: Think of a multi-voltage chip as separate mini-countries with their own currency (voltage) β a cell that belongs to the 0.75V CPU domain physically cannot live outside the CPU's voltage-area polygon, because the rows there are wired to VDD_CPU, not the top-level 0.95V rail. The voltage area is a real floorplan object the placer treats as an exclusive move bound β `create_voltage_area -power_domains {PD_CPU} -region {...}` β and cells mapped to that domain are hard-constrained inside it.
- 54 How do you identify and debug runaway buffer insertion (buffer bloat) during `place_opt`?Expert: Buffer bloat is what happens when `place_opt` inserts so many buffers to fix electrical or timing problems that your standard-cell count balloons 20β40% β and the instinct to just throw more area at it is usually treating the symptom, not the disease. Root cause #1 β unrealistic input transitions: if `set_input_transition 5.0` is declared on a port feeding a 0.5 ns clock domain, the tool has to build a chain of 10+ cascaded buffers just to slew that edge down to something usable. Check your SDC input transitions against your actual clock period before blaming the placer.
- 55 Why is scan-shift hold time fixing intentionally deferred during placement optimization?Expert: Scan flip-flops sit in long shift chains connected through dedicated scan-in/scan-out pins, and during scan-shift mode the clock runs much slower than functional speed β hold time between adjacent scan flops in that mode depends purely on local clock skew. The catch: during placement, clocks are still modeled as ideal (zero latency, zero skew, per the earlier "why clocks must remain ideal" question) β so under that ideal model, literally every back-to-back scan flop pair looks like a hold violation, even though none of them actually are.
- 56 How do you calibrate and correlate pre-CTS placement timing with signoff PrimeTime STA?Expert: This is the classic "tool divergence" tapeout risk: your implementation tool (ICC2/Innovus) reports clean, comfortable slack pre-CTS, and then signoff PrimeTime β often run with different assumptions β reports massive negative slack on the same paths. Closing that gap is what correlation work is about. **Align the SDC first, always.** Both environments need identical clock definitions, generated clocks, multicycle paths, and case analysis β literally run `check_timing` in PrimeTime and confirm it matches what the implementation tool has active. A single missing generated-clock relationship or mismatched case-analysis setting can produce a huge, misleading divergence that has nothing to do with the physical implementation at all.
- 57 How do you resolve severe standard cell placement congestion in narrow channels between hard macros?Expert: Narrow corridors between adjacent SRAMs or IP blocks are the single most common source of unroutable placement layouts β the global placer naturally wants to pack logic there to minimize wirelength to nearby macro pins, without knowing the channel's metal tracks are already spoken for by macro power rings, PG straps, and wide data buses. Remedy 1 β partial placement blockages: cap placement density in the channel (say, 30-50%), which leaves the router room to use the rest of the channel's tracks for macro feedthroughs and bus routing while still allowing some minimal buffer placement.
- 58 How does Physical Register Retiming work during placement, and how is Formal Verification maintained?Expert: When a combinational logic cone between two pipeline stages has badly imbalanced delay, sizing and buffering alone often can't close setup timing β retiming actually moves the register boundary itself to rebalance the pipeline. Mechanically: forward retiming slides a flip-flop from a logic gate's input pins to its output pin, and backward retiming does the reverse β moving a register from a gate's output back across to all of its input pins β reshaping where pipeline stage boundaries physically sit.
- 59 How does `place_opt` resolve optimization conflicts across competing MMMC views?Expert: Optimizing a chip for a single corner/mode combination inevitably hurts it in the other operating views it also has to survive β this is the core tension MMMC placement optimization exists to manage. Concrete example of the conflict: Scenario A (functional mode, slow-slow corner, setup-critical) wants high-drive LVT/ULVT cells and wide buffers to overcome slow transistor switching and high RC delay.
- 60 What mandatory checks define the Placement Signoff Gate before proceeding to Clock Tree Synthesis (CTS)?Expert: Proceeding into CTS on an unverified or illegal placement is a guaranteed way to build an unroutable clock tree and blow timing closure downstream β this gate exists precisely to catch that before it becomes an expensive problem. Placement legality must be exactly zero across the board: zero unplaced instances, zero cell overlaps, zero off-grid instances, zero illegal orientation flips, and zero pin-access violations β "mostly clean" doesn't count here.
- 61 What does enabling a trial clock tree in place_opt actually change, and why would you turn it on before CTS?Expert: By default, place_opt.flow.trial_clock_tree is false and place_opt uses ideal (zero-delay) clocks throughout placement -- fast, but blind to real clock-tree insertion delay. Setting place_opt.flow.trial_clock_tree = true makes the tool build a temporary clock tree and use propagated clocks during placement instead, which is exactly what CCD (Concurrent Clock and Data optimization) needs to compute useful skew accurately during place_opt. The tradeoff is real: more accurate pre-CTS timing, at the cost of building and discarding a throwaway tree during every placement iteration.
- 62 What is Common Path Pessimism, and how does CPPR remove it?Expert: A good CTS algorithm branches clock paths as late as possible -- close to the leaf cells, not near the source -- so that under on-chip variation, delay differences along each path stay local and the shared (common) portion of the path doesn't contribute to skew. But that same shared common path then gets analyzed twice with opposite variation assumptions (worst-case for the launch side, best-case for the capture side), which introduces artificial pessimism into the reported slack -- that's Common Path Pessimism (CPP). CPPR (also called CRPR, Clock Reconvergence Pessimism Removal) is the analysis step that identifies the actual shared common path and removes that double-counted pessimism from the timing report.
- 63 What is CCD (Concurrent Clock and Data optimization), and what does it actually change in the clock tree?Expert: CCD applies useful-skew techniques during datapath optimization -- deliberately adjusting individual registers' clock arrival times to spend positive slack on paths that need it, instead of treating every register's clock latency as fixed. It's enabled by default for place_opt and clock_opt, but must be explicitly enabled for route_opt. The adjustments are stored as offsets -- set_clock_latency -offset and set_clock_balance_point -offset -- visible via write_script but NOT captured by write_sdc, which matters if you're trying to hand off timing intent downstream.
- 64 How does CTS merge clock-gating cells, and when should you disable it?Expert: By default, CTS merges ICGs (integrated clock-gating cells) only within the same clock tree level -- cts.icg.merge_cross_level is false by default, meaning merging across levels is an explicit opt-in, not automatic. Separately, place_opt.flow.merge_clock_gates controls whether ICG merging happens at all during the placement-stage flow (merge_clock_gates must run before create_placement). Disabling merging matters when two ICGs that look mergeable actually gate logic with different enable timing requirements -- merging them would force one clock structure to serve two enable conditions that shouldn't share one.
- 65 What ECO techniques are available after CTS if a hold violation shows up, and when do you use freeze-silicon ECO instead of a normal buffer insertion?Expert: For a normal post-CTS hold fix, add_buffer_on_route inserts a buffer directly on the existing route topology, or size_cell resizes an existing cell -- both are logic/metal-only changes to an already-placed, already-routed design. Freeze-silicon ECO is a different tier: it maps the fix onto pre-placed programmable spare cells (matched by psc_type_id) so the change requires only a metal-mask respin, not a full new mask set -- used specifically when the design has already taped out or is close enough that touching silicon layers is unacceptable.
- 66 Why is multimode clock synthesis genuinely harder than single-mode CTS, not just "more of the same work"?Expert: Clock distribution must be balanced for both functional and scan mode simultaneously -- and this is made harder by multilevel clock gating, clock dividing, mode-switching circuits, and a scan clock all being present in the same tree. Balancing for one mode doesn't guarantee balance for another; the tree that's optimal for functional-mode skew may not be optimal for scan-shift-mode skew, and CTS has to satisfy both from one physical structure.
- 67 What's the real difference between integrated and user-specified clock-gate latency estimation, and which one is the default?Expert: Integrated latency estimation is the default and more accurate method -- the tool estimates and updates clock-gate latency throughout the place_opt flow automatically. User-specified latency uses set_clock_latency directly, where lat_reg is the estimated network latency to ungated registers' clock pins, and lat_cgtoreg is the estimated delay from a CGC's clock pin to the gated register's clock pin -- for CGC clock pins specifically, you use lat_reg minus lat_cgtoreg, not lat_reg alone.
- 68 If both set_clock_gate_latency and set_clock_latency are applied to the same clock-gating cell, which one wins?Expert: set_clock_latency has higher precedence and is not overwritten. set_clock_gate_latency specifies clock network latency BEFORE clock gates are inserted, used at compile_fusion insertion time, as a function of clock domain, gating stage, and CGC fanout -- but if set_clock_latency has also been applied to the same object, that value governs, not the gate-latency-by-stage estimate.
- 69 What exactly counts as a "boundary path" for CCD, and what's the strongest way to protect them from useful-skew changes?Expert: Boundary paths are paths connected to boundary registers -- the transitive fanout of input ports or fanin of output ports. ccd.optimize_boundary_timing (false) excludes them from CCD entirely; ccd.optimize_boundary_timing_upstream (false) goes further and additionally prevents the tool from changing the clock-tree fanin cone of boundary registers, a heavier restriction on CCD's scope near I/O.
- 70 What's the actual difference between targeting CCD at the preroute stage versus the postroute stage?Expert: At the preroute stage (place_opt/clock_opt), ccd.targeted_ccd_path_groups plus ccd.targeted_ccd_end_points_file target specific path groups and endpoints, with ccd.enable_top_wns_optimization targeting the worst 300 paths specifically. At the postroute stage (route_opt), route_opt.flow.enable_targeted_ccd_wns_optimization is a separate flag, and ccd.targeted_ccd_select_optimization_moves controls which move types are allowed (auto includes buffering; size_only/equal_or_smaller_sizing/footprint_sizing restrict to sizing only).
- 71 How does ICD actually make CCD faster, and what's the real mechanism behind the speedup?Expert: Pre-CTS CCD is about 10% of place_opt runtime, mostly from medium/high-effort CUS (compute useful skew) calls. ICD (place_opt.flow.enable_fast_cus_in_final_opto) reduces one global CUS call to two LOCAL CUS calls focused only on critical endpoints, in the final_opto stage -- trading exhaustive global recomputation for a narrower, targeted recomputation that still catches the paths that matter most.
- 72 What specific failure mode does the nworst skew framework in multithreaded CTS fix, and why does it happen in the first place?Expert: MTCTO (multithreaded CTS) minimizes global skew -- the gap between the longest and shortest clock path. If optimization stalls on the shortest path specifically, other paths remain under-optimized, because the algorithm's attention is consumed trying to fix the one extreme rather than distributing improvement across the whole distribution. cts.optimize.enable_nworst_skew_optimization addresses this by considering more than just the single worst-case pair.
- 73 What is a clock balance group actually for, and why can't the tool balance skew between a generated clock and its master automatically?Expert: A clock balance group is a set of clocks considered together for delay balancing, created with create_clock_balance_group and optionally explicit per-clock offset_latencies. derive_clock_balance_constraints auto-identifies clocks with interclock timing paths worse than a threshold, and balance_clock_groups actually performs the balancing. The one hard limit: the tool cannot balance skew between a generated clock and other clocks -- a generated clock's relationship to its master is already fully determined by the generation relationship itself, not something interclock balancing can independently adjust.
- 74 How does the tool actually decide what counts as a "root net" for clock NDR purposes, and what's the edge case that can silently change that?Expert: Root nets are single-fanout nets from the clock root to the first branch; internal nets run from that branch point toward sinks; sink nets connect to leaf sinks. -root_ndr_fanout_limit sets the transitive fanout limit for identifying root nets -- a smaller value means MORE nets get root-net constraints, raising routing congestion risk. The edge case: if an identified root net is shorter than 10 microns, the tool uses internal-net constraints instead, regardless of the fanout-based classification.
- 75 What real problem does topological_ndr solve, and what's the actual sort order it enforces?Expert: Without the level-based rule, post-CTS NDR application at different tree levels can be discontinuous -- an internal net at one level might get a heavier NDR than the root net feeding it, which is physically backwards. With cts.compile.topological_ndr enabled, NDRs are topologically sorted: Root NDR > Internal NDR > Sink NDR, ensuring the NDR weight actually decreases as you move from source toward leaves, matching real current/EM demand.
- 76 What problem do via ladders actually solve on a clock tree, and where does insert_via_ladders fit in the clock_opt flow?Expert: Via ladders address electromigration and high-current-path concerns on critical clock nets by inserting redundant/stacked via structures. The sequence matters: define via ladder rules and constraints first, enable opt.common.enable_via_ladder_insertion for HP (high-performance) plus EM ladders on critical paths, run clock_opt -to build_clock to get the tree structure in place, THEN insert_via_ladders, THEN clock_opt -from route_clock to complete routing with the ladders already placed.
- 77 How does create_clock_straps decide whether it's building a mesh or a spine, and what does -margins actually control?Expert: The -type option per direction decides the topology: stripe in both directions builds a mesh; one direction as user_route (with the orthogonal direction as detect for spine detection) builds a spine instead. -margins sets the margin within which a strap may move -- default 0, which means an exact position or no strap at all, a real constraint if you need flexible strap placement rather than fixed coordinates.
- 78 What's the actual tradeoff between fishbone, comb, and sub_strap topologies when routing to clock straps?Expert: Fishbone (the default) connects each driver pin individually to the nearest stripe with comb routing for loads onto a single finger, controlled by -fishbone_fanout, -fishbone_span/-fishbone_sub_span, -fishbone_layers. Comb routes driver and load pins directly to the nearest stripe, falling back to Steiner topology beyond the comb distance (default 2 global routing cells) -- good for many pins directly under stripes, but creates many stacked vias, a real physical DRC risk. Sub_strap adds parallel straps on intermediate layers specifically to reduce those stacked vias versus comb.
- 79 Why does a clock mesh specifically need SPICE-level analysis instead of the normal STA delay-calculation flow, and what are the actual prerequisites?Expert: A clock mesh has multiple drivers feeding the same net, which normal STA delay calculation isn't built to resolve accurately -- analyze_subcircuit performs transistor-level circuit simulation to back-annotate accurate timing instead. Prerequisites: a detail-routed clock mesh net, a circuit-level model per gate and transistor model per transistor, and access to a SPICE simulator (NanoSim, FineSim, or HSPICE) -- this is a heavier, more accurate analysis specifically because mesh topology genuinely needs it.
- 80 What's the real tradeoff behind htree_explore_all_repeater_solutions, and why would you NOT just always enable it?Expert: htree_explore_all_repeater_solutions evaluates all repeaters per node for DRC-compliant solutions and selects the least-latency top-level solution -- genuinely better results, but runtime degrades as the library grows, since it's evaluating every candidate repeater at every node rather than a fast heuristic choice. htree_single_repeater_at_node avoids placing two repeaters at the same node (avoiding routing DRC, at the cost of possibly needing more levels) -- a different, narrower tradeoff.
- 81 What does a multisource clock sink group actually guarantee, and why would you need one beyond normal tap assignment?Expert: Normal tap assignment (set_multisource_clock_tap_options) assigns each sink to its closest tap driver independently. A multisource clock sink group (create_multisource_clock_sink_group) overrides that independence for specific skew-critical objects, keeping them under the same tap even if that's not each individual object's closest driver -- because for a genuinely skew-critical group, being on the same tap matters more than each member individually being closest to its own nearest driver.
- 82 What does the Buffer Adjust step in the early CCD-iSMSCTS flow actually do, and why is it needed specifically for SMSCTS-built clocks?Expert: In the early CCD-iSMSCTS flow, CCD runs during initial_opto on iSMSCTS-synthesized clocks, generating level-friendly useful-skew offsets. The Buffer Adjust step (buffer_adjust), introduced in final_place before placement, adds or removes repeaters to physically match those useful-skew offsets -- because on an SMSCTS structure, an abstract latency offset has to be realized as actual repeater insertion/removal, not just a number applied post-hoc the way it might be on a simpler traditional tree.
- 83 When would you actually need irregular global tree synthesis instead of a standard H-tree, and what does "irregular" specifically mean here?Expert: Irregular global tree synthesis handles non-symmetric, unevenly inserted tap drivers -- floorplan or global-tree complexities that require manual global tree insertion rather than an automated symmetric H-tree. It constructs multilevel, DRC-clean global trees without tight OCV or common-path requirements, using multilevel buffer trees in a non-H-tree style specifically for minimum latency to all tap drivers -- usable at block level or for top-level channel distribution.
- 84 How does -bias_to_nets actually provide shielding on a clock mesh, and why would you want that specifically for clock straps?Expert: -bias, -bias_to_nets, and -bias_margins on create_clock_straps bias strap position relative to PG nets or specific nets -- effectively using those nets as a shield against coupling noise on the clock strap. This matters for clock straps specifically because clock nets are high-switching-activity aggressors and victims both; positioning a strap with deliberate bias relative to a PG net gives it a stable, low-impedance neighbor rather than leaving its exact position purely up to the routing grid.
- 85 How does the ML-based global-route optimization flow actually improve preroute/postroute timing correlation for clock trees, and what has to stay constant across iterations?Expert: For designs with poor preroute/postroute timing correlation, ML collects Features (inputs) and Labels (predicted outputs, e.g. real post-route delay) from detail routing to train a Model relating them. Iteration N trains the model (est_delay.ml_delay_gre_mode = feature, then estimate_delay -train_model after detail routing); iteration N+1 uses it (est_delay.ml_delay_gre_mode = enable). The hard requirement: the same active scenarios must be used at each step and iteration, and the model must be re-created if the design, environment, or flow changes -- a stale model silently mispredicts.
- 86 What does report_clock_qor -type robustness actually measure, and why is -robustness_corner a required option, not optional?Expert: The robustness metric is the ratio of a sink's latency at the reporting corner to its latency at a required -robustness_corner -- a direct cross-corner comparison, not an absolute number. -robustness_corner is required specifically because the metric is meaningless without a reference corner to compare against; a ratio needs two points, and the tool won't guess which corner should be the baseline.
- 87 How do you build more than one global H-tree in different parts of the same floorplan, and how are the sections actually defined?Expert: set_regular_multisource_clock_tree_options -htree_sections takes a list of section definitions, each with -section_name, -prefix, and either -tap_boundary (a bounding box) plus -tap_boxes (a symmetric grid within it) or explicit -tap_locations -- letting you build genuinely separate H-trees for genuinely separate floorplan regions instead of forcing one global tree to span an entire irregular floorplan.
- 88 What extra steps does multi-level physical hierarchy (MLPH) clock driver insertion need beyond the normal create_clock_drivers flow?Expert: MLPH clock driver insertion needs set_editability -blocks {...} -value true first (to allow the insertion to touch multiple physical hierarchy blocks), then cts.multisource.enable_mlph_flow set true, then create_clock_drivers as usual, then synthesize_multisource_global_clock_trees with -roots and -leaves specified plus -use_zroute_for_pin_connections. Ports are reused if they already exist, and new ports are only created if set_freeze_ports allows it -- a real constraint on hierarchical boundaries that ordinary single-block flows don't have to think about.
- 89 What determines whether a gate can automatically be identified as part of a false path via sensitization, and why is this genuinely hard?Expert: A gate is sensitized if a transition can propagate through it from a particular input to the output while other inputs hold a NON-controlling value (logic 1 at an AND input, logic 0 at an OR input) -- a controlling value (logic 0 at AND, logic 1 at OR) would force the output regardless, blocking propagation. Sensitization criteria are static (a set of input vectors exists giving non-controlling values at all side inputs along the path) or dynamic (vectors applied at different TIMES produce non-controlling values when the propagating transition actually arrives -- considered very complex and still an active research area).
- 90 What is the Elmore delay formula actually computing, and where specifically does it become inaccurate?Expert: For an interconnect with N nodes, Elmore delay at node i is D_i = sum over k=1..N of (R_ki * C_k), where R_ki is the resistance of the path segment common to the input-to-node-i and input-to-node-k paths, and C_k is the capacitance at node k. It's popular for its algebraic simplicity and is accurate for nodes FAR from the driving point -- but can be off by orders of magnitude for nodes NEAR the driving point, because of resistive shielding: when wire resistance is comparable to or larger than the driver's output resistance, the metal resistance shields the wire's capacitance from the driver, and Elmore's simple summation doesn't capture that shielding effect.
- 91 How does the effective-capacitance (k-factor) model correct for what Elmore delay gets wrong, and why must k be computed iteratively?Expert: Given driver resistance R_d, wire resistance R_w, and loads C1/C2, wire delay is D_w = R_d*(C1+C2) + R_w*C2. If R_d >> R_w, driver delay is accurately a function of total load (C1+C2). If R_w is comparable to or exceeds R_d, driver delay decreases and part of C2 is shielded, so delay is characterized as a function of (C1 + k*C2), where k (the effective capacitance factor) ranges 0 to 1. Because k itself depends on driver resistance -- which depends on the delay being computed -- it has to be computed iteratively, independent of any specific driver model, rather than solved in one closed-form step.
- 92 How does AWE improve on Elmore delay's accuracy, and why does the method typically stop at just 2-3 poles?Expert: AWE (Asymptotic Waveform Evaluation) constructs a pole-residue transfer function H(s) = sum(i=1..q) of k_i/(s - p_i), with time-domain impulse response h(t) = sum of k_i * e^(p_i*t) -- using higher-order moments than Elmore's single first moment. AWE matches the first 2q moments of the network's transfer function to h(t)'s moments to uniquely specify the poles and residues. q=2 or 3 is typically sufficient for reasonable accuracy at reasonable computational cost -- going higher captures more of the waveform's true shape but with rapidly diminishing returns against a real computational cost increase.
- 93 What do ANDR, ERI, and EWI each actually control during post-route optimization, and how do they relate to each other?Expert: ANDR (Auto Non-Default Rules) are non-default rules the tool creates AUTOMATICALLY during preroute and global-route optimization for timing/power -- not user-specified NDRs, tool-generated ones. ERI (enable_runtime_improvements) is a runtime-focused post-route optimization enhancement. EWI (enable_wireopt_improvements) specifically enables ANDR wire optimization and layer promotion, mostly during global-route-based optimization in clock_opt -- meaning EWI and ANDR are directly linked (EWI is what turns on ANDR's wire-optimization behavior), while ERI is a separate, runtime-oriented improvement.
- 94 How does eco_netlist actually determine what changed, and why is -write_changes a required option rather than optional?Expert: eco_netlist compares the current design against a golden reference -- either a golden Verilog netlist (-by_verilog_file) or a golden block (-block, assumed in the current design library unless -golden_lib is given). -write_changes <file> is REQUIRED, not optional, and produces Tcl netlist-editing commands representing the diff. By default it ignores differences in physical-only cells, timing ECO changes, and power/ground objects -- -compare_physical_only_cells and -extract_timing_eco_changes opt into including those.
- 95 How does record_layout_editing actually enable multiple engineers to work on parallel ECO changes to the same layout?Expert: record_layout_editing -start begins recording, and every layout-editing operation performed afterward (create/remove of layout objects via Tcl, set_attribute, and GUI move/resize) gets captured. record_layout_editing -stop -output <file> writes those recorded operations as a Tcl script. Multiple engineers can each record their own independent session this way, producing separate Tcl files that can ALL be applied to the original, unmodified layout -- rather than each engineer's changes needing to be applied sequentially to an already-modified copy.
- 96 What's the actual difference between the three -legalize_mode options on place_eco_cells, and when does each one risk large cell displacement?Expert: free_site_only (the default) legalizes ECO cells only on free sites without moving pre-existing cells -- can cause large displacement if no free site is nearby, since the cell may have to travel far to find one. allow_move_other_cells legalizes to the nearest legal location by moving pre-existing cells instead -- no free-site search, but disturbs the existing layout. minimum_physical_impact tries free sites first, and only moves pre-existing cells for cells that still have no nearby free site -- a hybrid that minimizes disturbance while still bounding displacement.
- 97 What does -check_prerequisites on place_group_repeaters actually validate before attempting placement, and what do a couple of its real error codes tell you?Expert: -check_prerequisites validates a real checklist before placement is attempted: site rows present, each net has one driver and can have multiple loads, pin/port locations assigned, standard cells carrying the pins are placed, supernets routed, route ends within 5 microns of driver/load pins in the search region, and more. Real error examples: ECO-329 ("the net net_wo_load does not have loads") and ECO-331 ("the cell driver1 of the pin driver1/X is not placed") -- both point to a genuinely missing prerequisite, not a placement algorithm failure.
- 98 How many different ways can you actually specify WHERE group repeaters land on a route, and how do they differ?Expert: place_group_repeaters offers several mutually exclusive location-specification methods: -repeater_distance (distance between groups, with -first_distance and -min_distance_repeater_to_load defaulting to half the repeater distance), -relative_distance (driver-to-first, first-to-second, etc.), -location (exact center of each group), -number_of_repeater_groups (total count inserted evenly along the route), and -cutlines (location pairs defining cutlines perpendicular to the route, with groups centered around them). Each represents a genuinely different way of thinking about placement -- distance-based, count-based, or geometry-based.
- 99 What's the actual difference between track_pattern mode and siteId_based mode for variant cell swapping, and what does 2-Variants vs N-Variants mean within siteId_based mode?Expert: Variant cells differ only in mask color (or small geometry) from a master variant, with identical timing data. In track_pattern mode, the variant type id is derived from the library cell's first track offset plus pitch value, starting from 0 (e.g. type 0 = master/mask_one at 1/2 site width, type 1 = mask_two at 1/6 site width). In siteId_based mode, mapping info is defined explicitly in the cell group -- with two sub-flows: 2-Variants (traditional, max 2 master/variant per group, only a mapping id is set, flipped id derived from mapping id plus cell width) and N-Variants (both mapping id and flipped mapping id are set explicitly, supporting more than 2 variants per group).
- 100 What genuinely distinguishes quadrature, bisection, and slice-and-bisection as min-cut partitioning methods, and why do most tools default to quadrature?Expert: Quadrature alternately partitions the core into equal instance counts vertically and horizontally, minimizing cut sizes in each direction, starting from the center -- producing an equilibrium between horizontal and vertical routing with no congestion area, which is exactly why most P&R tools default to it. Bisection repeatedly bisects with cut lines until bins hold one or two rows, without necessarily minimizing cut sizes between partitions. Slice-and-bisection divides cells so a smaller partition N/k is assigned to a row by horizontal slicing, then uses recursive vertical bisecting.
- 101 What is the quadratic placement objective function actually minimizing, and what's its well-known real limitation?Expert: Quadratic placement minimizes total squared wire length: Phi(x,y) = 1/2 * sum(c_ij) * [(xi-xj)^2 + (yi-yj)^2]. With a symmetric connectivity matrix C and modified matrix B=D-C (D diagonal, d_ii = sum of c_ij), this reduces to Phi(x,y) = x^T*B*x + y^T*B*y -- because x and y are symmetric and independent, only a 1-D problem needs solving in each dimension. The main problem: it creates very high cost for long wires and very low cost for short wires, so a highly-connected cluster can spread out over the core, increasing congestion and reducing routing-resource flexibility.
- 102 How does the simulated annealing acceptance rule actually work during detail placement, and why does the initial temperature matter?Expert: Simulated annealing's acceptance rule: P=1 if the cost change (delta C) is <= 0 (always accept an improvement); P = exp(-delta C / T) if delta C > 0 (probabilistically accept a WORSE move, with probability shrinking as temperature T falls). The algorithm starts at a very high temperature and cools per an annealing schedule, so cost-increasing moves become progressively less likely as T falls -- eventually only cost-reducing moves are accepted. A higher initial temperature means more trials and longer runtime, since more of the early search space gets explored via probabilistically-accepted worse moves.
- 103 Why did the industry shift from load-based to gain-based (logical effort) timing optimization for deep submicron designs specifically?Expert: Load-based optimization approximates interconnect capacitance with a wire capacitance model, choosing cell drive strength from the estimated load -- fine when intrinsic delay dominated and wire resistance was low. As designs grew, synthesis using an estimated wire-load model could cause a NON-TERMINATING iterative process of resizing during timing closure, because the wire-load model no longer predicted actual wire lengths until physical design was complete. Gain-based optimization (logical effort) became preferred specifically because of load-independent cell delay -- it doesn't have this circular estimate-then-re-estimate problem.
- 104 What does the logical effort delay formula actually decompose gate delay into, and what does g=1 for an inverter specifically mean?Expert: Total CMOS gate delay: d = p + f (p = parasitic/intrinsic delay, f = effort/extrinsic delay), in units of tau (process-characterized delay through the smallest inverter). f = g*h (g = logical effort, h = electrical effort/gain = Cl/Ci). Logical effort g = T_gate / T_inverter -- the cell's ability to produce output current based on topology, independent of transistor size. A typical inverter (2 PMOS + 1 NMOS transistor units, equal rise/fall) has T=3, giving g=1 -- inverters are the BASELINE; more complex gates are slower (g>1) purely from their topology, before size is even considered.
- 105 Beyond the basic congestion-driven effort setting, what other specific ICC2 app-options target congestion reduction, and what does each one specifically address?Expert: Several targeted options exist beyond the general effort knob: congestion_layer_aware (per-layer congestion instead of combined layers), increased_cell_expansion (expand virtual cell area per local routing need), congestion_expansion_direction=both (default is horizontal only), ndr_area_aware (accounts for clock NDR area specifically), seq_array_icg_aware (reduces congestion from sequential-array clock nets), spread_repeater_paths (spreads repeaters orthogonally, avoiding clumping at macro/blockage edges), and wide_cell_use_model (wide-cell density modeling for advanced nodes).
- 106 What three settings together actually determine whether pin-cost-aware, pin-density-aware, both, or neither placement behavior is active?Expert: set_technology -node {7|7+|5|s5|s4} sets the tech-specific pin-cost model -- a prerequisite. place.coarse.pin_cost_aware (default false) and place.coarse.pin_density_aware (default false, applicable to all tech nodes) are two independent toggles. The COMBINATION of all three -- which node was set, and which of the two booleans are true -- determines the actual resulting behavior: pin-cost-aware placement, pin-density-aware placement, both, or neither.
- 107 How does variant-aware legalization actually fix a DRC violation differently from ordinary legalization, and what happens when no matching variant exists?Expert: place.legalize.enable_variant_aware, when true, makes the legalizer fix legalization DRC violations by SWAPPING a cell with an equivalent variant (same function, different mask color or minor geometry, identical timing) rather than moving it. If no variant exists for that cell, the legalizer falls back to the normal behavior: moving the cell. This is a genuinely different repair strategy -- fix-in-place via substitution, versus fix-by-relocation -- and it only works where equivalent variants actually exist in the library.
- 108 What's the actual sequence for enabling IR-drop-aware placement, and how does the tool decide which cells get the most spreading treatment?Expert: The flow: place and legalize the block first (or place_opt -to final_place), then source a RedHawk setup script, run analyze_rail -voltage_drop static -nets {VDD VSS}, then enable place.coarse.ir_drop_aware, then optionally set additional IR-drop settings and re-run placement (or place_opt -from final_place). It requires Digital-AF and SNPS_INDESIGN_RH_RAIL license keys. The tool creates three cell categories by total cell count: Upper (top 1%, most spread), Middle (next 5%, less spread), Lower (the rest, not spread) -- percentages changeable via dedicated app-options.
- 109 What's the actual mechanism behind place.coarse.auto_density_control's 'enhanced' default, and when would you override it manually?Expert: place.coarse.max_density controls max density during non-congestion-driven placement; place.coarse.congestion_driven_max_util (default 0.93) controls max utilization in less-congested areas surrounding highly congested ones. place.coarse.auto_density_control defaults to -enhanced, following a preset schedule unless disabled -- and the enhanced default improves total power and wire length. Critically, you NEVER need to disable auto_density_control to override it -- explicit user settings for max_density/congestion_driven_max_util always take precedence, and settings apply INDEPENDENTLY to each placeable area (voltage area, exclusive move bound), not averaged over the whole block.
- 110 What does the short-circuit (transition) power formula capture that dynamic power doesn't, and what specifically controls it during placement?Expert: Transition (short-circuit) power occurs when the input transition is slow enough that NMOS and PMOS conduct simultaneously, creating a direct supply-to-ground path that contributes nothing to gate operation: Pt = I^2 * (Rp + Rn). This is a genuinely different mechanism from dynamic (switching) power -- it's wasted current from both transistors briefly conducting together, not useful charge/discharge of a load capacitance. Reduce it by controlling max input transitions during placement, or specifying max allowable transition per cell in the library.
- 111 What does magnet_placement actually require of the cells you name with -cells, and why do two seemingly reasonable -cells lists pull nothing at all?Expert: magnet_placement declares a fixed object (a fixed macro cell, a pin of a fixed macro cell, or an I/O port) a magnet so connected standard cells get placed close to it -- best performed BEFORE standard cell placement, to improve congestion in a complex floorplan or improve timing. The key rule: cells are pulled ONLY if they form a CONTIGUOUS data path from the magnet. magnet_placement C0 -cells {C3 C4 C5} pulls NOTHING if C3/C4/C5 aren't contiguous with C0; magnet_placement C0 -cells {C3 C6 C8} also pulls nothing if that specific set isn't a contiguous data path, even though C3, C6, and C8 might each individually be reachable from C0 through some path.
- 112 After routing you have 300 setup violations, 50 DRCs and SI noise failures. What order do you attack them in, and why?Expert: Connectivity first, then DRCs, then timing with signal integrity included, then hold, and re-check DRC and antenna after every round of fixes. Opens and shorts make every other number meaningless. DRC fixes move wires and change parasitics, so timing fixed before DRCs is timing you will fix again.
- 113 Late in the flow, how do you stop the router from disturbing already-clean nets?Expert: Late in the flow, you decide which nets the router is allowed to move. In ICC2 the `physical_status` attribute on a net sets its rerouting mode: `locked` freezes it, `minor_change` allows only small changes, and `unrestricted` is the default. Combine that with ECO routing limited to modified nets, and clean routing stays as it was.
- 114 When do you use the Custom Router instead of Zroute?Expert: Use the Custom Router for nets that need geometry Zroute is not built to produce: shielded buses, differential pairs, matched-length groups, and variable-width or variable-spacing routes. Typical cases are DDR interfaces, analog-sensitive nets and critical clocks between blocks. It pre-routes those nets with `route_custom`, and ICC2 then finishes the rest of the design normally.
- 115 How does the hybrid Custom Router and Zroute flow split the work, and why?Expert: In the hybrid flow the Custom Router routes the trunks of special nets and deliberately leaves some or all pin connections unfinished, and Zroute completes them. The two routers connect to pins differently, so letting Zroute make the pin connections avoids inconsistencies and DRCs. The split is set with `custom.route.skip_connect_pin_type`.
- 116 What does chasing near-100% redundant vias cost, and how do you protect timing?Expert: Near-100% insertion treats redundant vias as hard design rules during routing, which costs runtime, sometimes a lot, and makes DRC convergence harder. It only works during initial routing, not ECO routing, and Zroute relaxes it automatically if DRCs will not converge. Timing is protected with the timing-preserve options on `add_redundant_vias`, but only at the very end, because using them early crushes the via rate.
- 117 What changes in routing at double-patterning nodes?Expert: At double-patterning nodes one metal layer is printed with two masks, so every shape and via gets a mask colour and same-mask shapes need more spacing than different-mask ones. Routing has to assign colours legally, usually automatically during detail routing. Cut metal shapes are used to separate line ends, and writing DEF or GDS needs specific options so masks and cuts carry through.
- 118 How do spread_wires and widen_wires improve yield, and what do they trade?Expert: A critical area is where a random particle defect would break the circuit: a conductive particle between two wires causes a short, and a missing piece of metal in a narrow wire causes an open. `spread_wires` moves wires apart to reduce short risk, and `widen_wires` makes wires wider to reduce open risk. They compete for the same space, so you balance them and protect timing on critical nets.
- 119 After routing, ICC2 and PrimeTime with StarRC disagree on slack. Where do you look?Expert: Compare the same path in both tools and find the first stage where they differ, then check the settings that feed it: extraction engine and corner, signal integrity settings, derates and variation, pessimism removal, clock propagation, scenario setup and missing annotations. The goal is to make the two agree, then fix in whichever tool matches signoff. A difference is almost always a setup difference, not a bug.
- 120 What routing checks are specific to a power-gated domain?Expert: In a power-gated domain you have to prove that everything that must stay alive still has power when the domain is off. That means always-on buffers and their secondary power pins routed to the always-on supply, the isolation enable and switch control nets routed correctly, and no signal from the switched domain reaching always-on logic without isolation. Standard DRC checks do not see any of this, so multivoltage checks are required.
- 121 A late functional ECO lands on a fully routed, timing-clean block. How do you implement it with minimum disturbance?Expert: Change as little geometry as possible and then re-check everything. Place new cells on spare cells or free sites near their connections, protect the clean nets you cannot afford to move, and ECO route only the modified nets. Then re-extract and rerun the full set of checks: DRC, LVS, antenna, and timing in every scenario.
- 122 First routed run shows 5,000 setup violations. What's your plan?Expert: Do not start fixing. Five thousand violations on a first routed run is a diagnosis problem: first prove the constraints and the analysis setup are right, then group the violations until they collapse into a handful of causes. Only after that do you decide whether each cluster is ECO work in PrimeTime or a reason to go back to placement or floorplan.
- 123 The ECO loop won't converge: setup fixes reopen hold, which reopens DRC. How do you break the cycle?Expert: The loop exists because each fixing step is allowed to hurt something else. PrimeTime defines precedence rules for exactly this reason: DRC fixing can degrade setup and hold, setup fixing honors DRC but may degrade hold, and hold fixing honors both setup and DRC. Run the steps in that order, give each step margins, and find the paths where no legal answer exists instead of looping over them.
- 124 When do you chase WNS, and when TNS?Expert: Chase TNS when there are many shallow violations and the aim is to reduce the amount of fixing work left. Chase WNS when a few deep paths set the frequency or block signoff. Early in closure TNS tells you how much work remains; at signoff every violating endpoint must be fixed, so the order is only a question of which method moves the design fastest.
- 125 You have 40 scenarios and 8 hosts. How do you run ECO efficiently?Expert: Set `eco_enable_more_scenarios_than_hosts` (PT) to true so DMSA ECO can run with fewer hosts than scenarios. The hosts then swap scenarios in and out, which is slow, so the script has to minimise swaps: fewer merged reports, one batched `remote_execute` (PT) block, and change lists written from one scenario. Also check whether 40 scenarios are all needed.
- 126 What does HyperTrace/graph-based refinement change in ECO fixing, and when does it not pay off?Expert: HyperTrace accelerates path-based analysis, and PrimeTime can use it to speed up ECO fixing when `fix_eco_timing` (PT) runs with a PBA mode. It changes runtime, not the fixing goal: the same PBA slack is targeted, reached faster. It needs a PrimeECO license, and it pays off little when fixing is graph-based or when the PBA work is small to begin with.
- 127 Take a metal-only ECO from PrimeTime to a mapped layout.Expert: In a freeze silicon ECO only metal and via layers may change, so every new cell must land on a spare cell that is already on the silicon. PrimeTime generates fixes restricted to spare cells with `-physical_mode freeze_silicon`, and ICC2 implements them in freeze silicon mode, checks feasibility, maps each ECO cell to a spare cell and reroutes only what changed. Then you extract and sign off again.
- 128 A freeze-silicon ECO needs a cell type with no matching spare. What now?Expert: By default ICC2 maps an ECO cell only to a spare with the same library cell name, so a type with no matching spare stays unmapped. Find those cells with `check_freeze_silicon` (ICC2), then let `create_freeze_silicon_leq_change_list` (ICC2) write a script that replaces each one with a logically equivalent spare or a combination of up to two spares. Review the script, source it, and map again.
- 129 What are the risks of fixing setup through clock-tree ECO changes?Expert: A clock change moves an edge for every register below it, so one fix can shift slack on many paths at once. Delaying a capture clock helps setup into that register but hurts hold into it and setup out of it, and the same change lands in every scenario and can alter CRPR. PrimeTime can do clock network fixing, but it should come after data-path fixing and with limits on how far up the tree it reaches.
- 130 Hold fails in 3 of 12 corners while setup is tight in 2 others. How do you fix without ping-pong?Expert: Fix hold once, in a DMSA session that contains all 12 scenarios, so every change is judged against setup in the tight corners and hold in the failing ones at the same time. Ping-pong comes from fixing the hold corners in one run and checking setup in another. Where no data-path change satisfies both, the endpoint is a real conflict and needs a clock or constraint answer.
- 131 An ECO created new crosstalk violations on untouched nets. Why, and how do you fix it?Expert: Crosstalk depends on the neighbours and on timing windows, and an ECO can change both without touching the victim. ECO routes fill gaps next to existing nets, upsized drivers switch faster, and shifted arrival times make aggressor and victim windows overlap. Find the victims with `report_si_bottleneck` (PT), fix delta delay with `fix_eco_drc -type delta_delay` (PT), and implement with `route_eco` (ICC2).
- 132 Signoff IR drop is shifting timing. How does voltage-aware timing change closure?Expert: Standard corner timing assumes every cell sees the full rail voltage. With IR drop, cells in hot spots see less, switch slower, and paths through them lose slack that no corner shows. Voltage-aware timing brings the drop into STA so those paths are fixed where they are, and in ICC2 the power integrity flow reduces the drop during placement and CTS so fewer paths need fixing later.
- 133 Can you waive a GBA violation, and what evidence is required?Expert: Yes, a GBA violation can be waived when exhaustive path-based analysis proves the endpoint passes, because GBA is deliberately pessimistic. The evidence must be regular exhaustive PBA to that endpoint, in every scenario where it failed, with no path limit cutting the search. Path-mode PBA, a single recalculated path, or ML-PBA do not qualify.
- 134 When do you stop ECOing and go back to placement or floorplan?Expert: Stop when the fixes you need are not the kind ECO can make, or when each iteration stops paying for itself. PrimeTime ECO sizes, swaps and buffers existing logic in the space that exists. When the problem is logic depth, wire length set by placement, congestion, or no room left for changes, you go back to placement or floorplan. The decision is cheaper the earlier it is made, so track the evidence from the first ECO round.
- 135 A block-level ECO in a hierarchical design: what changes at the top, and what must be regenerated?Expert: A block ECO changes the block interface timing the top sees, so every abstraction of that block used at the top is now out of date. Regenerate the block model, whether an extracted timing model from `extract_model` (PT) or a HyperScale block model, and rerun top-level timing. If the top changes as a result, regenerate the block context with `characterize_context` (PT) and `write_context` (PT) so the block is fixed against the real environment.
- 136 A merged-mode scenario hid a violation that appears only after unmerging. How do you catch it?Expert: Mode merging creates a superset mode so fewer scenarios need analysis, but the merged constraints are only as good as the merge. If a clock, case value or exception from one mode masks a path that another mode checks, the merged scenario never tests it. Catch it by reviewing the merge report, comparing analysis coverage against the original modes, and running the individual modes at defined checkpoints.
- 137 How does latch time borrowing affect closure, and why cap it?Expert: When data reaches a transparent latch after its opening edge, the path borrows time and the next stage starts later by the same amount. Closure looks easy on the first stage and the deficit shows up downstream, possibly several stages later. Capping borrowing with `set_max_time_borrow` (SDC) keeps each stage honest and leaves margin in the pulse width, which you want in signoff.
- 138 How do you use normalized slack to decide the achievable clock period?Expert: Normalized slack divides a path's slack by the propagation delay it is allowed, so paths with different cycle counts can be compared on their effect on frequency. With the same launch and capture clock, the worst normalized slack gives the period change directly: ΞPeriod = β(worst normalized slack) Γ period. Enable it with `set_app_var timing_enable_normalized_slack true` (PT) before the timing update.
- 139 What happens when you manually edit an instance of a multiply-instantiated block in PrimeTime?Expert: PrimeTime uniquifies the edited instance automatically. If you `size_cell` (PT) a cell inside one of several instances of the same block, that instance, and every block above it up to the first singly instanced block, becomes a new unique design. The timing is right for what you did, but the physical side now has two different versions of a block that was built once, so decide first whether the change belongs to every instance.
- 140 What is the final gate before an ECO'd block tapes out?Expert: After the last ECO, nothing incremental counts. The gate is a full extraction of the final layout, a full PrimeTime run in every scenario with SI and exhaustive PBA, a coverage and constraint check, equivalence checking of the final netlist, and clean physical checks. Every one must pass on the same final database, or the block does not go.
- 141 How do you ECO-buffer a long routed bus without the buffers clumping?Expert: Buffering each bit of a bus at the same interval puts all the buffers in one column, where they fight for sites and pin access and push cells aside. ICC2 has bus buffer patterns for this: define a stagger with `create_eco_bus_buffer_pattern` (ICC2), then place the buffers with `add_buffer_on_route -user_specified_bus_buffers` (ICC2), giving the pattern, the library cell and the first buffer location.
- 142 LVS fails with thousands of errors. Where do you start?Expert: Start with shorts, and among shorts start with power to ground. One VDD-to-VSS short merges both supplies into a single extracted net, so every cell in the block stops matching and one defect shows up as thousands of errors. Clear supply shorts, then signal shorts, then opens, then device and label problems, rerunning after each class, because the count usually collapses long before you reach the bottom of the list.
- 143 20,000 signoff DRCs appear late in the schedule. How do you triage?Expert: Don't start fixing. A flood that large almost always comes from a few root causes, so first group the violations by rule and by region, then ask what changed. Fill, a macro abstract that differs from its GDS, and a rule deck or layer map that does not match the design are the usual suspects. Only after the cause is known do you decide what `signoff_fix_drc` (ICC2) can repair and what must be fixed upstream.
- 144 DRC- and LVS-clean chips can still fail in silicon. What does signoff miss?Expert: DRC checks shapes against geometric rules and LVS checks connectivity against the netlist. Neither checks how the chip behaves electrically over time or under real activity. Dynamic IR under real vectors, EM lifetime, ESD discharge paths, litho hotspots that pass rule checks, density gradients and thermal hotspots all sit outside those two runs, so each needs its own analysis and its own owner.
- 145 Signoff DRC passes in ICC2 but fails in standalone IC Validator on the merged GDS. Why?Expert: The two runs are not checking the same data. By default `signoff_check_drc` (ICC2) reads the design view for the top block and standard cells but only the pin information from the frame view of macros and pads, while standalone IC Validator reads every polygon in the merged GDS. Any macro geometry that the frame view abstracts away, such as internal metal near the edge, is invisible to the ICC2 run.
- 146 Fill insertion broke timing after signoff. What do you do?Expert: First prove it with extraction that includes the real fill, then repair only around the nets that lost slack. Remove fill around critical nets with `signoff_create_metal_fill -mode remove` (ICC2) using `-nets` or a setup slack threshold, reinsert with timing-driven spacing, and recheck density and timing. Never rip out fill block-wide to recover a few picoseconds.
- 147 How does isolated-via fixing choose a fix, and when can't it fix everything?Expert: `signoff_fix_isolated_via` (ICC2) looks for a neighbour within the range you set per via layer, and if none exists it adds a fixing via using dummy fill as the landing. It tries three methods in a fixed order: a via between an existing non-wide net shape and fill, then a line-end extension plus via, then a via between a wide metal shape and fill. On very congested or very sparse blocks it may not fix them all, and by default it also skips clock and PG nets.
- 148 A post-route IR hotspot: fix the grid, move cells, or add decap?Expert: Diagnose before choosing. If the hotspot shows in static analysis and the resistance from the cells to the taps is high, the grid is the cause and needs more metal or vias. If the grid is fine but many high-current cells sit together, spread or downsize them. If static is clean and only dynamic analysis shows the droop, decap is the right fix, because decap does nothing for an average-current drop.
- 149 How much decap do you add for dynamic IR, and where?Expert: Size decap from the charge the hot region pulls in one switching event and the droop you can accept, then place it next to the cells that switch, not evenly across the die. Every decap leaks, so the target is the least capacitance that brings the worst window inside budget. Let RedHawk identify the hot instances, add decap there, and remove decap that analysis shows is doing nothing.
- 150 An EM violation on a power strap: what are the fix options, and what does each cost?Expert: EM fails when current density in a wire or via exceeds the limit, so you either spread the current over more metal or send less current through that segment. Widening the strap, adding a parallel strap, enlarging the via array, and moving current sources or taps all work, but each costs tracks, capacitance, or placement change. Pick by whether the violation is in the wire or in the vias, and by what the surrounding routing can give up.
- 151 How do you choose the activity scenario for dynamic IR signoff?Expert: Use vectorless analysis to find weak areas across the whole design, then sign off with VCD windows chosen for the highest power and the fastest change in current, not whatever the testbench happened to dump. The danger is optimistic vectors: a reset sequence or a light test gives a clean result that real traffic never matches. Document which windows were run and why each is the worst for its mode.
- 152 What can RedHawk Fusion in ICC2 not do that standalone RedHawk signoff can?Expert: RedHawk Fusion is built for fast in-design rail analysis, not for every signoff feature. The ICC2 guide states it does not support hierarchical analysis or dynamic analysis with lumped or SPICE packages, analyses only the current scenario of an MCMM design by default, and does not support signal EM or inrush current analysis. Some signoff features can be enabled in ICC2 with RedHawk signoff licenses; anything outside that list needs standalone RedHawk.
- 153 How do you run rail analysis across multiple scenarios?Expert: RedHawk Fusion analyses only the current design scenario by default, so multiple scenarios need rail scenarios. Enable them with app options, mark the design scenarios for IR drop, create each rail scenario with `create_rail_scenario` (ICC2) before configuring it with `set_rail_scenario` (ICC2), then run them together with `analyze_rail -rail_scenarios` (ICC2). Pick scenarios by current, not by timing corner names.
- 154 Why can the package make or break IR signoff?Expert: The die grid is only part of the supply path. Package and bump resistance add DC drop that static analysis must include, and package inductance adds L di/dt droop during current steps that only dynamic analysis with a package model shows. A run with ideal taps assumes a perfect supply at the bumps and can look clean while the real chip droops.
- 155 What IR problems are specific to power-gated domains?Expert: A gated domain has two IR problems ungated logic does not. When on, current flows through the switch cells, so their on-resistance adds drop between the always-on supply and the virtual supply. At wake-up, the whole domain capacitance charges at once and the rush current can pull down the always-on rail that neighbouring logic depends on. Switch sizing trades the first against the second, and daisy chaining spreads the turn-on over time.
- 156 How does an ESD check verify discharge paths?Expert: ESD signoff checks that the metal between each pad or bump and its clamp is low-resistance enough to carry a discharge without damaging the gates it protects. RedHawk's PathFinder builds a clamp database, then `perform esdcheck` (RH) measures bump-to-bump loop resistance, bump-to-clamp and clamp-to-clamp resistance and other rule types against limits in a rules file. DRC and LVS can confirm a clamp exists and is connected, but not that its path is strong enough.
- 157 What double-patterning problems show up only at signoff?Expert: ICC2 prevents odd cycles in what it can see: its own routes, pins and cell abstracts. Signoff checks the full layout, including macro internals, cell metal that the abstract simplifies, and fill added late, so odd cycles that span those shapes appear only there. Wrong mask mapping between ICC2 and the runset shows up the same way. Fix other rules first, then run DP fixing as its own pass.
- 158 Signoff DRC takes 30 hours. How do you cut runtime without cutting coverage?Expert: Add compute before you remove checks. IC Validator scales across CPUs and hosts with `-host_init` (ICV), `-host_add` (ICV) and `-host_elastic` (ICV), keeps hierarchical processing on so repeated cells are checked once, and caches the compiled runset between runs. Then find the few checks that dominate runtime and fix their cause. Incremental and rule-subset runs help during iteration, but the final signoff run is full.
- 159 Why must EM limits account for temperature?Expert: Electromigration speeds up sharply with temperature, so the current a wire can carry for its lifetime drops as it gets hotter. An EM check run at a nominal temperature passes wires that fail in the hot parts of the die. Run thermal analysis first, then set the EM temperature to the hot-region value, or check hot regions separately.
- 160 What is the final physical signoff gate, and who signs each item?Expert: The physical gate proves that the exact GDS going to the fab is manufacturable and electrically sound. Full-chip DRC and LVS on the final merged GDS with the released runset, ESD and ERC checks, IR and EM signoff, and a reviewed waiver list must all be closed, each with a named owner. Timing is signed separately through the timing gate, which `eco-final-signoff-gate` covers.
- 161 After a metal-only ECO, what must be re-verified?Expert: Incremental checks are fine for DRC and fill while you iterate, but connectivity is global, so LVS always runs in full. After the ECO, run incremental signoff DRC on the changed areas, remove and repair fill that now conflicts, rerun full LVS, and rerun IR and EM where current or metal changed. Before tapeout, run full-chip DRC on the final GDS, since incremental runs only look where things changed.
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.