Reporting Violations Into a Clock Gater

Loop over every startpoint pin in the fan-in cone of the clock-gate enable pin and report timing from each one to the clock gater. For example: foreach_in_collection pin [all_fanin -to <clk_gate_pin> -startpoints_only -flat] { report_timing -nosplit -nworst 1 -max_paths 1 -from [get_pins $pin] -to [get_pins <clk_gate_pin>] >> ./clock_gate_vios.rpt }

KEY Iterate over the gater's fan-in startpoints with all_fanin and report_timing each path into a file.

Steps in Building the CTS Clock Tree

• Trace the clock network.
• Delete the existing clock-tree cells.
• Insert buffers according to the transition limit, with the tool keeping the more common shared path.
• Balance skew based on the path with the highest delay.

KEY CTS build: trace, delete old tree, insert buffers per transition limit, then balance skew.

Checks Performed During CTS

• Design rule violations - max transition, max capacitance and fanout.
• Skew, both local and global.
• Timing - setup and hold.
• Clock quality.
• Power.

KEY CTS checks cover DRVs, local/global skew, setup/hold timing, clock quality and power.

Causes and Fixes for Clock-Gating Violations

• A clock gater is always on the capture side - it cannot launch data to any flop, so timing paths always run 'to the clock gater'.

The basic problem is skew: the launch register can have a larger clock-path delay than the clock-gating cell, where skew is launch