Clock Tree Synthesis, Post-CTS Optimization, Checks and Handoff: build, then judge

Why this chapter matters in a real project

Until clock tree synthesis (CTS), every timing number assumed an ideal clock. That clock reaches every register at the same moment and costs nothing. CTS replaces it with real buffers, inverters and wires. From then on, each register has its own clock arrival time, and every setup and hold slack can move.

Mistakes here are expensive in both directions. A wrong skew group or a missing sink gives clean reports for the wrong problem. The real violation then appears after routing, when a fix means a rebuild. A report read in the wrong view, or about the wrong candidate, gives false violations. Those send you into repairs that change nothing, or that make hold worse.

This chapter therefore treats CTS as an evidence task. We configure one thing at a time and read it back. Then we build once and judge the result with reports that each answer one question.

Prerequisites

• Placement, Pre-CTS Optimization, Checks and Handoff: the accepted placed checkpoint and its handoff record are our starting point.
• Design Data Preparation, Import, Sanity Checks and Export: you know what constraint modes, delay corners and analysis views are.
• Floorplanning: you know what a macro channel and a halo are.
• Understanding the Innovus Environment and Session: you can restore and save a design and read the log.
• You do not need to know how the CTS engine works inside. We read its stages from its outputs.
• You do not need to know routing or signoff timing. This chapter stops before both.

Learning objectives

1. Explain what CTS changes in a database, what it leaves alone, and which evidence shows each change.
2. Read a clock circuit, a clock tree and a skew group, and tell them apart.
3. Read setup, hold, gating and generated-clock timing on aligned waveforms, with the sign of skew.
4. Set each clock setting with a native command, read it back, and state what it costs.
5. Select between ccopt_design, ccopt_design -⁠cts and clock_opt_design from the input database.
6. Read the clock reports and the post-CTS timing reports, and state what each one does not prove.
7. Apply a debugging pattern that goes from a symptom to a confirmed cause, starting from the right saved state.
8. Decide in four independent assessments whether the result is ready for routing, and hand it over with its evidence.

Figure 1 puts the whole chapter on one page. Come back to it whenever you lose your place.

CTS on one page

From an ideal clock to a reviewed candidate that routing can start from

What to notice: A change returns to a saved state and rebuilds, as in Figure 2, and handoff needs all four assessments to be PASS or WAIVED (see the acceptance section).

Before you start

The starting point is the accepted placed checkpoint from Placement, Pre-CTS Optimization, Checks and Handoff. It has a legal placement, pre-CTS optimization done, a handoff record, and the clock assumptions written down. We do not repeat placement here.

1  Where clock tree synthesis fits

Until now, every timing number in the flow assumed an idealized clock. CTS builds the real clock network. That network is made of cells and wires that carry the clock from its source to every register. After CTS each register has its own clock arrival time, so setup and hold slacks change. The new cells and wires also become something routing must respect.

1.1  The handoff from placement

We use the package as our input, but we do not trust it blindly. You restore the checkpoint and run the readiness checks of the next section on what was actually restored.

1.2  What CTS changes and what it leaves alone

Functional clock cells that already exist stay in the design. Examples are clock gates and dividers in the netlist. CTS builds and sizes the distribution network around them.

1.3  Three construction commands

The input database decides the choice. Our checkpoint came from place_design and optDesign -⁠preCTS. It is not a PODV2 database, so clock_opt_design rejects it.

The chapter follows one sequence: configure, build, inspect, diagnose, hand off. Figure 2 draws that sequence as one picture.

The CTS flow of this chapter

From the accepted checkpoint to routing, with the return path for every change

What to notice: Every return goes back to Build from a saved state, the configured or baseline checkpoint, never from the current database.

2  Is the placement ready for CTS?

Each row of Table 3 has one evidence source and one blocking condition. Give each row one of four words, shown in Figure 3. A missing report is never a pass. It is NOT RUN. Acceptance at the end of the chapter adds a fifth word, WAIVED, for a known failure with an approved exception.

The four words for a readiness row

Each check gets exactly one word

What to notice: Missing evidence is NOT RUN, never PASS, and you build only when every row is PASS.

3  Clock concepts the tool works with

Every clock command and every clock report uses a small vocabulary. Two words in it, clock tree and skew group, are easy to confuse. Mixing them up is behind many wrong repairs. Let us define each word on one small circuit first. The commands come later.

3.1  One small circuit for the whole chapter

The divider's own clock pin is a fourth thing. It is an electrical load on the tree, not a sink. The tool treats it as the start of the generated clock, so it is not among the 3803.

3.2  The constraints behind the circuit

# Function mode: the divider output is a generated clock, mux selects I0.
create_clock -name clk_core -period 2.5 [get_ports clk_core]
create_generated_clock -name gclk_div2 -source [get_ports clk_core] \
    -divide_by 2 [get_pins u_div/Q]
set_case_analysis 0 [get_pins u_clkmux/S]
# Scan mode (a separate constraint mode): slower clock, mux selects I1.
#   create_clock -name clk_core -period 10 [get_ports clk_core]
#   set_case_analysis 1 [get_pins u_clkmux/S]

The skew groups below follow this contract. They are the pattern for this example, not a rule for every design. Figure 4 draws the circuit.

3.3  Words you will meet

A clock source is where a clock enters the design or is created. Examples are a port, a phase-locked loop (PLL) output or a divider output. The root is the pin where the tool starts building. A sink is a pin that needs the clock edge to work. Examples are a register clock pin, a latch enable or a macro clock pin. A pin that only passes the clock on is not a sink.

A clock tree is the network between a root and its sinks. It is made of buffers, inverters, gates, nets and wires. It is a physical object.

A skew group is different. It is a balancing rule: a list of sinks plus a target for how alike their arrival times should be. By default the tool makes one skew group per clock per constraint mode. The clocks come from the SDC constraints, the standard timing-constraint format. So function-mode clk_core and scan-mode clk_core use one tree and two skew groups. Table 5 lists the three groups of the example.

The running example as a circuit

One clock port, four kinds of load, a divider and a clock mux

What to notice: u_clkmux selects I0 (the divided clock) in function mode and I1 (the bypass) in scan mode; data connections and the divider feedback are omitted.

The generated-clock group only reports. It does not take the 600 registers away from the master group. The master group clk_core/func still balances them with the other 3203 sinks, because their clock comes from clk_core through the divider.

This is the standard pattern for a generated clock. The generated group is non-constraining, and the master group balances the downstream sinks. The memberships add to 3803 + 3803 + 600 = 8206, but the design has only 3803 distinct sinks. If you want the divided branch balanced by a different rule, name the group that constrains it. A reporting-only group never does. Figure 5 shows the difference between the tree and the groups.

Insertion delay, also called latency, is the delay from a clock source to a sink. Source latency is the part before the network, such as PLL or board delay stated in the constraints. Network latency is the part the tree provides. A register sees both.

A clock tree is not a skew group

One tree above; below, the sinks that each skew group counts

What to notice: The u_io flops are in clk_core/func through I0, in clk_core/scan through I1, and in the reporting-only gclk_div2/func.

Slew, or transition time, is how long an edge takes to move between its limits. Slow clock edges make downstream delay uncertain and can fail a minimum pulse width.

A clock gate switches a clock off with an enable, so the registers behind it stop toggling and save power. A generated clock is made from another clock by logic, such as a divider. A mux may select between clocks. Clocks with a fixed phase relation are related. Clocks without one are unrelated.

An ideal clock reaches each sink at its declared latency and ignores the network. In our simplified example every ideal arrival is 0.00 ns. In general, declared latencies, generated-clock phase and early-clock flows can make ideal arrivals differ. A propagated clock arrives after the real delay of real cells and wires. Figure 6 compares the two on one edge.

The same edge, ideal and propagated

Zoom on the first rising edge only, -0.1 to 0.9 ns; the period is 2.5 ns

What to notice: Propagated arrivals differ: here the spread is 0.69 − 0.62 = 0.07 ns.

3.4  Why a clock-gate check is tight

An ICG compares its enable with the clock at the gate. The gate sits early in the tree, so its clock edge arrives early. The enable comes from an ordinary register whose clock arrives later. The enable therefore has less time than the register clock suggests.

A library ICG states both as setup and hold times of the enable pin. Both are measured against the clock edge at its CK pin. Setup uses the latest enable arrival, and hold uses the earliest.

The hold side needs the earliest arrival, which is a different path. The figure draws the earliest change at 0.85 ns. That is 0.64 + 0.21 with no logic delay at all. It assumes the same launch-clock arrival, the same clock-to-Q and a minimum logic and wire delay of zero. With those fixed assumptions, any nonnegative logic or wire delay moves the change later.

It is not a bound on a real hold view, which has its own minimum clock arrival and clock-to-Q. The hold region is therefore qualitative here. A numeric gating hold slack needs your design's minimum clock arrival, clock-to-Q and logic delay. It also needs the library hold time of the ICG.

A gating check on waveforms

The enable register, its logic, the ICG fed from the clock tree, and three waveforms on one axis from 0 to 3 ns

What to notice: Setup slack is 2.71 − 2.45 = 0.26 ns, while the hold side shows only an illustrative earliest change, not a measured minimum.

3.5  Generated clocks and muxes

