Wednesday, November 18, 2015

Specifying Clock Tree Exceptions

To define clock tree exceptions, use the set_clock_tree_exceptions command or choose Clock > set Clock Tree Exceptions in the GUI. You can set clock tree exceptions on pins or hierachical pins.

If you issue the set_clock_tree_exceptions command multiple times for the same pin, the pin keeps the highest-priority exception. ICC prioritizes the clock tree pin exceptions as follows:

1 Nonstop pins
2.Exclude pins
3. Float pins
4. Stop pins

Note:
The don't touch subtree exception is compatible with the nonstop, exclude, float, or stop pin exception. You can set both exceptions on a pin, and clock tree synthesis honors both exceptions.

To remove clock tree exceptions, use the remove_clock_tree_exceptions command or choose Clock > Remove Clock Tree Exceptions in the GUI.

To see the clock tree exceptions  defined for your design, generate a clock tree exceptions report by running the report_clock_tree -exceptions command or by choosing choose Clock > Report Clock Tree in the GUI and selecting Exceptions.

Note:
If your design contains sequential cells with unconnected outputs, the clock pins of these cells are marked as implicit ignore pins. When you run clock tree synthesis, these unloaded sequential cells are deleted from the design. As a result, at the end of clock tree synthesis, you no longer see these implicit ignore pins. To prevent the removal of these sequential cells, set the physopt_delete_unloaded_sequential_cells variable to false before running clock tree synthesis.

If your design contains dangling nets, the clock tree exceptions report might show false implicit ignore pins on these nets.  If this happens, you can remove the false implicit ignore pins by saving your design and reopening it.

Specifying Nonstop Pins
Nonstop pins are pins that would normally be considered endpoints of the clock tree, but instead ICC traces through them to find the clock tree endpoints. The clock pins of sequential cells driving generated clocks are implicit nonstop pins. In addtion, ICC supports user-defined ( or explicit ) nonstop pins.

To specify a nonstop pin, use the set_clock_tree_exceptions -non_stop_pins command.

For example, to specify pin U2/CLK as a nonstop pin, enter
icc_shell> set_clock_tree_exceptions -non_stop_pins  [get_pins U2/CLK]
 To remove the nonstop pin definition from a pin,  use the remove_clock_tree_exceptions
-non_stop_pins command.

For example, to remove the nonstop pin definition from pin U2/CLK , enter
icc_shell> remove_clock_tree_exceptions -non_stop_pins  [get_pins  U2/CLk]

Specifying 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 for design rule constraints. In addtion to the exclude pins inferred by ICC ( the inplicit exclude pins), ICC supports user-defined ( or explicit)  exclude pins. For example, you might define an exclude pin to exclude all branches of the clock tree that fan out from some combinational logic or to  exclude an implicit stop pin.

During clock tree synthesis, ICC isolates exclude pins ( both implicit and explicit) from the clock tree by iserting a guide buffer before the pin.  Beyond the exclude pin, ICC never performs skew or insertion delay optimization, bot does perform design rule fixing.

To specify an exclude pin, use the set_clock_tree_exceptions -exclude_pins command.

For example, to exclude clock sink U2/CLK, enter
icc_shell> set_clock_tree_exceptions -exclude_pins [get_pins U2/CLK]
To remove the exclude pin definition from a pin, use the remove_clock_tree_exceptions
-exclude_pins command.

For example, to remove the exclude pin definition from pin U2/CLK, enter
icc_shell> remove_clock_tree_exceptions -exclude_pins  [get_pins U2/CLK]

For another example, assue that a clock tree also drives combinational logic,

Explicit Exclude Pin


To exclude all branches of the clock tree that fan out from this point, enter

icc_shell> set_clock_tree_exceptions -exclude_pins  [get_pins  U2/A]

Specifying Float Pins
Float Pins are clock pins that have special insertion delay requirements. ICC adds the float pin delay ( positive or negative ) to the calculated insertion delay up to this pin.

To specify a float pin and its timing characteristics, use the following
set_clock_tree_exceptions options:

1.  -float_pins [get_pins pin_list]
2.  -float_pin_max_delay_fall max_delay_fall_value
3.  -float_pin_max_delay_rise max_delay_rise_value
4.  -float_pin_min_delay_fall min_delay_fall_value
5.  -float_pin_min_delay_rise  min_delay_rise_value

For example, to define an active-low float pin ( so that clock tree synthesis considers only the falling edge), enter
icc_shell>set_clock_tree_exceptions -float_pins [get_pins U1/CLK] \
      -float_pin_max_delay_fall 0.10 -float_pin_min_delay_fall 0.08

The clock tree exceptions report ( report_clock_tree -exceptions) shown the float pin values only for the active edge. For Example, the report for the float pin defined above shows

Explicit sync pins:  1
      (F) U1/CLK    ( -0.100 -0.080 )

The float pin delay values can be either positive or negative, depending on your timing requirements. To increase the path delay to a pin, specify a negative float pin delay. To decrease the path delay to a pin, specify a positive float pin delay.

