What does check_netlist contribute before floorplanning?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Linking (binding the netlist against your libraries) only tells you the tool found a definition for every instance — it proves the netlist parses, not that it makes sense. check_netlist goes a level deeper: it looks for structural problems that can survive linking perfectly cleanly — things like multiple drivers on one net, unconnected/dangling pins, or other connectivity defects that don't stop the netlist from loading but will definitely cause trouble later.
Technical Explanation
- A classic example: two different cells both driving the same net (a multiple-driver conflict) links fine — the tool knows what both cells are — but it's structurally broken and will produce wrong or undefined behavior, which
check_netlistis specifically built to catch. - Running this before floorplanning matters because floorplanning and placement decisions get baked in around the netlist's assumed connectivity — finding a multiple-driver or dangling-pin issue after placement means redoing work, whereas catching it here is nearly free.
- Treat a clean
check_netlistrun as a real gate, not a formality — review every warning it produces, because "the design loaded" and "the design is structurally sound" are two different claims.
Visual Verification
The check_netlist utility catches critical structural defects—such as multi-driven nets, floating inputs, and dangling wires—that compile cleanly in Verilog but cause chip electrical failures.
What To Check
- Warning sign: The design links but contains loops, multiple drivers, unloaded or undriven objects, or empty logic.
- Inspect: Start with one named object in the report and trace it to the netlist, library, or SDC statement that created it.
- Correct: Classify every reported structure as a defect or reviewed intent, repair at the source when possible, and rerun.
Command Checks & Actions
- check_netlist: reports structural connectivity problems
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: It checks structural consistency such as connectivity defects that can survive parsing and linking.
- 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