Identifying the Clock Tree Endpoints

Clock Paths have two types of endpoints:

1) Stop Pins
Stop pins are the endpoints of the clock tree that are used for delay balancing. During clock tree synthesis, ICC uses stop pins in calculations and optimizations for both design rule constraints and clock tree timing ( skew and insertion delay).

Stop pins are also referred to as sink pins.

2)Exclude pins
Exclude pins are clock tree endpoints that are excluded from clock tree timing calculations and optimizations. ICC uses exclude pins only in calculations and optimizations fro design rule constraints.

ICC traces the transitive fanout from the clock roots to determine the implicit stop pins ( the default sink pins) and the implicit exclude pins.

When ICC finds a pin in the clock's transitive fanout that is defined as a clock pin of either a sequential cell ( a latch or flip-flop) or a macro cell,  it adds that pin to the default set of clock sinks (unless the fanout of that cell drives a generated clock ).

If the fanout of a sequential cell drives a generated clock, ICC considers the clock pin to be an implicit nonstop pin and traces through the sequential cell to locate the clock tree endpoints. In addtion, ICC considers the clock pins of integrated clock-gating (ICG) cells to be implicit nostop pins.

ICC defines the following clock endpoints as implicit exclude pins:
1) source pins of clock trees in the fanout of another clock
2)Nonclock input pins of sequential cells
3)Multiplexer select pins
4)Three-state enable pins
5)Output ports
6)Incorrectly defined clock pins ( for example, the clock pin does not have trigger edge information or does not have a timing arc to the output pin)
7)Buffer ot Inverter input pins that are held constant ( by using set_case_analysis)
8)Input pins of combitional cells or integrated clock-gating cells that do not have any fanout or that do not have any enabled timing arcs.

Verify that the default sink pins ( implicit stop pins), implicit nonstop pins, and implicit exclude pins are accurate by generating a clock tree exceptions report.

If the default sink pins, implicit nonstop pins, and implicit exclude pins are correct, you are done with the clock tree exception definition. Otherwise, first identify any timing settings, such as disabled timing arcs and case analysis settings, that affect the clock tree traversal . To identify disabled timing arcs in your design, use the report_disable_timing command. To identify case analysis settings in your design, use the report_case_analysis command. Remove any timing settings that cause an incorrect clock tree definition.

You can modify the set of sink (stop) pins, nonstop pins, and exclude pins by setting clock tree exceptions.

Defining the Clock Root Attributes
If the clock root is an input port (without an I/O pad cell), you must accurately specify the driving cell of the input port. A weak driving cell does not affect logic synthesis, because logic synthesis uses ideal clocks. However, during clock tree synthesis, a weak driving cell can cause ICC to insert extra buffers as the tool tries to meet the clock tree design rule constraints, such as maximum transition time and maximum capacitance.

For example, if  clock tree CLK1 has input port CLK1 as its root and CLK1 is driven by cell CLKBUF, enter
icc_shell> set_driving_cell  -lib_cell  mlib/CLKBUF  [get_ports CLK1]
If you do not specify a driving cell ( or drive strength ),  ICC assumes that the port has infinite drive strength.

If the clock root is an input port with an I/O pad cell, you must accurately specify the input transition time of the input port.

For example, if clock tree CLK1 has input port CLK1 as its root and the I/O pas cell has already been insered, enter
icc_shell> set_input_transition -rise 0.3 [get_ports CLK1]
icc_shell> set_input_transition -fall 0.2  [get_ports CLK1]

Cascaded Clocks

If a netsed clock tree has its own source, ICC considers the source pin of the driven clock (clk2 in this example) to be an implicit exclude pin of the driving clock (clk1 in this example). Sinks of the driven clock are not considered sinks of the driven clock.

Cascaded Clock With Two Source Clocks

To Verify that the clock sources are correctly defined, use the check_clock_tree command.

Cascaded Generated Clocks

If a nested clock tree has a generated source, ICC traces back to the master clock source from which the generated clock is derived and considers the sinks of the generated clock to be the sinks of the driving clock tree.

Cascaded Clock With Generated Clock

Incorrectly defining the master clock source,  as in the follwoing cases, results in poor skew and timing QoR.

