How primetime identifies vdd value in multivdd chip?

Primetime identifies vdd value in multi vdd chip by using lppi (link path per instance) file.

It gives information about the blocks and on which vdd that block is operating on.

what are the commands inside to define this?

Setup and hold times trade-off while fixing

-start_end pair option
Fix setup
Remove delay cells, Back to back buffers

In the same path, setup and hold can't fail.
Fix setup firstYou can add delay at the start point also to fix hold

Add delay at the capture flop in that hierarchy where setup is not affected.

Query1: Trade-off: Hold check is violating once setup fixes are done

I have setup violations from FF1 to FF2. There is little scope in data path and clock push as well as pull options are there. But hold is failing to FF2 as soon as i fix setup issues.

How do i proceed in this situation?

Use -start_end pair option 

Setup and hold can't fail in the same path-> i.e. Start point or end point are different for setup and hold violations.

Fix setup first 

Fix hold by adding delay at the start point or adding delay in the capture path where hold is failing. It must be lie in the different path where setup should not fail. 

buffer vs delay cells to fix hold violations

i) When local congestion is not there at endpoint:

generally delay cells are big compared to buf and 1 delay cell can give 80ps (for e.g.) and buf cell can give only 20ps => so instead of putting 4 buf cells (area of 4 buf cells is more than 1 delay cells for the same delay), it it better to put 1 delay cell.


ii) When local congestion is there, 80ps delay cell may not fit there and 4 buf cells can be inserted 1 top on other on different routing tracks.

So, it is difficult say which is put to fix and which is advantageous to have to fix certain ECO.

get attributes of different classes

How to which classes are there?

list_attribute  -application  -class  xyz

i) Physical class (pin, port, net, cell)
ii) Virtual class (clock)


ii)  list_attribute -app -class libcell
 reports all attributes related to libcell

get_attribute [get_cell  cell_name]  attribute_name

To do: analysis oncross talk affected nets

If cross talk delta on net is more,

i) Upsize driver

STA:Do the following analysis:
report_delay_calc  -from net_source_pin    -to    net_sink_pin

Gives aggressor nets  and victim nets and related analysis
    i) Downsize aggressor
    ii) Upsize victim


To PD guys:
i) If it is in clock path, double spacing , shielding techniques
ii) If net is data path, then change to higher metal to reduce delay and viceversa

whatif analysis

Let us assume, we are pushing the clock at FF2/clk

          -  Understanding the impact on hold violation at FF2/d
          -   Understanding the impact on next stage setup violations

This analysis is mentioned as whatif analysis.

Getting scaling factor of the library from min to max corners

While working at ECO phase, it important to know what is the impact of SS corner setup fix on FF corner hold timing.

It is better to have this ratio upfront to know whether SS corner fix violates FF corner hold or not. This saves a lot of time.

How to get this:

i) Take max corner timing path
Note down buf 1x delay (assumed 1x buf is there in that path)

ii) Go to min corner and note down buf 1x delay
report_timing -through  above_buffer_instance

             Scaling factor = (max corner delay/min corner delay) 

Repeat this exercise for available drives in that library.
get_cells buf*
     - to get drives available in that library.

prepare a chart and it is constant for a given technology.


ii) Check whether you get the same info from estimate_eco ?

report_timing -path_type summary

The below command prints in the following format
[startpoint   sp_lib_cell  endpoint  ep_lib_cell  slack]

set paths [report_timing   -path_type  summary  -max_paths  10]

foreach p1  $paths {
      # get lindex 0 from the list
}

Clock push or pull techniques

Identifying common cell in the multi branch flops (next stage):

report_transitive_fanin -from FF1/clk

see from which cell it is diverging and do insert_buffer at the cell, to fix on all the cells at the same time.


Good clock tree:
Diverging of the clock path should be close to the flops otherwise

i) No of cells are more => results high dynamic power
ii) Common path should be as long as possible (CRP should be high) otherwise pvt, Rc corner variaions and skew is more => high uncertainity values

Because of bad clock tree, worst hold failures may happen at min, low voltage compared to min, high voltage corners.

cgc setup and hold checks

Why clock gaters:
    Clock gating is the well known technique to reduce dynamic power consumption.

i) If done properly: Saving the dynamic power of flops
ii) if not done properly: Glitches may lead to meta-stability issues.

Adv of using CGC:

1. Its worth mentioning that clock gating does not have much significance on individual flops. But imagine a scenario of writing a 64bit register based on an enable. The power dissipated by all 64 flops can be greatly reduced by using a single clock gate cell common to all 64 flops, which amounts to a very significant power saving.

2. On a side note, clock gating can greatly help save area in the scenario described by getting rid of the large mux'ed feedback path which would otherwise be necessary to meet logic requirements.

Drawback of Simple AND as CGC:

Think of a clock gate as "simple and" with an enable gating the clock. The reason you do this is to stop unnecessary toggles on the clock pin of flops. Even if the output doesn't toggle, the internal flop circuitry dissipates unnecessary power. Power saving can be achieved by simply gating the clock with an enable.

1. Here's the catch, if the enable is asynchronous to the clock and gates the clock during its active phase, you can end up with a clipped clock, which effects the duty cycle.

