STA ETS flow

ETS:

ETS is encounter timing system, which is a STA timing tool from cadence. It's similar to PT.

Steps: Below are the steps to run ETS.


dir: /db/proj_ch/design1p0/HDL/ETS/digtop
cmd: ets -10.1_USR1_s096 -nowin -f scripts/check_timing_mmmc.tcl | tee logs/run_et_mmc_timing.log => -nowin means no window, else gui window comes up

File: scripts/check_timing_mmmc.tcl:
----
setDesignMode -process 250 => sets process tech to 250nm. For 180nm, use 180. For 150nm, use 150.

#read min/max lib
read_lib -max /db/../synopsys/src/PML30_W_150_1.65_CORE.lib /db/../synopsys/src/PML30_W_150_1.65_CTS.lib

read_lib -min /db/.../synopsys/src/PML30_S_-40_1.95_CORE.lib /db/.../synopsys/src/PML30_S_-40_1.95_CTS.lib

#read verilog
read_verilog ../../FinalFiles/digtop/digtop_final_route.v

set_top_module digtop => only when we run this, is when all max/min lib, netlist files are analyzed.

source scripts/create_views.tcl => source views file, same as from Autoroute dir

set_analysis_view -setup {func_max func_min scan_max scan_min} -hold {func_max func_min scan_max scan_min}

#set propagated clk by entering interactive mode
set_interactive_constraint_modes [all_constraint_modes -active]
set_propagated_clock [all_clocks]
set_clock_propagation propagated
set_interactive_constraint_modes {}

#read min/max qrc spef files
read_spef -rc_corner max_rc ../../FinalFiles/digtop/digtop_qrc_max_coupled.spef
read_spef -rc_corner min_rc ../../FinalFiles/digtop/digtop_qrc_min_coupled.spef

#wrt sdf
write_sdf -min_view func_min -max_view func_max -edges check_edge ./sdfs/digtop_func.sdf => has both min/max not in same file
write_sdf -min_view func_max -max_view func_max -edges check_edge ./sdfs/digtop_func_max.sdf => min/max are both equal to max
write_sdf -min_view func_min -max_view func_min -edges check_edge ./sdfs/digtop_func_min.sdf => min/max are both equal to min

NOTE: synopsys sdc file used in create_views.tcl is used to gen the delay in sdf file. set_load units may not get set appr, causing mismatch in delay num for all o/p buffers b/w SNPS sdf and CDNS sdf. Look in PnR_VDI.txt for more info.

#set_analysis_mode: sets analysis mode for timing analysis.
#-analysisType => single: based on one op cond from single lib, bcwc: uses max delay for all paths during setup checks and min delay for all paths during hold check from min/max lib, onChipVariation: for setup, uses max delay for data path, and min delay for clk path, while for hold, uses min delay for data path, and max delay for clk path. default is onChipVariation.
#-cprr < none | both | setup | hold > => removes pessimism from common portion of clock paths. none: disables removoal of cprr, while both enables cprr for both setup and hold modes. default is none.

set_analysis_mode -analysisType bcWc -cppr both

#setAnalysisMode => this is the equiv cmd in vdio as set_analysis_mode in ETS. diff is that default analysisType is set to single (if only 1 lib is provided) or bcwc (if 2 lib are provided).

#set_delay_cal_mode -engine aae -SIAware true => this is used to set timing engine, as well as to specify if we want SI(similar to PTSI)

#log file in log dir to report timing, clk, violations, etc. If this file is clean, no need to look at files in rpts dir.
check_timing -verbose >> $check_timing_log
report_analysis_coverage >> $check_timing_log
report_case_analysis >> $check_timing_log
report_clocks >> $check_timing_log
report_constraint -all_violators >> $check_timing_log => If we see any max_cap violation, we can run "report_net_parasitics -rc_corner " to find out cap of that net. We can get gate cap of all load atached from .liberty files. NOTE: wire/via cap(in rc table) and gate cap(in stdcell lib) changes with corners.
report_inactive_arcs >> $check_timing_log => This is put at end of file since it's very long.

