Reading ICC Timing Reports

At any stage of the design you will be reporting timing. You can use your PnR tool to report the timing after placement, after CTS and various stages of routing and optimization. Even though the P&R timing reports are not signoff STA, they are still very important in understanding the tool behaviour. ICCompiler & PT has similar report structure and I will try to explain a simple path here.

A few tips before we begin.

  • When reporting timing, make sure you use “full_path” reporting for an easy analysis.
    • e.g. To report setup time, report_timing -delay max -path full_clock -nworst 10
  • The -delay determines whether hold or setup is reported. To report hold paths, use “-delay min”
  • Use –scenario option if you have created multiple scenarios in PnR.

This article talks about decoding the ICC report. To understand the setup and hold analysis, please first read STA – Setup & Hold.

Now, let’s see how a simple register-register path looks in a timing report.

The header of the timing report is given below. This gives the options you have used while running “report_timing”. As can be seen from “delay min”, this is a hold violation report. -scenario option is specified and timing is reported for the scenario “func_max”. We will take about derating in another post so as not to complicate stuff.

Report : timing
        -path full_clock
        -delay min
        -nworst 10
        -max_paths 10
Design : digtop
Scenario(s): func_max
Version: E-2010.12-ICC-SP2
Date   : Mon Jul 23 11:01:20 2012

* Some/all delay information is back-annotated.
	Scenario            : func_max
	Parasitic source    : LPE
	Parasitic mode      : RealRC
	Extraction mode     : MULTI_CORNER
	Extraction derating : 95/95

In a hold timing report, the tool is checking whether the data is held long enough after the clock arrival at the clock port of the flop. i.e. if the data path is faster, the data at the flop edge can change earlier than the stipulated hold time.

There are three clock edges we are considering in the above signal diagram. tS & tH are the setup and hold times of the flops respectively. In the clock edge marked I, you can see that data is stable at tS & tH and changes only outside this window. However, in the behavior at the clock edge marked II, the data is not stable in the setup window, and hence the design has a setup violation. This is caused by the data path being slow compared to the clock path. In the clock edge marked III, the data changes in the hold window, hence causing a hold violation.

Startpoint: dig_agc_0/int_term_reg_0_
              (rising edge-triggered flip-flop clocked by clk_agc)
  Endpoint: dig_agc_0/int_term_reg_0_
            (rising edge-triggered flip-flop clocked by clk_agc)
  Scenario: func_max
  Path Group: clk_agc
  Path Type: min

Point                                      	 Fanout  Derate  Incr       Path      Voltage
clock clk_agc (rise edge)                                      0.00       0.00      
clock source latency                                           3.13       3.13 r    
timing_control_0/C1276/Y (AND2X3)                              0.00       3.13 r    3.00
timing_control_0/o_clk_agc (net)               2               0.00       3.13 r    
dig_agc_0/BUFX8_G6B1I2/A (BUFX8)                               0.00 &     3.13 r    3.00
dig_agc_0/BUFX8_G6B1I2/Y (BUFX8)                               0.77       3.91 r    3.00
dig_agc_0/o_clk_agc_G6B1I2 (net)               15              0.00       3.91 r    
dig_agc_0/int_term_reg_0_/CP (SDFFCQX2)                        0.01 &     3.92 r    3.00
dig_agc_0/int_term_reg_0_/CP (SDFFCQX2)                        0.00       3.92 r    3.00
dig_agc_0/int_term_reg_0_/Q (SDFFCQX2)                         0.97       4.89 r    3.00
dig_agc_0/int_term[0] (net)                    3               0.00       4.89 r    
dig_agc_0/U306/A (OAI21X1)                                     0.00 &     4.89 r    3.00
dig_agc_0/U306/Y (OAI21X1)                                     0.26       5.15 f    3.00
dig_agc_0/n209 (net)                        	 1               0.00       5.15 f    
dig_agc_0/U309/B (OAI21X1)                    	         0.00 &     5.15 f    3.00
dig_agc_0/U309/Y (OAI21X1)                                     0.42       5.57 r    3.00
dig_agc_0/N105 (net)                           1               0.00       5.57 r    
dig_agc_0/int_term_reg_0_/D (SDFFCQX2)                         0.00 &     5.57 r    3.00
data arrival time                                                         5.57      