A divider output starts a generated clock tree. The tool builds it from the divider's output pin. It also makes a reporting-only skew group for it. The divider's own clock pin remains an electrical load on the master tree. See Figure 8 for the master and the divided clock on one axis.

A mux in a clock path makes one sink reachable by two clock paths. If the two are never active together, each mode's skew group ignores the input that is inactive in that mode. If both can be active, the sink belongs to two constraining groups and must satisfy both.

Master and divide-by-2 clocks

A divider flop with its inverted output fed back to D, and both clocks on one time axis

What to notice: gclk_div2 has twice the period, 5.0 ns against 2.5 ns, and its rising edges follow every second master edge after the divider delay of 0.22 ns.

Thus, a tree is a set of cells, and a skew group is a rule about arrival times. Skew is the difference between two arrivals. With this vocabulary we can set the first clock property.

4  Configure clock cells, targets and corners

The tool builds the tree from the cells the designer allows, to the targets given, in the corner named first. If a choice is left open, the tool typically picks a default that might not suit the library. This section sets one thing at a time. Each setting has a command, a readback and a few lines on what it means.

innovus> restoreDesign accepted_place.enc.dat stream_acc ;# load the accepted placement

When you later compare two CTS candidates, start both from this same checkpoint. Read them with the same reports in the same views. A difference between candidates means little if the starting state or the reports differ.

After each set_ccopt_property below, read the value back. A setting you did not read back is only a setting you intended.

A property has a name, a value and sometimes an object it applies to. Selectors name the object: -⁠net_type, -⁠pin, -⁠skew_group, -⁠clock_tree, -⁠inst, -⁠cell, -⁠delay_corner. To learn what a property means, ask the tool. get_ccopt_property -⁠help with the property name shows its valid values and where it applies.

4.1  Main settings

These are needed for the main run.

Primary delay corner

innovus> set_ccopt_property primary_delay_corner dc_slow ;# build against the slow corner
innovus> get_ccopt_property primary_delay_corner ;# read the corner back

• Meaning: transition and skew limits are judged in this corner first.
• Choice: use the corner that dominates setup. The default is the corner of the first setup view you gave to set_analysis_view, so name it when several exist.
• Trade-off: a corner that is not dominant builds a tree that is good where it matters less.

Buffer cells, inverter cells and clock gate cells

innovus> set_ccopt_property buffer_cells \
    {CKBUF_X6 CKBUF_X8 CKBUF_X12 CKBUF_X16} ;# clock buffers allowed
innovus> set_ccopt_property inverter_cells \
    {CKINV_X6 CKINV_X8 CKINV_X12 CKINV_X16} ;# clock inverters allowed
innovus> set_ccopt_property clock_gating_cells {ICG_X4 ICG_X8 ICG_X12} ;# clock gates
innovus> get_ccopt_property buffer_cells ;# read the buffer list back
innovus> get_ccopt_property inverter_cells ;# read the inverter list back
innovus> get_ccopt_property clock_gating_cells ;# read the clock gate list back

• Meaning: listing a cell overrides its dont_use mark, so check that every listed cell is one you want.
• Choice: use clock-quality cells with balanced rise and fall delay. Keep each list short, about five cells at most. Do not exclude small sizes only to force bigger ones.
• Trade-off: a longer list gives freedom and costs runtime. The largest cells can raise clock power and electromigration load.
• Availability: a clock gate list matters only for a design that has clock gates to build or resize. A design with none needs no gating cell list.

innovus> report_ccopt_cell_filtering_reasons -cell_type buffer \
    -file filter_buf.rpt ;# write why buffers were filtered out

The filtering report names why the tool dropped a listed cell. The reason "Not available in all views" points to a library or view problem. The reason "Weak max cap cell" means the cell cannot drive copies of itself at the clock frequency. Choose a stronger cell then.

Inverter preference

innovus> set_ccopt_property use_inverters auto ;# let the tool choose
innovus> get_ccopt_property use_inverters ;# read the preference back

• Meaning: valid values are auto, true and false.
• Choice: auto lets the tool decide. Inverter pairs can give lower delay or power in some technologies.
• Verify: look at the cell names in report_ccopt_clock_tree_structure.

Transition targets for top, trunk and leaf nets

innovus> set_ccopt_property -net_type top   target_max_trans 150ps ;# top nets
innovus> set_ccopt_property -net_type trunk target_max_trans 150ps ;# trunk nets
innovus> set_ccopt_property -net_type leaf  target_max_trans 100ps ;# leaf nets, sharpest
innovus> get_ccopt_property -net_type leaf target_max_trans ;# read the leaf target back

• Meaning: the largest transition the tool aims for on that kind of net.
• Choice: leaf nets drive sinks and usually need the sharpest edge. Trunk and top nets can be looser. Take the numbers from your library and clock period.
• Trade-off: too tight means more cells, more power and more runtime. Too loose means slow edges and less gating margin.
• Verify after the build: report_ccopt_clock_trees -⁠histograms -⁠file trees_slew.rpt shows the transition spread per net type.

Skew target, and when it applies

innovus> set_ccopt_property target_skew 80ps ;# global skew target
innovus> get_ccopt_property target_skew ;# read the target back

• Meaning: ccopt_design -⁠cts builds toward this skew. Full ccopt_design does not use the global value as its closure objective, because useful skew scheduling decides the arrival times.
• Choice: in the main flow, state a bound only where you need one, on a named skew group. Those groups do not exist until the specification creates them, so those commands live in the specification section, with their trade-off.
• Trade-off: a tight target costs cells and power. It buys little if the data path cannot use it.
• Verify: report_ccopt_skew_groups has a column that shows which target applied. An unmet global target after a full run is not a defect by itself.

Macro clock pin insertion delay

innovus> set_ccopt_property -pin u_buf_a/CK insertion_delay 0.35ns ;# RAM A offset
innovus> set_ccopt_property -pin u_buf_b/CK insertion_delay 0.35ns ;# RAM B offset
innovus> set_ccopt_property -pin u_coef/CK insertion_delay 0.35ns ;# ROM offset
innovus> get_ccopt_property -pin u_buf_a/CK insertion_delay ;# read one offset back
innovus> report_ccopt_pin_insertion_delays -file pin_offsets.rpt ;# list all offsets

• Meaning: this is CTS compensation. The tool arrives at these pins 0.35 ns earlier, so that the clock reaches the macro's internal registers together with the others.
• Choice: set it only if the constraints and the library do not already carry the delay. Two places that both apply it count it twice.
• Not the same thing: the compensation moves where CTS aims. It does not prove that the timer's macro timing model contains the same internal clock delay. Check the model separately, and decide once where the 0.35 ns lives.
• Trade-off: a wrong value shifts the macro's real arrival by the error.

Common path pessimism removal

innovus> setAnalysisMode -cppr both ;# credit shared clock path in setup and hold
innovus> getAnalysisMode -cppr ;# read the setting back

• Meaning: the timer gives credit for the shared part of the launch and capture clock path, in setup and hold.
• Choice: load the post-CTS constraints with this on and with clocks not yet propagated. CCOpt then makes the clocks propagated.
• Verify: getAnalysisMode -⁠cppr prints the setting. The exact text it prints differs between installations, so read it for both.

4.2  Advanced and study settings

Skip these on your first run.

Insertion delay limit

innovus> set_ccopt_property auto_limit_insertion_delay_factor 1.5 ;# cap global growth

• Meaning: CCOpt first computes the maximum insertion delay over all skew groups. This factor multiplies that initial maximum. Scheduling may not grow the global maximum beyond the result. The default is 1.5.
• Not a per-sink rule: it is not 1.5 times a given sink's own shortest clock path. A sink can sit far above or below that value, as long as the global maximum stays inside the limit.
• Choice: lower it to limit useful skew and shorten clock paths.
• Verify: the constraint window in report_ccopt_worst_chain.

Useful skew effort

innovus> setOptMode -opt_skew_ccopt standard ;# default effort
innovus> getOptMode -opt_skew_ccopt ;# read the effort back

• Meaning: none, standard or extreme.
• Choice: extreme raises runtime a lot. Pair it with a high flow effort, and use it only when standard leaves setup failing.
• Flow applicability: see the strategy table in the section on other ways to build a clock tree.

Balance mode (study only)

innovus> set_ccopt_property balance_mode cluster ;# stop after clustering

• Meaning: cluster, trial or full. full is the default.
• Choice: use a study mode only to look at sink clustering or virtual delays. The optional pre-CTS work section shows the standard pair of commands.
• Trade-off: a study candidate is not a result you hand off. Return to the saved baseline, or set balance_mode full, before the real build.

4.3  Views and modes

The tool derives its clock constraints from the multi-mode setup. Load the constraints you intend to close with, with the clocks still ideal, before the specification exists.

In the example, dc_slow is the setup corner and dc_fast the hold corner. The views are av_func_slow for setup, and av_func_fast and av_scan_fast for hold. These are the illustrated case, not a law. Confirm your own dominant corners, including temperature inversion and any advanced variation modeling.

A restored checkpoint normally carries its own views. In the example, the setup list holds one view, the functional one. The hold list holds the functional and scan views. So the example analyzes scan hold. It does not analyze scan setup. No scan setup result in this chapter would exist unless you add a scan setup view.

