set_timing_derate

set_timing_derate
set_timing_derate is a command that lets you constraint the timing a bit more. The idea and application is simple enough, but you might get confused with all the talk about process variation and OCV whenever someone starts on derate. Best option is, forget the OCV. 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.

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.

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.

7 Comments

  1. Pingback: Clock Uncertainty & set_clock_uncertainty | VLSI Pro

Leave a Reply

Your email address will not be published. Required fields are marked *