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.

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.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

Report:timing

-path full_clock

-delay min

-nworst10

-derate

-input_pins

-nets

-max_paths10

Design:digtop

Scenario(s):func_max

Version:E-2010.12-ICC-SP2

Date:Mon Jul2311:01:202012

*Some/all delay information isback-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.

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.

1

2

3

4

timing_control_0/C1276/Y(AND2X3)0.003.13r3.00

timing_control_0/o_clk_agc(net)20.003.13r

dig_agc_0/BUFX8_G6B1I2/A(BUFX8)0.00&3.13r3.00

dig_agc_0/BUFX8_G6B1I2/Y(BUFX8)0.773.91r3.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.

SETUP REPORT

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.

HOLD REPORT

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.

Recommended for you

19 Comments

diapanagar

September 28, 2013 at 3:17 am

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.

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

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.

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?

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.

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)

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.

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?