1. Determine the existing clock latencies by doing a quick clock_opt run.
Use the set_latency_adjustment_options cmd to identify the timing relationships between a source clock and associated generated clocks or virtual clocks.
For example, for a generated clock, enter
icc_shell>set_latency_adjustment_options -from_clock master_clk -to_clk gen_clk
Use the skew_opt -clock_balancing_only to configure interclock delay balancing groups. The generated skew_opt script includes the annotation of the changed ideal latencies for clock objects. In addtion, to ensure the same I/O latencies that are seen by skew_opt and the psynopt cmd that is embedded in clock_opt, you should perform clock routing seperately from the clock_opt cmd to avoid an addtional update_clock_latency call inside clock_opt after clock routing.
The following script shows an example of how to determine the latencies for your design:
icc_shell>place_opt
icc_shell>save_mw_cel -as placed
icc_shell>close_mw_cel
icc_shell>open_mw_cel placed
icc_shell>set_latency_adjustment_options ...
icc_shell>skew_opt -clock_balancing_only
icc_shell>clock_opt -inter_clock_balance -update_clock_latency -no_clock_route
icc_shell>route_zrt_group -all_clock_nets -reuse_existing_global_route true
icc_shell>extract_rc
2. Run the skew_opt command.
icc_shell>skew_opt
icc_shell>close_mw_cel
3. Load the updated clock latencies and useful skew solutions.
icc_shell> open_mw_cel placed
icc_shell> set_latency_adjustment_options ...
icc_shell> source skew_opt.tcl
4. Perform clock tree synthesis and optimization with interclock delay balancing.
icc_shell> clock_opt -inter_clock_balance -no_clock_route
icc_shell> route_zrt_group -all_clock_nets -reuse_existing_global_route true
icc_shell> extract_rc
icc_shell> route_opt
Note:
Because the skew_opt cmd works across all clock domains in your design, you must perform interclock delay balancing when running clock tree synthesis after skew_opt.
In addtion, do not update the clock latency after clock tree synthesis
( clock_opt -update_clock_latency option or update_clock_latency cmd). Updating the clock latency after clock tree synthesis invalidates the script file generated by skew_opt.
Balancing The Skew Using Skew Groups
You can selct a group of clock sinks from the same clock domain to form a subgroup named a skew group. ICC automatically balances the skew of clock sinks, including the clock pins of integrated clock-gating cells, enable flip-flops, and clock dividers, in each skew group. You can specify different skew and insertion delay constraints for different skew groups in the same clock domain.
Skew Group Flow
Guidelines for Defining Skew Groups
When defining a skew group, use the following guidelines:
- Select nonhierarchical pins such as leaf stop pins, leaf float pins, the clock pins of integrated clock-gating cells, and the clock pins that start the sequential timing arcs.
- Select pins from the same master clock domain only. Pins from different generated clock domains are allowed in the same skew group.
- Each pin can only belong to one skew group.
- No pins should have upstream-downstream dependency in the same skew group.
- A skew group that constains any nonstop pins or clock pins of integrated clock-gating cells creates dependency on the skew group to which their downstream sink pins belong.
- Clock sinks that are not defined in any skew groups are automatically included in the default skew group.
- A skew group is independent when only clock sink pins are defined in the group.
- Only one level of dependency is allowed between skew groups.
For example, skew group A is dependent on skew group B, so no skew groups should be dependent on skew group A.
- No dependency loop between skew groups is allowed.
For example, skew group A is depend on skew group B, and skew group B should not be dpendent on other skew groups
- If one skew group is dependent on other skew groups, only one of which is allowed to have independent subtrees.
For example, skew group A is dependent on skew group B, C and D, so only one skew group out of B, C, and D is allowed to have independent subtrees.
The guidelines also apply to the default skew group.
To create a skew group, use the set_skew_group cmd or choose Clock > Skew Group > Set Skew Group in the GUI.
For example, the following cmd creates a skew group named grp1 on the timing-criticle path from reg_0_/CLK to gen_ck_reg_1_/DATA with two clock sinks , reg_0_/CLK and gen_ck_reg_1_/CLK,
as below
icc_shell>set_skew_group -name grp1 { reg_0_/CLK gen_ck_reg_1_/CLK}
Skew Group grp1 with two clock sinks
The skew group grp1 automatically balances the skew, so you do not need to either adjust the clock latencies, latency A and latency B, or specify the float pin value at reg_0_/CLK to aviod setup violations.
You can specify the skew and insertion delay constraints by using the -target_skew and
-target_early_delay options respectively. Note that the skew group constraints take precedence over the clock tree design rule constraints and the design rule constraints of the logic library and the design. If you do not specify the skew or insertion delay constraints for a skew group, the skew group inherits the most strick clock tree design rule constraints of the clock sink in the clock domain. The default skew group always uses the clokc tree design rule constraints.
To report the skew of each skew group, use the report_clock_tree -skew_group cmd.
Validating and Committing Skew Groups
After creating or modifying a skew group, you should always commit the skew group by using the commit_skew_group cmd or choose Clock > Skew Group > Commit Skew Group in the GUI. The cmd checks the skew group in the design against the guidelines. When the cmd detects an invalid skew group, it generates an error message and makes no changes to the netlist. If all skew groups are valid, the cmd restructures the clock trees to seperate the skew groups. When you specify the
-check_only option, the cmd only validates the skew groups, but it does not restructure the clock trees.
You can report the settings of skew groups by using the report_skew_group cmd or by choosing the Clock > Skew Group > Report Skew Group in the GUI.
To remove a skew group, use the remove_skew_group cmd or choose Clock > Skew Group > Remove Skew Group in the GUI.
Limitations of Using Skew Groups
Use skew groups has the following three limitations:
- If you run the remove_clock_tree cmd on a design that constains skew groups, you must rerun the commit_skew_group cmd before balancing the clock trees again.
- If there is dependency between skew groups, the -target_skew and -target_early_delay options are not honored.
- You cannot use skew groups with features such as clock tree configuration files, logic-level balancing, and OCV-aware clustering.
Resynthesizing The Clock Trees
In some cases, to achieve the best results, you must fine-tune the clock tree synthesis settings, then resynthesize the clock trees.
Resynthesizing the clock trees consists of the following steps:
1. Input the postplacement design that you saved before performing clock tree synthesis.
If you did not save the design before running clock tree synthesis ( or if you want to keep some synthesized clock trees, but resynthesize others), you must remove the synthesized clock trees before you can resynthesize the clock trees. The resulting design might not be identical to your design before running the initial clock tree syntheiss, because some gates might have been moved or sized during the clock tree synthesis process.
2. Validate the setup
3. Fine-ture the clock tree synthesis settings.
4. Resynthesize the clock trees.
The following sections describe these steps.
Validating the setup
If the synthesis results do not meet your requirements, check the following items before fine-tuning:
-- The input design
Ensure that the input design meets the requirements for clock tree synthesis.
-- TLUPlus models
-- The clock root
Verify that you have correctly defined the clock root, including setting a driving cell if the clock root is a top-level input port. Verify that the attributes of the clock root, such as the input transition time and output capacitance , are correct. Verify that the library model for the root cells is accurate.
-- The Clock Sinks
Run the report_clock_tree -exceptions cmd to verify that the clock tree exceptions ( both implicit and explicit ) are correctly set.
-- The design rule constraints
To verify the design rule constraints and check that they are realistic, use the report_clock_tree cmd to report on the clock tree ( or choose Clock > Report Clock Tree in the GUI). If your clock trees have too many cells or levels, this typically indicates that the design rule constraints are too tight.
Resynthesizing The Clock Trees
You can resynthesize the clock trees either by using the clock_opt cmd or by using standalone clock tree synthesis.
Modifying the Nondefault Routing Rule
If your design is congested, you can modify the nondefault routing rule of an existing clock tree. To modify the nondefault routing rule, use the mark_clock_tree -routing_rule cmd ( or choose Clock > Mark Clock Tree in the GUI and specify the routing rule in the "Routing rule" field). In the same way that you specify the nondefault rule for unsyntheiszed clock trees, you can use the default routing rule for the nets connected to the clock sinks by specifying the
-use_default_routing_for_sinks level_count option ( or by selecting "Routing rule" in the GUI and specifying the level count in the "Use default routing for sinks at level" field). In addtion, you can specify the layers to use for clock routing by specifying the -layer_list layers option ( or by selecting the layers in the GUI).
Note:
If you specify an undefined routing rule or layer, the mark_clock_tree cmd exists with an error message and does not change the existing settings.
No comments:
Post a Comment