CTS and post-CTS qualification

9.1 Stage purpose

Before this stage, timing was analysed with ideal clocks: every flop saw the clock at the same moment, so the clock network cost nothing. Clock tree synthesis, or CTS, builds the real network. It inserts buffers and inverters, balances the delay from the clock root to every sink (a flop, latch or macro clock pin), and routes the clock nets. The result is described in Figure 12. The delay from the root to a sink is its insertion delay. The spread between the largest and smallest insertion delay in a group of sinks that must be balanced together is the skew, and such a group is a skew group.

The main command is ccopt_design. Run without options it performs clock concurrent optimization, which builds the tree and optimises the clock and the datapath together. With -cts it performs clock tree synthesis only, with no datapath optimisation or useful skew. After either form the clock nets are detail routed and the clocks are switched to propagated mode, which means timing now uses the real clock latencies. The reference says a clock that was already propagated before CCOpt is not switched and gets no source latency update, and that update_io_latency must not be run after ccopt_design.

Four ideas are kept apart in this chapter. Tool completion means the command returned. Analysis coverage means the timing checks you expect were actually evaluated. Stage qualification means the evidence meets your project budgets for skew, insertion delay, slew, hold and legality. Signoff comes later, after detail routing and signoff extraction. A tree can complete, report no violations, and still be unqualified because a clock never reached its flops. Thus, each card below asks what the output proves, and what it leaves unproven.

9.2 Entry prerequisites

9.3 Relevant files and analysis context

CTS works from a clock tree specification: the clock trees, skew groups and CTS properties derived from the timing constraints. The command create_ccopt_clock_tree_spec defines it from all active setup and hold views. With -file it only writes the specification as a script and does not execute it. You then run source on the script, once per session, and delete_ccopt_clock_tree_spec or reset_ccopt_config removes a loaded specification. The script is the best record of what CTS was asked to do.

CTS behaviour is controlled by CCOpt properties, set with set_ccopt_property and read with get_ccopt_property. The ones that matter for qualification are the target maximum transition, the target skew (which the reference says full ccopt_design ignores, see C-04), the route types for leaf, trunk and top nets, the buffer, inverter and clock gating cells, and the primary delay corner. A route type binds a non-default routing rule (NDR), preferred layers and a shield net, and it is created with create_route_type. The route type is only a request, so Section 9.4 checks the routed result.

Record the following with every report, because two runs with different settings are not comparable.

One distinction affects how every report is read. The report_ccopt_* reports use the clock tree timing engine, which is the model CTS itself used. report_ccopt_clock_trees and report_ccopt_skew_groups recalculate timing by default, and report_ccopt_clock_tree_structure shows timing details only with -update_timing. The timing reports of timeDesign and the clock reports of report_clock_timing use the common timing engine. The reference does not say how closely the two engines agree (not verified), so compare them once, and treat the common engine as the one that feeds the stage decision.

9.4 Checks and command cards

9.4.1 Pre-stage checks

ccopt_design -check_prerequisites
check_design -type cts -out_file <report_file>
get_ccopt_clock_trees
get_ccopt_skew_groups
get_ccopt_delay_corner

The reference states that check_design -type cts cannot run on the database straight after place_opt_design, and needs the CCOpt options set and the specification loaded. If the block uses UPF, CTS also needs always-on buffers and inverters in its cell lists so that it can buffer across switched domains. That check is not applicable to a flat single-supply block, and the status table in Section 9.6 marks it so. For the clock_opt_design flow the prerequisite check is clock_opt_design -check_cts_config.

9.4.2 Post-stage checks

ccopt_design
ccopt_design -cts
report_message -errors -count
report_message -warnings -count

report_ccopt_clock_trees -summary
report_ccopt_clock_trees -file <report_file>
report_ccopt_clock_trees -histograms
report_ccopt_clock_tree_structure -file <report_file>
report_ccopt_clock_tree_drv -num_nets all -file <report_file>
report_ccopt_clock_tree_drv -drv_types {transition max_cap max_source_to_sink_net_length}

report_ccopt_skew_groups -summary
report_ccopt_skew_groups -file <report_file>
report_ccopt_skew_groups -summarize_stage_depth {buffer inverter}
report_ccopt_pin_insertion_delays -file <report_file>

reportRouteTypeConstraints -summary
reportRouteTypeConstraints -detailed -file <report_file>
report_route -clock
report_route -ndr
report_route -shield
dbGet -p1 top.nets.isCTSClock 1

