How does CTS merge clock-gating cells, and when should you disable it?

Short Answer

By default, CTS merges ICGs (integrated clock-gating cells) only within the same clock tree level -- cts.icg.merge_cross_level is false by default, meaning merging across levels is an explicit opt-in, not automatic. Separately, place_opt.flow.merge_clock_gates controls whether ICG merging happens at all during the placement-stage flow (merge_clock_gates must run before create_placement). Disabling merging matters when two ICGs that look mergeable actually gate logic with different enable timing requirements -- merging them would force one clock structure to serve two enable conditions that shouldn't share one.

Technical Explanation

• ICG merging happens at more than one point in the flow, and the controls are genuinely different, not the same switch under two names.
• place_opt.flow.merge_clock_gates controls whether ICG merging happens during the place_opt flow at all -- and the underlying merge_clock_gates operation must run before create_placement.
• cts.icg.merge_cross_level (default false) controls whether CTS merges ICGs across different tree levels; by default CTS only merges within the same level.
• Cross-level merging isn't the default because two ICGs at different levels may drive logic with genuinely different enable-pin timing requirements -- merging forces one shared structure to serve both, which can be wrong even when it looks like an area/power win.
• place_opt.flow.optimize_icgs is a related but distinct optimization -- sizing/positioning ICGs whose enable pin sits on a critical timing path, not consolidating separate ICGs together.
• Disable merging (or cross-level merging specifically) when two candidate ICGs likely gate logic with different enable timing behavior.

Healthy, Suspicious & Hard-stop Results

• Expected: merged ICGs share genuinely equivalent enable-pin timing requirements, and post-merge functional/timing checks show no change in when the gated clock actually toggles.
• Investigate: a merged ICG's downstream logic shows different toggle behavior than expected for one of the two original enable conditions -- check whether cross-level merging was enabled without verifying the two ICGs' enable timing actually matched.
• Stop: functional simulation shows a gated clock toggling under a condition where the pre-merge design would not have toggled it -- that's a real functional bug from over-aggressive merging, not a timing nit.

What The Interviewer Is Testing

Whether you know ICG merging is controlled by more than one setting at different flow stages, and whether you understand the functional risk (not just area/power tradeoff) behind cross-level merging specifically.