Clock tree synthesis readiness

8.1 Stage purpose

Clock tree synthesis (CTS) replaces the single ideal clock net of each clock with a tree of buffers, inverters and clock gates, and routes it. This chapter does not run CTS. It checks that the design, the constraints and the CTS configuration are ready, so that the run in the next stage is a test of the tree and not of your setup. Figure 11 shows the objects involved.

A clock tree is the part of the netlist that CTS buffers, from a clock source down to the pins it must reach. A sink is a pin the tree must reach and balance, typically the clock pin of a register. A skew group is a set of sinks that must arrive together, and it is the CTS counterpart of an SDC clock. Insertion delay is the delay from the clock source to a sink, and skew is the difference in that delay between two sinks.

CTS names three kinds of net. A leaf net connects to one or more sinks. A trunk net is any other net in the tree. A top net is a trunk net above a sink count that you choose, and it exists only if you set that count. A non-default rule (NDR) gives a net wider wires or larger spacing than the default, and a route type binds an NDR to preferred layers and a shield. Shielding means running wires tied to a power or ground net beside the clock wire, so that neighbouring signals cannot disturb its timing.

Readiness is cheaper to check than a tree is to rebuild. A wrong sink list, a missing macro delay or an unusable cell list costs a full CTS run.

The four ideas of this book stay apart. Tool completion means a command ended. Analysis coverage means a report examined the clocks and views you needed. Stage qualification means the evidence meets your project budgets. Signoff is a later stage and is not claimed here. The checks in this chapter read configuration and constraints, so they give implementation evidence. Any timing figure taken at this point uses ideal clocks and is preliminary evidence.

8.2 Entry prerequisites

8.3 Relevant files and analysis context

CTS reads the design in memory, the constraint modes and analysis views, the clock tree specification, and a set of CCOpt properties. CCOpt is the clock engine of the tool. A property is a named setting that you read with get_ccopt_property and change with set_ccopt_property, either globally or for one object such as a clock tree, a net type or a pin.

The specification comes from create_ccopt_clock_tree_spec, which analyses all active setup and hold views. With -file it writes an editable Tcl script and does not execute it, and the script records why each setting was made. You source that script once. Sourcing it again gives the error that clock trees are already defined, and delete_ccopt_clock_tree_spec or reset_ccopt_config removes the earlier one. The second command also clears every value set with set_ccopt_property, so use it only when you mean to start the configuration again. Store the script with the run.

Order matters. A pin type set with the sink_type property takes effect only if it is set before the specification is created. The quick start in the reference sets the route types, cell lists and targets before it creates the specification, and the cards follow that order: constraints, rules, cells, targets, specification, then the checks that read the specification, and finally the tool check. Cards K-06 and K-07 can repeat, because a pin type found there must be set before the specification is created again.

8.3.1 Ideal and propagated clocks

An ideal clock reaches every register at the time the clock definition says, with no delay through a clock network. A propagated clock includes the delay of the actual buffers and wires. Before CTS there is no network to propagate through, so clocks are ideal. The reference says timeDesign and optDesign at the pre-CTS stage use -clkSrcPath false with -clockPropagation forcedIdeal. In the setter, -clockPropagation defaults to sdcControl, which follows the set_propagated_clock assertions in the constraints.

After CTS the situation reverses. The reference states that CCOpt switches the timing clocks to propagated mode and updates the source latencies so that input and output timing stays correct. It adds that update_io_latency is not needed after ccopt_design and gives invalid results if used. Thus, a readiness check does not try to prove skew. It proves that the clocks are defined, are ideal and are about to be replaced by a tree built to a stated intent.

8.4 Checks and command cards

8.4.1 Pre-stage checks

Before the cards, write the clock plan down and keep it with the run. It is the document the tool output is compared against.

List, for each clock, its name, source pin and modes, its sink count, any clock gates, generated clocks and clock-selecting muxes, the routing rule for each net type with its layers, the allowed buffers, inverters and clock gates, the transition target, skew target and useful skew intent, and every macro clock pin with its internal delay. Cards K-01 to K-08 compare the tool with these items.

Then confirm that the Chapter 7 exit checklist is complete, and save the design so that the placement baseline can be restored if the clock configuration has to be repeated. If the netlist is hierarchical, run checkUnique -verbose: the reference says CTS requires each module to be instantiated once.

8.4.2 Post-stage checks

check_timing -type clocks -verbose
report_clocks
getAnalysisMode -clockPropagation
report_clocks -source_insertion -insertion

report_case_analysis -propagated
report_clock_gating_check

get_ccopt_property route_type -net_type trunk
add_ndr -name <ndr_name> -width_multiplier {<layers> 2} -spacing_multiplier {<layers> 2} -generate_via
create_route_type -name <route_type> -non_default_rule <ndr_name> -top_preferred_layer <layer> -bottom_preferred_layer <layer> -shield_net VSS
set_ccopt_property -net_type trunk route_type <route_type>
set_ccopt_property routing_top_min_fanout <n>