set_analysis_view selects views that are already defined. It does not create modes, corners or views. If a needed one is missing, define it first with the multi-mode commands of your flow: create_constraint_mode, create_delay_corner, create_analysis_view. Then select. The command is not incremental, so give the complete lists:

innovus> set_analysis_view -setup {av_func_slow} \
    -hold {av_func_fast av_scan_fast} ;# full setup and hold lists, not additions

Thus, each CCOpt setting is applied, read back and judged against the plan before anything is built. Next we turn to the clock wires, which the router treats like any other net unless the designer says otherwise.

5  Clock net types and clock routing rules

The clock is the most sensitive net in the design. A small change in its wire resistance or coupling moves the arrival time of thousands of registers together. A router treats a clock net like any other net unless the designer says otherwise.

A non-default rule (NDR) asks for wider wires, more spacing or special vias. It uses routing resources that signals also want. Let us first look at the three kinds of clock net, then at the rules attached to each kind.

5.1  Leaf, trunk and top nets

Conceptually the top nets are the upper part of the trunk. The native query, however, treats the three kinds as separate categories. get_ccopt_clock_tree_nets -⁠net_types trunk returns trunk nets that are neither leaf nor top. Count the three kinds separately and add them. Do not expect the trunk query to include the top nets.

Figure 9 uses the invented threshold routing_top_min_fanout = 2000. A net that feeds 2400 sinks through lower buffers is a top net. A net that feeds 800 sinks is a trunk net. A net that touches a register clock pin is a leaf. The wires carry the route type policy of the next subsection.

Leaf, trunk and top nets on a connected tree

One direct-load subnetwork drawn as a circuit; the divider and u_io branch are omitted, and the short port net is top as well

What to notice: A net that touches a sink is a leaf even if it is drawn high up, and only nets with more than 2000 sinks behind them are top.

innovus> foreach t {leaf trunk top} { ;# count the built nets of each kind
    puts "$t nets: [llength [get_ccopt_clock_tree_nets -net_types $t]]"
}

The same -⁠net_types filter exists on get_ccopt_clock_tree_cells.

5.2  Why wider and farther apart

Figure 10 draws three clock rules on the same tracks. Let us first see why each one helps.

Both reduce the variation of clock delay. Variation is what turns a balanced tree into a skewed one in silicon. A shield is a grounded wire laid beside the clock wire. It replaces switching neighbors with steady ones, and it costs the most routing resource.

Default, wider-and-farther, and shielded clock wire

The same seven tracks on one routing layer, t0 to t6, drawn three times at one scale

What to notice: The wider rule empties t2 and t4, shields sit on t1 and t5 (the trunk rule only), and the signals that moved away are the cost.

5.3  Layers and vias

innovus> puts [dbGet head.layers.name] ;# print every layer name

The layer names in this section (M4 to M7) are placeholders. Replace them with your technology's names. A range such as M4:M7 is valid add_ndr syntax for all layers from M4 to M7, not only the two named layers.

Wider wires need vias that fit them, so the rule command can generate vias for the changed widths. A tall via stack from a driver pin up to the clock layers adds resistance. Route types therefore offer a minimum stacked-via layer and a preference for multi-cut vias.

5.4  The policy, one command at a time

Each command below does one thing. Doing one does not do the next.

innovus> add_ndr -name CTS_2W2S -width_multiplier {M4:M7 2} \
    -spacing_multiplier {M4:M7 2} -generate_via ;# double width and spacing
innovus> add_ndr -name CTS_2W1S -width_multiplier {M4:M5 2} \
    -generate_via ;# double width, default spacing

• CTS_2W2S: double width and double spacing over the range M4:M7. Used for trunk and top.
• CTS_2W1S: double width, default spacing. Used for leaf, where shielding thousands of nets would cost too much.

innovus> create_route_type -name cts_trunk -non_default_rule CTS_2W2S \
    -top_preferred_layer M7 -bottom_preferred_layer M6 \
    -shield_net VSS ;# trunk: M6 and M7, shielded by VSS
innovus> create_route_type -name cts_leaf -non_default_rule CTS_2W1S \
    -top_preferred_layer M5 -bottom_preferred_layer M4 ;# leaf: M4 and M5

The recommended practice is one layer pair per kind, one horizontal and one vertical. The tool's estimates then correlate with the final route. Here trunk uses M6 and M7, and leaf uses M4 and M5.

innovus> set_ccopt_property routing_top_min_fanout 2000 ;# top above 2000 sinks
innovus> set_ccopt_property -net_type top   route_type cts_trunk ;# top nets
innovus> set_ccopt_property -net_type trunk route_type cts_trunk ;# trunk nets
innovus> set_ccopt_property -net_type leaf  route_type cts_leaf ;# leaf nets

innovus> get_ccopt_property -net_type top   route_type ;# expect cts_trunk
innovus> get_ccopt_property -net_type trunk route_type ;# expect cts_trunk
innovus> get_ccopt_property -net_type leaf  route_type ;# expect cts_leaf
innovus> get_ccopt_property routing_top_min_fanout ;# expect 2000

innovus> exportNdr CTS_2W2S -lef ndr_CTS_2W2S.lef ;# trunk rule as LEF
innovus> exportNdr CTS_2W1S -lef ndr_CTS_2W1S.lef ;# leaf rule as LEF

A rule that exists is not a rule that was used, and one clean net is not all nets. Until you have looked at actual wires, the claim "routing policy applied" is not established. The report map in the clock reports section lists these two commands.

5.5  Macro channels and halos

Clock trunks may need to cross the channel between two macros. A channel has a limited number of routing tracks. Signals use most of them, and the clock rule takes more than a default wire would. Figure 11 shows the squeeze.

Clock wires in a macro channel

Two macros, the channel between them, one shielded trunk clock wire and the signal wires

What to notice: The halo strips stop standard cells, not wires, so the channel keeps all of its tracks for routing.

Each of these is an experiment. Restore the accepted checkpoint, change one thing, rebuild, and compare with the same reports.

For a rule that comes from the technology LEF, modify_ndr cannot change it in the session. In this guide the NDR is settled before routing, because a rule changed afterwards means rebuilding the clock routes.

Thus, a routing rule is a trade: the clock gains a steadier path, and signals lose tracks. The tool still needs a description of the clock network before it builds anything. We read that description next.

6  The clock tree specification

Before it builds anything, the tool writes down what it believes the clock network is. That covers which trees, which skew groups, which pins are sinks and which are not. The build then follows that description.

If the description is wrong, the tree is built correctly for the wrong problem. A sink is left out, a gate is balanced with the wrong registers, or a divider is counted as a sink. Reading the specification costs minutes. The same fault found after the run costs a full rerun.

6.1  What the specification contains

When you ask for the file, it also holds comments that record why the tool set some constraints. Those comments are not stored if you let the tool extract the specification directly, without a file.

6.2  Derived, inspected and changed: three different acts

The reason for that preference is simple. An ignore pin stops the clock tree from tracing past a point, but a timing report still propagates the clock through it. A change made only in the specification makes CTS and the timer disagree about the network.

6.3  Creating it, once

# Write the specification to a file instead of applying it directly.
innovus> create_ccopt_clock_tree_spec -file ccopt_spec.tcl ;# derive and write the spec
# Apply it. Source it ONCE per session.
innovus> source ccopt_spec.tcl ;# create the trees and skew groups in the session

Source the file only once. A second source fails with a message that clock trees are already defined. A tree name returned by get_ccopt_clock_trees after this step means the specification object exists. It does not mean any clock cell or wire was built. Evidence that CTS was built comes later, from the structure reports.

6.4  What the file looks like

create_ccopt_clock_tree -name clk_core -source clk_core -no_skew_group
create_ccopt_generated_clock_tree -name gclk_div2 -source u_div/Q \
    -generated_by u_div/CK
create_ccopt_skew_group -name clk_core/func -sources clk_core -auto_sinks
create_ccopt_skew_group -name clk_core/scan -sources clk_core -auto_sinks
create_ccopt_skew_group -name gclk_div2/func -sources u_div/Q -auto_sinks
modify_ccopt_skew_group -skew_group clk_core/func -add_ignore_pins u_clkmux/I1
modify_ccopt_skew_group -skew_group clk_core/scan \
    -add_ignore_pins {u_clkmux/I0}
set_ccopt_property constrains -skew_group gclk_div2/func none

Now follow the 600 u_io registers through these lines. In function mode their clock comes from clk_core through the divider and mux input I0. The master group clk_core/func has -⁠auto_sinks, and the generated group is non-constraining. So the master group balances those 600 registers together with the other 3203 sinks, 3803 in all.

gclk_div2/func lists the same 600 so you can read their divided-domain latency, and it constrains nothing. The line to check in your own specification is exactly this one. Does a constraining group hold the sinks behind each generated clock?

6.5  Restricting skew on one named group (advanced)

Now that the groups exist, you can set a bound on one of them. In full ccopt_design, a group target alone is not a hard limit throughout the optimization. The standard way to carry it into the full flow is to set the target and the constraint scope together:

innovus> set_ccopt_property -skew_group clk_core/func target_skew 80ps ;# group bound
innovus> set_ccopt_property -skew_group clk_core/func constrains all ;# make it binding
innovus> get_ccopt_property -skew_group clk_core/func target_skew ;# read the bound
innovus> get_ccopt_property -skew_group clk_core/func constrains ;# read the scope

