• If the clock gates sit roughly halfway down the tree, splitting (replicating) the clock gate can help; this creates parallel copies of the driver with fewer loads each. Doing the split pre-CTS effectively pushes the clock gate further down the tree, increasing power but improving enable timing - see the split_clock_net command.
• If the clock gates are at the beginning or near the bottom of the tree, splitting is unlikely to help. Instead, add a pre-CTS clock latency to the ICG clock pin to model the pre-CTS latency correctly - in the example above you would apply a -700ps latency to the clock-gate clock pin during place_opt but before CTS.
• If the ICG is a single top-level clock gate fed by a relatively small cone of logic, you can apply a float-pin constraint to the flops feeding the enable logic so their clocks arrive earlier (useful skew). This is often the best option for top-level clock gates because it does not impact power, whereas splitting a top-level clock gate can have a very large power impact.

KEY Post-CTS clock gates sit mid-tree and arrive early, degrading enable-path slack; fix by splitting, adding pre-CTS latency, or using float-pin useful skew.

Uncertainty Pre-CTS vs Post-CTS

Uncertainty defines a window within which a clock edge may occur. In physical design it models factors such as jitter (the clock edge's deviation from its ideal position), additional margins, and skew (pre-CTS). Different uncertainty values are used for setup and hold. Because the hold check is performed against the same clock edge, any clock-edge deviation (jitter) affects the launch and capture flops in the same way, so jitter does not need to be modeled in hold uncertainty - this is why hold uncertainty is always smaller than setup uncertainty. Before CTS, uncertainty also models the skew expected after the clock tree is built; at post-CTS stages the uncertainty values are reduced because the actual skew is now known.

Setup uncertainty: pre-CTS = jitter + skew + extra setup margin.