PT path timing cmds

Details

Last Updated: Wednesday, 12 February 2025 03:27

Published: Thursday, 15 October 2020 04:01

Hits: 4789

PT path timing cmds:

Most important info that we get from running a timing tool on the design is to find out if all the paths in design meet timing requirement. There are diferent types of timing that needs to be met for each path. i.e setup, hold, recovery/removal, etc. We have 2 kinds of cmds to show us the timing paths. We saw under "PT: object access functions" section that get_* and report_* are 2 kinds of cmds that allow us to access and report objects. For timing paths, we have those 2 cmds available:

1. report_timing cmd: This is for reporting path timing. This is for visual reporting, and can't be used in scripts etc.

2. get_timing cmd: This is for getting the timing path as a collection of objects, which can then be sued inside a script to get parameters of interest.

report_timing => most powerful cmd to see details of a timing path. This is the cmd that you will be using the most in any timing tool to debug paths and check timing. So, it's best to see this cmd in a separate section of it's own in detail. Max 2M paths are shown (If you specify a value >2M in any of the options below, it will error out or won't be honored).

Syntax: report_timing <options> <path_collection>

Options: There are lots of options available. See PT manual for full syntax. Here's the important ones.

• -from/-to/-through: Options here same as in timing exception cmds (see that section) where we specify start/end point (pins, ports, nets, seq cells or clocks) of the path.  Can also specify direction as -rise_from, -fall_from, -rise_to, -fall_to, -rise_through, -fall_through.
  • If multiple objects are specified in -through option, then all paths passing thru any of the objects are reported. Ex: report_timing -from A1 -through {B1 B2} -through C1 -to D1 => this cmd gets a path that starts at A1, then passes through either B1 or B2, then passes through C1, and ends at D1.
• -path_type < summary | end | short | full | full_clock | full_clock_expanded > => summary shows only startpoint, endpoint and slack. Useful for quick overview of path. full_* options are same as those show for -path above.
  • This old format is deprecated: -path < full | full_clock | full_clock_expanded > => default is full (meaning full clock paths are not shown).  use full_clock_expanded to see full clk path (including generated clk point). -full_clock and -full_clock_expanded are different only when clk is a generated clock.-path is deprecated, so use -path_type shown below.
• -delay min|max => min=hold, max=setup (min_max reports both min and max timing). -delay looks deprecated as of PT 2018, so use -delay_type.
  • Default is to show "max" (i.e setup) paths if no -delay_type option provided. So, if we want to see hold paths, we have to specify "-delay_type min" for hold paths (and "-delay_type max" for setup paths). Use -delay_type min_max to show both setup and hold arcs in same report.
• -nets -cap(or -capacitance) -tran(or -transition_time)=> to show these values in timing reports. -voltage shows voltage (when we have Multi Voltage design, it's useful). -derate, -variation are used to report when we have derate/variations applied to PT runs.
• -input_pins => Shows input pins in the path report. By default, the report shows only output pins. this is sometimes helpful as we want to know the i/p pin as well as o/p pin of a gate to check the arc in .lib.
• -sort_by group|slack => By default, paths are sorted by group, and within each group, by slack (i.e if multiple groups present, all paths for grp 1 will be shown first, then paths for group 2 and so on). 
• -nworst : number of paths to report per endpoint (default=1). We need to use this option when we do report_timing to a particular end point, and want to see all failing paths thru it. We usually set -nworst to something large so that we can all worst violating paths, irrespective of whether they are to the same endpoint or not. Otherwise we'll only see 1 failing path to each endpoint (even if they come from many different startpoints).
• -max_paths : number of paths to report per path group. (default=1)
• -start_end_pair => by default, only 1 worst path is reported (as max_paths=1 by default). However, this reports single worst path for each startpoint-endpoint pair. This option can result in large num of timing paths reported, so use -slack_lesser_than to limit paths. We can't use this option with -nworst, -max-paths, -uinque_pins or slack_greater_than (as start_end_pair option is meant to be used when we just want to do report_timing and don't want to clobber the report with similar paths).
• -unique_pins => This reports only the single worst timing path thru any seq of pins. As an ex, we might have the same seq of pins repeated for diff paths, as rise/fall may change for different pins, and so multiple such paths are possible (I think only 2 paths are possible for unique start and end point, one with flop o/p rise at start and other with flop o/p fall at start. All other directions for rise/fall are determined based on gate polarity). This avoids displaying such duplicate paths which are different just in the unateness. This option is especially useful when we have non-unate logic as XOR gate, since it can result in large number of rise/fall combinations causing our report_timing to show 100's of paths (since XOR gate o/p depends on the value of other pins too, it may serve as inverting or non inverting so we may have to consider all possible cases).
• -false => usually we provide list of false paths to PT to remove those paths from timing consideration. By using this option, we can also have PT automatically detect false paths based on the logic configuration of the design. This option is rarely used, as we don't want to rely on the tool to figure out FP for us.
• -exceptions all => reports timing exception that applies to that path (to see why a certain path is unconstrained etc). Exception may be because of false_path, multicycle path or min/max delay. This is to helpful to use, when you have unconstrained endpoints in design. You can use this option on that path to see why is the path unconstrained. Other options are "dominant" and "overridden". We use option "all" as that shows us all exceptions that made this path unconstrained.
• -slack_greater_than/-slack_lesser_than => used to show paths within particular slack range. Default is to show paths with slack < 0. To show paths with all slacks, use "-slack_lesser_than infinity"
• -include_hier => reports timing with all hier included for a given net. So, if a given net is traversing 3 hier, we only see 1 line in reports. But by using this option, this one net will show up 3 times, with all 3 hier shown on separate lines. This is sometimes easier to debug as we may know the net name at a certain hier only. In such a case, printing all hier helps.
• -group {*gating} => shows paths only for that path group. Use -group [get_path_groups *] to get reports for all path groups, where worst path for each path group is reported. If we don't use this option, then by default only the worst path in the whole design is shown. Usually we use it when we have multiple clock groups, and we want to see path associated with particular clock, but we don't know the start or end point.
• -crosstalk_delta => reports annotated delta delay and delta transition time which are computed duringcrosstalk SI analysis. Using this option does not initiate crosstalk analysis.
• -nosplit => this option is same as that used in other PT cmds, where it prevents line splitting. This way everything is printed in 1 line (by default, PT creates new line when text can't fit in 1 line, which becomes an issue for scripts that parse reports)
• -normalized_slack => Sometimes we may want to report paths by normalized slack instead of raw slack. This option allows us to do that. To enable normalized slack analysis, set the timing_enable_normalized_slack variable to true before running timing analysis. The rationale behind normalized slack is this. Let's say we have few paths on clk running at 100Mhz and few other paths on clk at 1GHz. If both paths are failing by 0.1ns, then it's lot more expensive to fix 1Ghz path, as clk freq would need to increase by 10%. But for 100MHz path, we can just increase the freq by 1MHz and pass timing. So, instead of arranging paths by pure slack number, it's more beneficial to list them by slack which takes impact of clk freq. PT reports normalized slack = slack/allowed_path_delay.  Allowed path delay (aka normalized delay) is 1 cycle of clk for full cycle path, 0.5 for half cycle paths, n ycles for MCP, etc. normalized slack is a decimal from 0 to 1. So, 0.2 implies that clk freq will need to be increased by 20% to pass timing. 

Ex:

• report_timing -from A/CP -to B/D -delay min => report timing for top failing path for hold.
• report_timing -group [get_path_groups *] -path_type summary => This reports 1 path for each path group in STA with summary only. i.e it only shows SP, EP and Slack for top path in each path grp.

Path collection: This is used with options as -start/-end/-through. Here we specify start, thru or end points. As we saw in section on "PT timing exception cmd", we can specify cell names for start/end_point. Then, all paths from all pins of start cell to all pins of end cell are considered. We know that valid start points are CLK pin of launch flop and valid end points are Data pin of capture flop for a data to data path. But a cell has 4-5 pins as  Clk, Data, Set, Reset, Out pin Q etc. Since only of these pins is a vlaid start/end point for a given flop, PT warns that there are multiple invalid start/end points and it'll be ignoring those.
Ex: report_timing -from sync_reg -to tsd_latch => PT warns that of 5 pins in start_point of sync_reg (Dff10 has PREZ,CLK,D,Q,QZ pins), 4 are invalid start points. CLK of Dff10 is the only valid start point. PT also warns that of 4 pins in end_point of tsd_latch (LAT10 has SZ,RZ,Q,QZ pins), 2 are invalid end points. SZ/RZ of LAT10 are the only valid end points. For PT false paths, start point should always be CLK and endpoint should always be D.

IMP: Synthesis tools as DC and VDIO don't warn about invalid start/end points when cells are provided in collection list. They just ignore the constraint, if it doesn't conform to valid start/end point. VDIO/ETS reports may show startpoints as Q or D, but when false pathing, we should always write them as from CLK, or they might get ignored.

Correlate timing sown in report_timing with that in lib files: Sometimes, we want to check if the delay reported in report_timing cmd for a certain cell is what is expected based on the delay of that cell in the .lib file. To do this, we do "report_timing" for path of interest. Then we run following cmds

• Get name of lib cell for cell of interest: use get_lib_cells cmd.
  • pt_shell> get_lib_cells -of [get_cells chip/gen/U134] => {"TSM_SS/OAI21_LVT"} => This is the lib cell used.
• Get name of .lib file where that lib cell is: use get_attr cmd.
  • pt_shell> get_attr [get_lib TSM_SS] source_file_name => /home//TSM_SS.db => This is the name of the file where that lib cell resides.
• Report pin to pin delay for the cell
  • pt_shell> report_delay_calculation -from chip/mod1/A1 -to chip/mod1/Z => this shows details of how cell delay was calculated (at given i/p transition and o/p load)

PT reporting style:

PT reports timing for clk and data path in 2 separate sections. 1st section "data_arrival_time" refers to data path from start point, while 2nd section "data_required_time" refers to clk path of end point. 1st section shows path from clk to data_out of seq element and then thru the combinational path all the way to data_in of next seq element, while 2nd section shows primarily the clk path of final seq element, ending at clk pin. Towards the end of 2nd section, it shows the final "data check setup time" inferred from .lib file for that cell.

Reports are shown for per stage. A stage consists of a cell together with its fan out net. So, transition time reported is at the i/p of next cell. delay shown is combined delay from i/p of cell to o/p of cell going thru the net to the i/p of next cell. & in report indicates parasitic data.

Ex: report_timing -from reg0 to reg1 => a typical path from one flop to other flop
Point Incr Path
------------------------------------------------------------------------------
clock clk_800k (rise edge) 1.00 1.00 => start point of 1st section
clock network delay (propagated) 3.41 4.41
.....
Imtr_b/itrip_latch_00/SZ (LAB10) 0.00 7.37 r
data arrival time 7.37
-----
clock clk_800k (rise edge) 101.00 101.00 => start point of 2nd section (usually starts at 1 clk cycle delay, 100 ns is the cycle time here)
clock network delay (propagated) 3.85 104.85
.....
data check setup time -0.04 105.76 => setup time implies wrt clk, data has to setup. So, we subtract setup time from .lib file to get data required time (as +ve setup time means data should come earlier)
data required time 105.76
------------------------------------------------------------------------------
data required time 105.76
data arrival time -7.37
------------------------------------------------------------------------------
slack (MET/VIOLATED) 98.39

Async paths in DC vs PT:

Async paths are paths ending in clear or preset pin instead of ending in D pin. These paths are covered differently than regular data-clock paths. DC (design Compiler from Synopsys used for synthesizing RTL) and PT treat these paths differently when reporting.

2 kinds of Async paths:

• recovery/removal checks: PT performs this check by default, but DC neither analyzes nor opt these paths.
  • DC: To analyze and opt these paths in DC, use this: set enable_recovery_removal_arcs true
  • PT: To disable these paths in PT, use this: set timing_disable_recovery_removal_checks true
• Timing paths thru asynchronous pins (i.e paths flowing thru set/reset pins to Q/QZ o/p pin of the flop and then setting up to clk of next flop as D pin, these are clear/preset arcs in .lib file) : by default neither PT nor DC report these paths.
  • DC: To report these paths in DC, use this: -enable_preset_clear_arcs (in report_timing cmd). Even if we have this option, it only allows us to view these paths during reporting, but DC never opt these paths.
  • PT: To report these paths in PT, use this: set timing_enable_preset_clear_arcs true (default is false)

NOTE: For recovery/removal paths, use Q of 1st flop as startpoint and CLRZ/PREZ of next flop as end point. For some reason, using CLK of 1st flop as startpoint doesn't work.

Latch based borrowing:

In latch based paths, borrowing occurs if data arrives in the transparency window. See PT doc (page 36-38). So startpoints may be from D, Q or CLK pins of Latch. CLK and Q startpoints are treated as starting from the clk of latch, while D is treated as starting from the D i/p of latch and going thru the latch to Q o/p pin of latch. Note, this behaviour is different when VDIO/ETS is used to report such paths. In VDIO/ETS path from startpoint D is still the same, but paths from CLK and Q startpoints are treated as worst case slack paths from D, CLK or Q.

to report timing for such paths, and see the latch borrowing, use -trace_latch_borrow (otherwise startpoint delay is shown for D, doesn't show the actual path to D)
Ex: report_timing -from ... -to ... -trace_latch_borrow

Ex: of time borrowing path
Point Incr Path
---------------------------------------------------------------
clock spi_stb_clk (rise edge) 55.00 55.00 => start point
...
data arrival time 56.55 => this is data path delay from 1st flop.
---
clock clk_latch_reg (rise edge) 1.00 1.00 => end point
...
Iregfile/tm_bank0_reg_9/C (LAH1B) 3.66 r => this is total delay to clk of latch
time borrowed from endpoint 52.89 56.55 => since data comes much later than rising edge of clk, we borrow the difference (56.55-3.66=52.89) from this latch, so that next path from latch o/p will consider that D->Q delay is 52.89ns.
data required time 56.55
---------------------------------------------------------------
data required time 56.55
data arrival time -56.55
---------------------------------------------------------------
slack (MET) 0.00

Time Borrowing Information
---------------------------------------------------
clk_latch_reg nominal pulse width 100.00 => this is width of clk pulse = clk_period/2
clock latency difference -0.36 => this is reduction of pulse width due to diffeerence in rising and falling edge
library setup time -0.26 => this is setup time of latch (wrt falling edge of clk) which needs to be subtracted, as max time available is reduced by this
---------------------------------------------------
max time borrow 99.37 => final max time available to borrow
actual time borrow 52.89 => actual time borrowed < max available. so timing met
---------------------------------------------------

get_timing_paths => A direct counterpart of report_timing is get_timing_paths. This cmd creates a collection of timing paths for custom reporting or other processing. All options are the same as report_timing cmd. The order in which paths are returned from get_timing_paths matches the reported timing path order of report _timing.

Syntax: get_timing_paths <options> <path_collection> => Same as in report_timing cmd.

NOTE: the collection returned above will always show only one path unless we use the option "-max_paths". By default, max_paths is 1 (as in report_timing), so only 1 path will be reported, and size of collection will always be 1. Even with "-max_paths" set, we still have to provide option "-slack_lesser_than infinity" to see all paths, otherwise only paths with -ve slack will be put into the collection.

Ex below:

• pt_shell> set mypaths [get_timing_paths -nworst 4 -max_paths 20] => It gets the collection of paths returned by get_timing_paths (with 20 such paths) and sets "mypaths" var to that collection for later processing.
• pt_shell> sizeof_collection $mypaths => returns 20
• pt_shell> report_timing $mypaths => 20 path timing reports displayed

Ex: report_timing [filter_collection [get_timing_paths -max 10000 -slack_lesser_than -10 -slack_greater_than -25] "dominant_exception == min_max_delay"] -path_type summary -max_paths 10 => Here we passed get_timing collection to report_timing to report timing for selected paths only. 

To get info about paths (i.e start/end points, slack, etc) we have to use get_attributes cmd. But for that we need to know what all attr are available for paths. We can use our familiar list_attributes cmd (explained in PT cmds section). define_user_attribute and set_user_attribute can be used to define our own attr and set it on paths of interest.

list_attributes -application -class timing_path => Most useful attr for paths are startpoint, startpoint_clock, endpoint, endpoint_clock, slack (slack of path), points (points correspond to pins or port along the path), arrival (arrival time of signal at a point in path)

Most widely used attr of a timing path is the "points" collection. A point corresponds to a pin or port along the path. Iterate through these points and collect attributes on them.

Ex: report arrival time at each cell in the specified path. The path has a launch flop, and nand2 gate and a capture flop. For simplicity, we just assumed one path. If there are multiple such paths, outer foreach loop will iterate thru all such paths.

foreach_in_collection paths [get_timing_paths -from A/flop1 -to B/flop2 -max_paths 100 -slack_lesser_than infinity] {

set path_points [get_attribute $paths points]
set startpoint [get_attribute $paths startpoint]
set endpoint [get_attribute $paths endpoint]

set slack [get_attribute $paths slack]

puts "startpoint -> [get_attribute $startpoint full_name]"

        foreach_in_collection point ${path_points} {
             set arrival [get_attribute $point arrival]
            puts " point -->  [get_object_name [get_attribute $point object]] arrival -> $arrival"
        }

puts "endpoint -> [get_attribute $endpoint full_name]"
puts "slack -> $slack"
}

Output from above code => It iterates thru the given path and reports arrival time at each pin or port aong the path.

sartpoint -> A/flop1/CP

point -->  A/flop1/CP arrival -> 0.00
point -->  A/flop1/Q arrival -> 0.22

point -->  A/I_nand2/A arrival -> 0.22

point -->  A/I_nand2/Z arrival -> 0.29
point -->  B/flop2/D arrival -> 0.29

enpoint -> B/flop2/D

slack -> -0.11

 ----------------

Instead of going thru the loop for all points in the path, we can also get attr directly for all points on the path.

ex:

• get_attribute [get_timing_paths -from x1 -to x2] launch_clock_paths => gets the lauch clk path, i.e from launch clk to the clk pin of the launching flop
• set my_points [get_attribute [get_attribute [get_timing_paths -from x1 -to x2] launch_clock_paths] points] => Here we get all the points on the launch clk path shown above.
• set my_obj [get_attribute [get_attribute [get_attribute [get_timing_paths -from x1 -to x2] launch_clock_paths] points] object] OR set my_obj [get_attribute $my_points object]=> Here we get "object" attr of all points on the path. We need to get object attr in order to get object names
• get_object_name $my_obj => This shows names of all points, i.e CLK_PAD I_BUF1 I_AND2 ... I_FLOP/CLK (the clk launch path starts from clk pad pin and ends at clk pin of the flop)