1) IF ICC cannot trace back to the master clcok source, the tool  cannot balance the sinks of the generated clock with the sinks of its source.

2) IF the master clock source is not a clock source defined by create_clock or create_generated_clock , ICC cannot synthesize a clock tree for the generated clock or its source.

Use the check_clock_tree command to verify that your master clock sources are correctly defined.

If a nested clock tree has a generated source that is defined at the intersection of overlapping clocks, ICC traces back to the master clock source from which the generated clock is derived and considers the source pin of the generated clock on a per clock basis during synthesis. By default, ICC clock tree synthesis supports querying phase delay and clock tree exceptions for each clock domain to achieve the best QoR for cascaded generated clocks with overlapping clocks.

For Example, Assume the flip-flop inside the clk1 and clk2 overlapping domains has a generated clock, genclk2, which is defined at its Q output and which uses clk2 as the master clock. If you perform clock tree synthesis on clk2, the clock tree after that flip-flop is synthesized and balanced as a generated clock of clk2.

cascated generated clock with overlapping clock domains

Defining the Clock Trees

ICC uses the clock sources defined by the create_clock command as the clock roots and derives the default set of clock sinks by tracing through all cells in the transitive fanout of the clock roots.
You can designate either an input port or internal hierarchical pin as a clock source. To disallow clock sources defined on a hierarchical pin, set the cts_enable_clock_at_hierarchical_pin variable to false before using the create_clock command. This variable is true by default.

Note:
ICC will not synthesize a clock tree if its source is set to a constant value by using set_case_analysis.

In addtion to simple clock trees, ICC also supports cascaded clock trees ( a clock tree that containts  another clock tree in its fanout). The nested clock tree can either have its own source ( identified by the create_clock command) or be a generated clock ( identified by the create_generated_clock command).

Analyzing the Clock Trees

Before running clock tree synthesis, analyze each clock tree in your design to determine its characteristics and its relationship to other clock trees in the design.

For each clock tree, determine

1) What the clock root is
2) What the desired clock sinks and clock tree exceptions are
     ICC supports the following types of clock tree exceptions:  exclude pins, stop pins, float pins,              don't touch subtrees, don't buffer nets, and don't size cells.
3) Whether the clock tree contains preexisting cells, such as clock-gating cells
If your design contains existing clock trees, you might want to either identify them or remove them before running clock tree synthesis.
4) Whether the clock tree converges, either with itself ( a convergent clock path) or with another clock tree ( an overlapping clock path)
5) Whether the clock tree has timing relationships with other clock trees in the design, such as interclock skew requirements.
6) What the logical design rule constraints ( maximum fanout, maximum transition time, and maximum capacitance) are
7) What the routing constraints ( routing rules and metal layers ) are

Use this information when you define the clock trees and to validate that ICC has the correct clock tree definitions.

CTS Prerequisites

Prerequisites for Clock Tree Synthesis

Before you run clock tree synthesis, ensure that your design and libraries meet the prerequisites described in the following sections.

Design Prerequisites

Before running clock tree synthesis, your design should meet the following requirements:

1) The design is placed and optimizaed.
Use the check_legality -verbose command to verify that the placement is legal.
Running clock tree synthesis on a design that does not have a legal placement might result in a long runtimes and reduced QoR.

The estimated QoR for the design should meet your requirements before you start clock tree synthesis. This includes acceptable results for

1) Congestion
If congestion issues are not resolved before clock tree synthesis, the addition of clock trees can increase congestion. If the design is congested, you can rerun place_opt with the -congestion and
-effort high options, but the runtime can be long.

2)Timing
3)Maximum Capacitance
4)Maximum Transition Time

To ensure that the clock tree can be routed, verify that the placement is such that  the clock sinks are not in narrow channels and that there are no large blockages between the clock root and its sinks. If these conditions occur, fix the placement before running clock tree synthesis.

5)The power and grounds nets are prerouted.

6)High-fanout nets, such as scan enables, are synthesized with buffers.

Library Prerequisites
Before you run clock tree synthesis, your libraries must meet the following requirements:

1)Any cell in the logic library that you want to use as a clock tree reference ( a buffer or inverter cell that can be used to build a clock tree) or for sizing of gates on the clock network must be usable by clock tree synthesis and optimization.