• Meaning: the value 80 ps is illustrative. constrains all makes the group a constraint for the whole optimization, not only a reported goal.
• Trade-off: a hard group bound limits what useful skew scheduling may do. Apply it only where a block really needs it, and expect fewer setup gains.
• Do not apply it to a reporting-only group. That group is meant to balance nothing.

6.6  Sink types: stop, ignore, exclude

# Example only: the pin name is invented.
# Run before create_ccopt_clock_tree_spec.
innovus> set_ccopt_property -pin u_test/jtag_clk_reg/CK sink_type ignore ;# not balanced

6.7  Other exceptions and what they mean

For a macro, if the constraints do not state its internal clock delay, give it with set_ccopt_property -⁠pin and insertion_delay. A positive value says the macro needs the clock earlier by that delay. The reports are report_ccopt_preserved_clock_tree_ports and report_ccopt_pin_insertion_delays.

In our example each macro has an invented internal clock path of 0.35 ns. With the 0.35 ns pin insertion delay, the tree reaches the pin about 0.35 ns before the registers. The clock inside the macro then arrives together with the register clock. If the value were omitted, the macro clock would arrive 0.35 ns late. The clock reports section shows the pin insertion delay report.

6.8  Shared clock and data, and clock tree convergence

A net that carries both clock and data confuses the tracing. So does a clock that fans back into a datapath through logic. If the SDC lets the clock propagate into a datapath, the tool finds huge numbers of reconverging clock paths. A missing case analysis is the usual cause.

• The tool checks for this when the specification is created. The check warns above 100 clock paths to any sink.
• report_ccopt_clock_tree_convergence lists the offenders.
• Fix it in the SDC with a case value or set_clock_sense -⁠stop_propagation, or with stop, ignore or exclude pins.

Do not build over it. The run is slow, and the tool does no datapath optimization.

6.9  Early clock flow and existing annotations

The placement stage may have used the early clock flow (setDesignMode -⁠earlyClockFlow true). Then the specification already exists, and the useful skew from place_opt_design is stored as annotations on it. Do not delete or regenerate that specification before ccopt_design. Deleting it loses the useful skew.

Our placement baseline did not use the early clock flow. So no annotation exists, and the specification is derived fresh. Record which case applies. After a specification change, update_clock_tree_spec_annotations can refresh the annotations. That command belongs to the early-clock-flow case.

6.10  What to check in the derived specification

innovus> get_ccopt_clock_trees ;# tree objects in the spec
innovus> get_ccopt_skew_groups ;# skew group objects in the spec
innovus> report_ccopt_clock_tree_convergence ;# clock paths that reconverge
innovus> ccopt_design -check_prerequisites ;# validate the setup, build nothing
innovus> check_design -type cts ;# CTS-related design checks

ccopt_design -⁠check_prerequisites and check_design -⁠type cts need the CCOpt targets set and the specification loaded. They cannot run on a pre-CTS database right after place_opt_design.

The names these queries return are specification objects. The membership of each group, meaning which sink pins are really active, is read after the build. Active sinks are updated only after the CTS timer runs. So do not use sink counts from get_ccopt_property with sinks now.

When you do read membership, keep the three counts of the concepts section apart. In our example the two constraining groups each hold 3803 sinks, and the reporting group holds 600. The memberships add to 8206, and the design has 3803 distinct sinks.

Matching totals do not prove matching members. For a group you doubt, compare its list of active sink pins with a list from an independent netlist query. Do not compare it with a list taken from the result you are testing.

6.11  Save the configured state (optional)

innovus> save_ccopt_config configured_ccopt_config ;# CCOpt settings to a folder
innovus> saveDesign configured.enc ;# the configured checkpoint

Thus, the specification is the last place where a wrong assumption costs minutes and not a rerun. Next we look at the work that can be done before the build, and then we run it.

7  Optional pre-CTS work

Sometimes the placed design is not ready for the clock tree. The macros might leave no room for clock cells. A clock gate might sit far from the registers it feeds. Or the datapath might have so little slack that skew scheduling needs every picosecond. This section lists the levers that exist before CTS, one rule that comes with them, and one way to look before committing.

7.1  Required and optional preparation

The previous sections already did what is required. Everything below is optional. Pull an optional lever only when evidence from the readiness check or from a study points to it. A lever tried "just in case" muddies every later comparison.

Repairing placement inside the CTS session and carrying on would hand CTS a placement that was never accepted.

7.2  Study first: look before you commit

innovus> set_ccopt_property balance_mode cluster ;# stop after clustering
innovus> ccopt_design -cts ;# CTS-only construction for the study

Read the log and the reports to see how far it went. A study candidate is not a clock tree you hand off, because it stopped early on purpose. When the study is done, return to the saved baseline, or set balance_mode full and rebuild, before the real construction. Do not continue the study candidate as if it were production.

7.3  The levers, and the symptom that justifies each

If you cannot name the evidence, do not pull the lever.

Thus, each lever moves the design before the build, and each one hands CTS a new placement that must be accepted again. If no lever is needed, we continue with the build.

8  Build the clock trees

One command now builds the clock network. It resizes and moves cells and makes the clock propagated. In the full flow, it also optimizes the data path around the new clock. Because the command is large, the preparation around it must be exact. You need the right start and the right command for the input. You also read the evidence before you judge the result. Building is not accepting. Acceptance is a separate decision, made at the end of the chapter.

8.1  Which command, for which input

-⁠outDir names the folder for the timing reports, -⁠prefix names the report prefix, and -⁠expandedViews asks for per-view reports. Without them, the reports land in a default folder under a name that does not say which candidate made them. A second candidate can then overwrite the first. (clock_opt_design spells its folder option -⁠out_dir.)

8.2  Run it

innovus> ccopt_design -check_prerequisites ;# validate the setup, build nothing
innovus> ccopt_design -outDir timing_ccopt -prefix cts \
    -expandedViews ;# build trees and optimize, per-view reports
innovus> saveDesign ccopt.enc ;# save the candidate under its own name

-⁠check_prerequisites validates the setup without building a tree. Keep the baseline checkpoint untouched. A second candidate then starts again from the baseline and gets its own name, folder and prefix. You can then compare the two with the same reports.

8.3  What to read in the log, in order

1. The prerequisites message, or the table that says why the command cannot run. Examples are a maximum transition target that is too low, or drivers that are too weak.
2. The per-stage summary the tool prints: slack and metrics. Its layout depends on your installation.
3. Messages with the IMPCCOPT prefix: cells, halos, preserved nets, targets.
4. The worst-chain report printed periodically. The most useful one is printed after the last skew adjustment and before re-clustering, usually the second to last.
5. The final lines and the elapsed time.

stage                      setup WNS (ns)   setup TNS (ns)   hold WNS (ns)
before ccopt_design        not shown        not shown        not shown
after clustering           -0.231           -41.7            -0.089
after skew scheduling       0.004             0.0            -0.061
after final optimization    0.012             0.0             0.021

The first row is not shown because this log layout prints no pre-CCOpt slack. Ideal-clock timing does exist: you have those numbers from placement.

In this illustration, setup and hold both improve through the displayed stages. Other candidates can trade setup against hold, so the final saved candidate still needs both analyses. The last row is not a verdict. The post-CTS timing section explains why it must be remeasured on the saved candidate.

Thus, the build is one command, but its start, its input and its evidence decide whether the result is usable. Next we look inside the command, so that its log and its cell names can be read.

9  Inside the CTS engine

The designer does not control the algorithm. The designer controls the inputs and reads the outputs. Even so, it helps to know the stages the tool goes through. Each stage leaves a different mark in the log and in the cell names. A failure at one stage typically looks different from a failure at another. The drawings here are concepts: only the stages are visible, not the methods inside them.

9.1  The stages

Figure 12 draws the stages as a strip.

The stages as a strip

Conceptual order, not a log

What to notice: The last card exists only in full CCOpt, and the virtual delays are a number on the graph until real cells replace them.

The command show_ccopt_cell_name_info lists the prefixes on your installation. These names are evidence. The prefix of a cell tells you which stage made it.

9.2  Placement, clustering and the first buffering

At the start, the sinks are where placement put them. The tool looks at their positions and groups the nearby ones. A group must be small enough that its driver can meet the transition target. The net must also meet the capacitance and length limits.

Each group gets a driver. The drivers in turn are grouped under drivers, up to the root. This is clustering, and it gives a tree whose shape follows where the sinks are. Figure 13 shows it with invented counts.

From placed sinks to a buffered tree

Three panels: placed sinks, clusters, and the tree of drivers beside a macro

What to notice: Clusters follow where the sinks are; here 48 sinks need 8 + 2 + 1 = 11 clock cells.

If clustering runs into a narrow channel, many blockages or a complicated power domain, the tree already shows large transition violations here. That is why you look at the clustering result first on a new design. This is the study of the optional pre-CTS work.

9.3  Constraint analysis, virtual delays and physical delays

After clustering, the tool knows roughly how long each sink's clock path is. The skew groups ask for those paths to be alike, within a target, or to differ by an amount the datapath wants. The tool works out how much delay each branch needs.

It does not insert a cell for every candidate. It writes the planned delay into the timing graph as a virtual delay and asks the timer what happens. A virtual delay is a number attached to a point of the graph. It is not a cell, it takes no area, and it vanishes when it is turned into real cells.