checkPlace <report_file>
checkPlace -inst <instances>
refinePlace
report_ccopt_cell_halo_violations -summary
cts_refine_clock_tree_placement

timeDesign -postCTS -outDir <dir>
timeDesign -postCTS -expandedViews -outDir <dir>
getAnalysisMode
get_clocks -filter "is_propagated_clock == true"
get_propagated_clock -clock <clock>
report_clock_timing -type summary

timeDesign -postCTS -hold -outDir <dir>
optDesign -postCTS -hold -outDir <dir>
optDesign -postCTS -hold -holdVioData <file>
getOptMode -opt_hold_target_slack

report_analysis_coverage -verbose {violated untested}
report_analysis_coverage -check_type {clock_gating_setup clock_gating_hold} -verbose {violated untested}
report_clock_gating_check

9.5 Required reports, artefacts and how to read them

Evidence classes follow the earlier chapters. Preliminary means useful for direction but built on estimates. Implementation means measured on the implemented database at this stage. Signoff means produced by signoff extraction and signoff timing, which this chapter never claims. Post-CTS timing uses early-route parasitics, so it is preliminary for any value that depends on the final routes.

Clock power comes from report_power -clock_network all, which reports the power of the clock networks including generated clocks. Adding -count_seq_elements_in_clock_network includes the leaf flop power. The value depends on the switching activity and the analysis setup, so use it to compare runs made with the same settings, not as a pass or fail number.

report_ccopt_skew_groups -summary             ## illustrative layout, ccopt_design -cts
Skew group  Corner            Min ID   Max ID   Skew    Target  Sinks
clk/func    slow:setup.late   0.388    0.411    0.023   0.040   48
clk/func    fast:hold.early   0.201    0.236    0.035   -       48
clk/scan    slow:setup.late   0.392    0.470    0.078   0.040   21

**WARN: (IMPCCOPT-1437): Found 6 clock tree instances which are
user dont_touch and are not resizable - this can impact clock QoR.

The numbers are illustrative, in nanoseconds. The layout is simplified and omits the Skew Target Type column, and the example is read as a run of ccopt_design -cts, where the skew target is enforced. A dash means the corner has no numeric target, which is the reference default for the hold early half. Read the table row by row. The functional group has 48 sinks, which matches Figure 12, and its skew of 0.023 ns is inside the 0.040 ns target in the setup late corner. In the hold early corner it shows 0.035 ns with no target, so there is nothing to meet there and you judge it against your hold budget. The scan group has a skew of 0.078 ns against the same target, so it misses its target even though CTS completed without an error. The warning is a separate finding. Six clock instances are protected from resizing, which can limit how well CTS balances the groups they feed, and it is a likely reason for the scan result.

9.6 Healthy, suspicious and hard-stop examples

9.7 Debugging, corrective action and reruns

Work from the clock outwards. Start with propagation and sink membership, because a clock that does not reach its flops makes every later number meaningless. Then read skew and insertion delay, then DRVs, then routes, and only then post-CTS timing. A timing failure that appears only after CTS is usually a clock problem, and fixing it in the datapath treats the symptom.

When a card fails, rerun from the earliest affected card. A change to the specification or to a CTS property needs the whole chapter again, because CTS rebuilds the tree. A route type is a CCOpt property, so changing it also needs the whole chapter. A legalisation fix needs C-03 to C-09 only. Keep the report from the failing run next to the report from the fixed run, so that the improvement is shown rather than assumed.

9.7.1 Worked example: a clean run of ccopt_design -cts with a scan skew group that misses its target

Suppose C-02 shows no errors, and C-03 shows both clock trees with the expected sink counts and no clock DRVs. C-04 then gives the summary in Section 9.5: the functional group is balanced and the scan group is not. The CTS warning about six non-resizable clock instances is the first lead. Compare the sinks at the ends of the min and max paths of the scan group, which the full skew group report lists with their pin names, against the instances the warning names. The warning says only that those instances cannot be resized, so check whether the late sinks sit behind one before blaming it. In a full ccopt_design run the same skew would not be a failure by itself, because CCOpt schedules useful skew.

The decision for C-04 is HARD STOP. The fix belongs to whoever owns the protection: allow resizing with the dont_touch value that permits it, or move the affected sinks out of the group or mark them as ignore pins if the specification allows it. Then restore the pre-CTS database and rerun from C-01. Note that the numbers in this example are illustrative, and your project budget decides what skew is acceptable.