1)Which routing rule (type of wire) to use
2)Which clock shielding methodology to use
3)Which routing layers to use
4)Which nodefault routing rules to use with which cell types
Specifying Routing Rules
If you do not specify which routing rule to use for clock tree synthesis, ICC uses the default routing rule (default wires) to route the clock trees. To reduce the wire delays in the clock trees, you can use wide wires instead. Wide wires are represented by nondefault routing rules.
Before you can use a nondefault routing rule, the rule must either exist in the Milkyway design library or have been previously defined by using the define_routing_rule command.
For example, to define the the clk_rule nondefault routing rule, enter the following command:
icc_shell> define_routing_rule clk_rule \
-widths {M1 0.28 M2 0.28 M3 0.28 M4 0.28 M5 0.28 M6 0.28 M7 0.28 } \
-spacings { M1 0.28 M2 0.28 M3 0.28 M4 0.28 M5 0.28 M6 0.28 M7 0.28 }
To see the current routing rule definitions, run the report_routing_rules command.
To see the clock tree routing rule, use the set_clock_tree_options -routing_rule command.
You can specify the clock tree routing rule for a specific clock tree by using the -clock_trees option to specify the clock or for all clocks by omitting the -clock_trees option.
For example, to use the previously defined clk_rule nondefault routing rule for routing all clock tress, enter the following command:
icc_shell>set_clock_tree_options -routing_rule clk_rule
By default, the specified routing rule is used for all nets in the clock tree. However, wide wires are often not required on the nets closest to the clock sinks. To use default wires on the nets connected to the clock sinks and the bottom n-1 levels of the clock tree, use the -use_default_routing_for_sinks option on the command line.
Note:
If you enable default routing for sinks, it applies to all clock trees. You cannot enable this capability on a per-clock basis. In addition, the default routing applies only to clock sinks connect to flip-flops. Clock sinks connected to macro cells are not affected by this option.
To see the nondefault routing rules defined for the clock trees in your design, run the report_clock_tree -settings command.
Shielding Clock Nets
ICC implements clock shielding using nondefault routing rules. You can choose either to shield clock nets before routing signal nets or vice versa. The methodology of shielding clock nets before routing signal nets yields better shielding coverage but can cause more DRC violations during signal net routing compared to the methodology of routing signal nets before shielding clock nets.
Clock Shielding Methodologies,
To define nondefault routing rules dor clock shielding, use the define_routing_rule command.
The syntax is,
define_routing_rule rule_name
[-snap_to_track ]
[-shield_spacings shield_spacing ]
[-shield_widths shield_widths ]
To assign nondefault routing rules to clock nets, use the set_clock_tree_options command.
The syntax is
set_clock_tree_options [-clock_tree_name clock_tree_name ]
[-root pin_name ]
[-routing_rule rule_name]
[-use_default_routing_for_sinks ]
The nondefault routing rules of clock shielding apply only to nets that are assigned with nondefault routing rules. You can indicate whether to add shielding to leaf pins by using the
-use_default_routing_for_sinks option.
After assigning nondefault routing rules to clock nets, you can synthesize clock trees and route clock nets using the clock_opt command.
ICC router and extractor honor virtual shielding rules. Virtual shielding rules require that the router leaves enough routing resources for shielding to be inserted later and that the extractor considers the shielding effect before shielding metal is inserted. Virtual shielding is supported by virtual routing, global routing, track assignment, and detail routing stages.
To route signal nets, you can use standalone commands such as route_zrt_global, route_zrt_detail, and route_zrt_auto, or the route_opt command.
After routing signal nets, you can add shielding to the routed clock nets using the create_zrt_shield command. Alternatively, you can choose to add shielding to the routed clock nets before routing signal nets.
The following sample script shows the methodology for routing signal nets before clock shielding.
#Create new nondefault routing rule named SP
define_routing_rule SP \
-widths {M1 0.14 M2 0.14 M3 0.14 M4 0.14 M5 0.14 M5 0.14 M6 0.42} \
-spacings {M1 0.14 M2 0.42 M3 0.42 M4 0.42 M5 0.42 M6 1.60} \
-via_cuts {V12 "lxl" V23 "1x1" V34 "1x1" V45 "1x1" V56 "1x1"}
-shield_widths {M1 0.14 M2 0.14 M3 0.14 M4 0.14 M5 0.14 M6 0.42} \
-shield_spacings {M1 0.14 M2 0.42 M3 0.42 M4 0.42 M5 0.42 M6 1.60 }
##Synthesis and route clock trees
clock_opt
set clock_nets [get_nets -of [all_fanout -clock_tree]]
#Route signal nets
route_opt
#Add shielding to clock nets
create_zrt_shield -nets $clock_nets
Specifying Routing Layers
If you do not specify which routing layers to use for clock tree synthesis, ICC can use any routing layers. For more control of the clock tree routing, you can specify prefered routing layers by using the set_clock_tree_options -layer_list command.
You can specify teh preferred clock tree routing layers for a specific clock tree by using the -clock_trees option to specify the clock or for all clocks by omitting the -clock_trees option.
For example,
icc_shell>set_clock_tree_options -clock_trees CK1 -layer_list {metal4 metal5}
When you specify the clock tree routing layers by using this command, the specified layers apply to all levels of the clock tree. For finer control of the clock tree routing layers, you can specify the layer constraints in a clock configuration file.
By default, ICC treats the minimum layer specification as a soft constraint and can use lower layers for clock tree routing, if necessary. To require clock tree routing on the specified layers, set the follwoing option before running clock tree synthesis:
icc_shell> set_route_zrt_common_options -min_layer_mode hard
Note:
If you have defined layer constraints on signal nets, you must reset this option to soft before performing detail routing on the design.
To remove the restrictions on the clock tree routing layers, use the
reset_clock_tree_options -layer_list command.
Association of Nondefault Routing Rules With Reference Cells
Electromigration problems result from an increase in current densities, which often occurs when strong cells drive thin nets. Electromigration can lead to opens and shorts due to metal ion displacement caused by the flow of electrons and can lead to the functional failure of the IC device.
To prevent these problems in clock networks, you can associate reference cells with compatible nondefault routing rules by using the set_reference_cell_routing_rule command.
You use the following syntax to assocoate reference cells with nondefault routing rules:
set_reference_cell_routing_rule
-routing_rule NDR_name
-reference list_of_reference_cells
You must specify both the -routing_rule and -reference options. If you use the
set_reference_cell_routing_rule command, specifying only the -routing_rule option but not the
-references option, the nondefault routing rule does not apply during clock tree synthesis and optimization.
For example, to use the CLOCK_RULE nondefault routing rule for nets that are driven by instances of the BUF, BUF2, and INV1 reference clock cells, enter
icc_shell> set_reference_cell_routing_rule -routing_rule CLOCK_RULE -reference {BUF1 BUF2 INV1}
When you associate reference cells with nondefault routing rules,
1)If multiple nondefault routing rules are associated with a reference cell, clock tree synthesis and optimization uses the nondefault routing rule that provides the best result for each instance of the reference cell.
2)The compile_clock_tree command, the optimize_clock_tree command, and interclock delay balancing consider these nondefault routing rules.
3)These nondefault routing rules do not apply to nets beyond exception pins.
To report the nondefault routing rules, use the report_reference_cell_routing_rule command. If you specify the -routing_rule option, the command lists the corresponding reference cells for each specified nondefault routing rule. If you specify the -references option, the command lists the corresponding nondefault routing rules for each specified reference cell.
To reset all nondefault routing rules, use the reset_reference_cell_routing_rule command.
Inserting Boundary Cells
When you are working on a block-level design, you might want to preserve the boundary conditions of the block's clock ports (the boundary clock pins). A boundary cell is a fixed buffer that is inserted immediately after the boundary clock pins to preserve the boundary conditions of the clock pin.
To enable boundary cell insertion during clock tree synthesis,
1. Specify the buffers (or inverters) used for boundary cell insertion.
2. Enable boundary cell insertion by using the set_clock_tree_options -insert_boundary_cell true command.
If you enable boundary cell insertion, it applies to all clock trees. You cannot enable boundary cell insertion on a per-clock basis.
Note:
You cannot use boundary cell insertion together with a clock tree configuration file. If you specify both options, ICC disables the boundary cell insertion and generates a warning message.
When boundary cell insertion is enabled, ICC inserts a cell from the buffer insertion clock tree reference list immediately after the boundary clock pins. For multivoltage designs, ICC inserts the boundary cells in the default voltage area.
ICC does not insert a boundary cell when the net is either a don't buffer net or a bidirectional net or when these is a large blockage at the boundary clock pin, which would cause a large distance between the boundary cell and the clock pin.
The boundary cells are fixed for clock tree synthesis; after insertion, ICC does not move or size the boundary cells. In addtion, no cells are inserted between a clock pin and its boundary cell.
Selecting the Clock Tree Clustering
ICC performs clustering of the clock sinks to minimize wire length. If your design is sensitive to on-chip viriation (OCV), ICC can also consider on-chip variation effects during clusting.
If you are using a multicorner design flow, you can reduce skew variation by using RC constraint-based clusting. To use RC constraint-based clustering , you must use a clock configuration file to specify the clock tree structure.
Enabling on-chip-variation-aware clustering
The optional OCV-aware clustering considers the timing constraints between clock sinks to influence clustering. Sinks with timing-critical paths driven by the same gates will be clustered together. To enable the OCV-aware clustering , use the set_clock_tree_options -ocv_clustering true command. When you set this option, it applies to all clock trees in your design.
When you use timing derating, using the set_timing_derate command, OCV-aware clusting can result in better timing (worst negative slack and total negative slack) with minimal impact on the clock tree skew and insertion. However, suing OCV-aware clusting can increase the runtime and power.
Note:
You cannot use OCV-aware clustering with clock tree configuration files. If you specify the -ocv_clustering option when these options are set, ICC ignores the -ocv_clustering option. If you specify a clock tree configuration file after setting the -ocv_clustering command, ICC generates an error message and ignores both settings.
Enabling Logic-Level Babancing
If on-chip variation is an issue for your design, use the logic-level balacing mode.
Note:
If the level count or fanout varies greatly between the brances of the initial clock tree, logic-level balacing might not be able to achieve good clock tree QoR.
Be default, ICC balances the delay in each branch of the clock tree, but it does not consider the number of logic levels in each branch. ICC can take into account both delay and the number of logic levels when balacing the clock tree. This feature is called logic-level balacing.
Logic -level balacing can use buffers, inverters, or both to balance the logic levels. If you use only inverters for logic-level balancing and the initial clock network does not have balanced logic levels, the generated clock trees might be unbalanced by one level.
Logic-level Balancing Using Inverters
To enable logic-level balacing, use the set_clock_tree_options -logic_level_balance true command.
If you enable logic-level balancing, it applies to all clock trees. You cannot enable logic-level balancing on a per-clock basic.
If a clock tree contains a subtree that is not modified during clock tree synthesis ( either a don't touch subtree or a subtree within an interface logic model), ICC traces through the subtree to determine the number of logic levels contained in the subtree. ICC considers these logic levels when constructing the clock tree. If the subtree does not have balanced logic levels, ICC generates a warning message and uses the maximum number of levels in the subtree as the number of logic levels for the subtree.
Logic-level balancing with a don't touch subtree,
If your design contains hard macros, use the set_clock_tree_exceptions -float_pin_logic_level command to specify the number of logic levels within the hard macro. The number of logic levels must be a positive integer. If you do not specify the number of logic levels and ICC cannot derive the number of logic levels, ICC assumes that there are no logic levels within the hard macro.
Note:
When you remove float pin logic level information by using the
remove_clock_tree_exceptions -float_pin_logic_level command, ICC removes level information for the entire design. It does not remove level information for an individeal pin.
After clock tree synthesis finishes, ICC verifies that the clock tree are balanced. IF the number of logic levels varies between branches, ICC generates a warning message.
To enable OCV-aware clustering while running logic-level balancing, set both the -logic_level_balance and -ocv_clustering options to true with the set_clock_tree_options command.
Caution:
If you use logic-level balancing, do not run clock tree optimization with delay insertion. Doing so can unbalance the logic levels. If you use logic-level balancing when running the clock_opt command, delay insertion is automatically disabled during the embedded clock tree optimization.
Enabling Region-Aware Clock Tree Synthesis
Region-aware clock tree synthesis considers region constraints to create more balanced clock tree and to avoid DRC violations in designs with complex floorplans. For designs with region constraints, using region-aware clock tree synthesis can produce better QoR, This capability is enabled by default. If you want to disable region-aware clock tree synthesis, set the cts_region_aware variable to false, changing it from its default of true.
Region-aware clock tree synthesis can identify the following region constraints:
1) Logic modules with move bounds
2)Logic modules with target library subset constraints
3)Disjoint voltage areas
4)Power guides in power-down regions
During region-aware clock tree synthesis, the tool performs the follwoing steps:
1. Enables the clock_opt or compile_clock_tree coammand to group buffers in the target library by the same operating condition, power state, and target library subset associated with move bounds.
2. Partitions a design into regions according to constraints such as voltage areas, plan groups, and move bounds: hard and exclusive .
3. Associates each buffer group with a region and vice versa.
4. Associates each power guide with the region that contains it.
5. Performs region-aware clustering.
Design Partitions
No comments:
Post a Comment