I am using one counter to trigger a second counter. The first counter is loadable but typically runs for a long time ('count' is
28 bit). This counter keeps running, and each time it terminates, produces a pulse. This pulse is used to trigger the second counter, which typically runs for much less time ('count' is 8 bit). This counter produces output 1 while it is counting, then returns to 0 until it is retriggered by the pulse from the first counter. The whole design is synchronous (running of a single clock at 100 MHz), using Webpack on Spartan IIE.
Question: how long must the pulse from the first clock be, to ensure that it triggers the second clock? As I see it, if it is one clock cycle long, then the second clock should trigger on the next clock rising edge (providing the sum of clock propagation and the 2nd clock flip-flop setup is less than one clock cycle)... but functionally the pulse will fall back at the moment it is triggered (one cycle later), so will only work if the hold time of the flip-flop is less than the clock propagation. Is this safe? Does the pulse need to be longer? Will the simulation tools realise if there is a problem here?
If you design synchronously and use a common global clock, you "have nothing to fear but fear itself" (to quote FDR). Instead of decoding TC of the big counter, you could waste a flip-flop and build a digital differentiator of the MSB. Just an idea for simplification.
When you use Global Clocks, you can forget about any hild-time issues. But it's good that you are not naïve ! Taht's worth at leaast an A- ( in US notation) Peter Alfke
The problem should be exactly the same as that in building the synchronous counter in the first place.
I still remember from many years ago, that the 74LS74 has 0 hold time, but the 7474 has a positive hold time. You can make T flip-flops by connecting Qbar to D on a 74LS74, but not (reliably) on a 7474. Most likely even one level of logic in between would be enough, though.
The LSB of a synchronous counter would normally have the shortest feedback path. That would be the first place to look.
As I understand it, FPGA's are usually designed so that in a synchronous design you don't have to worry about hold time, though possibly setup time. It might be that it is not possible to make a feedback path short enough, even if the FF itself has a positive hold time.
Now, some people might design a synchronous counter with a clock input from the TC pulse of another synchronous counter. That would not qualify as synchronous logic, and could cause timing problems.
Here are some practical points. For all but the most extremely fast applications ( say up to 200 MHz), synchronous counters are built using a global clock, and the bult-in free ripple carry structure, which of course determines a max frequency (where the ripple carry can still meet the set-up time requirements of the MSB.) Decoding TC can be quite tricky, that's why I suggested the digital differentiator which actually detects TC+1.
With all due respect, I have a different explanation of hold time. It is based on the mismatch between data and clock delay in the master latch: If the data delay is longer than the clock delay, there is a set-up time, but no hold time ( negative hold time) If the clock delay is longer than the data delay, there is a hold time requirement, but no set-up time.
The difference between data and clock delay moves the data capture window. For a given circuit, temperature and voltage, this window is extremely small ( see the metastability tests, which demonstrate a sub-femtosecond window). For reliable operation, the manufacturer specifies a worst-case window of set-up + hold time. All smart chip manufacturers try to err on the side of zero or negative hold time, and accept the corresponding larger set-up time. An unduely large set-up time sacrifices max clock rate. A positive hold time can mean unreliable operation at any speed. :-(
I don't know that it was every explained why, but there have been descriptions of the Cray-1 that included PC board traces taking extra long paths, like zig-zags, to lengthen the propagation time. It may have been to match hold time.
Maybe I misunderstood the application. I had thought it was a divide by N counter, where at some count value the counter is reloaded with the initial value, and at the same time the second counter is started.
Now that I think about it, you should get the carry out from the MSB when the counter is about to wrap. That would seem easier than detecting other values, and can be used as the load input for both.
Is there anything in the physics that encourages this?
My reading is that it simplifies the software. If the hardware guys will promise that the prop time is enough to cover the hold time plus clock skew, then the software doesn't have to check that case.
Only if the software doesn't check for that case.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Before FPGA's, when gates and FF's were wired together, hold time would limit what you could wire together. My previous example, the common 7474 dual D flip-flop with the Qbar output to the D input would, technically fail. (I don't know if I ever tried it.) 74LS74 had a 0 hold time.
Only if you can guarantee that the software check works for all voltages and temperatures at which the device might run.
Ony might hope that they scale the same, but I don't know that it is guaranteed.
No, it is just so much easier to sell something when you can tell the potential customer: "Don't worry about hold time, as long as you use a global clock. Period, no ifs and buts."
Starting with the XC3000, 16 years ago, Xilinx has always offered a delay circuit in the I/O data input, in order to minimize the danger of a hold-time issue. In XC3000 this delay was permanent, in XC4000 and later, it was optional. We knew that we left performance on the table, but we thought (and think) that satisfied customers are more important than the ultimate bragging numbers... Peter Alfke
It doesn't involve physics and in fact it is pretty straight forward, but it's hard to understand without a visual diagram to help. I couldn't find anything useful on the Web, and no textbook comes to mind. Dr. Howard Johnson recommends this book:
"I think John Wakerly covers a lot of good points about metastability in his book Digital Design Principles and Practices, Prentice-Hall, 1990 (ISBN
0-13-212838-1). He has a nice "ball and hill" description that I find very helpful."
You could do it yourself by drawing a diagram of two flip-flops. Connect a wire from FF#1's Q output to a cloud which represents a variable amount of delay. Then hook that cloud to FF#2's D input. Both flip-flops are connected to the same clock (you can assume there's zero clock skew). Now start drawing (or simulating) waveforms, varying the delay and clock frequency, to see what conditions cause a setup-time violation and hold-time violation.
Two things that you should discover is:
1) A setup-time violation can be fixed either by reducing the delay or increasing the clock period.
2) A hold-time violation can ONLY be fixed by ADDING delay.
If designers had to worry about both setup and hold time, we'd have to worry about minimizing logic delay (so we can meet our performance goals) BUT having enough logic delay (so we don't violate hold-time). Even if EDA tools warned us when we have hold-time violations, what a waste of time having to go back to fix your logic. It's better to prevent the violations by having zero-hold time. That way instead of worrying about two things during logic design, I only have to worry about one thing, minimizing logic levels/delay.
You can have zero hold-time by making sure you have a large enough clock-to-Q delay, or by adding delay in front of the FF's D input. The problem with the first solution is the IO flip-flop of your chip might take an input from an external register which has clock-to-Q you can't guarantee without taking time to check. Once again, we want to minimize the things we have to worry about, so it's better to add delay to the D input of a flip-flop.
When you have zero hold-time, what you're doing is increasing your setup-time, thereby reducing the maximum clock rate your chip can run at. So your sacrificing some performance for ease of design. As a designer I rather have ease of design and peace of mind.
Well I hope that was helpful, and more importantly I hope that it's correct. I had to give it my best guess because zero hold-time is one of those things everyone does and uses, but most dont' know why.
It was more obvious to me connecting Qbar to D of the same FF. Then there is no question about clock skew.
worry
violations
logic
But if there is clock skew, then even zero hold time isn't good enough. You can't make it too easy.
take
guarantee
we
Not so long ago I was reading about the design of pipelined computers. In most cases there should be enough logic never to have to worry about hold time, but in some cases FF's are wired with no logic in between. Then you might need to add some to be sure. There is also a design for a combination latch and two level of logic. That helps in allowing faster clocks for the amount of logic per pipeline stage.
Please excuse me if i go somewhat out of the topic this seems somewhat relating to wave pipeline concept used in asics .. just want to know can present fpgas can make use of this kind of pipeline concept ? people have tried this doing manually as google tells me. or the future fpgas plus routing softwares are going to do this stuff automatically.
I was simplifying the example for the sake of making things easier to understand. But you are correct that during real design you need to take clock skew into account. That is one reason why FPGA vendors make great efforts to provide a low skew clock network. I'm sure FPGA software also takes clock skew into account when analyzing a design.
In
Yeah I agree with you that there's usually enough logic so you wouldn't have to worry. And with FPGAs a significant amount of delay comes from the routing.
One advantage of having zero hold-time parts is that you can port a proven design to a faster speed grade without having to worry about a hold-time violation.
the
Do you happen to have a URL to that example? It sounds interesting.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.