clock clk_agc (rise edge)                            		 0.00       0.00      
clock source latency                                 		 3.13       3.13 r    
timing_control_0/C1276/Y (AND2X3)                            	 0.00       3.13 r    3.00
timing_control_0/o_clk_agc (net)               2               0.00       3.13 r    
dig_agc_0/BUFX8_G6B1I2/A (BUFX8)                               0.00 &     3.13 r    3.00
dig_agc_0/BUFX8_G6B1I2/Y (BUFX8)                               0.77       3.91 r    3.00
dig_agc_0/o_clk_agc_G6B1I2 (net)               15              0.00       3.91 r    
dig_agc_0/int_term_reg_0_/CP (SDFFCQX2)                        0.01 &     3.92 r    3.00
clock reconvergence pessimism                                  0.00       3.92      
clock uncertainty                                            	 0.10       4.02      
dig_agc_0/int_term_reg_0_/CP (SDFFCQX2)                        0.00       4.02 r    
library hold time                                             -0.48       3.54      
data required time                                                        3.54      
data required time                                                        3.54      
data arrival time                                                        -5.57      
slack (MET)                                                               2.03   

The above path reports the data and clock as it reaches dig_agc_0/int_term_reg_0_/D and dig_agc_0/int_term_reg_0_/CP pins respectively. From clock port “clk_agc” to the clock pin CP of the flop dig_agc_0/int_term_reg_0_, there is a delay of 3.54ns. So the data should take at least 3.54 seconds to reach the cooresponding D pin, which becomes the “required time”. The signal on the data pin takes 5.57ns to reach the D pin, which is actual arrival time.

timing_control_0/C1276/Y (AND2X3)                              0.00       3.13 r    3.00
timing_control_0/o_clk_agc (net)               2               0.00       3.13 r    
dig_agc_0/BUFX8_G6B1I2/A (BUFX8)                               0.00 &     3.13 r    3.00
dig_agc_0/BUFX8_G6B1I2/Y (BUFX8)                               0.77       3.91 r    3.00

In the above snippet of the path, the transition due to net timing_control_0/o_clk_agc is given. The source of the net is timing_control_0/C1276/Y. The incremental delay is 0.00, and the total path delay upto this point is 3.13. The voltage corner used for the timing report is 3.00V. The net timing_control_0/o_clk_agc has 2 fanouts and in the path going to A pin of dig_agc_0/BUFX8_G6B1I is under analysis. The net adds a further delay of 0.00 and the total path delay stays the same. In the next line, a 0.77 delay is added, which is the internal cell delay of the buffer BUFX8[A->Y].

A setup check is also done on the paths to make sure no setup timing is violated. Together these checks ensure that the design will be functional for the frequency specified.

Now let us see some more analysis paths.


Click on this linkto see two setup timing reports for the same IO port-to-register path. The first report is taken after placement, but before completing CTS. The data path is from port ‘sdi’ to the D pin of the data_okay_reg. The clock at both launch and the capture edges are ideal. The clock network is reported after the line “data arrival time”.With an ideal clock network delay of 0.00, the setup time is met in this report. Further down, we have the setup analysis report for the same path after CTS. Here, we have propagated the clock, and now we have the delays associated with the clock network built by CTS. If you look at the section before “data arrival time” it is very different from the first report. You can also see why the path now violates setup.


Here is a hold analysis report for a register-register path. The data pin is SI ( the scenario here is scan), and the path is reported to be violating since the data arrived too early with respect to the clock.