2. This scenario can lead to timing violations on the flop and downstream logic. If clock clipping happens very close to the active edge of the clock, there might even be a clock width violation.

How to mitigate this problem:

To prevent violations, its best to sync the enable signal with respect to the clock it is gating. This is achieved by using a latch which is transparent only during the inactive phase of the clock. For example, to gate the clock to its low state, use an active low latch to sync the enable and gate the clock with the sync'ed version as described by the code below:

Code:

always_latch
   if(!clk) en_syn <= en;

assign gated_clk = clk & en_syn;

always_ff @(posedge gated_clk) ....

Many ASIC vendors, supply clock-gate cells. Which is internally a combination of the latch and the gate described above. These gates can be instantiated in the design or better yet inserted during synthesis (if the RTL is coded following the tool requirements of cg insertions).

The clock_gating_setup_time is essentially the setup requirement of the latch and is available for STA delay annotation in the dbs read by PT.

How to model:

-ve latch followed by AND gate:
En is input to -ve latch, CLK is the clock of the -ve latch
Output of latch and CLK are going to AND
Output of AND is going to set of flops

Let us assume EN pin is gating clock pin (CLK)

The gating check is performed on pins (EN) that gate a clock signal.

When Clock gating Checks required:

Clock gating checks need to be done where the clock is gated with a data or enable signal. The basic idea here is to check whether the enable signal is toggling only when the clock is in its inactive phase. If enable toggles in the clock's active phase, it will result in glitch in the gate output clock.

AND/NAND gate is inactive when clock is in the LOW phase. i.e., at this time gate output will not depen on the other inputs. So AND/NAND gate is having a HIGH clock gating check.  Similarly, for OR/NOT gate is inactive when clock is in the HIGH phase, so it has LOW clock gating check.

Setup violation:
         Similar to normal flop, here, D input is EN and clock is CLK. And we are checking setup violation of Latch.

The clock gating setup check is used to   ensure   the   controlling   data signals   are stable before the clock is active. i.e., EN signal is stable enough before the -ve level (as it is -ve latch) of clock signal.

This check is performed on combinational gates through which the clock signals are  propagated.

The   arrival   time   of   the   leading   edge   of the clock pin is checked against both levels of any data signals gating the clock.

If clock gating setup failure leads to:  A clock   gating   setup failure can cause either a glitch at the leading edge of the clock pulse, or a clipped clock pulse.

How to fix setup violations in PrimeTime:

          Let us assume setup violation is occurring in the below path

 start point:  FF1 clock

 end point: EN input of CGC

Fix1:

1. Reduce data path delay:

2. Clock push:

           - adding delay in the clock path (inserting buffers at CLK input pin of CGC)

When this clock push can be done?

      As a general phenomenon, clock push can be done when there is setup margin at the next stage.
As output of CGC is the start point for setup of flops, so our clock push should not result in setup violtaion at the startpoints of those timing paths.


##Getting slack of next stage flops (from endpoint of current path under fix) as gated clock is the start point for those flops:
set f [open slc_cg.txt w ]
set fo [get_cells [all_fanout -from   CGC_cell/clk -flat -endpoints_only -only_cells]]

foreach_in_collection fo1 $fo {
set slack [get_attribute [get_timing_path -from [get_attribute $fo1 full_name ]/clk -exclude [get_ports *] ] slack]
puts $f "[get_attribute $fo1 full_name] $slack "
}
close $f

ECO:

insert_buffer  path_till_CGC/CGC_cell/clk_in          clk_buffer_1x_drive

Hold check:
The clock gating hold check is used to ensure that the controlling data signals   are   stable while the clock is active. 

The arrival time of the trailing edge of the clock pin is checked against both   levels   of   any
data signal gating the clipped clock pulse.

References:
http://tech.tdzire.com/clock-gating-checks-and-clock-gating-cell/


How to define CGC constraints:

EXAMPLES
         The   following example specifies a setup time of 0.2 and a hold time of 0.4 for all gates in the clock network of clock CK1.

                 pt_shell> set_clock_gating_check -setup 0.2 -hold 0.4 [get_clocks CK1]

         The following example specifies a setup time of 0.5 on the gate and1.

                 pt_shell> set_clock_gating_check -setup 0.5 [get_cells and1]

set_clock_gating_check

