PT - DSLG flow

Details

Last Updated: Wednesday, 11 August 2021 03:46

Published: Tuesday, 20 July 2021 05:22

Hits: 2438

PT DSLG (define scaling lib group):

In previous section, we saw that PVT variations can be modeled by using derating on cells. Voltage and Temperature variations were modeled by using derating. Different derating values were applied to different cells depending on ir drop and temperature of the cell. We had 4 voltages that were applied depending on if the cell was on clock path or data path:

1. Early Clock Voltage => shortest delay path for clock (fast clk)
2. Early Data Voltage => shortest delay path for data (fast data)
3. Late Clock Voltage => longest delay path for clock (slow clk)
4. Late Data Voltage => longest delay path for data (slow data)

Derates are inaccurate, and a lot of spice simulations have to be performed on different cells to figure out the value of derates for a given voltage drop. A lot of things are not accounted for when estimating derates, as it's very time consuming process. For ex, impact of voltage on drive strengths, input slews, output loads, pin caps, etc are not accounted for. We had to use derating, because we didn't have libraries for each and every voltage and temperature combination. However, if we did have continuous libraries for each and every voltage and temperature, then we could accurately calculate the delay of any cell, by figuring out it's voltage and temperature, and then calculating it's delay at that corner from the library. This would be much more accurate than the derate approach. This is known as the "scaling" methodology. This scaling flow from synopsys PT is called DSLG (define scaling lib group) flow.

There are 2 different techniques employed in DSLG:

1. Library scaling: Library scaling is a known technique that performs voltage and temperature scaling by interpolating data in libraries that was characterized at different voltage and temperature corners. This cross-library scaling
allows us to analyze timing, noise, and power at voltage and temperature values that are different from that of the corner libraries. CCS libraries are generally used for scaling as the scaling is more accurate. NLDM libraries may also be used, although accuracy will be lower.

For library scaling, following guidelines should be followed:

1. All libraries should be checked by using Library Compiler Qualification System to make sure libraries an be scaled. All lib need to have identical cell names, pins names and identical arcs.
2. Linking library that is provided via using "link_library" cmd (or using min_library to specify min lib too) is still provided and is used for linking the design. This link lib can be present in only one of the groups defined using "define_scaling_lib_group". Rest of the libs provided are used for scaling purpose only. In DSLG flow link_library has no special meaning (as all libs in a group have same arc). link_library is used as a fallback library, when PT can't continue with DSLG flow.
3. 1D scaling requires atleast 2 libs. General 2D scaling requires at least 3 libs. Temp and Voltage are treated as separate scaling dimension. PT currently supports 3 different types of scaling formation => 2^n on the grid, (2n+1) and (n+1). For single voltage domain, it doesn't matter, but when we have multiple voltage domain on same cell (such as level shifters)l, then scaling is more complex.
4. Delay can usually be interpolated linearly. But for setup, hold, recovery, removal, min pulse width (MPW), min period (MP) constraints, etc., more accurate non linear interpolation is done. 
5. For single voltage design running in single mode, we don't need to specify PVT cond, as there's only 1 lib to use. We do provide op cond for PVT, but the values in there aren't used for anything.