21 comments on “Reading ICC Timing Reports

  1. diapanagar

    Hi ,

    here slack = 3.54 -5.57 = -2.03 . so the slack is negative. hence the set up time is not met right? there is a set up voilation.  but why have u mentioned it as MET?  plz let me know if m wrong in analysing this slack.

    1. Sini

      This is a hold analysis report. The given report is verifying that the hold is met at D pin of flipflop dig_agc_0/int_term_reg_0_.

      Please note the following difference in definitions:

      Clock Setup Slack = Data Required Time – Data Arrival Time
      Clock Hold Slack = Data Arrival Time – Data Required Time

      In the given report, the second half of the report calculates the time required for the clock to reach the CP pin of the flop. When hold checks are done, we are verifying that the data is present AFTER the clock arrives. So the MINIMUM time the data should take to reach D pin so as to be read using clock at CP is 3.54ns. If the data had arrived at D before 3.54ns (i.e. before the clock is stable at CP pin of int_term_reg_0_ ), we would have a hold violation.

      I will add a some different kinds of paths as examples, so there is less confusion. Let me know if my explanation is still not clear. Just keep in mind that when you are dealing with any data pin, the earlier the signal is, you can potentially have a hold violation. Because the clock that should launch/capture this data hasn’t reached the clock pin.

      Update: Added a setup path analysis report and a reg-reg hold report.

      Please visit the following article to understand the types of analysis. STA – Setup & Hold

    1. Sini Mukundan Post author

      Annotation is specified by ‘&’. There are also other characters used. Typically after SDF annotation, you will see * in the timing report. This is an ICC report before any back-annotation. ‘&’ mean this is annotated by tool calculated delays using “Elmore delay calculation”. Elmore is a simple RC network calculation used by the tool. You can see sometimes, it “C” which is Arnoldi alogorithm based RC extraction.

      This is very important even at ICC stage, since ELmore delay can give a relatively accurate number, without too much runtime. You can explore the various options of the command ‘set_delay_calulation’ to see the differences.

      The value ‘r’ & ‘f’ near path is not representing back-annotation. Rather, they state whether the signal transition is rising or falling.

  2. david

    I don’t understand why library hold time is negative. It seems to me that it relaxes the hold time requirement. It isn’t the library hold time supposed to be positive to force the data stay stable to meet the hold time requirement?

    1. Sini Mukundan Post author

      Think of it as the requirement of your library and not as relaxing the constraint. A negative library hold time means that the data pin can change before the related pin(CP).

      Please check the hold_falling/hold_rising statements in the .lib file. These can be a mixture of +ve and -ve values.

      So in both the reports given in the article, you are in effect “relaxing” the minimum delay requirement of the paths, but that is allowed by the library.

  3. pramod

    Theoretically we will study that library hold time should be added to capture clock which gives required time. But why here library hold time is subtracted. Is my analysis correct. Or there is some other explanation for it, please explain it.

  4. Sini Mukundan Post author

    The library hold time is getting added here also. The value is negative. If you check your .libs you can see some cells with negative hold time requirement. Read the previous comment too.

  5. Sarvang Sanghavi

    I have 2 doubts…
    1. what i LPE parasitic source ??
    2. How tool calculates RC values of a net after global routing ?
    (At placement, all WLMs are removed and TLU+ file contains RC info. but only for metal layers (and not for nets used during GR).
    correct me if i am wrong)

  6. Sini Mukundan Post author

    1. LPE is layout parasitic extraction, and is essentially the parasitics from the layout, nets included.
    2. In Cadence EDI, the tool creates a trial route to calculate the RC. This is not a complete clean route, but a rough route according to the global route.

  7. bharath

    after postroute if they are lot of DRC vilolations(eX:1000)? what can be done instead of manual can we fix it in synposys tool

  8. sai vijaya bhaskar

    madam ,
    a small doubt…
    example : 1
    i have a setup violation ..i increased drive strength of cell CKBD12 to CKBD20 . now again is it necessary to perform CTS or else nanoroute is enough. which is correct?

    thanks in advance

  9. Ramesh

    About IO-port to register paths, the input delay in the above example is set to 90ns. For IO that are internally synchronized and/or source synchronous, can we set the external input delay to zero?

    For instance, we have a two-wire serial port, and both signals are internally synchronized.

    Thank you! Your blog is very helpful, compared to digging through synopys manuals…

  10. hhs28

    Hi ,

    Could you please explain the timing from Latch to Register and other way around as well? Would be great if you can post some timing report as well for both setup and hold.<

  11. Nitesh

    Hi, I have a doubt
    I got positive slack during synthesis, but when i do encounter, I get negative wns? How to fix this? Can you please tell


Leave a Reply

Your email address will not be published. Required fields are marked *