NAME          set_clock_gating_check                     Specifies   the   value   of   setup   and hold time for clock gating                     checks. SYNTAX          string set_clock_gating_check                     [-setup setup_value]                     [-hold hold_value]                     [-rise | -fall]                     [-high | -low]                     [object_list]          float       setup_value          float       hold_value          list object_list ARGUMENTS          -setup setup_value                     Specifies the clock gating setup time.   The default is 0.0.          -hold hold_value                     Specifies the clock gating hold time.   The default is 0.0.          -rise   Indicates that only rising delays are   to   be   constrained.    By                     default,   if   neither -rise nor -fall are specified, both rising                     and falling delays are constrained.          -fall   Indicates that only falling delays are to   be   constrained.    By                     default,   if   neither -rise nor -fall are specified, both rising                     and falling delays are constrained.          -high   Indicate that the check is to be performed on the high level   of                     the   clock.   By default, PrimeTime determines whether to use the                     high or low level of the clock using information from the cell's                     logic.   That   is,   for AND and NAND gates PrimeTime performs the                     check on the high level; for OR and NOR gates, on the low level.                     For some complex cells (for example, MUX, OR-AND) PrimeTime can-                     not determine which to use, and does not perform   checks   unless                     you   specify   either -high or -low.   If the user-specified value                     differs from that derived by PrimeTime, the user-specified value                     takes precedence, and a warning message is issued.   Unlike setup                     or hold time, this option sets the attribute only on the   speci-                     fied   pin   or cell and does not affect the transitive fanout pin                     or cell.   If you specify -high or -low   you   must   also   specify                     object_list;   in that case, object_list must not contain a clock                     or a port.          -low    Indicates that the check is to be performed on the low level   of                     the   clock.   By default, PrimeTime determines whether to use the                     high or low clock level using information from the cell's logic.                     That   is, for AND and NAND gates PrimeTime performs the check on                     the high level; for OR and NOR gates, on the low edge.   For some                     complex cells (for example, MUX, OR-AND) PrimeTime cannot deter-                     mine which to use, and does not perform checks unless you   spec-                     ify   either   -high or -low.   If the user-specified value differs                     from that derived by PrimeTime, the user-specified   value   takes                     precedence,   and   a   warning message is issued.   Unlike setup or                     hold time, this option sets the attribute only on the   specified                     pin   or   cell   and   does not affect the transitive fanout pin or                     cell.   If you specify   -high   or   -low   you   must   also   specify                     object_list;   in that case, object_list must not contain a clock                     or a port.          object_list                     Specifies a list of objects in the current design for which   the                     clock   gating check is to be applied. The objects can be clocks,                     ports, pins, or cells. If a cell is specified, all input pins of                     that   cell   are affected.   If a pin, cell, or port is specified,                     all gates in the transitive fanout are affected.   If a clock   is                     specified, the clock gating check is applied to all gating gates                     driven by that clock.    If you specify -high or   -low   you   must                     also   specify   object_list;   in   that case, object_list must not                     contain a clock or a port.   By default, if   object_list   is   not                     specified,   the   clock   gating   check   is applied to the current                     design. DESCRIPTION          The set_clock_gating_check command specifies a setup or hold time clock          gating   check to be used for clocks, ports, pins, or cells.   The gating          check is performed on pins that gate a clock signal. Removing CGC checks: remove_clock_gating_check Captures clock-gating checks. SYNTAX string remove_clock_gating_check [-setup] [-hold] [-rise] [-fall] [-high | -low] [object_list] list object_list ARGUMENTS -setup Indicates the removal of the clock-gating constraint on the setup time only. If you do not specify either the -setup or -hold option, both setup and hold constraints are removed. -hold Indicates the removal of the clock-gating constraint on the hold time only. If you do not specify either the -setup or -hold option, both setup and hold constraints are removed. -rise Indicates the removal of the clock-gating constaint on the rising delays only. If you do not specify either the -rise or -fall option, constraints on both rising and falling delays are removed. -fall Indicates the removal of the clock-gating constaint on the falling delays only. If you do not specify either the -rise nor -fall option, constraints on both rising and falling delays are removed. -high Remove the high specification from the obejct list, previously set up by set_clock_gating_check command. This option has to be either high or low.. -low Remove the low specification from the obejct list, previously set up by set_clock_gating_check command. This option has to be either high or low. object_list Specifies a list of objects in the current design for which to remove the clock gating check. The objects can be clocks, ports, pins, or cells. If you specify a cell, all input pins of that cell are affected. If you do not specify any objects, the clock-gating check is removed from the current design. DESCRIPTION This command is available only if you invoke the pt_shell with the -constraints option. The remove_clock_gating_check command removes clock gating checks for design objects set by set_clock_gating_check. EXAMPLES The following example removes the setup requirement (for rising and falling delays) on all gates in the clock network involved with clock CK1 path. ptc_shell> remove_clock_gating_check -setup [get_clocks CK1] The following example removes the hold requirement on the rising delay of gate and1. ptc_shell> remove_clock_gating_check -hold -rise [get_cells and1] An alternative way to remove information set by set_clock_gating_check is to use the reset_design command.

clock phase meaning; related to asyn/syn clocks definition concepts

get_timing_path slack, startpt, endpt

set f [open output.txt w]

set pa1 [get_timing_paths \
-from START_POINT \
-to END_POINT \
-start_end_pair]
#set pa1 [get_timing_paths -from START_POINT -to END_POINT -start_end_pair -group CLK_NAME]

