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]

You're correct that in a traditional sense, the uTsu is subtracted from the Data Arrival Time, making the slack worse(or making it harder to meet timing). I have submitted cases like this for analysis, and it comes back that it's the way it's modeled. In essence, the data path at the register might be longer than it should be, and the uTsu becomes negative to account for that. In essence, it was determined to be correct, but I get what you're saying and it is confusing. 

Of course, with 19ns of slack it probably doesn't matter...:)

[Altera_Forum]

--- Quote Start ---  You're correct that in a traditional sense, the uTsu is subtracted from the Data Arrival Time, making the slack worse(or making it harder to meet timing). I have submitted cases like this for analysis, and it comes back that it's the way it's modeled. In essence, the data path at the register might be longer than it should be, and the uTsu becomes negative to account for that. In essence, it was determined to be correct, but I get what you're saying and it is confusing. Of course, with 19ns of slack it probably doesn't matter...:)  --- Quote End ---     This issue was raised before, see thread at: http://www.alteraforum.com/forum/showthread.php?t=1745  I can not see how Tsu can be negative at register level. Moreover if it was negative its sign should have been there.  There is nothing scientific here. It is up to altera to sort out the confusion. is the equation wrong or the tool wrong?

[Altera_Forum]

It can, depending on where you define the boundaries for your "register". 

If your "register" happens to include a considerable delay in the clock signal, then you end up with negative Tsu.

[Altera_Forum]

I think from a pure model of a register, where there is no clock or data delay to the register just the intrinsic feedback path, the uTsu is always a positive number that should be subtracted from the Data Required Path. That being said, it is not always modeled that way and clock or data delays near the register can be included. In both situations, the slack calculations will be the same, as you don't use uTsu as a value by itself, but as part of a calculation, and if some of the clock/data path is rolled into the uTsu number, it is taken out of the Data Arrival/Required Path. So in the end the slack calculation is correct, although looking at specific numbers may be misleading. 

(A similar one I've seen in Stratix V is with an M20K unregistered output. When the M20K is the source of a critical path, the access time is really small, less than 100ps, which is amazing for a RAM access. But on the flip-side the path's clock skew is -1ns, which is terrible. What's really happening is some of the RAM access time is modeled as clock delay. I'm not sure the reasoning behind this, but the slack calculation is correct in the end).

[Altera_Forum]

--- Quote Start ---  I think from a pure model of a register, where there is no clock or data delay to the register just the intrinsic feedback path, the uTsu is always a positive number that should be subtracted from the Data Required Path. That being said, it is not always modeled that way and clock or data delays near the register can be included. In both situations, the slack calculations will be the same, as you don't use uTsu as a value by itself, but as part of a calculation, and if some of the clock/data path is rolled into the uTsu number, it is taken out of the Data Arrival/Required Path. So in the end the slack calculation is correct, although looking at specific numbers may be misleading. (A similar one I've seen in Stratix V is with an M20K unregistered output. When the M20K is the source of a critical path, the access time is really small, less than 100ps, which is amazing for a RAM access. But on the flip-side the path's clock skew is -1ns, which is terrible. What's really happening is some of the RAM access time is modeled as clock delay. I'm not sure the reasoning behind this, but the slack calculation is correct in the end).  --- Quote End ---    tSU of a register(so called micro Tsu) as well as micro tH are always positive by defintion. They can only change sign if the perspective changes e.g. to pins or another source register. But the equation clearly states micro tSU. So there ought to be something wrong here.

[Altera_Forum]

Err.. "kind of".  

In most, if not all, cell libraries for ASIC designs, the flip-flops have negative hold times.

[Altera_Forum]

Setup time and hold time of a register are defined as positive values with respect to clock edge. if the window shifts when viewed somewhere in advance e.g. pins then it could shift relative to clock edge due to delay variation of data and clock between pin and register port. if (at the pin) timing window shifts past behind clock edge then tSU becomes negative and tH stays positive. If timing window shifts to front of clock edge then tSU stays positive, tH becomes negative.

[Altera_Forum]

Setup and hold times are defined at the pins, relative to the clock edge. 

But they don't actually have to be both positive. That actually depends on the internal circuit design of the flip-flop and how the delays add up at the transistor level.  You can have FFs with positive Tsu and positive Th, meaning the sensitivity window begins before the clock edge and ends after the clock edge.  You can have FFs with positive Tsu and negative Th, meaning the sensitivity window begins and ends before the clock edge.  This is actually the prevalent type of flip-flop design in integrated circuits today. I lack the knowledge to explain properly how they're designed like this, but I'm looking at the design kit for a fairly recent process node for a well known foundry right now.  The flip-flops all have negative hold times and I don't see any wasteful delays inside the flip-flop circuits.  You can also have FFs with negative Tsu and positive Th, meaning the sensitivity window begins and ends after the clock edge.  I've never seen one out in the wild, but I've see papers describing the design.

[Altera_Forum]

ok we are talking same about the same issue! the tSU of an FF is what altera calls micro tSU and xilinx calls it register tSU. It is is that window at ff ports. 

If we are not interested at ff level e.g. we are looking at io pins then we only care about the window at pin level. So it is simply a relative issue. In FPGAs micro tSU is always positive by convention and tSU viewed anywhere in front is no longer called micro but just tSU e.g. from source register perspective or pin perspective.

[Altera_Forum]

I'm not sure we're talking about the same thing.. 

 What I'm saying is that, at the lowest level you have a circuit you can call a flip-flop, you can have negative Tsu or negative Th. In Altera terms, that's having a negative uTsu or a negative uTh. And not only you can have, but having negative Th is the prevalent type of flip-flop in integrated circuits nowadays.  So, there's no sense in a convention that (u)Tsu and (u)Th are always positive. That convention falls apart in the face of actual, existing, circuits.

[Altera_Forum]

--- Quote Start ---  I'm not sure we're talking about the same thing..  What I'm saying is that, at the lowest level you have a circuit you can call a flip-flop, you can have negative Tsu or negative Th. In Altera terms, that's having a negative uTsu or a negative uTh. And not only you can have, but having negative Th is the prevalent type of flip-flop in integrated circuits nowadays.  So, there's no sense in a convention that (u)Tsu and (u)Th are always positive. That convention falls apart in the face of actual, existing, circuits.  --- Quote End ---    The central theme in register timing is that a register(at its port level) needs input not to change before its clock edge (by +tSU time) and not to change after clock edge (by +tH time). So they must be positive. They only get negative relative to clock edge if you move your definition forwards say to clock/data pins.

[Altera_Forum]

No, you really can design flip-flop circuits (registers) where that is not true! :) 

 Ie, this cell library has a FF with a Tsu of 180 ps and Th of -95 ns. And the definition point are the terminals of the FF circuit. This means the signal on the D input terminal must stay stable from 180 ps BEFORE the rising edge of the signal on the CLK input terminal and until 95 ps BEFORE the rising edge of the signal in the CLK input terminal.  If D changes 50 ps before the CLK rising edge.. it's OK!

[Altera_Forum]

--- Quote Start ---  No, you really can design flip-flop circuits (registers) where that is not true! :)  Ie, this cell library has a FF with a Tsu of 180 ps and Th of -95 ns. And the definition point are the terminals of the FF circuit. This means the signal on the D input terminal must stay stable from 180 ps BEFORE the rising edge of the signal on the CLK input terminal and until 95 ps BEFORE the rising edge of the signal in the CLK input terminal.  If D changes 50 ps before the CLK rising edge.. it's OK!  --- Quote End ---    I am talking specifically about fpga D flops. Ofcourse one can design a flop with internal delays to change timing to negative but that is totally irrelevant on this forum.

[Altera_Forum]

I see no reason why FPGA FFs are different in this regard of FFs for standand cell and full custom ICs.

[Altera_Forum]

The flop is a two state sampling device. By law of nature a sampling device needs to recognise its input state during a finite sampling window. If the input state is neither low nor high for a finite time then sampling naturally fails. That is the whole point. The second issue is how to measure this sampling window relative to what. 

FPGAs view it at lowest level at flop ports before any further delays are inserted. It is possible that some fpgas may be produced with its internal intrinsic delays and hence the reference point changes. But the central physical theme stays regarding sampling a stable input.

[Altera_Forum]

Just let me make this clear. 

These FF with negative Th do NOT have extra delay buffers for the purpose of having negative Th. These FFs are highly optimized circuits, for area/power/speed and the negative Th is a side-effect of the circuit design and the balance of the various paths inside the circuit.

[Altera_Forum]

--- Quote Start ---  Just let me make this clear. These FF with negative Th do NOT have extra delay buffers for the purpose of having negative Th. These FFs are highly optimized circuits, for area/power/speed and the negative Th is a side-effect of the circuit design and the balance of the various paths inside the circuit.  --- Quote End ---    going back to original thread. if micro tSU is negative then the report should say that.If it is positive it should say that. It clearly states a positive value on micro tSU in first post. So the question is again why the required data time equation says subtract tSU but the tool is adding it???

[Altera_Forum]

That I can only speculate. 

My impression is that, in general, FPGA tools work with a "gate level" representation of the circuit which mashes up the physical delay into abstractions. And as a result, they end up doing/having to do weird things. I have to admit I have considerably more difficulty following TQs path information than I have with IC tools.  I was only taking issue with the concept that Tsu/Th are always negative by convention.

[Altera_Forum]

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!

[Altera_Forum]

Hmm, that said... I'm not sure TQ was saying uTsu was positive in one place and negative in another place. 

The OP made it look like that but...  the only place where I see Tsu in TQ is in the "data required report". All the values there are, by convention, positive when they increase the "Data required" timing.  I.e., positive uTsu show up as negative increments and negative uTsu as positive increments.  I haven't bothered to fire up Vivado yet, as none of my current projects is going with a 7 series. Xilinx's doc has always been pretty good. Their software on the other hand, has induced several fits of homicidal rage. I do hope Vivado improves things.