How would you decide which clock-related decisions to standardize versus leave to block owners?

Short Answer

Standardize whatever must be identical everywhere it appears to compose correctly across the chip — the primary clock definitions, the clock-group relationships, the ideal-versus-propagated and uncertainty conventions, and the verification gates. Delegate whatever is genuinely internal to one block, like a local generated clock or a block-specific uncertainty refinement, as long as it follows the standardized conventions.

Technical Explanation

The dividing line is whether a decision is shared across the chip and has to compose with every other block's view, or whether it only affects logic inside one block.

• Standardize the primary clock definitions. create_clock (SDC) for every top-level clock — period, waveform, PLL/reference scheme — has to be identical everywhere it is referenced, because two blocks disagreeing about a shared clock's period is a bug, not a modeling choice.
• Standardize the clock-relationship framework. set_clock_groups (SDC), declaring which domains are asynchronous, logically exclusive, or otherwise related, has to be chip-wide, because a crossing cannot be asynchronous in one block's view and synchronous in another's.
• Standardize the modeling conventions. Ideal-versus-propagated staging, set_clock_uncertainty (SDC) usage, and jitter-as-dynamic-uncertainty need one chip-wide convention so a report from one block means the same thing as a report from another.
• Standardize the single-source discipline. Every block reads clock definitions from one shared, version-controlled source, so nobody drifts from the golden definition unnoticed.
• Standardize the verification gates. check_timing (PT) clean of unclocked registers, and report_clock (PT) matching the intended tree, are mandatory checks applied the same way everywhere — exactly the checks that catch a silent, chip-wide clock error.
• Delegate what is genuinely block-internal. A generated clock feeding only one block's logic, defined with create_generated_clock (SDC) per the standard conventions, is a block owner's call. Block-internal clock-gating structures and checks stay with the block. A block-specific uncertainty refinement is fine as long as it sits within the chip-level framework.
• Why the split holds up. None of the delegated items cross a block boundary, so as long as they conform to the standardized definitions and relationships, a local choice cannot break another block's view of the clock — precisely the property standardization protects.

Follow-up Question & Model Response

"A block owner wants to add their own clock uncertainty number that differs from the chip-level convention, arguing their block's clock tree is unusually deep. Do you allow it?"

Candidate Model Response: I would allow a block-specific number, but only as a documented refinement layered on top of the chip-level set_clock_uncertainty (SDC) convention, not a replacement for it — for instance, an additional residual justified by that block's own clock-tree skew data, reviewed and recorded rather than silently substituted. The chip-level convention still has to be the baseline every block starts from, or the next full-chip integration cannot tell whether a difference in reported margin is a real block characteristic or an undocumented deviation.