foreach_in_collection p1 $pa1 {

#Get slack
set slack1 [get_attribute $p1 slack]


##Get startpoint
set sp_m [get_attribute [get_attribute $p1 startpoint] full_name]
set sp [string trimright $sp_m "\/clk"]

##Get Endpoint
set ep_m [get_attribute $p1 endpoint]
set ep [get_cell -of_object $ep_m]

##Getting the prev stage margin: slack, cell
set sp_pa1 [get_timing_path -to $sp/d]
set sp_pa1_slack [get_attribute $sp_pa1 slack]

set ep_sp_pa1 [get_attribute $sp_pa1 endpoint]
set ep_sp_pa1_cell [get_cell -of_objects [get_pin $ep_sp_pa1]]
set ep_sp_pa1_cell_slack [get_attribute [get_timing_path -to $ep_sp_pa1_cell] slack]

##Getting the next stage margin: slack, cell
set ep_pa1 [get_timing_path -from [get_attribute $ep full_name]/clk]
set ep_pa1_slack [get_attribute $ep_pa1 slack]

set sp_ep_pa1 [get_attribute $ep_pa1 startpoint]
set sp_ep_pa1_cell [get_cell -of_objects [get_pin $sp_ep_pa1]]

set sp_ep_pa1_cell_slack [get_attribute [get_timing_path -to $sp_ep_pa1_cell] slack]


puts $f "$sp [get_attribute $ep full_name] $slack1 $sp_pa1_slack $ep_pa1_slack"

}
close $f

What is CRP? Explian with Cross talk taken into account and given simple example?

FLOW of STA run:

FLAT run:

Linking the design:
     i) Verilog netlist files
    ii) def files for each sub module
     i) Logic libraries or std cell libraries.
     ii) Memories

Inputs:
     i) AOCV/POCV derates tables
     ii) Hold margin files ?
    iii) spef files and annotation
              - STAR RC extraction
    iv) Constraints files
    v) PNR inputs
             - def files, lef files

Outputs:
    i)

Can clock path be like this?

CLK  -----> going to paraller branches of 3 symmetric buffers each ----> series branch of 2 buffers


No. Though symmetric and equal number of buffers are used in the parallel branches, still glitches may occur because of metal layers change and parasitic changes etc...

RC corners used for setup and hold violations

For setup:
cw  ==> for shorter nets, optimistic compared to rcw;  extraction takes less time compared to rcw.
rcw  ==> used for longer nets, contributes more delay (worst)

   cw is used at the early stage for setup fixes but rcw is used at the final sign-off.

For hold:
cb  ==> best and optimistic for hold,
rcb  ==> we never use this combination.

ECO fixing: Which is a must fix and which can be left out of max_transition, max_cap violations?

Max_tran is must fix.

Max_cap can be left; because your cell is good enough to drive other cells without violating max_tran of  each input though it violates max cap requirement.

Further explaination is required ???????


Fixing max_tran violations:

i) size_cell
ii) insert_buffer
         - should be ideally placed from the pin (not very closed to pin). i.e., mention the location

report_clock_timing

report_clock_timing

            --> Reports timing attributes of clock networks.

EXAMPLES

The following example shows a typical summary style report.

pt_shell> report_clock_timing -type summary

****************************************
Report : clock timing
        -type summary
        -nworst 1
 ...
****************************************

  Clock: CK1
----------------------------------------------------------------------------
  Maximum setup launch latency:
      flop9/CP                                               3.08      rp-+

  Minimum setup capture latency:
      or2_3/B                                                1.15      fpi-+

  Minimum hold launch latency:
      or2_3/B                                                1.15      fpi-+

  Maximum hold capture latency:
      flop9/CP                                               3.08      rp-+

  Maximum active transition:
      or2_3/B                                                0.20      fpi-+

  Minimum active transition:
      or2_3/B                                                0.09      fpi-+

  Maximum setup skew:
      flop9/CP                                                         rp-+
      flop10/CP                                              0.87      rp-+

  Maximum hold skew:
      flop9/CP                                                         rp-+
      flop10/CP                                              -0.21     rp-+
----------------------------------------------------------------------------

The following example displays the five worst setup skews in the clock network of CLK1, taking uncertainty into account.

pt_shell> report_clock_timing -clock CLK1 -type skew -setup \
             -nworst 5 -include_uncertainty_in_skew

****************************************
Report : clock timing
        -type skew
        -nworst 5
        -setup
        -include_uncertainty_in_skew
Design : multi_domain
 ...
****************************************

  Clock: CLK1

  Clock Pin                              Latency   Uncert    Skew
----------------------------------------------------------------------------
  f2_2/CP                                6.11                          rp-+
  f2_1/CP                                2.01      0.11      4.21      fp-+

  l3_2/G                                 4.10                          rpi-
  f1_2/CP                                1.00      0.22      3.32      rpi-+

  l2_2/G                                 4.11                          rp-
  f1_2/CP                                1.00      0.12      3.23      rpi-+

  f2_2/CP                                6.11                          rp-+
  l3_3/G                                 3.01      0.11      3.21      rp-

  l1_3/G                                 5.11                          rp-
  f2_1/CP                                2.01      0.11      3.21      fp-+
----------------------------------------------------------------------------

The following displays the five worst launching latencies for hold paths in the clock network of CLK2.

pt_shell> report_clock_timing -clock CLK2 -hold -launch -nworst 5 \
             -type latency

****************************************
Report : clock timing
        -type latency
        -launch
        -nworst 5
        -hold
Design : multi_domain
 ...
****************************************

  Clock: CLK2

                                               --- Latency ---
  Clock Pin                    Trans     Source    Network   Total