get_ccopt_property buffer_cells
report_ccopt_cell_filtering_reasons -cell_type buffer -file <f>
set_ccopt_property buffer_cells {<buf_a> <buf_b>}
set_ccopt_property inverter_cells {<inv_a> <inv_b>}
set_ccopt_property clock_gating_cells {<icg_a> <icg_b>}

get_ccopt_property target_max_trans
getOptMode -opt_skew_ccopt
getDesignMode
set_ccopt_property target_max_trans 100ps -net_type leaf
set_ccopt_property target_skew 50ps
setOptMode -opt_skew_ccopt standard
setDesignMode -earlyClockFlow true

create_ccopt_clock_tree_spec -file <spec.tcl>
source <spec.tcl>
get_ccopt_clock_trees *
get_ccopt_skew_groups *
delete_ccopt_clock_tree_spec

report_ccopt_clock_trees -list_special_pins -file <f>
get_ccopt_clock_tree_sinks -in_clock_trees <clock_tree>
set_ccopt_property sink_type ignore -pin <pin>
check_ccopt_clock_tree_convergence -warnthreshold <n>
report_ccopt_clock_tree_convergence -num_worst_sinks <n> -file <f>

set_ccopt_property insertion_delay <value> -pin <macro_ck_pin>
report_ccopt_pin_insertion_delays -file <f>

report_preserves -dont_touch
report_ccopt_cell_halo_violations -summary

ccopt_design -check_prerequisites
check_design -type cts -out_file <f>
clock_opt_design -check_cts_config

8.5 Required reports, artefacts and how to read them

check_timing -type clocks -verbose                       ## illustrative excerpt
   Warning                  Description                                     Number
   ideal_clock_waveform     Clock waveform is ideal                             3
   no_gen_clock_source      No clock source found for generated clock           1
   clock_crossing           Clock domains interact                              2

Assume the clock plan lists three clocks. The three ideal-clock warnings match them, so none has been propagated, which is what you want. The no_gen_clock_source line is a hard stop for that clock. A divided clock whose source pin is not driven by a clock source has no master, so the specification cannot tie its tree to a parent. The two crossings are information if the plan lists the clock pairs, and a question if it does not. The counts here are illustrative.

ccopt_design -check_prerequisites                        ## illustrative excerpt
CCOpt configuration status: cannot run ccopt_design.
Check the log for details of problem(s) found:
---------------------------------------------------
Design configuration problems
---------------------------------------------------
One or more clock trees have configuration problems
---------------------------------------------------
Clock tree configuration problems:
------------------------------------------------------
Clock tree      Problem
------------------------------------------------------
clk_div2        The maximum transition target is too low
clk_div2        The selected drivers are too weak
------------------------------------------------------
clk_core        The selected drivers are too weak

The status line says the run cannot start, so this is a hard stop for K-10 and the tool has not built anything. The first block says only that some trees have problems, and the table names them. Two of the three findings are about drivers that are too weak, and the divided clock has a low transition target as well. Weak drivers and a tight target are linked, because a tight target needs strong drivers. Look at the cell lists in K-04 and the target in K-05 together, and read the filtering reasons before widening either one. The names and the problems in this excerpt are illustrative.

8.6 Healthy, suspicious and hard-stop examples

8.7 Debugging, corrective action and reruns

Fix problems in the order the configuration is built. Constraints come first (K-01, K-02), then rules, cells and targets (K-03 to K-05), then pin types and the specification (K-06, K-07), then insertion delays, halos and protected objects (K-08, K-09), and last the tool check (K-10). A change to the constraints or to a pin type changes the specification, so delete it and create it again. The tool documentation is not consistent on whether pin properties survive the delete, so list them afterwards with get_ccopt_property. A change to a rule, a list or a target needs its own card and K-10 to run again. The reference does not say that these changes require a new specification, so confirm the new value with the matching get command.

Keep the specification script and a record of the properties with each attempt. When a CTS result is poor later, the first question is whether the configuration changed, and a stored record answers it.

8.7.1 Worked example: a transition target that is 100 times too large

Suppose the library time unit is 0.1 ns, and someone sets the top net target with a bare number. K-05 shows the property and the unit, and the tool log shows what the tool took from it.

get_time_unit                                            ## illustrative excerpt
0.100000ns
set_ccopt_property -net_type top target_max_trans 100
ccopt_design -check_prerequisites
...
Clock tree balancer configuration for clock_trees ...
Slew time target (top): 10000.0ps

The unit is 0.1 ns, so 100 means 10 ns, which the log shows as 10000 ps. The reference examples use targets such as 100ps and 150ps, so a target of 10 ns is off by a large factor. Do not rely on the prerequisite check to catch it. The decision for K-05 is HARD STOP. The reference gives this same case and notes that a target that is too low or too high harms runtime and quality, and that check_design -type cts cross-checks transition targets.

set_ccopt_property -net_type top target_max_trans 100ps   ## illustrative correction

After the correction, read the log line again, rerun K-05 and K-10, and check that the target for leaf and trunk nets still has its unit. The numbers in this example are illustrative. Your clock plan and library set the real values.