What is the difference between importing and linking a netlist?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Reading a Verilog netlist (read_verilog) is like reading an address book — it creates the names of design objects (instances, ports, nets) and records how they're supposed to connect, but it doesn't verify any of those references actually resolve to something real. Linking is the follow-up step where ICC2 actually finds the real definition for every instantiated cell — whether that's a leaf-level library cell or a lower-level design module — and connects the netlist's abstract references to concrete objects.
Technical Explanation
- Think of it as the difference between writing down "call John" and actually dialing a number that connects — import writes the names down, link makes the connection real.
- This distinction matters practically because a netlist can "read" cleanly with zero errors while still containing unresolved references — the failure only shows up at link time, when the tool reports unresolved/black-box instances it couldn't find a definition for.
- Watch the link log carefully: unresolved references becoming silent black boxes is a common source of "my design is missing logic" bugs that trace back to a reference library not being in the search path at link time.
- Both steps matter for correctness before anything downstream (floorplanning, SDC, UPF) is applied — you want to know your design is fully bound before you start constraining or placing it.
Visual Verification
Importing reads Verilog text into memory with unmapped cell names; linking binds those leaf instances to physical technology libraries, resolving real pins, capacitances, and footprints.
What To Check
- Warning sign: The Verilog reads successfully while instances remain unresolved or black-boxed unintentionally.
- Inspect: Start with one named object in the report and trace it to the netlist, library, or SDC statement that created it.
- Correct: Correct the reference setup or source netlist and link again; do not create dummy cells to silence the problem.
Command Checks & Actions
- read_verilog <netlist.v>: imports the gate-level connectivity
- link_block: resolves instantiated references
- report_unbound: lists objects that did not resolve
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: Import creates design objects from the Verilog; linking resolves every instantiated reference against the available design and library context.
- Stop before floorplanning when required logic or timing coverage is missing or unexplained.
Common Mistake
The Trap: Do not assume the check passed just because ICC2 continued. Fix or narrowly justify the named objects, then rerun the same command.
What The Interviewer Is Testing
Be ready to explain why this matters before floorplanning.
Physical Design & Planning Handbook
Master ASIC Physical Design Planning & Floorplanning
Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising