TimeQuest Timing Analyzer[Setup slack analysis]

[Altera_Forum]

HI, 

 I am trying to understand how the Time Quest analyzer calculating required setup and hold time.I have written code for register and the clocks are common(50 MHz). As per my understanding data required time for setup calculation = clock arrival time -Tsu - Setup Uncertainty. From the Time Quest analyzer  clock arrival time = 22.982ns[ from source latency to clock pessimism] Tsu = 0.021ns Setup Uncertainty = 0ns  data required time = 22.982 - 0.021 = 22.961ns.  But the tool showing the calculation like below mentioned way,  data required time = 22.982 + 0.021 = 23.003ns.?  If i am not wrong the data required time should be 22.961ns.Please let me whether my understanding is correct or not? For your ref ------------------------------------------------------------------------------------------------------------------------ path summry: from node q1_s to node q~reg0 launch clock clk latch clock clk data arrival time 3.945 data required time 23.003 slack 19.058 ------------------------------------------------------------------------------------------------------------------------ data required path: total incr rf type fan out location element 20.000 0.000 source latency 20.000 0.000 1 pin_31 clk clk 20.000 0.000 rr ic 1 ioibuf_x0_y14_n1 clk~input|i 20.990 0.990 rr cell 1 ioibuf_x0_y14_n1 clk~input|o 21.182 0.192 rr ic 1 clkctrl_g4 clk~inputclkctrl|inclk[0] 21.182 0.000 rr cell 2 clkctrl_g4 clk~inputclkctrl|outclk 22.339 1.157 rr ic 1 ff_x1_y10_n17 q~reg0|clk 22.957 0.618 rr cell 1 ff_x1_y10_n17 q~reg0 22.982 0.025 clock pessimism 23.003 0.021 utsu 1 ff_x1_y10_n17 q~reg0 --------------------------------------------------------------------------------------------------------------------------------   Thanks in advance, Karthi.S

[Altera_Forum]

I own TimeQuest maintenance and development now, although I did not design TimeQuest. 

 rbugalho is generally right in this thread. The Th, Tco, Tsu params are refecting real circuit delays, more precisely, relative delays between two ports on the register circuitry. The documentation clearly states how these params are used in the equations. And the values can be positive or negative, depending on the HW design. My team is SW and do not modify the model delay values from the ICDesign teams without very good reasons; and we have no good reasons to make these params positive.  Of course, model bugs appear all the time, so we appreciate the users reporting perceived problems. But the micro params on these registers, since they are so visible, have been scrutinized heavily by the SW and HW modeling teams (for mature FPGA products) and should be correct by now.  Chris Wysocki

[Altera_Forum]

--- Quote Start ---  I own TimeQuest maintenance and development now, although I did not design TimeQuest.  rbugalho is generally right in this thread. The Th, Tco, Tsu params are refecting real circuit delays, more precisely, relative delays between two ports on the register circuitry. The documentation clearly states how these params are used in the equations. And the values can be positive or negative, depending on the HW design. My team is SW and do not modify the model delay values from the ICDesign teams without very good reasons; and we have no good reasons to make these params positive.  Of course, model bugs appear all the time, so we appreciate the users reporting perceived problems. But the micro params on these registers, since they are so visible, have been scrutinized heavily by the SW and HW modeling teams (for mature FPGA products) and should be correct by now.  Chris Wysocki  --- Quote End ---    Thanks Chris for your reply but unfortunately you are avoiding direst answer.  I understand Tsu/Th can be negative if relative delays exist at data/clock ports.  But then you are implying that the uTsu/uTh definition includes these delays and so can be either positive or negative. No problem but why not then report uTsu/uTh as they are.  Take this post specifically. We have this set of data:  data required path: total incr rf type fan out location element 20.000 0.000 source latency 20.000 0.000 1 pin_31 clk clk 20.000 0.000 rr ic 1 ioibuf_x0_y14_n1 clk~input|i 20.990 0.990 rr cell 1 ioibuf_x0_y14_n1 clk~input|o 21.182 0.192 rr ic 1 clkctrl_g4 clk~inputclkctrl|inclk[0] 21.182 0.000 rr cell 2 clkctrl_g4 clk~inputclkctrl|outclk 22.339 1.157 rr ic 1 ff_x1_y10_n17 q~reg0|clk 22.957 0.618 rr cell 1 ff_x1_y10_n17 q~reg0 22.982 0.025 clock pessimism 23.003 0.021 utsu 1 ff_x1_y10_n17 q~reg0  Is uTsu reported positiveor negative?  answer 1: it is positive as implied from final sum then the data required time equation is wrong answer 2: it is negative so equation is right but report is wrong.

[Altera_Forum]

TO_BE_DONE

[Altera_Forum]