When the plan is settled, the implementation step turns each virtual delay into physical delay. That can be a different buffer size, a longer wire or an extra inverter pair. The refinement step then adjusts the built cells to the timing they really produce. Figure 14 shows one branch before and after.

A virtual delay and the cells that replace it

Top: a planned delay on the graph; middle: real cells; bottom: the two delays on one axis

What to notice: The dashed block takes no area, and the residual is 0.12 − 0.11 = 0.01 ns.

9.4  Useful skew, chains and windows

Zero skew is the usual picture of a good clock tree, but it is not what the datapath always wants. A path with too little time can borrow it from the next path. It does so by letting its capture register's clock come later.

CCOpt treats the launch clock, the capture clock and the datapath as adjustable at each sink. It always uses propagated timing. Its aim is to improve negative setup slack, specifically the worst slack of the high-effort path groups.

A chain is a sequence of register-to-register paths through which slack can be passed. The worst negative slack is limited by a chain, not by one path. A chain ends at a loop or at a port. A clock gate can be part of it, because moving a gate's arrival moves everything behind it. The tool reports the worst chain.

Useful skew moves a sink only inside its window. If a sink sits at the edge of its window, no amount of scheduling frees more slack for it. The datapath must give.

A later clock at F2 helps the path into F2 and costs the path out of F2. It also takes the same 0.125 ns from the hold slack of F1→F2 (see the post-CTS timing section).

Useful skew on one chain

The chain F1 to F3 and its capture edges on one zoomed axis, before (A) and after (B) the F2 clock moves

What to notice: Moving the F2 clock 0.125 ns later turns −0.100 and +0.150 into +0.025 and +0.025 ns, so slack moves from the later path to the earlier one.

9.5  Conceptual, not proprietary

The stages and cell prefixes above are what the tool shows you. The algorithms, the order of the internal sub-steps and the choice of cells are the tool's own. Use the stages to interpret what you see, never to predict a specific cell count. If two runs differ, the evidence is in the reports, not in a guess about the engine.

Thus, the stages help to interpret evidence, not to predict it. The reports that carry this evidence come next.

10  Reading the clock tree reports

Each report answers one question about the clock network and cannot answer another. A skew-group report, for example, tells how alike the arrival times are. It does not tell whether a data path meets timing. A clean design-rule report says nothing about hold.

This section pairs each native report with the question it answers and the fields worth reading. It also says what each report does not show. Every command here is an Innovus command. Give it a file name of your choice and read the file.

The two views can differ, and neither is wrong. They answer different questions.

10.1  The command map

Table 13 maps each engineering question to its native command. The five CCOpt reports that most often carry the story follow the table, with literal file names.

innovus> report_ccopt_skew_groups -include_reporting_only_skew_groups \
    -file skew_groups.rpt ;# balance per group and corner
innovus> report_ccopt_clock_tree_structure -update_timing -show_sinks \
    -file clock_structure.rpt ;# levels, cells and sinks
innovus> report_ccopt_clock_tree_drv \
    -drv_types {transition max_cap max_source_to_sink_net_length} \
    -file clock_drv.rpt ;# clock-network limit violations
innovus> report_ccopt_pin_insertion_delays -file pin_offsets.rpt ;# pin offsets
innovus> report_ccopt_worst_chain -file worst_chain.rpt ;# what limits useful skew

Run them on the candidate that is in memory, or restore the candidate you saved first. Name the candidate in your notes. A report without a candidate name is a report about an unknown design.

10.2  The skew-group report

• Question: how alike are the arrival times at the sinks of each group, in each corner?
• Command: report_ccopt_skew_groups -⁠include_reporting_only_skew_groups -⁠file skew_groups.rpt.
• Fields: per group and corner, the sink count, the earliest and latest insertion delay, the skew, the target and its type. It also gives the share of sinks inside the best window (occupancy). The type is explicit, auto computed, auto scaled or ignored.
• Scope: the CCOpt timing model, in the named corner. Check whether source latency is included.
• Limit: it does not say whether any data path meets timing. In full CCOpt an unmet global skew target is not a failure by itself.

Group           Corner   Sinks  MinID  MaxID  Skew   Target  Type      Occ.
clk_core/func   dc_slow   3803  0.612  0.668  0.056  0.080   explicit  100%
clk_core/func   dc_fast   3803  0.431  0.472  0.041  n/a     ignored   n/a
clk_core/scan   dc_slow   3803  0.620  0.684  0.064  0.080   explicit  100%
gclk_div2/func  dc_slow    600  0.331  0.376  0.045  n/a     n/a       n/a

Those 600 are also inside the 3803 of clk_core/func. That is why the rows do not add up to the number of sinks. This excerpt is the CTS-only alternative, where the global target applies. In the main full flow, read the group's constraint windows and the type column to see which target applied.

Reading a skew-group row

Rows of the report, with numbered markers tied to the question each column answers

What to notice: A sink count that differs from the specification is a coverage problem, not a skew problem.

10.3  The clock tree and structure reports

• Question: what did the tool build, and does it meet its own electrical limits?
• Commands: report_ccopt_clock_trees -⁠histograms -⁠list_special_pins -⁠file clock_trees.rpt and report_ccopt_clock_tree_structure -⁠update_timing -⁠show_sinks -⁠file clock_structure.rpt.
• Fields of the first: cell counts per tree, clock gates by depth, area and capacitance. It also has tables of slew, capacitance, fanout, length and resistance violations. The Clock Timing Summary compares each transition target with the measured value. A star marks a target not met.
• Fields of the second: levels from the root, cells with types, fanout per level, clock gates, sink counts and labeled macro sinks.
• Limit: they describe the tree, not the data path. Violation lists show only the top ten by default, so check the count before the list. The structure report uses the primary delay corner, and only its late or early half. A clean primary corner says nothing about other corners.

Clock Timing Summary
net type     target(ns)   measured max(ns)   met
top nets     0.150        0.141              yes
trunk nets   0.150        0.149              yes
leaf nets    0.100        0.097              yes

10.4  The clock-network design-rule report

10.5  The pin insertion delay report and the worst chain

• Question: which pins carry an offset, how large, and from where? What limits useful skew right now?
• Commands: report_ccopt_pin_insertion_delays -⁠file pin_offsets.rpt and report_ccopt_worst_chain -⁠file worst_chain.rpt.

Positive (advancing): 3 pins     mean 0.350     largest 0.350 (u_buf_a/CK)
Negative (delaying):  0 pins

The three macro clock pins carry the 0.35 ns offset set during configuration. The report lists offsets, not each sink's measured arrival.

A long tail of small, different offsets calls for an explanation. However, the size of the tail does not name the cause. Read the source recorded for each offset before you decide who put it there.

Do not mix up two things. An offset is CTS compensation. It is not proof that the timer's macro timing model carries the macro's internal clock path.

10.6  Halo and legality are two reports

It is not a placement legality check. Overlapping, off-site or unplaced cells come from checkPlace. Run checkPlace after CTS as well, and judge its result independently of the halo report. A design can pass one and fail the other.

10.7  The clock timing report

• Question: what are the clock latencies and skews as the timer sees them, with common-path pessimism removed?
• Command: report_clock_timing -⁠type skew -⁠nworst 4 and -⁠type summary. Set setAnalysisMode -⁠cppr both first.
• Fields: skew, latency and clock pin per entry, one entry per clock domain by default. In the report, r or f marks the transition at the register clock pin, and i marks inverted polarity.
• Limit: take a pair of registers in the same group, measured the same way. Their absolute pair skew cannot exceed that group's latest arrival minus its earliest.

A larger number usually means the report differs in clock, view, early/late derate, CPPR setting or timing model. Check what each number measures before comparing.

10.8  Membership, net types and routed wires

These three questions have their own native queries.

• Membership. Which pins are active sinks of a group? get_ccopt_skew_group_delay -⁠skew_group clk_core/func -⁠all_active_sinks returns a Tcl dictionary of active sink pins and their latencies, after the CTS timer has run. dict size of the result is the active sink count. In the example, clk_core/func and clk_core/scan each hold 3803, and gclk_div2/func holds 600.
• A matching total does not prove correct membership. For a group you doubt, compare its pin list with an independent netlist query.
• Net types. get_ccopt_clock_tree_nets -⁠net_types with leaf, trunk and top counts the built nets of each kind. The three categories are disjoint: the trunk query does not return the top nets.
• Routed wires. report_net_wires -⁠net with one clock net prints the regular wire topology of that net. Each edge shows an NDR and a width. report_via -⁠on_clock_nets -⁠detail summarizes single-cut and multi-cut vias on all clock nets.

Configuration readback says what you asked for. These two reports say what was drawn. A via total or a sample of 40 nets does not show that every clock net obeyed its rule. So state whether you looked at all of them or a sample. The exact output layout of these two commands is not confirmed here, so read it once on your design to learn it.

innovus> set d [get_ccopt_skew_group_delay -skew_group clk_core/func \
    -all_active_sinks] ;# dictionary of active sinks and latencies
innovus> puts "clk_core/func active sinks: [dict size $d]" ;# print the count
innovus> report_net_wires -net clk_core_trunk1 -file wires_trunk1.rpt ;# one net's wires
innovus> report_via -on_clock_nets -detail ;# via summary on all clock nets

