PT and ETS timing flow

Details

Last Updated: Tuesday, 03 November 2020 22:32

Published: Tuesday, 02 April 2019 20:03

Hits: 3613

--------------
Primetime:
---------------

PrimeTime: gate level STA tool. dynamic analysis requires input vectors and simulating those, so may not capture all possible paths. PT has most of the same timing cmd as used in DC.
--------------
It takes gate level netlist in: .db, .v, .vhdl format
It takes delay info in std delay format (SDF). Both net and cell delay are in this file. This file is optional.
It takes parasitic data (R and C) in std parasitic exchange format (SPEF). Only net delays can be caculated here by using parasitics from SPEF. when SDF not vailable, SDF is generated from SPEF, and used for net delays. It takes cell delays from .lib.
It takes timing constraints in synopsys design constraint (SDC) format

For prelayout timing analysis, cell delay come from .lib and net delay come from wire load models which estimate delays based on estimated cap and res of nets. PT supports use of timing models to represent chip submodules or std cells. Liberty model (.lib) is widely used model that it supports.

Clk/data paths are most common paths that PT analyzes. These paths start at i/p port or clk pin(of seq cell) and end at o/p port or data pin(of seq cell).
4 types of path analyzed: data path, Async paths (on async set/reset pins of flops as recovery/removal checks), clk path (thru Clk tree), clk gating paths. (clk and data paths are combined for data setup/hold checks).

PT automatically creates path groups for these paths (each of these path groups have 2 path types: setup(max) and hold(min)):
1. clk/data path (path group has the name of the clk associated with capture flop/latch, if there are multiple "create_clock" or "create_generated_clock" cmds, then separate path group created for each created/generated clock). Latch may be normal or SR latch. When considering check b/w set/reset pins (non-seq arc), the path group is assigned to the clk, which drives the end_point set/reset pin.
2. clkgating paths (clk_gating_default for paths that end on combinational element used for clk gating, EN pin wrt clk)
3. async paths (async_default for paths that end on asyn set/clr i/p of FF, checks for recovery/removal checks wrt clk). set/clr pins may be driven by o/p of flops, but they are still async wrt capturing clk.
4. default paths (default) that don't fall into any category.
5. none (unconstrained paths).

We can also have user defined path groups. In DC, these path groups affect design opt.

PT cmds:
-------
0. report_path_groups => shows all path groups above.

0. report_timing -from -to : most powerful cmd to see details of a timing path.
---
-from/to can also be -rise_from, -fall_from, -rise_to, -fall_to. -through can be -rise_through, -fall_through.
-path full | full_clock | full_clock_expanded => default is full. use full_clock_expanded to see full clk path.
-delay min|max => min=hold, max=setup (min_max reports both min and max timing)
-nets -cap(or -capacitance) -tran(or -transition_time)=> to show these values in timing reports
-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.
-max_paths : number of paths to report per path group. (default=1)
-exceptions all => reports timing exception that applies to that path (to see why a certain path is unconstrained etc)
-slack_greater_than/-slack_lesser_than => used to show paths within particular slack range
-group {*gating} => shows paths only for that group. Use [get_path_groups *] to get reports for all path groups. 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.
-input_pins => Shows input pins in the path report. By default, the report shows only output pins.
#NOTE: for report_timing, default is to show "max" (i.e setup) paths. So, if we want to see hold paths, we have to specify "-delay min" for hold paths (and "-delay max" for setup paths). Use -delay min_max to show both setup and hold arcs in same report.

ex: report_timing=> see options below

-path_type full
-delay_type max
-input_pins
-nets
-slack_lesser_than 0.000
-max_paths 100
-transition_time
-capacitance
-sort_by slack

