2 hold checks - why?

[Altera_Forum]

I don't know about anyone else, but just when I seem to have a grip on TimeQuest timing analysis, I realise I've lost it again. If I have a short break from an intense timing analysis period, I seem to lose it. It just does not stick. 

 Anyway, the question is simple: why are there 2 hold checks for each setup check? I know it says, "well you have to check the current launch against the previous latch and the current latch against the next launch". OK, I can accept this, but I cannot truly see why.

[Altera_Forum]

I don't know about "two" hold time per each flip(I don't use TimeQuest) but I thought it is one hold time and is the time between flip1 data launch edge[+ data delay - clk delay] and flip2 clk latch edge. Not the opposite way.(flip1 inputs to flip2) 

 May be you are referring to micro hold time versus hold time with respect to pins or am I completely out of tune?

[Altera_Forum]

You're probably looking at the documentation, which I think it too technical and more confusing than it should be. 99% of the time these two checks are identical. And if they're not, TimeQuest only uses the most restrictive of the two. So if you're not sure what the hold requirement will be, do a report_timing between the two nodes(or clocks) in question and see what the launch and latch times are. Look at them in the timing waveform and see if it makes sense. My guess is it will make a lot more sense then following those checks.  

Also, for a less technical way to look at setup and hold requirements, the following might be useful: http://www.alteraforum.com/forum/showthread.php?t=1845&highlight=timequest

[Altera_Forum]

I'm not a big fan of Altera documentation but usually it's my starting point. I think the example in the documentation has a funny shaped clock waveform which results in two different setup relationships. I guess it's to cover that scenario. 

Thanks.

[Altera_Forum]

The documentation, and TimeQuest in general, is designed to handle all sorts of complicated issues that are rarely done in practice. I find most designs the clock requirements are quite simple. And in the complicated cases, users spend a lot of time looking at their constraints, drawing it out, and trying to figure out what's going to happen. It's so much easier to just put in a first guess, run it through TimeQuest, and see how it uses it. If it's not what you want, make a change. Multicycles are a great example of this, where it's often easier to just put in a value and check it, then understand all the possibilities of what a Multicycle can do. (Just be sure to check setup and hold...)

[Altera_Forum]

Thanks. 

 I would still like to know the "why's and wherefor's" about the 2 hold checks though. It's not so much curiosity as wanting to know that I understand the foundations of timing analysis. Yes it is very complicated (I fought my way through DDR source synchronous timing constraints and applied them successfully and I'm very bruised as a result), but when I came back to it the other day, I really struggled to pick it up again. I think it is because of these very basic concepts not being adequately explained.

[Altera_Forum]

What document are you looking at? Note that for a given path TimeQuest only analyzes the most restrictive hold requirement, since if it passes that, it passes any less restrictive checks. So every launch edge must make sure it passes its own hold requirement. The quote "well you have to check the current launch against the previous latch and the current latch against the next launch" can be re-interpreted so the latter part is just a check of subsequent launch edges to subsequent latch edges. I personally would say there are more than 2 hold checks. Think of an 8ns clock feeding a 10ns clock. The first rising edge at time 0 has a hold requirement of 0ns to the latch edge at time 0ns(assuming no MCs). This happens to be the most restrictive hold requirement. But the next launch edge at time 8ns has a -8ns hold requirement to the latch edge at time 0ns. The launch at time 16ns has a -6ns hold requirement to the latch at time 10ns. There is also a -4ns and -2ns hold requirement before the pattern starts repeating. (These are edge aligned so the first requirement happened to be the most restrictive. But, for example, on a setup requirement where a 10ns clock feeds an 8ns clock, the most restrictive setup will be 2ns, with a launch at time 30ns and latch at time 32ns). And if the clocks even stranger frequencies, it gets worse, to the point I can't easily figure it out(i.e. when a 4.567ns clock feeds a 7.890ns clock.) Of course, these should just be considered asynchronous. But the directions should show how TQ analyzes them. 

(FYI, source synch DDR is about as painful as it gets, at least to do correctly. I posted a document with examples that hopefully helps, in case you're interested.)

[Altera_Forum]

http://www.altera.com/literature/hb/qts/qts_qii5v3_02.pdf (http://www.altera.com/literature/hb/qts/qts_qii5v3_02.pdf) 

Page 13.  As you said earlier, perhaps the best thing to do is to play around in TimeQuest to see how it is analysing the edges - and perhaps draw some diagrams myself - until things click.

[Altera_Forum]

I made some reading of TimeQuest and my understanding is this: 

 First for setup time(Tsu) it defines a launch edge as the closest previous to a latch edge. This is the easy bit.   For hold time(Th) it makes sure that every launch edge drives its next latch edge.(remember the central idea is that every launch edge(source flip) must drive its next latch edge(destination flip) but this has to be designed carefully through delays by fitter and then checked by TimeQuest, failure could occur resulting in occasional edge slips when a launch edge loses track of its latch edge).   The discussion is centred on flipflop chains, each flip sourcing the next flip. It is purely of interest to Altera chip architects rather than fpga field engineers. However basic background is useful. But I don't quite see why all those strings of equations of data delay/clk delay put in this document as it is purely a headache for the architects and not the poor field engineers. Surely there is some commercial impact on the vulnerables...   edit: Altera architects depend very much on Fmax to control Tsu. But for (Th) they depend on their internal design of data/clk delays to keep Th right until the field designer comes forward and gates the clks certainly leading to clk skew if it is not put back on those global fast lines