Physical design needs six real inputs, not just a blueprint: the netlist (what to build), timing library models (how fast and how much power each cell uses), physical library views (each cell's real dimensions and pins), technology data (the manufacturing grid, layers, vias, rules), RC tech models (how the wiring itself behaves electrically), and SDC (the speed target and legal timing exceptions) — like handing a contractor a full kit, not just a blueprint. The netlist is only cell instances and connections — nothing about timing or size unless the matching logical library models are loaded too.
A gate-level netlist describes your circuit purely as connectivity — instances of library cells or modules, wired together by nets — it captures *what connects to what*, not where anything physically sits or what shape the wires will eventually be. Think in terms of a simple electrical vocabulary: a cell is a component, a pin is its terminal, a net is a wire connecting terminals, and an instance is one particular usage of a cell (the same inverter cell might be instantiated hundreds of times under hundreds of different instance names).
RTL is intent — "add these two registers" — while the netlist is the actual implementation synthesis chose: specific gates, specific drive strengths, specific structures. RTL alone can't tell you which adder topology or cell variants got used; only the mapped netlist exposes the real instances and connectivity that physical design can place and route.
A Liberty (`.lib`) library is essentially a cell's complete behavioral datasheet — how it behaves electrically and logically under specific characterized conditions — used for timing, power analysis, and picking legal cells during synthesis/optimization. It is not a placement or layout drawing. Core content includes: cell and pin names, pin directions, Boolean function, input pin capacitance, timing arcs, output transition behavior, and electrical limits (max cap, max transition).
LEF is the rulebook and parts catalog — it describes reusable technology data (layers, vias, sites) and cell-level physical abstractions (a cell or macro's boundary, pin geometry, routing obstructions), independent of any specific chip. DEF is the actual layout of one particular design — where instances actually sit, how they're oriented, the die area, rows, tracks, blockages, and (depending on stage/export settings) routing.
NDM is ICC2's library/database framework — the container system, not a specific library itself. Reference libraries are the toolbox: standard cells, macros, anything reusable that your design draws from.
The technology file is the process "dictionary" — units, layers, vias, placement sites, and routing rules — that gives every coordinate and dimension a consistent, legal meaning. Without it, a netlist can be logically perfect while being physically impossible to build: the router doesn't know what layers exist or how to legally hop between them, and the placer doesn't know a grid compatible with the cells.
SDC is the design's stated timing contract: which clocks exist, which paths matter, and under what electrical assumptions they get checked. A solid handoff SDC defines primary and generated clocks with real periods and waveforms, input/output delay budgets, sensible transition or driving-cell/load assumptions at the boundary, and any timing exceptions — with justification, not just wildcards.
Input and output delays exist because your block doesn't operate in isolation — timing "outside the box" (the external device driving into your input, or the external device receiving from your output) has to be modeled relative to your reference clock, or the block-level timing analysis is meaningless. An input delay says "here's when data launched externally can reach my input pin" — think of it as pre-paid budget already spent before the signal even crosses your boundary, leaving less time for your internal logic to work with.
Before PD can start, you need a complete "clock passport" for the design: every real clock source (PLL outputs, crystal-derived clocks, external clock pins), every generated clock (dividers, multipliers) and its exact relationship to its master clock, and the waveform/uncertainty assumptions that apply in each operating mode. A **generated clock** isn't automatically asynchronous to its parent just because it's divided — the master/source/edge relationship has to be explicitly declared (`create_generated_clock -source -divide_by`, etc.) so STA compares the right launch and capture edges; get this wrong and you'll either miss real timing paths or create phantom violations on paths that are actually safe.
Cell timing models tell you how a gate behaves, but they say nothing about the wires connecting gates — and wire geometry adds both delay and load, so you need a separate model for that. A wire's electrical behavior depends on its shape and its neighbors: a long, thin wire behaves very differently from a short, wide one, and a nearby parallel conductor changes its effective capacitance.
Think of an RC technology file (like TLUPlus) as a recipe for calculating parasitics, reusable across any design on that process — SPEF is the finished dish: the actual extracted parasitic values for one specific design's nets. The extractor combines the technology recipe with your design's real layout geometry to produce that design-specific result, complete with net names, connections, and R/C values in whatever naming and unit convention the receiving timing flow needs to interpret correctly.
A mode describes *how* the design is operating (functional, scan-shift, test); a corner describes the *analysis conditions* (process/voltage/temperature plus the RC model); a scenario is simply one mode paired with one corner. Process, voltage, and temperature all shift cell delay, but interconnect matters too — a corner setup needs matching cell models, matching parasitic assignments, and whatever OCV/derating methodology the signoff plan requires.
Think of the initial floorplan DEF/script as the physical envelope and ground rules that everything downstream (placement, routing) has to operate inside — it's the "site plan" before any construction begins. Typical contents: die and core geometry, legal standard-cell rows and sites, the routing track grid, macro positions and orientations, port/pin locations, and any relevant placement or routing blockages.
A macro handoff isn't one file — it's a package: physical abstraction (size, pin shapes, obstructions) for placement/routing, timing views for interface behavior across every required operating condition, and a functional model for simulation or equivalence checks. A netlist black box with no supporting views is not a complete handoff — it's a placeholder that will silently break downstream analysis the moment someone assumes it's real data.
UPF captures power *intent*, not connectivity — which logic belongs to which power domain, how supplies and power states are modeled, and what protection strategies (isolation, retention) are required. When a power-gated block shuts off, its outputs can float to invalid values, so neighboring always-on logic needs isolation cells; a crossing between two different voltage domains needs a level shifter; registers that must remember their state through a shutdown need retention.
Scan chains exist to make internal registers reachable during manufacturing test — data shifts serially through them during scan-shift and exercises the circuit during capture. A scan-inserted netlist only tells you *that* registers are connected in a chain; SCANDEF is what actually supplies the chain's physical structure and the reordering constraints the physical-optimization flow is allowed to use.
Switching-activity files are conditional, not mandatory — you can import and place a design without them, but you lose accuracy on anything activity-dependent, mainly dynamic power estimation and optimization. Dynamic power depends on how often a node switches, its capacitance, supply voltage, and frequency; VCD records every value change over time while SAIF summarizes activity over an interval — either way, the tool still has to successfully map that recorded activity onto the implemented netlist.
Checking each input file in isolation isn't enough — the real bugs live in the *relationships* between files, where each one is individually valid but they collectively describe different designs. Start with identity: does the top module, hierarchy, netlist revision, macro configuration, library release, and process/metal stack all point to the same intended design? A valid SDC for last week's netlist revision can be silently wrong for today's.
"Unresolved reference" just means one thing: an instantiated design or cell name couldn't be bound to any actual definition — your job is to find out why, not to make the error message disappear. Start by pinning down the exact instance and the exact referenced name from the diagnostic, then classify it: is it supposed to be a standard cell, a hard macro, a hierarchical sub-block, or a deliberate black box?
A clean slack summary can lie to you — paths that were never checked (missing clocks, missing I/O delays) or paths that got exception'd out of analysis entirely both disappear from the report without ever actually passing. Walk representative input-to-register, register-to-register, and register-to-output paths by hand, and confirm generated clocks actually reach their intended registers and that case analysis matches whatever mode is active.
The core rule isn't a rigid fixed sequence — it's dependency order: nothing that annotates or constrains an object can be applied before that object exists and is identifiable. Start with library and technology context — create/open the design library with the correct reference libraries and technology file, since everything else depends on this foundation being right.
A file's role isn't fixed by its extension — it depends entirely on what stage you're at. A routed DEF or an extracted SPEF can be the *output* of one run and turn right around as the *input* to the next restart or analysis step. For a fresh implementation start, the core handoff is a mapped netlist plus approved library, technology, timing, and (where applicable) power data — the floorplan can be generated locally or imported, scan data matters only if scan optimization is required, and activity data matters only for the power tasks you're actually running.
"It loaded" and "timing looks clean" are both weaker claims than they sound — loading only proves the tool accepted the data syntactically, and clean timing only proves the paths that *were* analyzed passed. Neither proves the files represent the chip you actually intend to build, and neither proves every case that needs checking was actually checked. Missing coverage is the most common trap: a missing generated clock means whole downstream paths never receive the clock-based checks they need — they just silently don't show up as violations because they were never analyzed at all. Similarly, an inactive slow-corner scenario can hide the exact violation that scenario would have caught.
A real readiness review isn't a file checklist — it's asking whether the next stage can start *reproducibly*, with complete and internally consistent intent, and recording evidence and ownership wherever something's still unresolved. Check identity and connectivity first: approved top module and revision, matching libraries and macros, all references actually resolved, design counts as expected, and every connectivity warning explained rather than ignored.
A number without its unit is just noise — PD juggles distance, time, capacitance, resistance, voltage, current, and power, often in different units across different files. Distance is usually micrometers (um) or nanometers (nm) — 1 um = 1000 nm. Time is nanoseconds or picoseconds — 1 ns = 1000 ps. Capacitance is picofarads or femtofarads — 1 pF = 1000 fF.
Database units (DBU) are just an integer scaling factor that lets DEF store every coordinate as a whole number instead of a floating-point micron value — floating point invites rounding drift across a huge file, integers don't. The DEF header states the scale, e.g. `UNITS DISTANCE MICRONS 2000 ;` means 2000 DBU = 1 micron. So converting is simple division: `microns = DBU_value / 2000`. Going the other way, multiply microns by the scale factor to get DBU.
Width is how thick the wire itself is, measured straight across it. Spacing is the empty gap between the edge of one shape and the edge of its neighbor.
A track grid is just a simple arithmetic sequence: `coordinate = offset + k × pitch`, where k is an integer within the track count — pitch sets the spacing, offset sets where the very first line sits. That means a coordinate can be arbitrarily close to a track without actually landing on one — e.g. a value like 100 µm isn't automatically centered on a track just because it "looks round."
A placement site is the smallest reusable unit of legal placement geometry — a row is just that unit tiled repeatedly across the floorplan, and a standard cell has to occupy a whole number of compatible sites, in a legal orientation. For a simple single-height library, every cell shares the same row-compatible height but varies in width (e.g., roughly 0.192 µm site-width increments) — that width quantization is exactly what lets the placer snap cells onto a clean, regular legal grid.