Gated Clock Problems

Do you understand metastability?

The problem you are describing is its first cousin called the arbiter problem. It used to be more common before designers generally switched to synchronous systems.

The basic rule is that you don't know how long an arbiter will take to generate the answer.

If you are working with traditional synchronous logic, it's probably simplest to send both external signals through the standard pair of FFs and then make the decision with normal logic. You can keep an extra bit of state and alternate the answer if both arrive during the same cycle.

--
These are my opinions, not necessarily my employer's.  I hate spam.

Data on D must be stable before CLK, else you'll got garbage, scientificaly called "metastability" problems.

Vasile

I feel I need to argue this morning ... you won't get garbage. If you violate setup, the output will go metastable for a short period of time and then settle on either the previous value or the new value. The metastability will be so short in duartion you may as well ignore is effect unless you have a clock period above 500Mhz.

Mike

Hi Mike, That's not true. (You did say you were up for an argument!) Flipflops can go metastable for any (unlimited) amount of time, with rapidly decreasing probability as the metastable time increases. Also, it is not necessarily the case that the FF's output goes crazy during metastability. The effect can manifest itself as an arbtrarily long clock to out. As to ignoring this effect unless you're going at 500MHz or more, I hope you don't work on any safety critical systems! In FPGA-land, the timing closure tools only aim to meet the clock timing for non-metastable FFs. The place and route could easily leave a circuit vulnerable to a slight increase in clock to out delay caused by metastability. There's no need for us to go over all this yet again. Googling comp.arch.fpga will doubtless return hundreds of posts about folks' "metastability proof FFs" with thousands of replies shooting these devices down! IIRC, Peter from Xilinx has published the results of his extensive experiments on this issue. I urge anyone interested to track this down. HTH, Syms.

p.s. As for the OP's question, I'm pretty sure the warning isn't the problem. I guess the P&R is optimising away logic which can be reduced, perhaps because the logic's outputs don't get used.

[...]

If the clock to out can be arbitrary long, how would the above proposed solution with the extra synchronizer DFF solve the problem? If the setup of the synchronizer DFF is violated (which is inevitable as the D-input is an external signal), it's output may violate the input setup time of the synchronous system for the next clock edge.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Hi Stef, That's the whole point. You can't cure the problem 100%, but you can get arbitrarily close to fixing it by using more synchronising FFs, or waiting longer. Someone once suggested that circuits should be designed to only go metastable once (on average) for twice the amount of time you plan to be in the job you're doing! HTH, Syms.

You don't solve the problem you ameliorate it. The probability that a flop going metastable is p, two of them going metastable one after the other is p^2 (rougly speaking, I'm an engineer not a mathematician). If p is sufficiently small, p^2 may be small enough that you won't get it till sun goes super nova (or what ever our star will do when it reaches its end of life). If that's not acceptable to you add another flop to make the probability p^3 and stick around till our galaxy becomes a mush.

What page of the data sheet says that?

How do you know what can be ignored in my application? (You probably won't "ignore" things if your system is doing critical things like pointing missles or keeping track of money.)

--
These are my opinions, not necessarily my employer's.  I hate spam.

You have to wait long enough. Long "enough" has to be defined by your application.

Metastability decays exponentially so waiting a little longer is a big help. In many cases, waiting a clock cycle gives a probability of trouble that is very very very low. You see jokes about 1 event until the sun goes nova, but numbers like that are reasonable.

--
These are my opinions, not necessarily my employer's.  I hate spam.

Symon wrote: (snip, someone wrote)

There is always the probability that your FF could get hit by a cosmic ray with enough charge to flip it. If you get the metastability probability below that, it should be good enough.

There has to be some margin in the timing calculation in addition to the specified setup and hold times. Below some frequency, the probability will be low enough not to worry about it. I don't know what that frequency is, though. Have you ever calculated the probability that all the air molecules will move to one half of the room and suffocate you?

-- glen

Hi Glen, Good point, although, to be pedantic, it's not the charge of the particle, it's its energy that's important. Especially if one of these buggers scores a bullseye.

Protons with as much kinetic energy as a 60mph cricket ball.

You need a tame Maxwell's demon for that to happen!

Cheers, Syms.

This thread seems to have gone way off the original topic. To address the OP's original issues:

1) Metastability will limit the best theoretically possible detection threshold for measurement. i.e. when the two signals are very close in time, there will be a chance of metastability. The degree to which this matters depends on the tme between receiving the input signals and making the decision based on the detector outputs. 2) Routing delays will afftect the accuracy of the "detector". i.e. if routing delay to clock differs from routing delay to D by more than the time difference between the incoming signals you may get an incorrect result. This routing delay difference is probably much larger than the metastability window for the D flip-flop. This is also why he gets a warning about "gated clocks". 3) The removal of 3/4 of his slices is probably unrelated to the "gated clock" warning. This usually occurs when an output is unused or a necessary signal (like a clock to a section of the design) is not provided, resulting in the removal of unused or undriven sections. The map report should shed some light on this. It may be necessary to set a verbose flag to get the logic removal details.

