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.