Thus, every report is trusted only for the question it answers, in the corner and mode it names. Next we place the timing numbers next to these reports.

11  Timing after CTS

In our ideal-clock example, every register saw the clock at the same time before CTS. After CTS they do not, and each setup and hold check now contains a skew term. Let us consider what changes.

The computed slack values change. Not every slack must change, but any of them can. A beginner who reads only the worst slack misses what changed. This section shows the arithmetic, the sign convention, and the difference between a number, a count and a coverage statement.

11.1  What timeDesign -postCTS does

-⁠hold makes it analyze hold only. -⁠expandedViews writes one folder per view and restores views the tool pruned.

The wiring is mixed. The clock nets are routed as part of full CTS, so their delays come from clock routes. The signal nets have no detailed route yet, so their wire delays come from early global route and extraction estimates. Say so whenever you quote a post-CTS number.

innovus> timeDesign -postCTS -expandedViews -numPaths 200 \
    -outDir timing_setup -prefix post_setup ;# setup, one folder per view
innovus> timeDesign -postCTS -hold -expandedViews -numPaths 200 \
    -outDir timing_hold -prefix post_hold ;# hold, one folder per view
innovus> report_constraint -all_violators > violations.rpt ;# every violated check
innovus> report_min_pulse_width > pulse_width.rpt ;# clock pulse width checks
innovus> report_analysis_coverage -verbose {violated untested} \
    -sort reason > coverage.rpt ;# which checks were analyzed

The value 200 is a report-size choice. It limits how many paths are written. It is not a completeness threshold and not a recommended value for every design. The default is finite as well, so leaving the option out does not mean every failure is shown. Read the scope before you read the numbers.

Scope of the views. timeDesign reports the views that are active. In the example, the setup list holds the functional view only. The hold list holds the functional and scan views. So the setup numbers of this chapter are functional-mode numbers. Scan setup was not analyzed, and no result here says anything about it. To analyze it, define and select a scan setup view first.

11.2  Launch, capture, and the sign of skew

A setup check asks whether data launched at one clock edge arrives before the next capture edge. A hold check asks whether data launched at an edge does not arrive too early for the same edge's capture.

Let L be the launching register and C the capturing register, with clock arrivals tL and tC. With the convention of the concepts section, s = tC − tL. A positive s means the capture clock arrives later than the launch clock. Figure 17 draws one pair.

Launch, capture and the sign of skew

Registers L and C, and their waveforms on one time axis from 0.5 to 3.5 ns; period T = 2.5 ns

What to notice: The same skew s = +0.250 ns helps setup and costs hold: setup slack is 3.26 − 3.20 = +0.060 ns, and hold slack is 1.00 − 0.95 = +0.050 ns.

11.3  Setup, worked

Real checks use different corners. The setup slack is:

setup slack = T + s − tsu − us − tcq − tdmax

With zero skew, the slack is 2.500 − 0.080 − 0.050 − 0.210 − 2.350 = −0.190 ns. The path fails by 0.190 ns.

Now the CTS result gives tL = 0.640 ns and tC = 0.890 ns, so s = +0.250 ns. The setup slack is −0.190 + 0.250 = +0.060 ns. The path now passes, and the tool did not change the data path at all.

11.4  Hold, worked on the same pair

The same clock-to-Q applies, for simplicity.

Thus a later capture clock helps setup and costs hold by the same amount, here 0.250 ns. The two checks are on different edges and usually in different corners. The numbers above use one corner for clarity.

In our example the slow corner is used for setup and the fast corner for hold. That is the illustrated case, not a law. The dominant corner depends on the technology, temperature inversion and variation modeling, so confirm which views dominate. The sign of the effect is what carries over.

Hold is checked before CTS too. With ideal clocks it compares the shortest data path with the hold time and the uncertainty, and the skew term is zero. After CTS the skew term appears. Pre-CTS hold numbers are therefore provisional, not absent.

The waveform figure draws exactly these edges. Report columns may define skew with the opposite sign. Before you read a report, write down which clock each column subtracts from which, and map it to s = tC − tL.

11.5  Early and late, OCV and CPPR

A real analysis does not use one delay per cell. In a setup check, on-chip variation (OCV) analysis uses the late delay for launch and the early delay for capture. A hold check uses the reverse. Derates scale early and late delays.

The flow of this chapter sets setAnalysisMode -⁠cppr both. report_clock_timing then shows a column for the adjustment.

Common path pessimism removal on one shared buffer

The launch and capture clock paths share 0.500 ns before they split

What to notice: The credit is 0.525 − 0.475 = 0.050 ns, and only the common part earns it.

11.6  A number, a count and a coverage

The overall TNS and the count of violating paths are endpoint-based. So they need not equal the sum over path groups. For example, an endpoint with −0.6 ns from an input and −0.3 ns from a register counts once, at −0.6 ns. In a multi-mode setup, the overall TNS sums the worst slack per endpoint across views, not per view.

If the summary shows positive worst slack and zero violators in the named scope, the same scope cannot also show 400 violators. Either the scope differs, or one of the numbers belongs to another view.

11.7  Special checks

The commands in the block above write these reports. Read each one for what it names. Read the coverage report for untested checks and their reasons.

11.8  What a post-CTS number does not prove

It is partly an estimate: the signal wires are estimated, not routed. It covers only the views and corners that were active. It says nothing about signoff extraction, signoff timing, crosstalk after routing, or electromigration. The acceptance section states what the chapter proves, and stops there.

Thus, setup and hold must be read together, with their coverage beside them. When a number is not what was expected, the debugging cases lead from a symptom to a cause.

12  Debugging cases: from a symptom to a cause

A failed clock run gives a symptom, not a cause. The same symptom, such as large skew, can have configuration causes, physical causes and report-state causes. The repair for one might make another worse.

This section holds seventeen cases in one pattern. Each has a symptom, evidence, competing causes and a check that tells them apart. Then come a justified repair and a remeasurement. It is the only place in the chapter that lists failures in detail, so keep it open while you work.

12.1  Check this first: is the evidence about this candidate?

If any answer is wrong, regenerate the reports on the right candidate (case 17) and start again.

12.2  Find the family

Figure 19, after case 1 below, turns them into a decision tree that asks for evidence at each branch.

Use three words and keep them apart. An observation is what a report shows. A hypothesis is a cause you suspect. A confirmed cause is a hypothesis that a second, independent check supports.

Each case ends with a remeasurement: the relevant assessment from the acceptance section, on a new candidate, with its own reports. Assessments 1 to 4 are the four rows of the acceptance table. None of the repairs below is "tighten the skew target" or "remove a restriction" by default. Each needs its owner and its evidence.

12.3  The seventeen cases

Case 1 - No clock tree is created

• Symptom: the run ends without clock cells, or ccopt_design prints a table saying it cannot run.
• Evidence: the prerequisites table and the check_design -⁠type cts findings. A tree name from get_ccopt_clock_trees only shows that a specification object exists, not that anything was built.
• Competing causes: no clock in the loaded mode, or a specification never created or deleted. A transition target may be too low, or drivers too weak. The constraints may stop the clock before any register.
• Distinguishing check: check_timing -⁠type clocks and report_clocks say whether the clock exists. ccopt_design -⁠check_prerequisites lists design problems and per-tree problems separately.
• Repair: fix the constraint or the property named in the table, then rebuild from the baseline.
• Remeasure: assessment 1.

Which family is the cause?

A decision tree that asks for evidence at each branch

What to notice: The first question asks whether the evidence is about this candidate; if not, no branch below it tells you anything.

Case 2 - Sinks are missing

• Symptom: a group's active sink count is lower than the plan, or a register is in no group.
• Evidence: the active sinks of the group from get_ccopt_skew_group_delay -⁠skew_group clk_core/func -⁠all_active_sinks, with the group you suspect. Compare them with an independent netlist query of the registers that should be there.
• Competing causes: a pin marked ignore or exclude before spec creation. A set_clock_sense -⁠stop_propagation or a case value may stop the clock. Or the clock does not reach the pin in the netlist.
• Distinguishing check: get_ccopt_property -⁠pin with the pin name and skew_groups_sink or skew_groups_active_sink names the groups of a pin. The second reflects connectivity and is current only after the CTS timer has run.
• Repair: fix the SDC so the timer and the tool agree. Otherwise change the sink type before regenerating the specification.
• Remeasure: assessment 1.

Case 3 - A sink is in the wrong skew group

• Symptom: a register is balanced with a clock it should not follow, or not with the one it should.
• Evidence: the group listing for the pin, and the skew-group report.
• Competing causes: exclusive sinks and rank, where a sink is active only in the highest-rank groups that hold it. Or a misplaced ignore pin. Or default balancing treats clocks as related when the constraints call them unrelated.
• Distinguishing check: the skew_groups_active_sink list of the pin against the rank of each candidate group.
• Repair: if the relationship is wrong in the constraints, fix the clock groups or false paths, and consider timing_connectivity_based_skew_groups. If only the grouping is wrong, use modify_ccopt_skew_group with a written reason.
• Remeasure: assessment 1.

Case 4 - Clock gating checks fail