#async path behaviour in DC vs PT: 2 kinds of async paths:
1. recovery/removal checks: PT performs this check by default, but DC neither analyzes nor opt these paths.
To analyze and opt these paths in DC, use this: set enable_recovery_removal_arcs true
To disable these paths in PT, use this: set timing_disable_recovery_removal_checks true
2. 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.
To report these paths in PT, use this: set timing_enable_preset_clear_arcs true (default is false)
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.

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. So PT warns about this, if there are any invalid points for start/end_points.
Ex: report_timing -from sync_reg -to tsd_latch => PT warns that of 5 pins in start_point of sync_reg (DTP10 has PREZ,CLK,D,Q,QZ pins), 4 are invalid start points. CLK of DTP10 is the only valid start point. PT also warns that of 4 pins in end_point of tsd_latch (LAB10 has SZ,RZ,Q,QZ pins), 2 are invalid end points. SZ/RZ of LAB10 are the only valid end points. For PT false paths, start point should always be CLK and endpoint should always be D. DC and VDIO don't warn about this, and just ignore the constraint, if it doesn't conform to this. VDIO/ETS reports may show startpoints as Q or D, but when false pathing, we should always write them as from CLK.

#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.

#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. 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
---------------------------------------------------
-------------------

1. report timing to auto detect False paths:
---
By using the report_timing -false command, you can have PrimeTime automatically detect false paths based on the logic configuration of the design.

2. report timing exceptions:
---
report_timing -exceptions all => reports all timing exceptions that apply to all paths. exception may be because of false_path, multicycle path or min/max delay.

3. set_disable_clock_gating_check: to disable clock gating check on specified cell or pin (when pin is spec, clk gating check is disabled only if pin is clk or En). This is needed when we are outputting clock on a dmux pin, and the tool checks for clk gating on these paths, as it thinks other i/p to the OR/AND gate to be the Enable signal trying to setup or hold to clk signal.
ex: set_disable_clock_gating_check {u_DIA_DIG/u_DMUX_DIG/U293 u_DIA_DIG/u_126/A} => disabled clock gating hold/setup checks. We cannot use set_false_path for such paths, as PT will warn about "valid endpoint not found", as it's really not a data path, but a clock gating check.