## Specifying a negative float pin
icc_shell> set_clock_tree_exceptions -float_pins U1/CLK \
   -float_pin_max_delay_rise -0.5 -float_pin_max_delay_fall -0.5

##Specifying a positive float pin
icc_shell> set_clock_tree_exceptions -float_pins U4/CLK \
   -float_pin_max_delay_rise 0.5 -float_pin_max_delay_fall 0.5

Float Pin Timing




To remove the float pin definition from a pin, use the remove_the_clock_tree_exceptions -float_pins command.

Specifying Don't Touch Subtres
In some cases you will want to preserve a portion of an existing clock tree. You need to do this, for example, when two clock networks share part of some clock logic behind a multiplexer. The portion of the clock tree that is preserved is called a don't touch subtree.

To specify a don't touch subtree, specify the root pin of the don't touch subtree by using the set_clock_tree_exceptions -dont_touch_subtrees command.

Although ICC does not make any modifications to the don't touch subtree during clock tree synthesis, it does propagate the clock tree attributes and the nondefault routing rules beyond the don't touch subtree. To prevent propagation of the clock attributes and the nondefault routing rules, set the
cts_traverse_dont_touch_subtrees variable to false.

ICC considers the sinks in the don't touch subtree when balancing clock delays and computing the clock skew.

To remove the don't touch subtree exception from a pin, use the
remove_clock_tree_exceptions -dont_touch_subtrees command.

Specifying don't Buffer Nets
In some cases you might be able to improve the results by preventing ICC from buffering certain nets ( ICC still performs global prerouting on these nets).

Note:
During clock tree synthesis, the don't buffer nets exception has priority over the clock tree design rule constraints. However, the clock tree specification in the clock tree configuration file has priority over the don't buffer nets exception.

To specify nets that should not be buffered, sue the set_clock_exceptions -dont_buffer_nets command.

For example, to specify net n1 as a don't buffer net, enter
icc_shell> set_clock_tree_exceptions -dont_buffer_nets [get_nets n1]

To remove the don't buffer net exceptions, use the
remove_clock_tree_exceptions -dont_buffer_nets command.

For example, to remove the don't buffer net exception from net n1, enter
icc_shell> remove_clock_tree_exceptions -dont_buffer_nets  [get_nets n1]

Specifying Don't Size Cells
During clock tree synthesis and optimization, ICC ignores the dont_touch attribute on cells and nets.
To prevent sizing of cells on the clock path during clock tree synthesis and optimization, you must identify the cells as don't size cells.

To specify cells that should not be sized, use the set_clock_tree_exceptions -dont_size_cells command.

For example, to specify cell U1/U3 as don't size cell, enter
icc_shell> set_clock_tree_exceptions -dont_size_cells [get_cells U1/U3]
To remove the don't size cell exception, use the remove_clock_tree_exceptions -dont_size_cells command.

For example, to remove the don't size cell exception from the cell U1/U3, enter
icc_shell> remove_clock_tree_exceptions -dont_size_cells [get_cells U1/U3]

Specifying Size-Only Cells
During clock tree synthesis and optimization, size-only cells can only be sized, not moved or split.
If a size-only cell overlaps with an adjacent cell after sizing, the size-only cell might be moved during the legalization step. To specify size-only cells , use the
set_clock_tree_exceptions -size_oly_cells command.

For example, to specify cell U1/U3 as a size-only cell, enter

icc_shell> set_clock_tree_exceptions -size_only_cells [get_cells U1/U3]

To remove the size-only cell exception, use the remove_clock_tree_exceptions -size_only_cells command.

For example, to remove the size-only cell exception from cell U1/U3, enter
icc_shell> remove_clock_tree_exceptions \
 -size_only_cells [get_cells U1/U3]

Preserving  the clock Pins of Existing Hierarchies
------------------------------------------------------------
In some cases, clock tree synthesis and optimization might cluster clock sinks from hierarchies to create new clock pins. You can prevent the clustering of clock sinks in the desired hierarchies that have clock sinks in other logical hierarchies by using the
set_clock_tree_exceptions -preserve_hierarchy command, so the clock pins of the desired logical hierachies are preserved.

For example, suppose your design has two hierarchical block instances L1 and L2 in the top level, and each block has clock pins CK1, Ck2, and CKO,

Hierarchical Clock Pins,
To preserve pin CK1 in cell instance L1, enter
icc_shell> set_clock_tree_exceptions -preserve_hierarchy [get_pins I1/CK1]

To preserve pins CK1, CK2, and CKO in cell instance I2, enter
icc_shell> set_clock_tree_exceptions -preserve_hierarchy [get_cells I2]

To preserve pins CK1, CK2, and CKO in cell instances L1 and L2, enter
icc_shell>set_clock_tree_exceptions -preserve_hierachy [get_references -hierarchical REG_A]

To remove the preserve-hierarchy exception, use the
remove_clock_tree_exceptions -preserve_hierarchy command. If the specified hierarchical pins or cells contain any leaf pins or cells that are not in the clock network, the tool issues a warning message.





















Tuesday, November 17, 2015

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]










Monday, November 16, 2015

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