HTH, Gabor

PS - I dropped out of a statistical mechanics course when the professor explained how multiplying a very large number by 10 resulted in essentially the same number. As I recall we were looking at numbers described as 10 to the 10 to the 23rd power (for example), and therefore the 10x bigger number was

10 to the ((10 to the 23rd power) plus 1). In any case it would take numbers of this magnitude to describe the chances of some large number of atoms drifting to one half of a room. By comparison, the age of the universe expressed in units of the time it takes light to traverse the electron orbit of a hydrogen atom can be expressed in numbers around 10 to the 40th power (IIRC). In other words, no way in hell :)

Thank you Symon, Mk and Hal for your amazingly synchrounous (pun intended :-) answers, rarity on usenet.

So far I've only seen talk of violated setup times in relation with the metastability problem. No problems with hold times?

I've done a resonable amount of logic designs (TTL/CPLD/FPGA), but never have run into this problem. Maybe because most of my designs run fairly slow and I always like to clock everithing through dff's anyway. :-)

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Yes, you have to meet hold times too.

Xilinx has decided to make all their hold times 0. That avoids calculating hold times. Well, not really. There is clock skew. So what they really guarantee is that the clock-to-out and shortest routing will provide enough hold time for the worst case clock skew.

So sometimes I/we get sloppy and forget to mention hold times.

Beware. It's not how slow your clock is running, it the ratio of your clock speed to the speed of your logic family. Metastability resolution scales (handwave, roughly) with logic speed.

--
These are my opinions, not necessarily my employer's.  I hate spam.

Exactly the same problems with hold times. Actually the truth is there are no such things as setup & hold times, there is only one data valid window where the data should not change in a window near (not necessarily around) the clock in order not to change the clk to Q delay more than a certain percentage.

Right. This could be defined as a glitch if it's short enough and a glitch is garbage if it's propagate further in the logic design. Is just a way of interpretation.

I think we have not argued at all.

Vasile

The metastability

What happened to the OP, he has just vanished after the first post?

Hi, I am not interested in metastability, not because it is very complex, but because we cannot do anything to eliminate it.

Let us help the problem poster to resolve his problem: How to differentiate two closely pulses.

The only method to resolve it is:

1. Using as high frequency as possible;
2. Feed two pulses to D input terminals for two adjacent FF, respectively;
3. When there are different outputs, it says one is faster than another;
4. Its time resolution is limited by the input clock frequency: 1/f in second. If a 400MHz frequency is used, its time resolution is 1/400M in second.

One cannot expect to get a 1/800M in second resolution with 400MHz clock.

With introduction of time resolution, we don't have to talk about metastability.

The reason is:

1. If a metastability happens in clock 1; 2 FF would still tell the differences between them, because output data are not reached to a stable data, either 0 or 1. If one were 1, it tells the truth: it is faster than another whose data is 0. If not, it tells the truth that both are equal because of time resolution.
2. With clock 2, its data input absolutely meets set up time and clock

2 outputs are stable and tell the truth: if one is 0, another is 1, it determine which is faster. If data are the same, it cannot tell the difference between them in the time resolution.

The way I suggested is a synchronous process and has no violations of any design principles.

Any comments?

Weng

Ask once, read never...

-- Uwe Bonnes snipped-for-privacy@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt

--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------