A feedthrough improves top-level timing but harms the block interface. How do you decide?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
This is a classic local-vs-global optimization conflict: the top-level integrator sees a timing win, the block owner sees a cost they didn't budget for, and neither party alone has enough information to make the call correctly. A faster route isn't automatically the right decision — "shorter and faster at the top level" has to be weighed against what it actually costs the block: pin count consumed, pin alignment disruption, routing capacity used up, buffering burden, voltage-area compatibility, and future ECO flexibility lost.
Technical Explanation
- Run the comparison properly: test the feedthrough option against alternatives — a full detour around the block, a "pure" feedthrough (touches nothing internal), a buffered feedthrough, or a reused feedthrough path — all measured with the same timing and congestion methodology so the comparison is fair.
- Identify which resource is actually the limiting one in each scenario. Sometimes the block's pin budget is the real constraint; sometimes it's top-level timing; sometimes it's future ECO headroom. The "right" answer changes depending on which resource is scarcest.
- This decision structurally cannot be made unilaterally — it needs sign-off from both the system/top-level owner (who benefits) and the block owner (who pays the cost), because each side is optimizing for a different metric and only has visibility into their own side of the tradeoff.
Formula Or Decision Rule
Decision rule: choose the lower total project risk, not the shortest path in isolation.
What To Check
- Warning sign: The top level claims the feedthrough without block evidence.
- Inspect: choose one affected region, macro, row, pin, path, or net and trace the physical cause.
- Correct: Document both alternatives, assign ownership, implement the chosen constraint, and rerun block and top-level checks.
Command Checks & Actions
- check_feedthroughs -include_original_feedthroughs -include_buffered -pure -mixed: checks targeted feedthrough classes and constraints
- report_feedthroughs -reporting_style block_based: reports feedthrough nets and traversed blocks
Run only the commands needed for this question. Save the report with the floorplan version and analysis context.
Healthy, Suspicious & Hard-stop Results
- Healthy: Compare top-level delay saved with block pin count, alignment, route capacity, buffering, voltage-area compatibility, reuse, and ECO flexibility. The system owner and block owner must agree.
- 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
The interviewer is testing whether you can connect “A feedthrough improves top-level timing but harms the block interface. ” to measurable physical evidence and an owned correction.
Follow-up Question & Model Response
"* Candidate Model Response: Model response: “I would change it if the same controlled rerun shows that the top level claims the feedthrough without block evidence. ”
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