PT check_timing cmd

Details

Last Updated: Saturday, 09 September 2023 13:01

Published: Thursday, 15 October 2020 02:52

Hits: 2001

check_timing cmd:

check_timing => reports possible timing problems in design. This cmd is run before generating timing to identify potential timing constraint issues. The cmd prints all the checks it's running, and violations found. This is a very imp cmd that should be run and all violations fixed (or atleast understood, since violations here are serious).

options are:

• -verbose => prints detailed violations, instead of just summary.
• -override_defaults <check_list> => The default checks performed are done based on checks in "timing_check_defaults" var. Using this override option, we dump out info for only the check_list provided.
  • ex: check_timing -override_defaults no_clock -verbose=> -override_defaults allow us to override checking all std timings checks, and instead just report for the ones listed. Here we listed "no_clock" check only, so only this check run. This is useful to isolate various checks in their own separate report file.
• -include/-exclude <check_list> =>This adds/removes checks from the default checks in "timing_check_defaults" var.

Checks: There are many checks performed, but these are the important ones to look at:

1. no_clock: Warns if no clock reaches a register clock pin. There should not be any except for spare flops whose clock pins are tied to high/low. These should be looked at carefully, as there will be no setup/hold checks performed on the data pin of that flop.

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 clock found" (no_clock warning in item 1 above) associated with any capture flop, all i/p (D, CLRZ, PREZ) are reported as unconstrained.

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

4. no_input_delay, partial_input_delay, no_driving_cell, dangling startpoints: All are Warnings for i/p ports, if no i/p delay or no driving cell speciified. Also partial i/p delay (such as set_input_delay -min or -max is specified, but not both) are also flagged.

5. clock_crossing, ideal_clocks, generated_clocks: All are clock related warnings.

• clock_crossings check for clock interactions b/w multiple clock domains. This is ignoring any FP or async/exclusive clk relation specified in constraints. If it finds a timing path and all paths between the two clocks are false paths or they are exclusive/asynchronous clocks, the path is marked by *. If only part of paths are set as false paths or exclusive/asynchronous clocks, the path is marked by #.
  • Report format is:There are as many lines as clocks with crossings (each line has one clk listed with it's interacting clks). So the report can be parsed easily via tcl cmds.
    
    • 1st line: <CLK1> <list of clks which have have paths from CLK1 to these clks, separated by comma>. i.e clk1 clk2*, clk4#, clk9, clk13
    • 2nd line: <CLK2> <list of clks which have have paths from CLK2 to these clks, separated by comma> and so on for all the clocks in design
• ideal and generated clocks are shown (there shouldn't be any ideal clocks, as all clocks should be propagated in PT runs)

6. loops: warns of combo feedback loops, as these loops are not analyzed. There shouldn't be any combo feedback loops, so be careful with these warnings. PT automatically breaks these combo loops by disabling one or more timing arcs, if not already broken by user using "set_disable_timing" cmds.

7. Voltages: All signal levels, supply voltages, pg pin connections are reported.

• signal_level: Checks that the driver signal level matches the load signal level. The signal levels are determined from the UPF or from lib attr.
• supply_net_voltage: Checks that each segment of UPF supply nets has voltage assigned to it by set_voltage command.
• unconnected_pg_pins - Checks that each power and ground pin is connected to a UPF supply net. The connection can be implicit (for example, power domains using UPF) or explicit (for example, connect supply_net).

8. Misc: Many more checks. Look in PT manual.