# generate separate reports for setup and hold for func/scan
# report_timing: reports timing (used in vdio/ets)
#-early/-late => use -early for hold paths and -late for setup paths.
#-path_type full_clock => shows full expanded path (in PT, we use full_clock_expanded to get same effect)
#-max_paths => max # of worst paths irrespective of end points (i.e paths with same end points will show up multiple times here). If we do not want to see multiple paths with same end point, we can exclude those by using -max_points. In this case, it shows only 1 worst path to each end point. If we want to see specific # of paths to each end point, use -nworst option along with -max_points. We can only use one of the 2 options => max_paths or max_points.
#-net => adds a row for net arc. This separates net delay from cell delay (else by default: net delay is added to the next cell delay)
#-format { .. } => default format is: {instance arc cell delay arrival required}. With -net option, it shows net also. net delay is shown with i/p pins (A,B,C), while cell delay is shown for o/p pins (Y). additional options as load, pin_load, wire_load are also helpful.
#-view => By default, the command reports the worst end-point(s) across all views. if we want to view results for a particular view. use that view. The view should have already been created using "create_analysis_view" and set using "set_analysis_view". i.e:
=> create_analysis_view -name func_max -delay_corner max_delay_corner -constraint_mode functional
=> create_analysis_view -name func_min -delay_corner min_delay_corner -constraint_mode functional
=> set_analysis_view -setup {func_max func_min} -hold {func_max func_min} => now, we can run setup or hold analysis on both func_max and func_min. For this run, we already set view to "-setup {func_max func_min scan_max scan_min} -hold {func_max func_min scan_max scan_min}"
report_timing -from -to -path_type full_clock -view func_max -early => reports partcular hold path for view func_max. NOTE that this will work only if hold is calc for analysis_view "func_max".

#func setup/hold at func_min/func_max
#if we do not specify -view below, then all views set currently will be used. So, for "early" all views "func_max, func_min, scan_max, scan_min" will be used and shown in the single report. Each path will show a view so it's easy to see which view was used for that particular timing of path. However, it's better to separate out func view and scan view reports. We could have also set_analysis_view to just func_max/func_min for this run, and then for the 4 scan reports, we could have set views to just scan_max/scan_min. It's same either way.
report_timing -path_type full_clock -view func_max -max_paths 2000 -early -format {instance cell arc load slew delay arrival required} >> $func_rptfilename
report_timing -path_type full_clock -view func_max -max_paths 2000 -late -format {instance cell arc load slew delay arrival required} >> $func_rptfilename
report_timing -path_type full_clock -view func_min -max_paths 2000 -early -format {instance cell arc load slew delay arrival required} >> $func_rptfilename
report_timing -path_type full_clock -view func_min -max_paths 2000 -late -format {instance cell arc load slew delay arrival required} >> $func_rptfilename

#scan setup/hold at scan_min/scan_max
report_timing -path_type full_clock -view scan_max -max_paths 2000 -early -format {instance cell arc load slew delay arrival required} >> $scan_rptfilename
report_timing -path_type full_clock -view scan_max -max_paths 2000 -late -format {instance cell arc load slew delay arrival required} >> $scan_rptfilename
report_timing -path_type full_clock -view scan_min -max_paths 2000 -early -format {instance cell arc load slew delay arrival required} >> $scan_rptfilename
report_timing -path_type full_clock -view scan_min -max_paths 2000 -late -format {instance cell arc load slew delay arrival required} >> $scan_rptfilename

exit

---------
Timing reports in ETS:

