How should clock modeling rigor differ for a safety-critical versus a consumer design?

Short Answer

Both designs use the same clock commands and modeling; what changes is how exhaustively completeness is verified, how conservatively margins are chosen and justified, and how traceable the clock spec is back to the fabricated design. Safety-critical work treats a clock error as a potential undetected hazard and adds evidenced gates and independent review; consumer work applies the same methodology with proportionate, lighter review.

Technical Explanation

The clock definitions and checks are identical between a medical-device SoC and a consumer wearable — create_clock (SDC), create_generated_clock (SDC), set_clock_groups (SDC), check_timing (PT). What differs is the evidence and margin discipline on top.

• Completeness becomes an exhaustive, evidenced gate. check_timing (PT) with zero unclocked registers is mandatory in both cases, but safety-critical work individually confirms every generated clock and reviews every clock-group relationship rather than assuming it from RTL intent.
• Margins are conservative and documented, not defaulted. Uncertainty, OCV, and jitter margins are chosen deliberately for the design and written down with their reasoning; dynamic jitter is modeled explicitly and worst-case early/late latency is applied.
• Clock-group discipline gets rigorous, because that is where silent gaps hide. Every set_clock_groups -asynchronous/-logically_exclusive (SDC) declaration is individually justified, and every synchronizer expected at an asynchronous crossing is verified to actually exist in the netlist.
• The clock spec becomes traceable. Which definitions and relationships produced a given qualified signoff run, and proof they match the fabricated clock tree, gets recorded rather than assumed from memory.
• Independent review applies to the clocking, not just the RTL. Clock constraints are reviewed as rigorously as the logic, because a clock error is part of the safety case — a skew-driven hold failure especially, frequently unfixable post-fabrication.
• Signoff runs against the real, propagated tree. set_propagated_clock (SDC) is confirmed applied everywhere clock-tree synthesis has completed, with no ideal shortcuts left in the signoff configuration.
• Consumer design runs the identical methodology, proportionately. Complete, propagated, correctly related clocks with verification still apply — but formal justification, traceability, and independent review are lighter, because a clock error there costs rework rather than a potential hazard.
• Review cadence follows the same pattern as constraint rigor. A safety-critical clock spec is typically re-verified on every ECO that touches a clocked interface or a PLL configuration, not only at the final signoff milestone, since a late clock-tree change can quietly invalidate an uncertainty margin chosen months earlier.

Follow-up Question & Model Response

"How would you prove to an auditor that no clock group in a safety-critical design is over-broad?"

Candidate Model Response: I would produce, for every set_clock_groups (SDC) declaration, a written justification tracing back to the RTL's actual clock architecture — which domains genuinely have no timing relationship, and which have a synchronizer at the crossing rather than simply being declared asynchronous. I would then cross-check that list against report_clock (PT) and the actual netlist connectivity to confirm no domain claimed as asynchronous is, in fact, timing-related through some path the RTL review missed, since that specific gap is what an over-broad group is designed to hide.