Besides modeling voltage and temperature changes, scaling reduces the number of libraries required for the analysis of multivoltage designs and therefore reduces the library characterization effort. Usually only voltage scaling is done, and derating is still used to account for temperature variations. Since Temperature variation is much less (only +/- 15 degrees or so), and scaling is not very accurate for this (as temperature and delay don't follow a monotonic relation at low nm tech), we don't usually do temperature scaling.

PT cmd: define_scaling_lib_group <libs> => To define a library group for scaling. We use this cmd multiple times to define multiple library groups to cover different portions of the design. We need different groups for diff libs that contain diff kind of cells as svt, lvt, level shifter, special cells, hard IP, etc. We can't scale data from lvt to svt or vice versa. So, we can't have these in same group for scaling purpose. Moreover, each library can be part of only one library group.

pt_shell> define_scaling_lib_group {lib_0.9V_0C.db lib_1.05V_0C.db lib_1.3V_0C.db} => This creates a lib grp with 2 libraries used to scale data from 0.9V-1.3V. PT reports a messages as "completing scaling lib gropus, loading db files ... scaling complete". That means all libs were consistent and scaling could be performed. SLG-308 and SLG-318 errors indicate that some arcs in link lib aren't there is scaling libs, and scaling can't be done. These will need to be fixed or else flow will fall back to link_library for timing.


2. Exact matching: As an alternative to library scaling, we can use library data in an exact-matching flow, where operating conditions must exactly match one of the libraries. In this flow, PrimeTime chooses a matching library based on the operating conditions applied to the specific design cell instances. If no matching library is found, PrimeTime issues an error message (or SLG-216 warning) and does not perform scaling. This warning helps you detect mistakenly applied operating conditions. Exact matching is used in conjunction with scaling. We specify exact matching for memories, phy and other hard macros, which don't have well defined relationship with voltage and Temperature (also internal paths are hidden, so hard to say how do the interface paths scale). In this case, we just do a exact match

PT cmd: define_scaling_lib_group -exact_match_only <libs> => same cmd as above, except we need to add the option -exact_match_only"

pt_shell> define_scaling_lib_group -exact_match_only {lib_0.9V_0C.db lib_1.0V_0C.db lib_1.1V_0C.db} => Does exact match only. If no matching corner library is found, the tool issues SLG-216

3. Best matching: As an alternative to exact matching, we also have a best-matching flow. Here, closest lib is found (when an exact match is not avilable) and that lib is used for analysis. Syntax same as above (This option not yet available in PT docs as of 2020).

pt_shell> define_scaling_lib_group -best_match {....}


NOTE: There's an extra option "-exclude_rail_names" to ignore certain rails for scaling or matching purpose (for rails that are irrelevant for timing analysis on an IP. i.e SRAM voltage inside an IP, where SRAM paths are not exposed to IP pins, we can exclude SRAM voltage power rail for matching purpose). This option not yet available in PT docs as of 2020.

pt_shell> define_scaling_lib_group -best_match  -excluded_rail_names {  VBB VPP BIASNW VDD_SRAM ... } { lib1.db lib2.db ... }

Additionally, we can set this user attribute to tell the tool to not scale certain IP, etc:

pt_shell> set_user_attribute -quiet [get_lib_cells */IP_SRAM] is_scalable false

DSLG flow:

1. Read library: link library as before with one of the timing library. In DSLG flow, link_library is just a fallback library to use in case something goes wrong with "scaling lib", and DSLG flow is not run.

2A. Read netlist:

• Read verilog netlist: read_verilog ...
• Set DSLG libs: define_scaling_lib_group <libs> => link library above may be used at most in one these groups. When finished, it prints "scaling complete" message
• report_lib_groups -scaling -show {voltage temp process} > ~/dslg_grp.txt => Once lib groups ared defined, we can report all scaling groups defined above , by using report_lib_groups cmd. It shows all groups along with the libs, their voltage+Temperature that we are using for that group. One of the groups is used for each cell in design. For seeing summarized info, just use "report_lib_groups -scaling"
• linking: link cmd not needed as above cmd does linking, if linking wasn't done already.
• list_libraries > ~/all_libs.txt => lists al libraries.. see detail of cmd in "PT Object access functions" section
• report_design => lists op cond. see detail of cmd in "PT-OCV" section

2B. Read parasitics file => Read spef file as before.

3A. Read constraints: Read all constraints as FP, MCP, SCA (set_case_analysis), etc.

3B. Setting Temp and Voltage: Here we have to set Voltage and Temperature for each cell in design. Previously we used set_operating_conditions cmd to set op_cond for the design. That specifies PVT for the whole design (either 1 set of PVT or 2 sets of PVT depending on analysis mode). For OCV flow where we needed to specify diff PVT for each cell, we specified diff derating for each cell in design. Here in DSLG flow, we use a combination of derating and scaling. First we set voltage and temperature for each cell using set_voltage and set_temperature cmds:

• set_operating_conditions <WCCOM> => sets op cond. See in "PT - OCV" section for details
• set_voltage => defines voltage on pwr nets or pins. For pins, we specify the cell name and the power pins of that cell to apply the voltage. We can  specify all 4 kinds of voltage for a power net - early clk/data, late clk/data depending on whether the cell is on clk path or data path. By default voltages apply for both data and clk. If we want to specify a diff voltage for clk path, we need to use option "-clock". By default voltages apply for both early and late. If we want to specify a diff voltage for late, we need to use option "-min". min or max refers to path delay here, so min means min delay (i.e fastest case), while max means max delay (i.e slowest case). There's a -dynamic option that specifies portion of voltage change that varies with frequency (i.e ripple in voltage supply). Frequency o this ripple is several clk cycles. This dynamic portion is considered during capacitive coupling analysis and various pessimism removal optimizations. This option is not used generally.
  
  • syntax for least voltage applied to both data/clk paths: set_voltage <max_delay_voltage> -dynamic <dyn_max_delay_voltage> -object_list <list_of_power_nets> => These options are for max delay (i.e slowest path). Add -min option to specify voltage for min delay (i.e fastest path). Applies to both clk and data if -clock not specified.
    
    • ex: set_voltage 0.540 -object_list {VDD_SOFT VDD_ON} => Here 0.54V is specified on power net VDD_SOFT, VDD_ON for both clk/data and for both early/late paths
    • ex: set_voltage 0.540 -min 0.562 -object_list VDD_SOFT => Here 0.562V is applied on early path (both clk/data), and 0.54V on late paths (both clk/data).
    • ex: set_voltage -clock 0.540 -min 0.562 -object_list VDD_SOFT => Here max/min delays are applied only on clock path. For data path, max/min delays are applied if set_voltage used without "-clock" option.
  • We also have an option to set voltage directly on pg pin of a cell, if we want to override what's provided on power net.Here we use -cell option to specify cell list, and -pg_pin to specify each pg pin of cell.
    
    • ex: set_voltage 0.04 -min -0.05 -cell I1 -pg_pin_name GND => sets "GND" pin of cell "I1" to 0.04V and 0.05V
    • ex: set_voltage -pg_pin VDD_SRAM -cell [get_cells I_top/sram_cell] 0.75 => Here we are setting pg pin of sram directly with a voltage. NOTE: voltage value is specified at end of cmd, and not in middle.
  • The way to use "set_voltage" is to first read in UPF file (which specifies power domain and power connections). Then specify voltages on these power nets or on each instance power pin.
  • In case you don't have an UPF file, you will need a pg verilog netlist, which has power pin connections for each instance of cell. Then we can use set_voltage to specify voltages on these power nets or on each instance power pin.
  • NOTE: since voltage may not be set for each every cell in design, there is a voltage priority sequence that's followed in case of voltage setting conflicts or voltages not defined explicitly:
    • Firstly, default supply voltage set via "voltage_map" in liberty file is taken as voltage.
    • If set_operating_condition is used, then that is applied to the design.
    • Then if set_voltage is applied on supply net, then that takes priority over the previous two. However, if set_voltage is applied on PG pin of a cell, then that takes highest priority.
• set_temperature => It's the counterpart of set_voltage for setting temperature. We can specify min and max case temp for cells on the design, so that are timed and optimized at the specified temperature. min and max refer to min delay (best case) and max delay (worst case). Min/Max case are used for early and late paths.
  
  • syntax: set_temperature <max_case_temp> -min <min_case_temp> -object_list <list of cells>
    
    • ex: set_temperature 125 -object_list [get_cells "I1 I2"] => this specifies both min and max case temp on this cell to be 125C.
    • ex: set_temperature 125 -min 25 -object_list [get_cells "I1 I2"] =>here min_case (best_case) temp is 25, while max case (worst case) temp is 125 for both cells.
  • NOTE: most of the times, we don't use temperature scaling, so we just use derating numbers, and not use this cmd at all.
• check_timing -override_defaults operating_conditions => Very imp to run this cmd. This operating cond check issues warnings as SLG* which need to be fixed. For scaling lib groups, it issues warnings if operating condition is set beyond the range of the libraries in the scaling group. For exact-matching library groups, issues a warning when operating conditions do not match any of the libraries in the scaling group For cells that are not part of either exact matching or scaling groups, it uses operating condition in link lib, and if different, it issues warnings.

4. Generate reports => generate timing reports and all other reports for analysis. NOTE: most of the lib reporting cmds that we used earlier, report link_lib when used in DSLG flow, when in reality the lib being used for timing are "combo of scaled libs" or "best matched lib" which may be different than "link_lib".

Additional helpful reports for DSLG:

• report_delay_calculation => This cmd shows how the tool scales data for delay calculation. When used with the -thresholds option, it also reports cell instance operating condition and rail names. For example:
  • pt_shell> report_delay_calculation -from [get_pins cell/A] -to [get_pins cell/Z] -thresholds => shows all rail voltages and op cond.
• report_power_net_info => Once power nets are assigned voltages, this cmd may be used to dump out op voltages for all power nets in design.Even thogh PT docs show this cmd, and "man report_power_net_info" shows info for this cmd, but it errors out with "unknown cmd" in PT 2021 versions.
• report_power_pin_info =>

report_lib <lib_name> => Here we can check for op_cond defined in specified lib. Not very useful, as we can do that by manually looking into lib file. See detail of cmd in "PT Object access functions" section

report_cell <cell_instance_name> => this shows ref lib cell, OC used, voltages etc for given cell. In DSLG flow, OC cond shown are from This is very helpful cmd. see detail of cmd in "PT Object access functions" section

shows ref

ame as regulat PT flow until read_

More PT scaling related useful cmds:

1. report_lib_groups: Once lib groups ared defined, we can report all scaling groups defined, by using report_lib_groups cmd.

pt_shell > report_lib_groups -scaling -show {voltage temp process} > ~/tmp1.txt => It shows all groups along with the libs, their voltage+Temperature that we are using for that group. One of the groups is used for each cell in design. For seeing summarized info, just use "report_lib_groups -scaling"

2. report_delay_calculation => command. The report shows
the results using the link library, then the scaling library group results if applicable and valid.

set_voltage

set_operating_condition