BeginnerQuestion 297 of 97Source PDF page undefined

Does ICC2's DRC checking actually enforce max fanout the same way it enforces max capacitance and max transition?

From PDVerse PnR Interview Handbook · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

No -- this is a specific, important exception: max fanout DRC is NOT honored by ICC2 as a hard design rule constraint. Instead, opt.common.max_fanout is a soft optimization constraint. Min capacitance, max capacitance, and max transition DO have technology-specific defaults in the logic libraries and can be overridden as real DRC -- max fanout is handled differently.

Technical Reference DiagramDoes ICC2's DRC checking actually enforce max fanout the same way it enforces max capacitance and max transition?
Does ICC2's DRC checking actually enforce max fanout the same way it enforces max capacitance and max transition?, illustrating the physical design concept.

Technical Explanation

  • Max fanout DRC is NOT honored by ICC2 the same way max transition/max capacitance are -- this is a specific, documented exception, not an oversight to work around.
  • Instead, opt.common.max_fanout is a soft optimization constraint -- the tool tries to respect it during optimization, but it isn't enforced as a hard DRC the way the other electrical constraints are.
  • Min capacitance, max capacitance, and max transition all have technology-specific defaults in the logic libraries and can be overridden as real, hard-enforced DRC constraints -- max fanout genuinely works differently.
  • The real workaround is set_app_options -name opt.common.max_fanout -value <n> -- since ICC2 doesn't honor a hard max-fanout DRC, this soft-optimization option (named here, but never shown as a full invocation) is what actually needs to be set.

Common Mistake

The Trap: Assuming a clean report_constraint pass means max fanout was checked and enforced the same way max transition/capacitance were -- it wasn't; max fanout is a soft optimization target via a separate application option, not a hard DRC.

Follow-up Question & Model Response

"Given max fanout isn't hard-enforced DRC, what would actually catch a net with genuinely excessive fanout in signoff?"

Candidate Model Response: The downstream electrical consequences would show up as real max transition or max capacitance violations on that net (or its loads) -- those ARE hard-enforced DRC, so excessive fanout still gets caught indirectly, just not by a fanout check itself.

Practical Example

Debug Scenario: report_constraint shows a clean pass with no fanout violations reported, but a specific net still has significantly more loads than the design's fanout guideline suggests -- because ICC2 never treats max fanout as a hard DRC to report a violation on in the first place.

Physical Design & Planning Handbook

Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.

Explore Design Planning Guide →

Continue practising

Related PnR (Place & Route) questions

BeginnerWhat's the practical fanout guideline STA uses, and what does it actually control?BeginnerWhat's the practical target fanout range for a high-fanout net driver, and why does HFN synthesis need its own handling at all?BeginnerWhat does set_dont_touch_network actually protect by default, and how does -clock_only narrow that scope?IntermediateWhat problem does split_fanout actually solve during a timing ECO, and how do you tell it what to split on?