How do chip I/O, top-level ports, macro pins, and block pins differ?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Last updated:
Short Answer
These are all "connection points," but they live at very different physical and logical boundaries, and confusing them is a common source of miscommunication between floorplan, package, and RTL teams. Chip I/O (pads or bumps) are where the die physically connects to the package — their placement and rules are driven by packaging constraints (bond-wire pitch, bump grid), not by what's convenient for internal routing.
Technical Explanation
- Top-level ports are the design's logical connection points — they represent what the netlist declares as its external interface, and they're what SDC constraints like
set_input_delaytypically target. - Macro pins belong to fixed hard macros (memories, analog blocks, hardened IP) — their geometry is fixed by the macro's own layout view, and the floorplan/placement tool can't move or reshape them, only work around them.
- Block pins are the interface points of a hierarchical sub-block — they exist because of how you've partitioned the design, and they expose that block's connections to the rest of the chip.
- The forces that drive each one's placement are different: package rules drive chip I/O, dataflow and hierarchy drive block pins, and macro pin geometry is simply inherited as-is from whatever the macro's layout view says — you don't get to redesign it.
- Getting these straight matters for floorplanning specifically: you can move a block pin's logical boundary, but you can't move a macro pin without changing the macro itself, and you definitely can't move a chip I/O pad without a package-level conversation.
Visual Verification
Package I/O pads interface with off-chip bondwires or bumps, block pins define hierarchical partition boundaries, and macro pins are fixed access points on IP blocks.
Formula Or Decision Rule
Decision rule: identify the boundary owner before applying placement, layer, spacing, or ordering constraints.
What To Check
- Warning sign: A block pin is treated like a package pad, or a macro pin is assumed movable.
- Inspect: choose one affected region, macro, row, pin, path, or net and trace the physical cause.
- Correct: Apply the constraint to the correct object class and verify the reported side, layer, and offset.
Command Checks & Actions
- report_pin_placement -format {layer side offset}: reports pin layer, side, and offset
Run only the commands needed for this question. Save the report with the floorplan version and analysis context.
Healthy, Suspicious & Hard-stop Results
- Healthy: Chip I/O pads or bumps connect the die to the package; top-level terminals represent design connections; macro pins belong to fixed macros; block pins expose hierarchical interfaces.
- Hard stop: required legality or physical feasibility is missing or unexplained.
Common Mistake
The Trap: Do not hide the symptom with an arbitrary utilisation, halo, channel, blockage, pin move, or die-size change.
What The Interviewer Is Testing
” to measurable physical evidence and an owned correction.
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