Forum Discussion
Honored ContributorTimeQuest Timing Analyzer[Setup slack analysis]
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
31 Replies
Altera_ForumYou'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.