ex: recovery check
Path 1842: MET Recovery Check with Pin Iregfile/tm_bank3_reg_6/C
Endpoint: Iregfile/tm_bank3_reg_6/CLRZ (^) checked with trailing edge of 'clk_latch_reg' => generated clk(div by 2 of osc_clk). so waveform is 1 101 201
Beginpoint: Iclk_rst_gen/n_reset_neg_sync_reg/Q (^) triggered by trailing edge of 'osc_clk' => created clk with waveform 1 51 101
Analysis View: func_max => shows view, doesn't show path group
Other End Arrival Time 104.067 => denotes capture clk timing
- Recovery 0.592 => recovery time for LAH1B from lib (+ve number in lib). +ve means it should setup sometime before the clk edge. So, we subtract recovery time from clk path delay. For setup, we subtract setup time, while for hold we add hold time.
+ Phase Shift 0.000 => This is the clock period for setup(for 10MHz clk, it's 100ns phase shift added for next clk edge)
+ CPPR Adjustment 0.000
= Required Time 103.475 => clk path delay
- Arrival Time 61.653 => data path delay
= Slack Time 41.822

=> start of data path (launch path)
Clock Fall Edge 51.000 => start point of clk fall
+ Drive Adjustment 0.041 => adjusted by driver for clk (invx1 or so), this number is added within clk/data path for PT, after the source latency number.
= Beginpoint Arrival Time 51.041
Timing Path: => data path as in PT
------------------------------------------------------------------------------------------------------------
Instance Cell Arc Load Slew Delay Arrival Required
Time Time
------------------------------------------------------------------------------------------------------------
clkosc v 3.312 0.064 51.041 92.863 => clk fall at 51.04ns
clkosc__L1_I0 CTB02B A v -> Y v 53.942 0.224 0.308 51.349 93.171 => clktree latency
clkosc__L2_I3 CTB45B A v -> Y v 62.517 0.346 0.488 51.837 93.659 => clktree latency
Iclk_rst/n_sync_reg DNC12 CLK v -> Q ^ 72.593 2.889 2.026 53.863 95.685
Iregfile/U171 NO211 A ^ -> Y ^ 55.505 4.133 2.999 56.862 98.684
Iregfile/FE_OFC0_n12 BU110J A ^ -> Y ^ 77.212 3.081 2.460 59.322 101.144
Iregfile/FE_OFC1_n12 BU110J A ^ -> Y ^ 72.938 2.919 2.235 61.557 103.379
Iregfile/tm_reg_6 LAH1B CLRZ ^ 72.938 2.927 0.096 61.653 103.475 => final arrival time of clrz
------------------------------------------------------------------------------------------------------------

=> start of clk path (capture path)
Clock Rise Edge 1.000 => start point of clk rise
+ Drive Adjustment 0.082
# + Source Insertion Delay -1.267 => insertion delay added if indicated in constraints (usually not present)
= Beginpoint Arrival Time 1.082 => final clk after adjusting for driver
Other End Path: => clk path as in PT
-----------------------------------------------------------------------------------------------------------------------------------
Instance Cell Arc Load Slew Delay Arrival Required Generated Clock
Time Time Adjustment
-----------------------------------------------------------------------------------------------------------------------------------
clkosc ^ 3.312 0.154 1.082 -40.740 => clk rise at 1.08ns
clkosc__L1_I0 CTB02B A ^ -> Y ^ 53.942 0.266 0.300 1.383 -40.440 => clktree latency
clkosc__L2_I4 CTB45B A ^ -> Y ^ 58.511 0.390 0.409 1.791 -40.031 => clktree latency
Ireg/wr_stb_sync_reg DTCD2 CLK ^ -> Q v 5.878 0.250 0.564 102.355 60.533 clk_latch_reg Adj. = 100.000 => falling edge of latch clk is setup edge for data. So, clk adjustment is done by 100ns (1/2 clk_latch_reg cycle). In PT, this adjustment is done in start of clk path.
Ireg/U176 AN2D0 B v -> Y v 46.242 1.848 1.702 104.057 62.235
Ireg/tm_bank3_reg_6 LAH1B C v 46.242 1.847 0.011 104.067 62.245
-----------------------------------------------------------------------------------------------------------------------------------

Ex: For SR latches, data to data checks done:
#Path 4: VIOLATED Data To Data Setup Check with Pin Imtr_b/itrip_latch_00/SZ => indicates SZ is clk
#Endpoint: Imtr_b/itrip_latch_00/RZ (^) checked with leading edge of 'clk_latch_reg' => indicates RZ is data (endpoint of data is RZ). clk_latch_reg refers to clk of SZ pin.
#Beginpoint: mtr_b_enbl (v) triggered by leading edge of 'osc_clk' => indicates startpoint of data is mtr_b_enbl pin. osc_clk refers to the clk firing the mtr_b_enbl signal. So, osc_clk is also the clk firing RZ, as there's only comb logic b/w mtr_b_enbl signal and RZ pin.
#Path Groups: {in2reg}
#Other End Arrival Time 1.861 => this is clk delay for SZ starting from created or generated clk. here, it's gen clk "clk_latch_reg".
#- Data Check Setup 0.036 => this is internal data setup req of latch wrt clk. here, RZ should come 0.036ns before SZ, so subtracted
#+ Phase Shift -100.000 => now, actual phases of clks taken into account (in PT, phase shifts are part of data/clk delays, but not in ETS). here, osc_clk has period of 100ns, while clk_latch_reg has period of 200ns. since SZ(clk) comes from clk_latch_reg, it may change at 0ns or 200ns or 400ns and so on, while RZ(data) coming from osc_clk may change at 0ns or 100ns or 200ns and so on. For data to data setup, we try to meet data setup wrt first clk edge. First SZ +ve edge is at 0ns, while worst case RZ +ve edge occurs at 100ns (if RZ +ve edge at 0ns chosen, then easy to meet timing, also if RZ +ve edge at 200ns chosen, then 2nd +ve edge of SZ would be chosen, which makes this pattern repeat, so we choose worst possible setup which is 100ns in this case). Phase shift is added to clk.
#= Required Time -98.175
#- Arrival Time 22.125 => this is data delay for RZ rising starting from mtr_b_enbl pin
#= Slack Time -120.299 => final slack