PT - on chip variation
- Details
- Last Updated: Friday, 23 July 2021 23:57
- Published: Wednesday, 10 April 2019 21:49
- Hits: 2598
ocv => on chip variation:
Regular PT is run across various PVT corners (Process=fast/slow/typ, Voltage =max/min/typ, Temperature=max/min/typ), but that assumes all PVT parameters are same on each die (i.e there is no within die variation). There is large wafer to wafer process variation as different wafers may get slightly different treatment, causing variations from 1 wafer to other. Some wafers may come out hot (fast), while some wafers may come out cold (slow). Within a single wafer, some dies in the center may see a slightly different process corner than some dies on the edges of wafer. These variations may make transistors faster (due to fast process) or slower (due to slow process). But we know that all these die to die variations are bounded by the slow/fast process corner. All dies are also bounded by voltage and temperature corner, as we don't allow ambient voltage and temperature to be out of these limits when running silicon. So, no matter what the PVT corner is, we are always guaranteed to meet timing.
This assumes that all transistors on a single die are on a single PVT corner. So, when running timing, we treat all gates as either at fast PVT corner or slow PVT corner within a single die, but do not allow for some gates to be fast while some gates to be slow at the same time. However in reality, within a die, variations may happen (known as OCV), which may cause different delays for different gates on same chip. These differences are not as extreme as die to die variation, but still are large enough at low nm tech to cause paths to fail timing. To allow us to do accurate timing in such scenario, PT allows us to set op cond to ocv mode via "set_operating_conditions" cmd.
set_operating_conditions:
This cmd is supported in both Synthesis and STA tools by synopsys. It's not an SDC cmd, and as such other tools are not required to support it. Cadence tools don't support it. Also, this cmd options are slightly different between Synthesis and STA tools from Synopsys.
PT can perform 3 types of analysis:
1. single mode(SM) - default: PT uses a single set of delay parameters for the whole circuit, based on one set of process, temperature, and voltage conditions. For launch clk and data path, and capture clk, it uses delays from that one set of PVT.
2. best-case/worst-case mode(BCWC): PrimeTime simultaneously checks the circuit for the two extreme operating conditions, minimum and maximum. For setup checks, it uses maximum delays for all paths. For hold checks, it uses minimum delays for all paths. This mode lets you check both extremes in a single analysis run, thereby reducing overall runtime for a full analysis. Not very useful, as we run both setup/hold across BC and WC PVT in 2 separate single mode runs, so that's more complete than this BCWC run. This doesn't seem to be supported anymore.
3. on chip variation mode(OCV): PrimeTime performs a conservative analysis that allows both minimum and maximum delays to apply to different paths at the same time. For a setup check, it uses maximum delays for the data path and minimum delays for the clock path. For a hold check, it uses minimum delays for the data path and maximum delays for the clock path.
For a single timing path, there are 3 separate delays that are considered = Launch_clk_delay, data_path_delay and capture_clk_delay. To account for the worst case possibility, we assign different delays for setup and hold checks. For setup check, we assign max delay to Launch_clk_path and data_path, while min delay to capture_clk path. For hold checks, we assign min delay to Launch_clk_path and data_path, while max delay to capture_clk path. So, let's see what does PT do for the 3 diff kindof analysis. We write delays in form of max/min. max implies delays for Setup checks, while min specifies delays for hold checks:
- SM: Here there's only 1 lib, so both setup and hold path delays are same for a given path. (max,min delay are still taken from one same lib, but min or max below implies whether shortest or longest path considered)
- Launch clk delay => max/min delay (same)
- Data path delay => max/min delay (same)
- Capture clk delay => min/max delay (same)
- BCWC: Here there are 2 libs = WC lib and BC lib. WC lib is chosen for all setup path delays, while BC lib is chosen for all hold path delays (WC/BC below implies which lib file is chosen. WC lib chosen for setup, BC for hold)
- Launch clk delay => max/min delay (WC/BC)
- Data path delay => max/min delay (WC/BC)
- Capture clk delay => min/max delay (WC/BC)
- OCV: Here there are 2 libs = WC lib and BC lib. For setup path delays, WC lib is chosen for launch clk + data path, while BC lib is chosen for capture clk. In contrast, for hold path delays, BC lib is chosen for launch clk + data path, while WC lib is chosen for capture clk. (setup or hold: WC lib for max delay, BC lib for min delay)
- Launch clk delay => max/min delay (WC/BC)
- Data path delay => max/min delay (WC/BC)
- Capture clk delay => min/max delay (BC/WC)
Clock reconvergence pessimism (CRP)
OCV suffers from clock reconvergence pessimism problem. We can remove this pessimism from slack calc and min time pulse width check. Clock reconvergence pessimism (CRP) is a difference in delay along the common part of the launching and capturing clock paths, under OCV analysis. The most common causes of CRP are reconvergent paths in the clock network, and different min and max delay of cells in the clock network. The shared segment is assumed to have a minimum delay for one path and a maximum delay for the other path. This condition can occur any time that launch and capture clock paths use different delays, most commonly with OCV analysis (see Table 11-4 on page 11-26 of PT documentation). Automated correction of this inaccuracy is called clock reconvergence pessimism removal (CRPR). We need to set above attribute to true (which is set to true by default, so no need to do anything):
set timing_remove_clock_reconvergence_pessimism true
syntax:
set_operating_conditions: options:
-analysis_type => single or bc_wc or on_chip_variation. bc_wc and ocv are collectively referred to as min-max mode as they use min and max conditions in same run. (For PT: we don't have bc_wc option here, just the 1st and 3rd options supported. For DC/Genus, all 3 options supported, but documentation doesn't list "single" as an option, as it's default one if this option is not used)
-library <lib_name>: this speciifes library containing above operating_conditions(W_150_1.65) in it. .lib file may have multiple libraries, but in our case, we just have one library specified at the top of the .lib file [library (STD_W_150_1.65_CELL.db) {]. link_library in .synopsys_dc.setup specifies which .db(.lib) file (/db/.../synopsys/bin/STD_W_150_1.65_CELLS.db) to look for in finding this library. If no lib specofed, then link lib used.
-min/-max <op_cond> => specifies min/max op cond for ocv/bcwc mode. For sm mode, we just specify single op cond directly (withot any option). If op cond not specified at all by using this cmd, then tool uses the default operating condition of the library to which the cell is linked (using link_path). If only max specified then max is used for min also.
-min_library/-max_library <lib_name> => specifies lib that contains min/max op conditions specified above via -min/-max (used in ocv/bcwc mode only). If SM, we use "-library <lib_name>" option to speciify single library containing above operating_condition. link_library specifies which .db(.lib) file (/db/.../synopsys/bin/STD_W_150_1.65_CELLS.db) to look for in finding this library.
-min_phys/-max_phys <resource_name> => specifies resource that contains min/max RC values. This option is only supported in Synthesis tool for Physical runs.
-object_list <object> => This is optional. By default, op cond applies on whole design, but we can also specify diff op cond on diff objects by setting op cond differently for diff objects. This option is for legacy purpose, and not used at all. To specify diff op cond for diff cells, use "set_voltage" cmd.
NOTE: op_cond speciified in.lib files as below. Look in "liberty" section of "vlsi digital standard".
operating_conditions("BCCOM") { process : 0.6 ; temperature : 20 ; voltage : 5.25 ; tree_type : "best_case_tree" ; } => op cond is BCCOM (best case cond).
operating_conditions("WCCOM") { process : 1.3 ; temperature : 150 ; voltage : 1.65; tree_type "worst_case_tree" } => op cond is WCCOM (worst case cond).
- ex: set_operating_conditions -min BCCOM -max WCCOM -analysis_type on_chip_variation =>switches design to ocv mode.Hhere min/max op cond specified. BCCOM used for min delay calc while WCCOM used for max delay calc. No lib specified, so default lib used to check for these op cond. If these op cond not found in default lib, then error is issued. Usually 2 diff lib contain these 2 op cond, so -min_lib and -max_lib also specified.
- ex: set_operating_conditions -analysis_type on_chip_variation => switches design to ocv mode. default lib used. since min/max conditions not specified, design is using single op cond specified in default lib (so it's essentially running in SM, and NOT OCV)
report_design: report_design is used to report op cond defined for current design. This cmd is always run when running STA/Synthesis to make sure all the op cond were picked up correctly.
pt_shell> report_design
Design Attribute Value
---------------------------------------------------------------------------
Operating Conditions:
analysis_type on_chip_variation
operating_condition_min_name ff_1p1v_-40c_cbest
process_min 1
temperature_min -40C
voltage_min 1.1
tree_type_min balanced_case
operating_condition_max_name ss_0p9v_125c_cworst
process_max 3
temperature_max 125
voltage_max 0.78
tree_type_max balanced_case
Wire Load: (use report_wire_load for more information)
wire_load_mode top
wire_load_model_max zwlm ... => similarly for min ...
Design Rules:
max_capacitance -- ... => and lot other param