• Symptom: report_constraint -⁠all_violators lists clock gating setup or hold violations.
• Evidence: the failing path report.
• Competing causes: the enable register's clock is late and the gate's early. Other causes are long enable logic or wire delay, a large clock-to-Q, uncertainty, or a distant gate.
• Distinguishing check: the gap between the two clock arrivals is only one term. Read the whole path: the clock edge relation, enable clock-to-Q, logic delay, net delay, uncertainty and the gating check. For hold, check that the enable stays stable after the edge.
• Repair: in CCOpt, useful skew normally schedules the enable register earlier, so read the worst chain for a window limit first. For CCOpt-CTS, one known option is a skew group that balances the enable register with the gate. Moving the gate closer is a placement-stage lever.
• Remeasure: assessment 3.

Case 5 - Transition violations on clock nets

• Symptom: starred rows in the Clock Timing Summary, or violations in the clock-network DRV report.
• Evidence: the violation summary by net type, and the detailed nets with their route type.
• Competing causes: an unrealistic target or a wrong unit, or cells filtered out. A long net may cross a narrow channel, or the tool may not be allowed to buffer it. A wider rule can also raise capacitance on a long net.
• Distinguishing check: read the target back (the unit trap), read the filtering reasons, and look at the net's length and layer split. The DRV report covers transition, max capacitance and source-to-sink length only. Fanout or other limits come from the clock tree report or another source.
• Repair: correct the unit, add a stronger cell, relieve the channel, or free a frozen net with its owner. Raise a target only with a written reason.
• Residual data-net violations: if maximum-capacitance or transition violations remain on data nets after the cause is fixed, the native repair is optDesign -⁠postCTS -⁠drv. It fixes those two violation types only, and it cannot be combined with -⁠incr.
• Remeasure: assessment 2.

Case 6 - Insertion delay is very large

• Symptom: the maximum insertion delay is far above the study's, or above the limit.
• Evidence: the skew-group report. The pin insertion delay report lists offsets, not each sink's measured arrival.
• Competing causes: many levels after clustering, weak cells or long distances. Scheduling may have lengthened sinks, a macro offset may be applied the wrong way, or topology is the cause.
• Distinguishing check: compare a balance_mode cluster study with the full run. If the study is already large, the cause is physical or configuration. If only the full run is large, look at scheduling and at auto_limit_insertion_delay_factor. That factor limits growth of the global maximum, not each sink.
• Repair: match the cause: cell list, offsets, the limit factor, or a physical lever.
• Remeasure: assessments 2 and 3.

Case 7 - The skew target is not met

• Symptom: the report shows a skew above the target.
• Evidence: the Type column and occupancy of the skew-group report.
• Competing causes: the target did not apply, or a physical limit, or the corner is not the primary one. Full ccopt_design does not use the global target_skew as its objective.
• Distinguishing check: which command ran, and which target type does the report show? If the type is ignored, or this is the global target in a full CCOpt run, there is nothing to fix. If you set a bound on a named group, check that you also set constrains all. If the target applied, read the worst chain.
• Repair: none if the target did not apply. Otherwise treat the physical or configuration cause.
• Remeasure: assessment 2.

Case 8 - A frozen net blocks repair

• Symptom: a violation stays on a net the tool did not touch.
• Evidence: the explicit dont_touch marks on the net (report_preserves -⁠obj_type net -⁠dont_touch), the computed marks that a net inherits (report_preserves -⁠computed -⁠obj_type net), and check_design -⁠type cts. A computed report that is also filtered by -⁠dont_touch has qualified meaning, so run the two reports separately.
• Competing causes: a restriction from an earlier stage or an IP owner.
• Not a preserved port: a preserved port belongs to the flexible H-tree flow. It keeps a module port in place so sinks below stay below. It does not freeze a net, and its report (report_ccopt_preserved_clock_tree_ports) is not a list of frozen nets.
• Distinguishing check: check explicit and effective preservation attributes, including inherited restrictions, before concluding that the net is free to change.
• Repair: a decision for the owner. Do not remove a restriction silently.
• Remeasure: assessment 2, with the decision recorded.

Case 9 - Hold violations after CTS

• Symptom: hold WNS is negative.
• Evidence: failing paths with launch and capture arrival and the skew term.
• Competing causes: a capture clock later than the launch by more than the data path allows. Short data paths, uncertainty or a fast corner can also cause it.
• Distinguishing check: compute the skew from the path report. Then compare all changed terms between the pre-CTS and post-CTS reports. A skew term that explains part of the shortfall does not prove the data path is unchanged.
• Repair: targeted hold repair, with the hold options set first (block below). Write down the finding, the believed cause and the expected evidence before you run it.
• Remeasure: assessment 3 on the repaired candidate, saved under its own name. Rerun post-CTS setup and hold in the same required views, and review WNS, TNS and margins. Refresh the affected special-check and coverage evidence. Recheck placement legality after inserted or moved cells.

innovus> setOptMode -opt_hold_target_slack 0.020 ;# aim for 0.020 ns hold margin
innovus> setOptMode -opt_hold_allow_setup_tns_degradation false ;# protect setup TNS
innovus> optDesign -postCTS -hold ;# repair hold only

If a hold violation stays, setOptMode -⁠opt_verbose true shows why. Listed causes include no legal location for a buffer, setup degradation the settings forbid, and an excluded path group.

Case 10 - Setup is worse than before CTS

• Symptom: a path that met pre-CTS now fails.
• Evidence: the same path in both reports: launch and capture arrival, uncertainty, derates.
• Competing causes: skew of the wrong sign for that path, CPPR not applied, uncertainty changed between stages, or estimated wires.
• Distinguishing check: compare the clock arrival terms. If CPPR was off, switch it on and read again.
• Repair: if the cause is real skew, read the worst chain for windows. If it is a setting, fix it and rebuild from the baseline. A blanket setup pass is not a repair. If a targeted setup repair is still justified after full CCOpt, optDesign -⁠postCTS, with the finding written down, is the native form.
• Remeasure: assessment 3.

Case 11 - Clock wires crowd a macro channel

• Symptom: routing overflow near a macro channel, or trunk nets detouring.
• Evidence: the congestion report and the trunk detail.
• Competing causes: shielded trunk wires take many tracks, or capacity was assumed from a halo.
• Distinguishing check: a halo is not a routing blockage. Compare against real routing capacity.
• Repair: fewer shielded wires or another layer pair. Otherwise route over the macro on a free layer, or get a wider channel from the floorplan.
• Remeasure: assessments 2 and 4.

Case 12 - The routing rule was not used

• Symptom: clock nets look default width.
• Evidence: the readback of the route types, and report_net_wires -⁠net for one trunk net and one leaf net.
• Competing causes: the route type was not attached, a name was mistyped, layers are not allowed, or the configuration was not restored.
• Distinguishing check: read all three kinds back, then read the wires. Readback says what you asked for, and the wire report says what was drawn. Say whether you looked at every clock net or a sample.
• Repair: reassign the route type and rebuild. This guide rebuilds a finished tree under its corrected rule instead of patching it, so the candidate stays reproducible.
• Remeasure: assessment 2.

Case 13 - Clock cells violate placement

• Symptom: checkPlace lists overlapping or off-site clock cells, or the halo report lists halo violations. These are two different problems.
• Evidence: both reports and the cell name prefixes.
• Competing causes: halos too large for the local density, or fixed cells in the way. Large cells with a density-based halo are another cause. The tool disables such halos with a message.
• Distinguishing check: the halo report checks halo rules for all three property pairs. Legality comes from checkPlace only.
• Repair: use the halo-in-microns or halo-in-sites form, or relieve the area at the placement stage.
• Remeasure: checkPlace clean, then assessment 2.

Case 14 - Functional timing passes and scan timing fails

• Symptom: hold or setup fails in the scan views only.
• Evidence: the per-view reports from -⁠expandedViews.
• Competing causes: the scan group is missing or unconstrained, a different latency in scan mode, or reversed mux ignore pins.
• Distinguishing check: first check which scan views were analyzed. In the example, the hold list holds the scan view, but the setup list holds the functional view only. So scan hold can be diagnosed, and scan setup cannot, because it was never analyzed. Then list the groups and their ignore pins, and compare scan arrivals with functional ones.
• Repair: constraints first, then a justified modify_ccopt_skew_group.
• Remeasure: assessments 1 and 3.

Case 15 - A generated clock or mux is mishandled

• Symptom: a divided domain is balanced with the wrong clock, or a mux input is counted as a sink.
• Evidence: the structure report with generated trees, and report_clocks.
• Competing causes: the generated clock's source pin is not reached by its master, or ignore pins are missing at the inactive input. Another cause is that no constraining group holds the sinks behind the divider, because the generated group is reporting-only.
• Distinguishing check: check_timing -⁠type clocks for generated clocks with no source, then the structure report. Then read the master group's -⁠auto_sinks line and the generated group's constrains none.
• Repair: fix the constraint, regenerate the specification and rebuild.
• Remeasure: assessments 1 and 3.

Case 16 - The wrong primary corner

• Symptom: skew and slew look good in one corner and bad in the one that matters.
• Evidence: the corner column of the skew-group report, and the readback of primary_delay_corner.
• Competing causes: the default, the first setup view's corner, is not the dominant one.
• Distinguishing check: which corner drives the limits?
• Repair: set it explicitly and rebuild.
• Remeasure: assessments 2 and 3.