----------------------------------------------------------------------------
  f1_2/CP                      0.04      0.00      1.00      1.00      rpi-+
  f1_3/CP                      0.00      0.01      1.00      1.01      fp-+
  f2_1/CP                      0.01      0.01      2.00      2.01      rp-+
  f1_1/CP                      0.00      0.00      3.00      3.00      rpi-+
  f3_2/CP                      0.00      0.00      3.00      3.00      fpi-+
----------------------------------------------------------------------------

The following example demonstrates how to request a verbose report showing the worst local skew from f2_2/CP to any other sink pin.

pt_shell> report_clock_timing -type skew -verbose -from f2_2/CP

****************************************
Report : clock timing
        -type skew
        -verbose
        -nworst 1
        -setup
Design : multi_domain
 ...
****************************************

  Clock: CLK1

  Startpoint: f2_2 (rising edge-triggered flip-flop clocked by CLK1)
  Endpoint: f2_1 (rising edge-triggered flip-flop clocked by CLK1)

  Point                               Trans       Incr       Path
  ------------------------------------------------------------------
  clock source latency                            0.11       0.11
  clk2 (in)                            0.00       0.00       0.11 r
  az_1/Z (B1I)                         0.09       1.00 H     1.11 r
  az_2/Z (B1I)                         0.13       1.00 H     2.11 r
  bf2_2_1/Z (B1I)                      0.02       1.00 H     3.11 r
  if2_2_1/Z (IVA)                      0.44       1.00 H     4.11 f
  bf2_2_2/Z (B1I)                      0.01       1.00 H     5.11 f
  if2_2_2/Z (IVA)                      0.13       1.00 H     6.11 r
  f2_2/CP (FD1)                        0.13       0.00       6.11 r
  startpoint clock latency                                   6.11

  clock source latency                            0.01       0.01
  clk2 (in)                            0.00       0.00       0.01 r
  az_1/Z (B1I)                         0.02       1.00 H     1.01 r
  az_3/Z (B1I)                         0.01       1.00 H     2.01 r
  f2_1/CP (FD1)                        0.01       0.00       2.01 r
  endpoint clock latency                                     2.01
  ------------------------------------------------------------------
  startpoint clock latency                                   6.11
  endpoint clock latency                                    -2.01
  ------------------------------------------------------------------
  skew                                                       4.10

The following example traces the two worst launch latencies for hold paths in the clock network of CLK1.

pt_shell> report_clock_timing -type latency -hold -verbose \
             -nworst 2 -clock CLK1

****************************************
Report : clock timing
        -type latency
        -verbose
        -launch
        -nworst 2
        -hold
Design : multi_domain
 ...
