Constraints for PVT Corners

Normally Best/Worst PVT means the Fastest/Slowest operating condition of the circuit: typical Best(fastest) PVT is {process: fast, voltage: low, temperature: low} while worst  (slowest) PVT is {process: slow, voltage: high, temperature: high }.

However, recent technology process encounters inverse temperature effect, where cells might function faster at certain high temperature than low temperature, Thus it is suggested that you consult with the cell library provider on what PVT is fastest & slowest.


Notes:
The process fast means, that all transistors on the chip have combination of parameters which gives the minimum cell delay.

Also, We should know about RC corners. The width and thickness of wires (metal) are also may vary from chip to chip ( even on one chip:).  So , for the setup check, we should use RCWorst corner for extraction and one of PVT corners that gives you the max cell delay.

Explanation of Deration and OCV

1) Derating is simply another way of adding margin to the design. This allows you to scale all delays by a certain percentage to increase margin. This is not an SDC constraint, but a variable to set within the tool run script.

2) OCV is a timing mode ( like a single or BC/WC). This allows you to use variation from the libraries in performing timing checks for ensuring worst case scenarios.

How to fix max transition time violations?

The max transition time is one of the three Design Rules ( max fanout, max transition, max capacitance).

It is much more important than setup/hold timing.
As we all know, in STA, the delay of each std. cells is calculated from looking up the NLDM ( non-linear delay model) tables which is defined in library. These tables are two factors: input transition time, and output load. The result of table is the delay value of cell under certain transition and output load.

If the input transition or output load is out of range is within but not the values in NDLM, interpolation is utilized to calculate.
If the input transition or output load is out of range of NLDM , ext-interpolation is used to calculation. But it is natural the result would be rather in-accurate.

So the STA will be rather in-accurate. Timing analysis is un-believable.
Now, you can understand how important max tran is.
-- one more reason of fixing max transition violation is that bigger transition will result in bigger DC
    power consumption.
-- The margin in 30% of max transition is allowed.
For example, if the constraint of max transition is 1 ns, then 1.3 ns is allowed.

PVT Corners

Generally in most user environments, the process, voltage, and the temperature (PVT) point is specified by referring to a predefined operating condition in  a specific timing library. The library operating condition provides the system with values for P, V, and T, and these then are used to calculate derating parameters and other aspects of the analysis.

However, these are situations when there are no predefined operating conditions in the user timing libraries or the pre-existing operating conditions are not consistent with the user's operating environment.

Defining Operating Conditions in PD using SoC Encounter

I am using SoC encounter for project. I want to introduce operating conditions into the flow.

1. How these operating conditions are defined?
2. Is it dependent on Synthesis & RTL?
3. On what basis these operating conditions are decided?
4. What is the difference between prePD and postPD netlist?

Answers:
1. Using setOptCond command.
2. No.
3. Normally best case and worst case operating conditions is used for SoC           encounter do timing optimization for setup and hold.
4. PostPD netlist has complete clock tree structure and so more accurate               timing analysis with wire capacitance.

On-Chip Variation Delay Analysis

During timing analysis, the tool uses the on-chip variation(OCV) mode to perform timing, which models the effects of variation in operating conditions across the chip. This mode performs a conservative timing analysis by simultaneously applying minimum and maximum delays to different paths.

For a setup check, the tool uses maximum delays for the launch clock path and data path and minimum delays for the capture clock path, as shown in the following figure.

skew_opt Flow

The flow for using the skew_opt cmd is

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.