# Gated Clock Problems

• posted

Hi everyone,

I am running into a really peculiar problem for a research project that I am working on. The circuit is fairly simple one, which needs to measure which one of two signals reaches a flip-flop first. Two impulses are sent through two different paths, and they are both fed to a D flip-flop. The circuit uses a nifty trick for outputting which signal got there first.

One of the signals (signal A) is connected to the D input, and the other one (signal B) to the Clock input. Both signals get a 0-to-1 transition. If signal A arrives first, D is '1' when there is a transition on Clk, so output of flip-flop is 1:

|------------- A (D) | ____|

|------------- B (Clk) | __________|

If signal B gets there first, then when Clock occurs, D is still '0', so output is '0'

|------------- D | _________|

|------------- Clk | ____|

(I hope my feeble attempts were sufficient to demonstrate the situation)

It was pretty easy to code this using VHDL; I just needed to connect the signals correctly.

The problem is that during the Place & Route phase, I receive a warning telling me that I have a clock signal coming from a combinatorial, gated circuit. As I have pointed out, this is actually what I want. The peculiar problem manifests itself as follows: When I synthesize it, the Device Summary correctly finds 64 slices that are being used. Yet when I run PAR, that number suddenly becomes 8 slices! I think the reduction in the slice count is due to the given warning, since the rest of the circuit behaves as expected.

Can anybody tell me how I should deal with this situation? I have tried using a CLOCK_SIGNAL attribute, but I doubt that's what I want.

I would appreciate any help, Thanks, Berk Birand

```--
Posted via a free Usenet account from http://www.teranews.com```
Loading thread data ...
• posted

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.

formatting link

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.```
• posted

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

formatting link

Vasile

• posted

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

• posted

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.

• posted

[...]

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)```
• posted

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.

• posted

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.

• posted

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.```
• posted

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.```
• posted

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

• posted

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.

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

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

Cheers, Syms.

• posted

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 :)
• posted

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)```
• posted

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.```
• posted

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.

• posted

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

• posted

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

• posted

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

• posted

Ask once, read never...

```--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt```

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.