****************************************

  Clock: CLK1

  Endpoint: f1_2 (rising edge-triggered flip-flop clocked by CLK1')

  Point                               Trans       Incr       Path
  ------------------------------------------------------------------
  clock source latency                            0.00       0.00
  clk1 (in)                            0.00       0.00       0.00 f
  if1_2_1/Z (IVA)                      0.04       1.00 H     1.00 r
  f1_2/CP (FD1)                        0.04       0.00       1.00 r
  total clock latency                                        1.00

  Endpoint: f1_3 (rising edge-triggered flip-flop clocked by CLK1)

  Point                               Trans       Incr       Path
  ------------------------------------------------------------------
  clock source latency                            0.01       0.01
  clk1 (in)                            0.00       0.00       0.01 r
  bf1_3_1/Z (B1I)                      0.00       1.00 H     1.01 r
  f1_3/CP (FD1)                        0.00       0.00       1.01 r
  total clock latency                                        1.01

The following example makes use of a slack filter to display the worst three skews between latches whose latch-to-latch paths are violating.

pt_shell> report_clock_timing -type skew -nworst 3 \
             -slack_lesser_than 0.0

****************************************
Report : clock timing
        -type skew
        -slack_lesser_than 0.00
        -nworst 3
        -setup
Design : multi_domain
 ...
****************************************

  Clock: CLKA

  Clock Pin                    Latency    CRP      Skew      Slack
----------------------------------------------------------------------------
  f2_2/CP                      6.01                                    rp-+
  f2_1/CP                      2.11      -0.03     3.87      -1.49     rp-+

  l2_2/G                       4.01                                    rp-
  f1_2/CP                      1.10      -0.21     2.70      -6.64     rpi-+

  l1_3/G                       5.01                                    rp-
  f2_1/CP                      2.11      -0.32     2.58      -1.63     rp-+
----------------------------------------------------------------------------

The following example requests the two largest setup skews for paths both launched and captured by any clock networks in the list $my_clocks.

pt_shell> report_clock_timing -type interclock_skew \
             -from_clock $my_clocks -to_clock $my_clocks \
             -nworst 2 -include_uncertainty_in_skew -show_clocks

****************************************
Report : clock timing
        -type interclock_skew
        -nworst 2
        -setup
        -include_uncertainty_in_skew
        -show_clocks
 ...
****************************************

  Number of startpoint pins   : 907
  Number of endpoint pins     : 907
  Number of startpoint clocks : 5
  Number of endpoint clocks   : 5

  Clock Pin                              Latency   Uncert    Skew
----------------------------------------------------------------------------
  orig_clk 
  orig_if/ram_pdp1/FFB35/CK              1016.72                       rp-+
  dcd_ram/ram_clk 
  dcd_ram/dcd_ram/RAM/CKRB               149.60    195.00    1062.12   rp-+

  comp_clk 
  comp_if/c_port_if/edge_trig_reg/CK     1400.42                       rp-+
  comp_clk 
  comp_if/c_port_if/posi/iq_reg/CK       1159.09   199.00    440.34    rp-+
----------------------------------------------------------------------------

The following reports the largest two setup skews in the domain of CLKB in the context of a detailed variation-aware clock analysis, and requests the augmentation of the report with variation information.

pt_shell> report_clock_timing -type skew -clock CLKB -variation

****************************************
Report : clock timing
        -type skew
        -nworst 2
        -variation
Design : multi_domain
 ...
****************************************

  Clock: CLKB

                                               --- Skew ---
  Clock Pin                    Latency   Stddev    Mean      Quant
----------------------------------------------------------------------------
  f2_2/CP                      0.40221                                 rp-+
  f2_1/CP                      0.13533   0.02825   0.26688   0.34732   rp-+

  l2_1/CP                      0.33036                                 rpi-+
  l2_2/CP                      0.18638   0.02626   0.14398   0.20948   rp-+ 

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

report_clock_timing

NAME
SYNTAX
ARGUMENTS
DESCRIPTION
EXAMPLES
SEE ALSO 

---

NAME

report_clock_timing

Reports timing attributes of clock networks.

SYNTAX

string report_clock_timing 
  -type report_type
  [-clock clock_list]
  [-from_clock from_clock_list]
  [-to_clock to_clock_list] 
  [-from from_list]
  [-to to_list] 
  [-setup | -hold]
  [-launch | -capture]
  [-rise | -fall]
  [-nworst worst_entries]
  [-greater_than lower_limit]
  [-lesser_than upper_limit]
  [-slack_lesser_than slack_upper_limit]
  [-include_uncertainty_in_skew]
  [-verbose]
  [-significant_digits digits]
  [-show_clocks]
  [-crosstalk_delta]
  [-derate]
  [-variation]
  [-sort_by sort_attr]
  [-clock_crossing]
  [-include_clock_gating]
  [-nosplit]
  [-pre_commands pre_command_string]
  [-post_commands post_command_string]

Data Types

report_type            string
clock_list             list
from_clock_list        list
to_clock_list          list   
from_list              list  
to_list                list
worst_entries          int
lower_limit            float
upper_limit            float
slack_upper_limit      float
digits                 int
sort_attr              string
pre_command_string     string
post_command_string    string

ARGUMENTS

-type report_type

Specifies the type of report to be generated. You can specify the following values for report_type:

• transition - Transition time report.
• latency - Latency report.
• skew - Skew report. You cannot use the -launch, -capture, -rise, -fall, and -lesser_than options if you specify a skew report, and you can use the -include_uncertainty_in_skew option only in a skew, interclock_skew, or summary report.
• interclock_skew - Interclock skew report. You cannot use the -launch, -capture, -rise, -fall, and -lesser_than options if you specify an interclock skew report, and you can use the -include_uncertainty_in_skew option only in a skew, interclock_skew or summary report.
• summary - Summary report, which shows the worst instances of transition time, latency and skew over the clock networks or subnetworks of interest. If you specify a summary report, you can use only the -clock, -to_list, -from_list, -include_uncertainty_in_skew, -nosplit, and -significant_digits options.
  For nonsummary reports, report entries are ordered with respect to the specified attribute of interest (transition time, latency, or skew). Note that all skews reported are "local" skews. For an explanation of local skew, see the DESCRIPTION section.

-clock clock_list

Uses the specified clock networks in the report. A subreport is typically produced for every clock in the clock_list, unless you additionally specify the to_list, from_list, or both options that has no network intersection with a given clock. In that case, PrimeTime drops these clocks from the clock_list and also issues a warning. By default, if you do not specify clock_list, all clocks in the design that have associated clock networks are used in the report.

-from_clock from_clock_list

Uses the specified clock networks as from-clocks in the current interclock skew report. This option can be used only in an interclock skew report. The report typically considers every clock in from_clock_list, unless you additionally specify the from_list option that has no network intersection with a given clock. In that case, PrimeTime drops these clocks from the from_clock_list and also issues a warning. By default, if you do not specify the from_clock_list option, all clocks in the design that have associated clock networks are used as from-clocks in the report.

-to_clock to_clock_list

Uses the specified clock networks as to-clocks in the current interclock skew report. This option can be used only in an interclock skew report. The report typically considers every clock in to_clock_list, unless you additionally specify a to_list that has no network intersection with a given clock. In that case, PrimeTime drops these clocks from the to_clock_list and also issues a warning. By default, if you do not specify the to_clock_list option, all clocks in the design that have associated clock networks are used as to-clocks in the report.

-from from_list

Considers the specified sequential clock network pins or ports as from-pins in the current report. If any named pin is not the clock pin of a sequential device, PrimeTime replaces that pin with all sequential clock pins in the transitive fanout of the named pin. If there are no sequential clock pins in the pin's transitive fanout, the pin is dropped from the list and a warning message is issued.

-to to_list

Considers the specified sequential clock network pins or ports as to-pins in the current report. If any named pin is not the clock pin of a sequential device, such as a sink pin, PrimeTime replaces that pin with all sequential clock pins in the transitive fanout of the named pin. If there are no sequential clock pins in the pin's transitive fanout, the pin is dropped from the list with a warning message.
For skew reports, the from-to skew sense is defined by the pins in the from_list and to_list options respectively; if the to_list option is not specified, by default all sink pins in the given clock networks are used. Thus, specifying the to_list option reduces the topological scope of the report. For transition time and latency reports, the from_list and to_list options are concatenated and treated as a single list; if neither is specified, the to_list option is assumed to be populated with all sink pins in the given clock networks.
For skew reports, the from-to skew sense is defined by the pins in the from_list and to_list options respectively; if the from_list option is not specified, by default all sink pins in the given clock networks are used. Thus, specifying the to_list option reduces the topological scope of the report. For transition time and latency reports, the from_list and to_list options are concatenated and treated as a single list; if neither is specified, the to_list option is assumed to be populated with all sink pins in the given clock networks.

-setup

Uses only the setup data path is to be used in the report. Also, the skews, latencies or transition times reported must correspond to those used by the report_timingcommand in the verification of setup constraints. The -setup and -hold options are mutually exclusive. If neither option is specified, the -setup option is assumed. You cannot use this option in summary reports.

-hold

Uses only the hold data path in the report. Also, the skews, latencies, or transition times reported must correspond to those used by the report_timing command in the verification of hold constraints. The -setup and -hold options are mutually exclusive. If neither option is specified, the -setup option is assumed. You cannot use this option in summary reports.

-launch

Uses only pins that launch data in the report. Also, latencies or transition times reported must correspond to those used by the report_timing command for sequential device clock pins that are launching data. In skew reports, the role is implicit from the from-to sense indicated by the from_list and to_list arguments. In all other reports, the -launch and -capture options are mutually exclusive. If neither option is specified, the -launch option is assumed. You cannot use this option in summary or skew reports.

-capture

Uses only pins that capture data in the report. Also, the latencies or transition times reported must correspond to those used by the report_timing command for sequential device clock pins that are capturing data. In skew reports, the role is implicit from the from-to sense indicated by the from_list and to_list options. In all other reports, the -launch and -capture options are mutually exclusive. If neither option is specified, the -launch option is assumed. You cannot use this option in summary or skew reports.

-rise

Specifies that the active transition is a rising edge for sequential device clock pins in the current report. The -rise and -fall options are mutually exclusive; if neither option is specified, the active transition at a latch or flip-flop is deduced from the launch or capture role and the behavior of the sequential device itself. This option enables you to answer "what if" questions regarding latency and transition time at sequential device clock pins. You cannot use this option in summary or skew reports.

-fall

Specifies that the active transition is a falling edge for sequential device clock pins in the current report. -rise and -fall are mutually exclusive; if neither is specified, the active transition at a latch or flip-flop is deduced from the launch or capture role and the behavior of the sequential device itself. This option enables you to answer "what if" questions regarding latency and transition time at sequential device clock pins. You cannot use this option in summary or skew reports.

-nworst worst_entries

Specifies the number of worst report entries to be reported per clock domain; the default is 1. Entries are sorted with respect to the attribute of interest (transition time, latency or skew) specified with the -type option of the report_type command.
The worst entries are those most likely to cause a violation. For example, if you request a latency report using -setup and -capture, the smallest worst_entries are listed, sorted in ascending order, because small capture latencies for setup paths are more likely to lead to a violation than large capture latencies. By contrast, for skew reports, the worst entries always correspond to the largest skews over the specified domain. You cannot use this option in summary reports.

-greater_than lower_limit

Shows only those entries with an attribute value (latency, transition time or skew) greater (more positive) than lower_limit. You cannot use this option in summary reports.

-lesser_than upper_limit

Shows only those entries with an attribute value (latency, transition time or skew) less (more negative) than upper_limit. You cannot use this option in summary or skew reports.

-slack_lesser_than slack_upper_limit

Shows only those entries with a slack value less (more negative) than slack_upper_limit. For skew report entries slack is the worst slack over all paths launched by the from-pin and captured by the to-pin. For transition time or latency report entries, slack is defined as the worst slack of all paths either launched by a transition at the sink pin (if the -launch option is used) or captured by a transition at the sink pin (if the -capture option is used).
Note that the use of this filter might greatly increase the runtime of this report. However, when used with the -capture option the effect on runtime should be small, since PrimeTime can make use of cached slack values to avoid expensive recomputations. You cannot use this option in summary reports.

-include_uncertainty_in_skew

Specifies that the user-defined uncertainty between the sequential devices in a launch/capture pair is to be considered a component of skew. You cannot use this option in summary or skew reports.

-verbose

Generates a more detailed report; instead of a single line per pin, verbose reports trace the entire source-to-sink path through a clock network to show how the final reported attribute (skew, latency or transition time) was accumulated over the course of the path. You cannot use this option in summary reports.

-significant_digits digits

Specifies the number of digits after the decimal point to be displayed for time values in the generated report. Allowed values are 0-13; the default is determined by the report_default_significant_digits variable, which has a default of 2. Use this option if you want to override the default. This option controls only the number of digits displayed, not the precision used internally for analysis. For analysis, PrimeTime uses the full precision of the platform's fixed-precision, floating-point arithmetic capability.

-show_clocks

Shows the launching and capturing clocks for every interclock skew entry in the report. This is useful if from_clock_list or to_clock_list contain more than one clock each. You cannot use this option in interclock skew reports.

-crosstalk_delta

Shows the delta delay and delta transition time in verbose reports. The deltas are computed during crosstalk signal integrity analysis, or they can be annotated manually using the set_annotated_delay -delta_only and set_annotated_transition -delta_only commands. Note that the -crosstalk_delta option reports only the calculated or annotated deltas, it does not initiate crosstalk analysis. Only deltas on input pins are shown.

-derate

Shows the derating factors in the report. By default, derating factors are not displayed. Derating factors are only shown when you specify the -verbose option.

-variation

Shows variation information. Using this option is allowed only when detailed variation-aware clock analysis is enabled. Without -variation, only the quantile or mean value is displayed, as specified using the variation_derived_scalar_attribute_mode variable. With -variation, the quantile, mean and either the standard deviation (for skew reports) or sensitivity (for latency or transition reports) is displayed for both verbose and non-verbose reports. In verbose reports, additional statistical info regarding individual path increments appear in new columns, namely the sensitivity, mean and increment, where the increment refers either to the quantile or the effective delay depending on the variation_report_timing_increment_format variable.

-sort_by sort_attr

Sorts the entries in the report with respect to the specified variational attribute. This option can be used only with the -summary option and only when detailed variation-aware clock analysis is enabled. Note that this option only controls the ranking of entries and not their display. You can specify the following values for sort_attr:

• quantile - Ranks entries using their quantile values.
• mean - Ranks entries using their mean values.
• sensitivity - Ranks entries using their sensitivity values. This option cannot be used in a skew or interclock_skew report.

-clock_crossing

Indicates that only skews between interacting clock domains (i.e. clocks connected by at least one non-false data path) is included in the report. This option can only be used in interclock_skew reports.

-include_clock_gating

Include clock pins of clock-gating checks in the report. By default, only sequential devices that exercise a setup/hold check are reported by report_clock_timing. This option additionally allows clock-gating checks to be reported.

-nosplit

Prevents line-splitting and facilitates writing software to extract information from the report output. If this option is not used, most of the design information is listed in fixed-width columns. If the information in a given field exceeds the column width, the next field begins on a new line, starting in the correct column.

-pre_commands pre_command_string

This option is available only if you invoke PrimeTime with the -multi_scenario option. This option allows you to specify a string of commands to be executed in the slave context before the execution of the merged reporting command. Commands must be grouped using the ";" character. The maximum size of a command is 1000 chars.

-post_commands post_command_string

This option is available only if you invoke PrimeTime with the -multi_scenario option. This option allows you to specify a string of commands to be executed in the slave context after the execution of the merged reporting commands. Commands are grouped using the ";" character. The maximum size of a command is 1000 chars.

DESCRIPTION

This command generates a report of clock timing information for the current design.
There are several reporting types provided, which allow you to examine skew, latency and transition time attributes of a given clock network or subnetwork at various levels of generality. By default, the report displays the values of these attributes only at sink pins (that is, the clock pins of sequential devices) of the clock network. You use the -verboseoption to display source-to-sink path traces. If you specify several clock domains, the report_clock_timing command generates a separate subreport for each clock domain.
At the highest level of abstraction is the summary style report, which provides only a list of maxima and minima of the skew, latency, and transition time attributes over the given networks. At a lower level of abstraction are the transition, latency, and skew type reports, called list style reports, in which you can sort, filter and display the worst set of sink pins in the given network with respect to a single attribute of interest. For skew reports, each report entry is a pair of sink pins and their relative skew. For transition time or latency reports, each entry corresponds to a single sink pin. The lowest level of abstraction is provided by verbose mode, which replaces every sink pin in a list style report by a corresponding source-to-sink path trace.
In both summary and list style reports, the rightmost column is an attributed column. Corresponding to each sink pin, the set of character symbols in this column indicates the following:

Symbol    Meaning
------    -------
 r        Rising transition
 f        Falling transition
 p        Propagated clock to this pin
 i        Clock inversion to this pin
 -        Launching transition
 +        Capturing transition
 m        Library clock insertion delay

In verbose mode, back-annotations on path elements in the timing path are indicated using a character symbol. For definitions of these character symbols, see the manual page of the report_timing command.
Skews reported by report_clock_timing are local skews only. Local skew exists from one sink pin to another only if their associated sequential devices are connected via a data path in the appropriate from-to sense. Note that even if all data paths between the sequential devices are false because of user-defined exceptions, the skew still qualifies as local skew if the devices are connected topologically.
If detailed variation-aware clock analysis is enabled using the variation_analysis_mode variable, the report_clock_timing command evaluates the attributes of latency, transition time and skew as statistical entities. By default, the quantile of these attributes is used for both ranking and display purposes. The ranking can be controlled using the -sort_by option, while the display parameter can be changed from quantile to mean using the variation_derived_scalar_attribute_mode variable. To augment the display with additional statistical parameters of report_clock_timing attributes, see the -variation option.