Case 17 - The reports do not match the candidate

• Symptom: a number cannot be reproduced, or two reports disagree about the same quantity.
• Evidence: the report folder and prefix, the restoreDesign line in the log, and when the design in memory last changed.
• Competing causes: reports made before a repair, after a restore, or for another candidate; or reports of different views and scopes.
• Distinguishing check: regenerate one report, for example report_ccopt_skew_groups, on the design you now hold. Compare it with the old file.
• Repair: regenerate the full set on the intended candidate. Never restore an older checkpoint and quote the old reports as proof of a repair.
• Remeasure: assessment 4.

Thus, a symptom is never repaired directly. Each case ends with a remeasurement on a candidate saved under its own name. Before the repaired result can leave this chapter, it has to be accepted. We do that after a look at the alternatives.

13  Other ways to build a clock tree

The rows below are alternatives, not steps.

13.1  Choose the flow from the input database

innovus> ccopt_design -cts ;# build the trees only
innovus> optDesign -postCTS ;# then optimize setup
innovus> optDesign -postCTS -hold ;# then repair hold

The post-CTS stage does not fix fanout load violations unless setOptMode -⁠opt_fix_fanout_load is set. Option spellings differ: ccopt_design writes reports with -⁠outDir, and clock_opt_design with -⁠out_dir.

13.2  Choose topology and effort from evidence

Topology answers a floorplan question: how is the top of the network distributed? Strategy answers a timing question: how hard may the optimization work on useful skew? Neither fixes a hard constraint or creates routing tracks that are not there. Table 16 and Table 17 list the options.

The tool names create_ccopt_flexible_htree and synthesize_ccopt_flexible_htrees for the H-tree, the clock tree source group commands for multi-tap, and create_ccopt_macro_model_spec for macro models. Check each one on your installation before use. The pin insertion delays of the configuration section are the simple case of macro modeling. A mesh is beyond this chapter.

Whether a setting applies depends on the flow and on your installation, so check each one with -⁠help on your installation.

14  Accept the clock tree and hand it to routing

A built clock tree is not automatically an acceptable one. No project-independent Innovus command knows a project's intended clocks, margins, approved waivers and routing assumptions. So none can declare "CTS accepted". Acceptance is a person's engineering decision on native evidence. This section gives the decision table, the five status words and the export commands.

14.1  Which saved state does each experiment start from?

14.2  Four assessments, kept independent

A pass in one assessment never offsets a failure in another. Good setup never cancels bad hold, and a legal placement never cancels missing clock coverage.

14.3  The status words

A waiver does not establish a check that never ran. Investigation comes first and establishes the result. A waiver then applies to an identified failure, not to ignorance. A waiver for another candidate does nothing.

An acceptance record for one candidate

Four assessments with their status words, drawn from the example above; the numbers are invented

What to notice: Each status carries text as well as color, and this candidate cannot be handed off until every row is PASS or WAIVED.

14.4  Save and export what routing needs

innovus> saveDesign handoff_cts.enc ;# the restart checkpoint
innovus> save_ccopt_config handoff_ccopt_config ;# the CCOpt configuration
innovus> saveNetlist handoff_cts.v ;# netlist exchange form
innovus> defOut -routing handoff_cts.def ;# DEF with the CTS routes

save_ccopt_config content is proprietary, and restore_ccopt_config is its only supported reader. The configuration is not restored if the design was restored with restoreDesign -⁠mmmcFile (warning IMPIMEX-4016). So a restored checkpoint does not automatically bring back every view and setting. State in the handoff note how your site restores the multi-mode setup and then the CCOpt configuration.

A nonempty file is not proof. Open the DEF, look for routing under the clock nets, and confirm that the intended rules survived.

14.5  The handoff note

A small table, Table 21, answers what the next engineer will ask. Figure 21 shows everything routing receives around the reviewed candidate.

What routing receives

The reviewed candidate in the middle, with the items routing needs around it

What to notice: The database alone is not the handoff: the note, the exceptions and the open items travel with it.

14.6  What this chapter establishes, and what it does not

• Established. Clock trees exist for the clocks and modes in the specification. Structure and electrical limits were read from reports of one candidate. Setup and hold were measured with propagated clocks in the views named.
• Provisional. Every timing number uses estimated signal wires, so margins change after routing and extraction.
• Not claimed. That the design routes, that post-route timing closes, or that signoff timing, crosstalk, IR drop or electromigration pass.

We followed one clock network from an accepted placement to a handoff note. Thus, routing receives a database with its evidence, and an owner for every open item.

15  Common mistakes and how to catch them

Table 22 indexes the seventeen debugging cases by symptom. Check first, always: the reports must be about the candidate you restored, written after its last change. Each repair starts from the built candidate or the baseline, and new reports on that candidate follow it.

16  Interview preparation

17  Chapter close

Compact glossary

CTS and handoff on one page

Keep this page open beside the terminal. Each block answers one question about a post-CTS design with a native command. A report that exists is not a pass: read its header, scope and candidate. File names are illustrative. The reasoning behind each symptom is in the debugging cases.

innovus> get_ccopt_property primary_delay_corner ;# construction corner
innovus> get_ccopt_property buffer_cells ;# allowed clock buffers
innovus> get_ccopt_property -net_type leaf target_max_trans ;# leaf slew target
innovus> get_ccopt_property target_skew ;# global skew target
innovus> get_ccopt_property -net_type trunk route_type ;# trunk route type
innovus> get_ccopt_property routing_top_min_fanout ;# top-net threshold
innovus> getAnalysisMode -cppr ;# look for: both

# Names here are spec objects, not built trees.
innovus> get_ccopt_clock_trees * ;# tree objects
innovus> get_ccopt_skew_groups * ;# skew group objects
innovus> get_ccopt_skew_group_delay -skew_group clk_core/func \
    -all_active_sinks ;# active sinks of one group, as a Tcl dict
innovus> get_ccopt_clock_tree_nets -net_types trunk ;# built trunk nets only
innovus> report_clocks ;# clock definitions
innovus> check_timing -type clocks ;# clocks with problems
innovus> ccopt_design -check_prerequisites ;# setup can run?
innovus> check_design -type cts ;# CTS design checks

innovus> report_net_wires -net clk_core_trunk1 -file wires_trunk1.rpt ;# one net's wires
innovus> report_via -on_clock_nets -detail ;# vias on clock nets

innovus> report_ccopt_clock_trees -histograms -list_special_pins \
    -file clock_trees.rpt ;# cells, slew histograms, special pins
innovus> report_ccopt_clock_tree_structure -update_timing -show_sinks \
    -file clock_structure.rpt ;# levels and sinks
innovus> report_ccopt_skew_groups -include_reporting_only_skew_groups \
    -file skew_groups.rpt ;# balance per group and corner
innovus> report_ccopt_clock_tree_drv \
    -drv_types {transition max_cap max_source_to_sink_net_length} \
    -file clock_drv.rpt ;# clock-network limits
innovus> report_ccopt_pin_insertion_delays -file pin_offsets.rpt ;# offsets
innovus> report_ccopt_worst_chain -file worst_chain.rpt ;# useful skew limit
innovus> report_ccopt_cell_halo_violations -summary -file halo.rpt ;# halo rules
innovus> report_ccopt_cell_filtering_reasons -cell_type buffer \
    -file filter.rpt ;# why cells were dropped

innovus> report_clock_timing -type skew -nworst 4 ;# skew, with CPPR on for setup and hold
innovus> report_clock_timing -type summary ;# latency summary
innovus> timeDesign -postCTS -expandedViews -numPaths 200 \
    -outDir timing_setup -prefix post_setup ;# setup; 200 is a report size
innovus> timeDesign -postCTS -hold -expandedViews -numPaths 200 \
    -outDir timing_hold -prefix post_hold ;# hold
innovus> report_constraint -all_violators > violations.rpt ;# other violators
innovus> report_min_pulse_width > pulse_width.rpt ;# pulse width
innovus> report_analysis_coverage -verbose {violated untested} -sort reason \
    > coverage.rpt ;# what was analyzed
innovus> checkPlace checkplace.rpt ;# legality, separate from the halo report

innovus> saveDesign handoff_cts.enc ;# restart checkpoint
innovus> save_ccopt_config handoff_ccopt_config ;# CCOpt configuration
innovus> saveNetlist handoff_cts.v ;# netlist
innovus> defOut -routing handoff_cts.def ;# -routing writes the CTS routes

Command roles. ccopt_design builds trees and optimizes the data path, so no routine extra setup pass follows it. ccopt_design -⁠cts builds trees only. clock_opt_design needs a PODV2 database. optDesign -⁠postCTS and -⁠postCTS -⁠hold repair. timeDesign and report_* only measure. A tree name from get_ccopt_clock_trees is a spec object, and a capped path list is not a coverage statement.

Where the next chapter goes, and why

We now hold a reviewed candidate with real clock trees, clock routes under their rules, and timing measured with propagated clocks. Every signal wire, however, is still an estimate.

Routing, Post-Route Optimization, Checks and Handoff replaces those estimates with real routes. It must respect the clock routes and rules handed over here, without rerouting them with default rules. Then the post-CTS margins are measured again on real wires. That is why the handoff note records the views, the routing assumptions and every open item: routing starts from them.