Is the following a good way to avoid meta stability problems? The signal 'd' is synchronous to a1.8 MHz clock?
At least one of the signals a,b or c could end up in a meta stabel condition.
It then takes the median of the 3 samples.
library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity median3 is Port ( clk_24M : in std_logic; d : in std_logic; q : out std_logic := '0'); end median3;
architecture beh of median3 is type state_type is (load_a, load_b, load_c); signal state : state_type := load_a; begin process(clk_24M) variable a,b,c : std_logic := '0'; begin if rising_edge(clk_24M) then case state is when load_a => a := d; state b := d; state c := d; state state
"Metastability" is a popular word to scare inexperienced designers.
If you run a 1.8 MHz clock (even with a similar asynchronous data rate), your chance of having a 3 ns extra metastable delay is once per billion years (at 24 MHz it would be only 5 million years). For every additional ns of acceptable settling time, the mean-time-between-failure increases at least a million times. (see XAPP094 on the Xilinx website) The probability of your flip-flop failing during the life of this universe (even if you do nothing) with more than 10 ns of unaccounted-for delay is so minute it is practically zero. There are more important things to worry about, forget metastability... Peter Alfke, Xilinx Applications (who actually has created quantitative data about metastability)
This certainly depends on the logic family, which the OP didn't specify. I have seen IO equipment, constructed with older slower logic families, fail due to improper synchronization at clock rates of much less than 24 MHz. Even today, with fast submicron CMOS, you can still create reliability problems with worse case register placements or interconnect routing.
Bob, I agree with everything you wrote, but the original posting mentioned 1.8 MHz and 24 MHz. I did not make that up. It sure is not a typical modern design... I think we would agree that such a slow design will, almost inevitably, have a few ns slack to accomodate a possible metastable delay. If you use a 500 Mhz clock to synchronize a 400 MHz asynchronous data stream, the problem is much more real. I am so happy that we went to the trouble of measuring the delays on real (V2Pro) silicon, same as we had done with XC4000 years before. That gives us quantitative data. Less arm-waving.
The rule still is: If you have reason to worry about metastability, give the flip-flop in question maximum slack to settle, and have it drive only one near-by synchronizing flip-flop. Without that precaution, you might get into trouble... Peter Alfke
In saying that Peter, I had a design I was working on last year using a 986 kHz clock (or there abouts) and a 16.384MHz clock.. and metastability 'glitches' hit 1 in 10 times... we use a Spartan 2e :-) with the usual double flip flop it was cured :-)
I think the frequencies are real too.. we use 10 Xilinx FPGA's in one product.. its cheaper than ASIC's in low volumes... and we get a good price. :-) The main external clocks are 8 kHz, 968 kHz, 16.384 MHz, 25 Mhz.. I have been known to splash out and use 32.768 MHz too. you may notice the telco frequencies here... 25 is 1/2 of 50 (Ethernet) the rest are 4 x E1.
Simon, your problem was not metastability. Since many designers do not really understand the metastable mechanism, it gets blamed for all mystery problems. In many cases the problem is caused by synchronizing an asynchronous input in more than one flip-flop in parallel. This will inevitably fail, because the two flip-flops have different capture times. But that has nothing whatsoever to do with metastabilty... Peter Alfke
And from your code I assume that the synchronizing clock is
24 MHz.
The answer to yor question is that your solution is NOT a good way to "avoid" metastability.
First, you can't avoid it, you can only make its effect lower probability. The way to make it lower probability is to have additional settling time within the synchronizer.
Second, while your circuit is clever, it boils down to a two stage synchronizer, with logic (your median circuit) between the first and second stage. This logic subtracts from the resolving time available between the first stage and the second stage of your synchronizer. As is often the case with proposed circuits to help mitigate metastability in clock domain crossing circuits, what you have done is made the analysis of the behavior harder, but the result is not as good as just two flipflops.
Peter's response to you is dead wrong in this part:
in this part:
the assumption of 3 ns slack is unsupported, and if you are using Xilinx's crappy FPGA router (you don't say which product you are targetting) then there may be no slack regardless of what the cycle time is, although as clock rates drop the likelyhood of there being no slack diminishes. This is because the router stops trying to improve the route as soon as the timing specification is met. At this point there is no slack.
This issue can be helped by adding specific timing constraints to the synchronizer circuit that force additional resolving time by specifying path requirements that are more demanding than the clock cycle time implies.
in this part:
this rule of thumb depends on what product you are using. The 1E6 is for the latest devices. You may be using something else. Older technology may have numbers as low as 1E2.
In summary, you will be better served with a simple two stage synchronizer, with as tight a timing constraint as you can use to maximize the slack time between the first and second flip flops.
You can read FAR more on the subject at this URL:
formatting link
Philip Freidin
=================== Philip Freidin snipped-for-privacy@fpga-faq.org Host for
Unless Peter has hidde talents I am unaware of, let me try to answer this.
Apply minimum time constraint to the routing of the signals in question.
This may be difficult to do, as if you overconstrain, the tools give up, without necessarily finding the best they can do (why work hard on something that can't be done?).
An alternative is to look at the placed and routed design in FPGA Editor so you can find the actual delays on the nets in question. If the delays are not acceptable, you can reroute by hand.
This is obviously tiresome, and difficult, which is the reason why you should not be doing this at all: one should register the signal in question ONCE, and then route it to where it is needed or used.
It is poor design to sample any signal more than one time, and expect to get the same result if timing is not guaranteed (ie synchronous with the proper setup and hold times being always observed).
I'm not Peter, but you could put the following two lines in your UCF:
INST "ss_1" LOC = "CLB_R1C1.S0" ; INST "ss_0" LOC = "CLB_R1C1.S0" ;
If you don't like the upper left corner, change both lines to different rows and columns to move it. Or if you want the tools to automatically place both FFs, put the following two lines in your UCF:
It would be more complex if one FF was in an IOB, or was an output from BlockRAM. It could be done with attributes in the source. This can get well beyond a rookie question!
Also, should make sure the routing agrees: Add something like the following to the UCF:
INST "ss_1" TNM = "SYNC_FF"; INST "ss_0" TNM = "SYNC_FF"; TIMESPEC "TS_SYNCS" = FROM "SYNC_FF" TO "SYNC_FF" 2.5 ns;
The time value needs to be adjusted based on the family, speed grade, and other variables.
--
Phil Hays to reply solve: phil_hays at not(coldmail) dot com
If not cold then hot
Well, Philip and I are good friends since 25 years back, that's why I let him call me "dead wrong". And we have a long-standing controversy about the dangers of metastability. My error was making the tacit assumption that a 24 MHz design would always have 3 ns slack. I should have suggested to force the router to assume 33 Mhz, which would then absolutely guarantee an extra 8 ns of slack. The design in question was descibed as dead slow.... Then the question of device generation: 8 years ago, in XC4008-8 devices, I measured 4 decimal orders of magnitude increase in MTBF fo every extra ns. (But that device was very slow even then) XC4005-3 was faster, and increased MTBF by 8 orders of magnitude per ns. And Virtex2Pro increased by 9 orders of magnitude, and has a much shorter basic delay. It's all documented in XAPP094. So you really have to go to the museum to get parts with slow recovery from metastability. Like 74S74 and 74H74 dual flip-flops, the arch-villains of bad metastable behavior in the 'sixties and 'seventies. But who cares about them today?
In many cases, designers just make the fundamentally unforgivable mistake of synchronizing an asynchronous input in two parallel paths, always expecting the identical result. Fat chance.
Philip wants to make sure that we all stay alert against the evil force of metastabilty, while I want to make people aware that the problem often is elsewhere. We are not that far apart. Peter Alfke, from home.
Looks like I read the 'english', and not the code.
Looks like it is registered once, and then sent to another FF. Both FF's are clocked on the rising edge, so it is not a metastability "filter" (which would clock the second FF on the falling edge) to reduce the probability of a metastable event (they can not be prevented, but the statistics can be improved to where you just don't care).
That is a standard looking shift register.
No issue with that.
The FPGA fabric is always slower than a global clock (except in some rare cases where things are really poorly placed due to other issues with poor or confusing or conflicting constraints), so there is no problem (like there could be in an ASIC) that the data might get to some FF's before the clock would (and an event is missed altogether).
The tools should make a reasonably good placement to prevent problems.
I have seen where folks used location constraints to be sure that the clock arrived at the MSB or last stage first, and then went against the flow of data towards the LSB or first stage to ensure that the clock would always get to the FF BEFORE the data coming to the FF could possibly change in ASIC standard cell flows. Not really needed in an FPGA: the fabric and clocks are supposed to be "correct by construction" so the engineer doesn't have to worry.
This whole thing also has nothing to do with metastability.
I always enjoy reading patents that claim to eliminate metastability.
Seems that the patent office has never figured this one out: they did make it a law that perpetual motion machines are not patentable, but there is no such restriction for metastability "eliminators" (all of which don't work!).
Many of these clever circuits perform worse than the standard solutions found in any good textbook on the subject, as you point out.
that's a bit sad.. if someone actually did in vent perpetual motion.. and it could be proved.. he would go broke as he can't patent it ... guess I'll buy a lotto ticket instead :-(
Damn! I thought I had said enough, but apparently not.
Both are correct. Paul's circuit is a shift register (2 bits) and it is logically indistinguishable from a shift register.
Excuse me, this is a two stage synchronizer. Exactly.
Which is NOT a two stage synchronizer. The "clock it on the falling edge" circuit saves 1/2 a cycle in synchronizer latency, and makes a major sacrifice in resolving time. This is not a good synchronizer.
Go read
formatting link
for more on this poor circuit.
Well I agree with this.
Right. And assuming that it is clocked on the global clock net (no reason not to assume this given Paul's posting) there are no hold time issues that you seem to be worried about (probably because it is written as a shift register (which can be problematic in ASICs)).
Agreed, but the issue being discussed in synchronizers.
Oh yes it does! A two bit shift register is identical to a two stage synchronizer.
Great! Now I've pissed of Peter and Austin. Did I mention I'm not having a great week :-) :-)
Philip Freidin Crusader for understanding metastability and how to minimize it.
=================== Philip Freidin snipped-for-privacy@fpga-faq.org Host for
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.