By default, clock tree synthesis and optimization cannot use buffers and inverters that have the dont_use attribute to build the clock tree. To use these cells during clock tree synthesis and optimization, you can either remove the dont_use attribute by using the rmove_attribute command or you can override the dont_use attribute by specifying the cell as a clock tree reference by using the set_clock_tree_reference command.

2) The physical library should include
-- All clock tree reference (the buffer and inverter cells that can be used to build the clock trees)
-- routing information, which inludes layer information and nondefault routing rules

3) TLUPlus modeels must exist.
Extraction requires these models to estimate the net resistance and capacitance.

Refining Placement

If your design shows large timing or power violations after you run the place_opt command, adjust the place_opt options and rerun place_opt.

If your design shows small timing or power violations after you run place_opt psynopt to fix these violations.

If your design has congestion violations after you run place_opt, rerun place_opt with high-effort congestion reduction (-congestion option). If your design still has congestion violations, you can refine the placement to fix these violations.

To refine the placement , use the refiner_placement command ( or choose Placement > Refine Placement in the GUI). The refine_placement command performs incremental placement and legalization.

To refine the placement with a minimum impact on QoR, use the medium-effort congestion removal:

icc_shell> refine_placemnt -congestion_effort medium

To achieve the best congestion removal, use high-level perturbation, and then perform physical optimization:

icc_shell> refine_placement -perturbation_level high
icc_shell> psynopt

Quality-of-Results Reporting

You can generate a report on the quality of results (QoR) for the design in its current state by using the create_qor_snapshot command ( or by choosing Timing > Create QoR Snapshot in the GUI).
This command measures and reports the quality of the design in terms of timing, design rules, area, power, congestion, clock tree synthesis,  routing , and so on, It stores the quality information into a set of snapshot files.  You can later retrieve and report the snapshot with the report_qor_snapshot  command. You can also selectively retrieve, sort, and display the desired information from the snapshot with the query_qor_snapshot command. ( or By choosing Timing > Query QoR Snapshot in the GUI).

create_qor_snapshot

create_qor_snapshot
   -name name
   [-power ]
   [-clock_tree ]
   [-show_all ]
   [-route ]
   [-save_mw ]
   [-significant_digits   digits ]
   [-zero_paths  number]
   [-max_paths  number ]
   [-nworst  number]

Alternatively, you can create a QoR snapshot in the GUI by choosing  Timing > Create QoR Snapshot.

The command options let you specify which aspects of quality are to be measured ( power, clock tree, and routes ) and the conditions for analysis ( zero wire load, maximum paths per timing group, and maximum paths per endpoint).

When you use this command, you must at least specify a name for the snapshot by using the -name option.
For Example,
icc_shell> create_qor_snapshot -name my_snapshot1

The report is written to a set of files into a directory called "snapshot" in the current working directory.  Once written, you can retrieve the report any time with the report_qor_snapshot command.

For example,
icc_shell> report_qor_snapshot

query_qor_snapshot
The query_qor_snapshot command reads in a QoR report generated by previous usage of the create_qor_snapshot command and analyzes the results by collecting information about each path. You can query the collected information with various searches and display the results in text
or HTML format, or in an interactive HTML window linked to the GUI layout view. The interactive HTML report lets you quickly find paths with certain problems such as large fanouts or transition degradation, and then view the path in the current design.

This is the syntax of the query_qor_snapshot command:

query_qor_snapshot
   [-name snapshot_name ]
   [-type min | max ]
   [-incremental ]
   [-display ]
   [-output_file file_name ]
   [-output_false_paths  file_name]
   [-sort_by  column_list ]
   [-columns column_list ]
   [-and  column_list ]
   [-filters  filter_list ]
   [-hierarchy ]
   [-from module_list ]
   [-to module_list ]
   [-through  module_list ]
   [-output_group_paths  file_name]
   [-path_group_prefix prefix]

Alternatively, you can create a QoR snapshot in the GUI by choosing Timing > Query QoR Snapshot.

Alternatively, You can create a QoR snapshot in the GUI by choosing Timing > Query QoR Snapshot.

The command options let you filter and sort the query results and display those results in text or HTML format. The command does not perform any addtional analysis of the design, but merely processes the report information