In what order should inputs be loaded into ICC2?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
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.
Technical Explanation
- 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.
- Read the structural netlist next and resolve the top block, then let linking resolve every instantiated reference — physical and timing data applied before the design is properly bound targets the wrong (or nonexistent) objects.
- Only after the design is imported and confirmed (check the import log and design identity) should floorplan information, UPF (for multivoltage designs, following the methodology's required sequence including any name mapping), and timing setup (modes/corners/scenarios, logical and parasitic models, constraints) get applied.
- There's no single universal ordering among floorplan/UPF/timing substeps beyond that — the right sequence depends on things like whether the power grid is owned by this block or inherited, whether low-power cells already exist in the netlist, and hierarchical setup specifics.
- The invariant that never changes: object names and physical/logical context must exist before you annotate or constrain them, and all required intent must be valid before optimization runs. Save an inspected checkpoint with reports after setup — and if automating via
icc2_shell -file, remember session-startup behavior (init files) is itself part of reproducibility.
Command Checks & Actions
create_lib / open_libTechnology and libraries load first, since every later step -- netlist binding, floorplanning, timing -- depends on them already being available.
read_verilog design.vNetlist import follows library setup, because binding requires the libraries to already be in memory.
read_def block.defThe floorplan and physical-constraint layer imports last, on top of an already-linked netlist, since DEF placement data refers to instances that must already exist.
Common Mistake
The Trap: Presenting a short illustrative command list as a complete production-ready flow for every process and ICC2 release.
Follow-up Question & Model Response
"Which checkpoint is most useful for debugging later QoR changes?"
Candidate Model Response: A reproducible initial database with the exact input manifest, setup scripts, tool version, and validation reports.
Practical Example
Tapeout Scenario: Reading an SDC against a different current block can yield empty selections. The remedy is to restore the correct block and scenario context, then reapply and verify the constraints; it is not to delete the failing lines.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
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