What extra steps does multi-level physical hierarchy (MLPH) clock driver insertion need beyond the normal create_clock_drivers flow?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
MLPH clock driver insertion needs set_editability -blocks {...} -value true first (to allow the insertion to touch multiple physical hierarchy blocks), then cts.multisource.enable_mlph_flow set true, then create_clock_drivers as usual, then synthesize_multisource_global_clock_trees with -roots and -leaves specified plus -use_zroute_for_pin_connections. Ports are reused if they already exist, and new ports are only created if set_freeze_ports allows it -- a real constraint on hierarchical boundaries that ordinary single-block flows don't have to think about.
Technical Explanation
- MLPH clock driver insertion first needs set_editability -blocks {...} -value true -- normal create_clock_drivers assumes one editable block, and MLPH crosses multiple physical hierarchy blocks.
- cts.multisource.enable_mlph_flow must be set true before create_clock_drivers is called, enabling the multi-level-hierarchy-aware behavior.
- synthesize_multisource_global_clock_trees then needs -roots and -leaves specified explicitly, plus -use_zroute_for_pin_connections, since the Custom Router's default pin-connection behavior needs the Zroute fallback more often across hierarchy boundaries.
- Ports are reused if they already exist at a hierarchy boundary; new ports are only created if set_freeze_ports allows it at that boundary -- a hierarchical constraint that a single-block create_clock_drivers flow never has to consider.
set_app_options -name cts.multisource.enable_mlph_flow -value trueis the real command that enables the MLPH flow -- the option name alone in prose doesn't configure anything without it.
Common Mistake
The Trap: Running create_clock_drivers across a multi-level physical hierarchy design without first setting cts.multisource.enable_mlph_flow and the necessary block editability -- the normal single-block flow doesn't know how to cross hierarchy boundaries correctly.
Follow-up Question & Model Response
"Why would set_freeze_ports on a lower-level block specifically block new port creation during MLPH clock driver insertion?"
Candidate Model Response: Because a frozen block boundary (set_freeze_ports) is specifically meant to prevent new ports from being added to an already-finalized hierarchy interface -- MLPH clock driver insertion respects that same protection rather than overriding it just because a clock driver needs a new connection.
Practical Example
Debug Scenario: A clock driver insertion spanning three physical hierarchy blocks fails to create needed ports at one block's boundary -- checking that block's set_freeze_ports setting reveals it was frozen, which is exactly the documented constraint preventing new ports from being punched there during MLPH insertion.
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.
Continue practising