4. set_disable_timing => disables timing through the specified cells, pins, ports, or timing arcs. It removes the affected objects from timing analysis, rather than removing the timing constraints from the paths (as in "set_false_path"). So, this cmd is more efficient, and can be used when all paths thru a pin are false (instead of using multiple "set_false_path").
NOTE: This cmd is also helpful when we want disable timing b/w 2 async pins of flop such as CLRZ/PREZ. In this case we can't use "set_false_path -from flop1/CLK -to flop2/PREZ", as then the path of flop2/PREZ setting up to flop2/CLK would be false pathed. We need path of flop2/PREZ setting up to flop2/CLRZ would be false pathed which wouldn't be possible using false_path.
set_disable_timing -from CLRZ -to PREZ {get_cells {u_SPT/Ret_reg} => timing arc from CLRZ to PREZ disabled for Ret_reg flop. This timing arc should exist in .lib file for that Flop. This is equiv to:
set_disable_timing [get_timing_arcs -from {u_SPT/Ret_reg/CLRZ} -to {u_SPT/Ret_reg/PREZ}] => this is equiv to one above.
NOTE: to see all timing arcs for a particular lib cell, do:
report_lib -timing MSL445_W_150_1.75_CORE.db { AN210 } => shows all timing arcs from .lib file for AN210 gate. Timing type/sense are specified in .lib file.

Arc Arc Pins
Lib Cell Attributes # Type/Sense From To When
----------------------------------------------------------------------------
AN210 0 positive_unate A Y => from i/p A to o/p Y
1 positive_unate B Y => from i/p B to o/p Y

5. set_false_path: to set false paths which are point to point timing exception. Declaring a path to be false removes all timing constraints from the path. PT still calculates the path delay, but does not report it to be an error. "report_timing" for such path will show "No constrained paths".
NOTE: false paths -to/-from are more strict than report_timing -to/-from.
---
For false paths, -to = I/P port or CLK, -from = O/P port or D
To remove false paths, do: reset_path ...

when we specify wild characters, false paths are expanded.

ex1: set_false_path -from Ireg/reg_0/* -to Ispi/s_reg_*
A single * expands to everything that matches before it hits a "/". So, "Ireg/reg_0/*" expands to pins of reg_0, while "Ispi/s_reg_*" expands to name of cells such as s_reg_0, s_reg_1 and so on. Since we didn't specify "Ispi/s_reg_*/*", it doesn't expand to name of pins on the cell. By specufying just the name of cell, we are asking PT to look at only valid endpoint of cell, which is Din pin of flop. Since reg_0 is a latch, startpoints are all i/p,o/p pins on latch, while end points are just the Din pins of cells, since they are flops. So, this expands to:
set_false_path -from [list [get_pins Ireg/reg_0/C] [get_pins Ireg/reg_0/D] [get_pins Ireg/reg_0/CLRZ] [get_pins Iregreg_0/Q]] -to [list [get_cells Ispi/s_reg_15] [get_cells Ispi/s_reg_14] ...]

ex: set_false_path -from Ireg/reg_0 -to Ispi/s_reg_* => NOTE: only cell name is specified in from list, so only clk and din pins are considered for this cell (which are the only valid startpoints for a ltach). So, this expands to:
set_false_path -from [list [get_cells Ireg/reg_0]] -to [list [get_cells Ispi/s_reg_15] [get_cells Ispi/s_reg_14] ...]

NOTE: So for a flop, we can just specify name of flop as starting point. That means clk of flop. Or, we could specify cell/clk. It means the same thing. cell/Q is invalid start point, though in this case, it refers to the same path. Similarly for destination flop, we can just specify the name of flop as ending pont. That means data_in of flop as ending point. Or, we could specify cell/data_in. cell/clk is invalid end point.

NOTE for PT: even though above style works for PT, when we do report_timing in PT, it warns about invalid start/end points. This is because, when we specify name of cell as startpoint, it checks for all pins on that cell. For a flop such as DTC20, its 5 pins (clk, din, clrz, Q, QZ) that it looks at all starting point of which only clk is valid, remaining 4 are invalid pins. Similarly for end point, it looks at 3 pins (clk, din, clrz) of which only din is valid, remaining 2 are invalid pins.

NOTE for VDIO/ETS: invalid start/endpoint paths will just be ignored in vdio/ets even though constraints.sdc file has it. We may even see invalid start/end points of such paths in vdio/ets timing report, but if we just cut and paste start/end point of such paths from vdio timing report, they may have cell/Q as startpoint, or cell/clk as end point which are invalid. These paths pasted in constraints.sdc file look fine, but don't get imported into vdio. When we do report_path_exceptions in vdio, we may not see the path in vdio. So, very IMPORTANT to remove Q or clk from such paths before putting them in false_path file.

Note: with a transparent latch, there's valid timing path from c2q and d2q as latch is transparent so path depends on whether data or clk comes first. So, when we just specify the cell name for a latch, it considers both cell/clk and cell/Data_in paths for start point.
A phase latch: rising clk path ( from Previous cell to D of latch, from D of latch to next cell and from C of latch to next cell ). falling clk path (from previous cell to latch)

SR latch: It has valid start point from some path to valid end point as SZ or RZ pin. If endpoint is RZ pin, that implies that SZ path is trying to setup to RZ pin. If endpoint is SZ pin, that implies that RZ path is trying to setup to SZ pin. Both setup/hold checks done. NOTE: for setup, data tries to setup in same cycle of clk (as apposed to normal paths, where setup of data is checked for next cycle of clk). This is because, these arcs are classified as nonseq arc(nonseq_setup/hold) since it's data to data arc, while normal setup/hold arcs are classified as seq arc(setup/hold_rising/falling), since they are data to clk arc.

#false path spanning different clk domain:
set_false_path -from [get_clocks I_CLK32K] -to [get_clocks I_CLK5M] => This false paths all paths starting from flops clocked by 32k clk, and going into D pins of flops clocked by 5Mhz clk.

special case of -through: clock can be specified as -from or -to and startpoint or endpoint can be specified as -through. This can be used in cases having muxed clocks. Ex:
pt_shell> report_timing -from [get_clocks ...] -through $startpoint
pt_shell> report_timing -through $endpoint -to [get_clocks ...]

combinational pins can't be path startpoints or endpoints (use -through for these). However with timing_report_always_use_valid_start_end_points variable set to false(default), PT considers these invalid start/end points to be -through points and continues searching. If set to true, it will just ignore these paths. with the exception of clk gating checks.

4. delay cmds:
---
set_input_delay: An input delay is specifying an arrival time at an input port relative to a clock edge from a register. The maximum input delay value should be equal to the length of the longest path to the register data pin, plus the max c2q time (max path delay) of the register. The minimum input delay value should be equal to the length of the shortest path to the register data pin, plus the min c2q time (min path delay) of the register.

set_output_delay: An output delay represents an external timing path from an output port to a register. The maximum output delay value should be equal to the length of the longest path to the register data pin, plus the setup time of the register. The minimum output delay value should be equal to the length of the shortest
path to the register data pin, minus the hold time (since that tells you how much min delay you should need inside your block to meet 0 hold slack).

5. misc cmds:
----
A. report_net U1/SCAN_ENABLE => This reports FO/FI/cap/res for given net. This is helpful to debug reset tree, scan_enable tree or clock tree to see if it has been buffered or not
B. report_ideal_network => This should be run in PT to make sure no n/w is set to ideal. It reports clk pins on all cells, on which it finds clk is set to ideal
C. set_case_analysis => Specifies that a port or pin is at a constant logic value 1 or 0, or is considered with a rising or falling transition. In case of pins, constant propagation is only executed forward. Also, even if these pins are driven by logic values from design, the values set by case_analysis dominate. When case analysis is specified as a constant value, this value is propagated through the network as long as the constant value is a controlling value for the traversed logic (i.e if 1 i/p of NAND2 is 0, then o/p is propagated as 1) . When some port or pin is set to constant, then the path thru that pin is unconstrained path, as it's a constant value on that pin. So, report_timing won't show any timing thru that path. That's why we never set constant value on i/p ports, so that we can have PT time all those paths from i/p ports. So, we have to be very careful when using set_case_analysis as that port/pin may never get timed, so even if it's violating setup/hold timing, it may never get reported. Use set_case_analysis only on scan_mode pin, and then have some other way to time setup/hold path from scan_mode pin. Do not use set_case_analysis on any other pins.
Note: When a logic value is propagated onto a a net, the associated design rule checking (DRC) constraint checks are disabled. However, the max_capacitance DRC check can be performed on driver pins for constant nets by setting timing_enable_max_capacitance_set_case_analysis variable to true. This variable is set to false by default. So, when we do set_case_analysis on scan_en pin, we may not see max_cap/max_tran violations on it, even though it may not be buffered and have large violations.
ex: set_case_analysis rising {U1/U2/A U1/U3/CI} => pins considered only for rise transition (fall transition on these pins is disabled)

D. remove_design -all => used to remove design from memory so that new PT run can be started w/o exiting PT. However it doesn't remove lib from memory. So do this too:
remove_lib -all => This removes all lib from mem. If we do not do this, then previous libs remain mem, so any new libs get added to prev libs. By default, libs added last are the ones that get used for final runs. Check it using report_design.
---------------
2 kinds of timing analysis:
1. Graph based (default): looks at worst case edge rate and load on a cell, and picks up the appropriate delay to use.
2. Path based (PBTA): looks at all the paths in question, and figures out which path gives the worst timing. In this case, if path x has larger delay, but better edge rate than path y, which has smaller delay but much worse edge rate, PBTA will analyze both paths, and pick the worst one. In Graph based, it would have just picked the worst edge rate from path y, and larger delay from path x, even though this may not happen.

In PT, we can temporarily change design, like insert_buffer, size_cell, etc and see the impact on timing. then to import these changes, run characterize_context cmd whichcreates a script that can be used in DC to specify timing condition for resynthesis.

multiple clocks:
we can specify multiple clocks as sync (generated clocks by dividing, etc), async (no relation) or logically exclusive (like clocks coming thru mux, so only one can be active). Use set_clock_groups to define such groups. With multiple clocks, best way to analyze is to set_case_analysis for multiple scenarios.
when using multiple clocks in design, we can specify the relaionship b/w clocks to be sync (default), async (set_clock_groups -async -group {ck1} -group {ck2} => essentially declares a false path b/w 2 clks) or exclusive (set_clock_groups -logically exclusive -group {ck1} -group {ck2} =>essentially declares a false path from ck1 to ck2 and vice versa).

-------------
CHECKS:
------------
1. Min pulse width check for clk: Clk pulse should not be too small at reg clk pin, else data may not get captured. Also, if pulse width is too small, clk pulse may not even get propagated. Min pulse width check is specified in lib cell.

2. Unate check: PT keeps track of clk sense. It recognizes the positive or negative sense of the clock signal arriving at each register clock pin. No specific action is necessary to tell PrimeTime the sense of a clock tree that has only buffers and inverters. In this case, the clock signal arriving at the register clock pin is said to be unate.
+ve unate: A clock signal is positive unate if a rising edge at the clock source can only cause a rising edge at the register clock pin, and a falling edge at the clock source can only cause a falling edge at the register clock pin.
-ve unate: Similarly, a clock signal is negative unate if a rising edge at the clock source can only cause a falling edge at the register clock pin, and a falling edge at the clock source can only cause a rising edge at the register clock pin. In other words, the clock signal is inverted.
non unate: A clock signal is not unate if the clock sense is ambiguous as a result of non-unate timing arcs in the clock path. For example, a clock that passes through an XOR gate is not unate because there are non-unate arcs in the gate. The clock sense could be either positive or negative, depending on the state of the other input to the XOR gate

ERRORS and WARNINGS: applies to both PT and ETS
--------------------------
A. check_timing: Shows possible timing problems for design.
-------------------
1. unexpandable_clocks:
--------------------------
Warns if there are sets of clocks for which periods are not expandable with respect to each other. The checking is only done for the related clock domains, such as ones where there is at least one path from one clock domain to the other. This could be because of an incorrectly defined clock period for one or more of the clocks. Another possibility is when asynchronous clocks with unexpandable periods are interacting where they should have been defined in different clock domains.

Generally, for the multiclocks defined, PrimeTime must ensure that the common base period for a set of related clocks is divisible by every clock in the set. The 'unexpandable_clocks' check warns if there are pairs of clocks where the periods
are not expandable with respect to each other.
In the case where the two clock periods differ, PrimeTime calculates a common base period (LCM) between the two clocks and expands both clocks to this common base period until it finds the common edge between the two clocks. If the clocks can not expand to a common base period, the "PTE-053" warning is issued.

The relationship between the clocks within a set is known as "related". This means, the cross-clock domain timing paths require all the clocks in the set to expand to a common base period, but due to differences in the clock period they can not be expanded.

2. unconstrained_endpoints:
--------------------------------
#Warns about unconstrained timing endpoints. This warning identifies timing endpoints (output ports and register data pins) that are not constrained for maximum delay (setup) checks. If the endpoint is a register data pin, it can be constrained by using create_clock for the appropriate clock source. You can constrain output ports using the set_output_delay or set_max_delay commands.
endpoint is unconstrained because of no_capture_clock (create_clock needed on the capture flop clk pin to fix this), dangling_end_point (set_output_delay needed on the o/p pin to fix this), or fanin_of_disabled (paths ending at fanin of disabled timing arc. to fix this, undo disable timing arc)
#startpoint is unconstrained because of no_launch_clock, dangling_start_point or fanout_of_disabled (paths starting from fanout of disabled timing arc)
#In both PT and ETS reports, whenever there is "no clk found" associated with any capture flop, all i/p (D, CLRZ, PREZ) are reported as unconstrained.

3. UITE-216: Object not valid (Important)
-------------------------------
-from , -to in set_false_path, set_multicycle_path, etc is not valid. (see page 200/494)

-from should have objects to be valid timing startpoints (i/p port, bidir port, seq cell, seq cell clk pins, data pin of level sensitive latch, clk or pin that has i/p delay specified). If a clock is specified as the -from object, all primary inputs clocked by that clock and registers clocked by that clock are used as startpoints. If cell is specified, cmd applies to one path startpoint on that cell (for seq cell, it's clk pin, while for latch it's clk as well as data pin).

-to should be valid timing endpoints (o/p ports, bidir ports, seq cell. seq cell data i/p pins, clk or pins that has o/p delay specified). If a clock is specified as the -to object, all primary outputs clocked by that clock and registers clocked by that clock (reg data pins are used as endpoints for each of these registers) are used as endpoints. If cell is specified, cmd applies to one path endpoint on that cell.

4. no_driving_cell: when i/p ports don't have drivers.

5. ideal_clocks: reports not propagated clocks. disabled by default. To enable, do check_timing -include { ideal_clocks }

6. PTE-060. Warning: No clock-gating check is inferred for clock at pins of cell. See solvnet article for details: https://solvnet.synopsys.com/retrieve/015769.html
This is a clock gating check warning, where PT is unable to infer clk gating check for complex gate (as MUX etc). By default, PT infers clk gating checks for simple gates as AND/OR/NAND/NOR only. We need to have PT check for clk gating on these complex gates: 2 options:
A. By doing "set_case_analysis" on one of the i/p of complex gate, we may be able to reduce it to simpler gate, which will allow clk gating check to be inferred.
B. help PT find correct gating relation by issuing clk gating cmds. Consider a mux with gating signal on S pin and clk on A pin,
- set_clock_gating_check -high UMUX/A => says that clk pin on UMUX/A is active high clk, so clk gating signal can only change while clk is low
- set_disable_clock_gating_check UMUX/B => says that other i/p pin of mux is not to be checked for clk gating. This may be needed if we are interested in clk gating check wrt S pin of mux only. Otherwise PT treats both pin B and S as gating pins, and reports worst case gating.

NOTE: Use report_clock_gating_check to see all clk gating checks. For multiple clk signal, use "set_multicycle_path" to get correct clk gating checks for setup/hold. All delay arcs thru clk gating cells are still honored during timing analysis. If we want to disable gating signal to get propagated (since clk gating check ensures that gating signal is clean, so won't cotribute to delay thru gating cell), we may set "timing_clock_gating_propagate_enable false".

7. PTE-052: expanding clocks to common base period. PrimeTime limits the waveform expansion of the smallest period to be no more than 1000 times and the waveform expansion of the largest period to be no more than 101 times. If the largest period is too large, then PT takes largest period as the common base period but still has not expanded the smallest period beyond its limit.In certain situations, this can cause paths between these clocks to be unconstrained.

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

------------------------------------------
VDIO/ETS vs PT: most of commands same b/w ETS and PT, but slight variations.
-------------------------------------

Commands used in ETS can be used within VDIO.

path groups: In PT, path groups are divided based on clks, but for same clk, all paths are in same path group. However, in ETS, for the same clk, paths are subdivided into 4 groups: in2reg, reg2reg, reg2out, in2out.

In VDIO: report_path_exceptions can be used to see list of all false paths used by VDIO.

report_timing: almost same syntax as in DC.
#-format used to format report. default is -format {instance arc cell delay arrival required}. -format {instance cell arc load slew delay arrival required} typically used. use incr_delay to show inc delay due to noise.
#-max_paths in PT reports paths with -ve slack, whilein ETS, it reports +ve slack paths too. So, use -slack_lesser_than option in PT. Also, max_paths in VDIO reports specified number of worst paths in the design, regardless of the endpoint. Use -max_points instead of max_paths to get worst path for each endpoint only once.
#-nworst Specifies the number of paths to be enumerated for each endpoint. This behaviour is same across PT and VDIO/ETS. By default, only the worst path to each endpoint is reported. However, in VDIO, this option can't be used with -max_paths, as that shows all worst paths, even if ending at the same end point.
#full_clock in ETS reports with clk delay expanded while in PT, it shows clk starting point and adds clk delay upto that point in "clock source latency". so, use full_clock_expanded in PT, so that it expands this clk src latency, and compares to ETS rpts.
PT: report_timing -delay max -path full_clock_expanded -slack_lesser_than 20 -max_paths 500
ETS/VDIO: report_timing -early -path_type full_clock -view func_max -max_points 500 -format {instance cell arc load slew delay arrival required}

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

For normal latches, report_timing behaves differently than in DC/PT. see primetime section above for details:
Ex: startpoints may be from D, Q or CLK. For DC/PT, 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. However, 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.

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

Graph based analysis (GBA) vs Path based analysis (PBA):
-------------------------------------------------------

https://solvnet.synopsys.com/retrieve/012134.html => link that explains it well

synopsys PT cmd:
report_timing -pba_mode path => pba applied to paths after collecting, but worst case may not be reported.
report_timing -pba_mode exhaustive => provides worst case path after recalc

cadence ETS cmd:
report_timing -retime path_slew_propagation => pba applied.