kaz asked: why are you avoiding the direct question of why not report the true micro Tsu param in the TQ report? 

Answer: that's because in practice, the modeling tools do not really give you the theoretical micro Tsu. Primetime will tell you the relative signal race delay (constraint) between the clock and data pins. HSPICE sim depends greatly on the setup of the simulation but in the end it is the same. The HW modeling teams provide these delays directly from the modeling tools and we use them.  slack = data required time - data arrival time data arrival time = launch edge + longest path from clk to src.clk + micro Tco + longest data path to dst.d data required time = latch edge + shortest path from clk to dst.clk - micro Tsu  So, in the above example, uTsu = -0.021ns (is negative on its own).  Timing analysis should always be done by looking at the the complete reg2reg transfer. I have to ask: why does this matter? If the reg2reg delays are well correlated on mature FPGA products now, why questions about the sometimes arbitrary breakdown of the delays? Someone, somewhere will always be surprised by such a breakdown, because the expectations of the delays on the micro level differ. For example, in the TQ equations above I would prefer the micro Tsu to be added to and reported with the arrival time, not subtracted from the required time; that logically makes more sense to me, but it would not be prudent for me to change this in TQ reporting now; it would invert all the signs on the reported uTsu, but then the total slack calculation would amount to the same value.

[Altera_Forum]

Hello Chris,For better understanding I was cross checked the same design with adding clock setup uncertainty.For this exercise I given 0.2ns for uncertainty. Here recalling the equation for setup slack analysis [ setup slack = clock arrival time -Tsu - Setup Uncertainty] Clock arrival time=22.982 ns Setup time =? Dont care Uncertainty=0.2 nsIn waveform window uncertainty value showing with negative sign(-0.2 ns). It means that the value is positive so it should be subtracted from the clock arrival time as per the calculation. Of course the same reflected in report window(22.982-0.2=22.782). Especially in incr coloumm the uncertainty value displayed with negative sign. For setup time also. value showing with negative sign(-0.021ns) in waveform window. Here I dont think the negative sign indicate it is negative setup for adding with clock arrival time. If so then why uncertainty value subtracted from clock arrival time? Here my question is very straight forward !!! how one value is subtracting from clock arrival time and another value is adding with clock arrival time when both values are in same sign(negative)? As per the equation when both values(setup&uncertainty) are in same sign (negative) then definitely both values should be added with clock arrival time! Am I making sense?

[Altera_Forum]

As you wrote "setup slack = clock arrival time -Tsu - Setup Uncertainty". 

Setup uncertainty = 0.2 ns Tsu = -0.21 ns So, you get setup slack = clock arrival time -(-0.21) -0.2 = clock arrival time +0.21 -0.20 The incr colum is the slack's increment. So, it lists +0.21 and - 0.20 respectively.

[Altera_Forum]

--- Quote Start ---  As you wrote "setup slack = clock arrival time -Tsu - Setup Uncertainty". Setup uncertainty = 0.2 ns Tsu = -0.21 ns So, you get setup slack = clock arrival time -(-0.21) -0.2 = clock arrival time +0.21 -0.20 The incr colum is the slack's increment. So, it lists +0.21 and - 0.20 respectively.  --- Quote End ---    Here the confusion start again,i given 0.2ns as clock setup uncertainty. But why in waveform window it showing as (-0.2ns) .Why the negative sign came in waveform window for uncertainty setup value ?

[Altera_Forum]

Ah, I see what you mean. 

In fact, it looks like the uTsu representation in the waveform display is inconsistent with the all the other values in the waveform display and with the data path table. For the datapath table and most of the values in the wave form, the following rule seems to apply: positive values are time increments (and have a right arrow). The uTsu representation in the wave form is an exception to this rule, it shows the "real" uTsu instead of it's contribution to the timing.

[Altera_Forum]

--- Quote Start ---  I have recently been involved with xilinx vivado that is replacing ISE and specifically it is xilinx attempt to catch up with timequest. They follow the same standards of synopsis sdc. Their documentation frankly is much better, shorter and up to the point with no excesses. Timequest gives a lot of information, equations that are not relevant at field. In fact I don't want to know how they internally calculate slack but I need to know basics of managing negative slack. There are several equations for computing slack but that is for the tooland I don't need to know that but discrepancies are really painful and the more one reads timequest the more pain one gets!  --- Quote End ---    I agree with u 999%

[Altera_Forum]

I find TimeQuest is using "Incr" for showing the Waveform 

So the uTsu 0.021 is actually -0.021 --- e.g. you can set a output delay max tsu. min -th. for an output pin  it will shows -tsu, th in "Incr" table in TimeQuest

[Altera_Forum]

The waveform is good for getting your bearings, but the Data Arrival tab has all the details. External delays should show up as iExt or oExt as the delay type in that report, so you can directly see how it's used in the calculation.