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
Gated Clock Problems
Started by ●September 19, 2007
Reply by ●September 20, 20072007-09-20
>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.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. http://en.wikipedia.org/wiki/Arbiter_%28electronics%29 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.
Reply by ●September 20, 20072007-09-20
Data on D must be stable before CLK, else you'll got garbage, scientificaly called "metastability" problems. http://www.interfacebus.com/Design_MetaStable.html Vasile On Sep 19, 7:52 pm, Berk Birand <d...@email.me> wrote:> 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 fromhttp://www.teranews.com
Reply by ●September 20, 20072007-09-20
"vasile" <piclist9@gmail.com> wrote in message news:1190286570.416365.21640@19g2000hsx.googlegroups.com...> Data on D must be stable before CLK, else you'll got garbage, > scientificaly called "metastability" problems. > http://www.interfacebus.com/Design_MetaStable.html > > 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
Reply by ●September 20, 20072007-09-20
"Mike Lewis" <someone@micrsoft.com> wrote in message news:55a73$46f26a9e$401a86c3$16577@PRIMUS.CA...> > "vasile" <piclist9@gmail.com> wrote in message > news:1190286570.416365.21640@19g2000hsx.googlegroups.com... >> Data on D must be stable before CLK, else you'll got garbage, >> scientificaly called "metastability" problems. >> http://www.interfacebus.com/Design_MetaStable.html >> >> 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.
Reply by ●September 20, 20072007-09-20
In comp.arch.fpga, Symon <symon_brewer@hotmail.com> wrote:>> >> "vasile" <piclist9@gmail.com> wrote in message >> news:1190286570.416365.21640@19g2000hsx.googlegroups.com... >>> Data on D must be stable before CLK, else you'll got garbage, >>> scientificaly called "metastability" problems. >>> http://www.interfacebus.com/Design_MetaStable.html[...]> 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.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)
Reply by ●September 20, 20072007-09-20
"Stef" <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote in message news:a9f1c$46f28f36$54f63171$8563@publishnet.news-service.com...> In comp.arch.fpga, > Symon <symon_brewer@hotmail.com> wrote: >>> >>> "vasile" <piclist9@gmail.com> wrote in message >>> news:1190286570.416365.21640@19g2000hsx.googlegroups.com... >>>> Data on D must be stable before CLK, else you'll got garbage, >>>> scientificaly called "metastability" problems. >>>> http://www.interfacebus.com/Design_MetaStable.html > [...] >> 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. > > 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 >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.
Reply by ●September 20, 20072007-09-20
On Thu, 20 Sep 2007 17:18:14 +0200, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:>In comp.arch.fpga, >Symon <symon_brewer@hotmail.com> wrote: >>> >>> "vasile" <piclist9@gmail.com> wrote in message >>> news:1190286570.416365.21640@19g2000hsx.googlegroups.com... >>>> Data on D must be stable before CLK, else you'll got garbage, >>>> scientificaly called "metastability" problems. >>>> http://www.interfacebus.com/Design_MetaStable.html >[...] >> 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. > >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.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.
Reply by ●September 20, 20072007-09-20
>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.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.
Reply by ●September 20, 20072007-09-20
>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.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.
