set_timing_derate
set_timing_derate set_timing_derate is a command that lets you constraint the timing. Forget the process variation and OCV for now and let's uncomplicate and first see how the command works.
Timing derate numbers are ratios used to derate(increase/decrease) the delay numbers you get in your timing reports. `derated_delay = delay + ((derate_factor - 1.0)*ABS(delay))`
Let's jump to some examples of set_timing_derate command.
`set_timing_derate -early 0.95` `set_timing_derate -late 1.05`
Here I am setting a derate of +5% on longest paths and a derate of -5% on the shortest path.
Look at the two setup timing reports below.
First, the timing report without derate specified.
Path 1: MET Setup Check with Pin max_count_reg_3_/CLK Endpoint: max_count_reg_3_/D (v) checked with leading edge of 'clk_in' Beginpoint: div_no[3] (v) triggered by leading edge of 'clk_in' Analysis View: func_max Other End Arrival Time 0.1035
- Setup 0.2065
- Phase Shift 8.0000
- CPPR Adjustment 0.0000 = Required Time 7.8970
- Arrival Time 5.1001 = Slack Time 2.7969 Clock Rise Edge 0.0000
- Input Delay 5.0000 = Beginpoint Arrival Time 5.0000 Timing Path:
Delay Derate Time
------------------------------------------------------------------------------------------------------------------------- div_no[3] v 3.2428 0.0001 5.0000 U82 inv1 3.2428 0.0006 0.0000 0.0000 1.0000 5.0000 U82 A v -> Y ^ inv1 1.6457 0.0335 0.0254 0.0000 1.0000 5.0254 U104 mux2x1 1.6457 0.0335 0.0000 0.0000 1.0000 5.0254 U104 B ^ -> Y v mux2x1 6.2156 0.0858 0.0747 0.0000 1.0000 5.1001 max_count_reg_3_ dff 6.2156 0.0858 0.0000 0.0000 1.0000 5.1001 ------------------------------------------------------------------------------------------------------------------------- Clock Rise Edge 0.0000 = Beginpoint Arrival Time 0.0000 Other End Path: ------------------------------------------------------------------------------------------------------------------------- Instance Arc Cell Load Slew Delay Incr User Arrival
Delay Derate Time
------------------------------------------------------------------------------------------------------------------------- clk_in ^ 6.5824 0.0001 0.0000 clk_in_L1_I1 cinv1 6.5824 0.0006 0.0000 0.0000 1.0000 0.0000 clk_in_L1_I1 A ^ -> Y v cinv1 6.5294 0.0097 0.0154 0.0000 1.0000 0.0154 clk_in_L2_I1 cinv1 6.5294 0.0097 0.0000 0.0000 1.0000 0.0154 clk_in_L2_I1 A v -> Y ^ cinv1 6.7317 0.0240 0.0207 0.0000 1.0000 0.0361 clk_in_L3_I1 cinv1 6.7317 0.0240 0.0000 0.0000 1.0000 0.0361 clk_in_L3_I1 A ^ -> Y v cinv1 27.6299 0.0357 0.0385 0.0000 1.0000 0.0746 clk_in_L4_I4 cinv1 27.6299 0.0357 0.0002 0.0000 1.0000 0.0748 clk_in_L4_I4 A v -> Y ^ cinv1 8.9172 0.0340 0.0282 0.0000 1.0000 0.1030 max_count_reg_3_ dff 8.9172 0.0340 0.0005 0.0000 1.0000 0.1035 -------------------------------------------------------------------------------------------------------------------------
You can see the "User Derate" column has a value of 1, which is the default derate value. The timing delays are calculated as per the func_max analysis view as can be seen by the header. In this case, it means the functional SDC constrainst and max corner libraries are used.
Now let us see the same path with the two aforementioned derate commands applied.
Path 1: MET Setup Check with Pin max_count_reg_3_/CLK Endpoint: max_count_reg_3_/D (v) checked with leading edge of 'clk_in' Beginpoint: div_no[3] (v) triggered by leading edge of 'clk_in' Analysis View: func_max Other End Arrival Time 0.0983
- Setup 0.2065
- Phase Shift 8.0000
- CPPR Adjustment 0.0000 = Required Time 7.8918
- Arrival Time 5.1051 = Slack Time 2.7867 Clock Rise Edge 0.0000
- Input Delay 5.0000 = Beginpoint Arrival Time 5.0000 Timing Path:
Delay Derate Time
------------------------------------------------------------------------------------------------------------------------- div_no[3] v 3.2428 0.0001 5.0000 U82 inv1 3.2428 0.0006 0.0000 0.0000 1.0500 5.0000 U82 A v -> Y ^ inv1 1.6457 0.0335 0.0267 0.0000 1.0500 5.0267 U104 mux2x1 1.6457 0.0335 0.0000 0.0000 1.0500 5.0267 U104 B ^ -> Y v mux2x1 6.2156 0.0858 0.0784 0.0000 1.0500 5.1051 max_count_reg_3_ dff 6.2156 0.0858 0.0000 0.0000 1.0500 5.1051 ------------------------------------------------------------------------------------------------------------------------- Clock Rise Edge 0.0000 = Beginpoint Arrival Time 0.0000 Other End Path: ------------------------------------------------------------------------------------------------------------------------- Instance Arc Cell Load Slew Delay Incr User Arrival
Delay Derate Time
------------------------------------------------------------------------------------------------------------------------- clk_in ^ 6.5824 0.0001 0.0000 clk_in_L1_I1 cinv1 6.5824 0.0006 0.0000 0.0000 0.9500 0.0000 clk_in_L1_I1 A ^ -> Y v cinv1 6.5294 0.0097 0.0146 0.0000 0.9500 0.0146 clk_in_L2_I1 cinv1 6.5294 0.0097 0.0000 0.0000 0.9500 0.0146 clk_in_L2_I1 A v -> Y ^ cinv1 6.7317 0.0240 0.0197 0.0000 0.9500 0.0343 clk_in_L3_I1 cinv1 6.7317 0.0240 0.0000 0.0000 0.9500 0.0343 clk_in_L3_I1 A ^ -> Y v cinv1 27.6299 0.0357 0.0366 0.0000 0.9500 0.0709 clk_in_L4_I4 cinv1 27.6299 0.0357 0.0002 0.0000 0.9500 0.0711 clk_in_L4_I4 A v -> Y ^ cinv1 8.9172 0.0340 0.0268 0.0000 0.9500 0.0979 max_count_reg_3_ dff 8.9172 0.0340 0.0005 0.0000 0.9500 0.0983 -------------------------------------------------------------------------------------------------------------------------
You can see that the data launching path is applied a derate of 1.05 and the capturing path is applied a derate of 0.95, and the values are modified accordingly. When you derate the setup analysis, you are increasing the delay on the data, so that it reaches even later. The clock is even faster due to 0.95 derate, so the chances of setup violations are greater than without any derate specified. If you go check the hold analysis reports, you will see that the launch path (which is early for hold) is applied a derate of 0.95 and the clock path will have a derate of 1.05.
You also have the option of targeting cells, nets, clock or data. `set_timing_derate -net_delay -late 1.05` `set_timing_derate -cell_delay -late 1.10` .....
Now let us look at another example. The set of commands I have given are: set_timing_derate -late 1.1 set_timing_derate -late -clock 0.95 set_timing_derate -early -clock 0.95
Here the clock paths for both launch and capture are given a derate factor of 0.95 and only the data path has a derate of 1.1.
Some more examples.
The command may differ slightly across tools, but most of the options and behaviour are the same.
Why use derate factors?
Now that we have seen how the command behaves in STA environment, let's get to the whys. Why do we specify timing_derate? It has to do with OCV or on chip variation. Components between chips or within a single chip can have different characteristic due to manufacturing process variation. For e.g. an AND gate located in two different locations in the same chip may exhibit different delay characteristics, even though they have the same cell layout while designing. A number of process stages, like litho and etching can be dependent on environment and can cause difference in channel size, interconnect thickness and dielectric thickness. This in turn creates small changes in delay characteristic. I will talk more about OCV in another post. For now, let us accept that the manufactured chip may not always exhibit the characteristic of one corner. Some cells may give you a delay number that falls within the worse range, while others may give a delay number that falls within the fast characterized range.
Most of the STA tools let you choose onchipvariation as a mode for analysis. Here you specify more than one operating condition. i.e. read in at least two sets of .libs characterized at different corners.
Then you set the analysis mode to OCV. `set_operating_conditions –analysis_type on_chip_variation –min $lib_min –max $lib_max`
In this case, your STA tool will pick delays from one corner for some paths, and the other corner for the rest. (Longest paths again will have max corner delays, and shortest paths min corner delays.)
Note that you do not need to specify `set_timing_derate` command to do an OCV analysis.
set_timing_derate lets you model OCV explicitly. For example, even if you have only one corner, you a are now able to take into account some timing difference between two paths by specifying different derates for early and late paths. You can also specify derates when you are using multiple libraries. The results are in turn more pessimistic, as the STA tool will have taken two different corners to calculate the Slack, AND then do a derated report. You can also specify timing_derates when your analysis mode is best_case/worst_case. In all reports, the effect of the command stays simple. Your delay numbers in the timing report are multiplied by the derate factors to give you a different Slack. How you apply it in your design is what makes your STA flow more robust, targeting specific paths and cells.