What goes wrong when a compound generated clock (divide-then-gate) is defined incorrectly, and how do you validate it?

Short Answer

A compound generated clock — one that is first divided down from a faster source clock and then gated off (stopped and started) by an enable signal — has to encode both operations correctly in its SDC. Get either one wrong, and the tool computes the wrong period, the wrong edges, or fails to recognize the derived clock's relationship to the rest of the design, since it can only reason about the exact waveform the designer describes to it.

Technical Explanation

• A divide-then-gate clock has two separate structures in the netlist: a divider (often a toggle flip-flop) that halves or quarters the source frequency, followed by an integrated clock gating (ICG) cell that lets an enable signal stop and restart the divided clock cleanly, without producing a runt (partial-width) pulse.
• create_generated_clock -source ... -divide_by N (SDC) models only the divider stage — it produces a clean, continuously running divided waveform. It says nothing about the gating, because the command describes a periodic clock, not a signal that can stop.
• When the divided clock also passes through an ICG, the generated clock's -source and target pin must point past the divider but at (or before) the gating cell in a way that the tool's clock tracing can actually follow — usually meaning the generated clock is defined at the ICG's output pin, once the tool can trace a continuous path back through both the gate and the divider to the root clock.
• If the generated clock is instead defined only at the divider's output, before the gate, the tool has no clock definition at the ICG's output at all, so it cannot compute setup and hold checks for any flop downstream of the gate — those paths report as unconstrained rather than analyzed.
• If the generated clock's -source points at the wrong pin (say, the ungated divider tap instead of the actual clock net feeding the downstream flops), the tool derives edges from the wrong reference, so its period and phase are wrong even though the SDC parses without error.
• The clock-gating check itself — verifying the enable signal only changes when the gated clock is safely low, so no runt pulse escapes — is a separate check from the generated-clock definition; report_clock_gating_check (PT) is how you confirm the enable's timing is safe, and it depends on the generated clock being defined correctly first, since the tool needs a correct clock waveform to know when "safely low" occurs.
• check_timing (PT) is the first validation step for the SDC generally: it flags clocks with no valid path from a defined source, unconstrained clock pins, and multiply-defined generated clocks, all of which surface a divide-then-gate definition that traced to the wrong pin.
• What breaks: an incorrectly rooted or incorrectly gated clock definition silently drops entire downstream flops from timing coverage — the report shows no violations not because the design is clean, but because those paths were never checked at all.

Follow-up Question & Model Response

"Suppose report_clock_gating_check comes back completely clean for this gated-divided clock. Does that alone confirm the generated clock definition is correct?"

Candidate Model Response: No — a clean gating check only confirms the enable signal's own timing is safe relative to whatever clock waveform the tool currently believes exists at that pin; it does not confirm that waveform is the right one. I would still separately confirm, with check_timing, that every flop downstream of the gate is actually receiving a defined clock and is not silently falling into the unconstrained-endpoints list, and I would spot-check report_clock on the generated clock to confirm its source, divide ratio, and period all match what the divider and gate are actually supposed to produce in the netlist.