Question about metastability that's been on my mind for a while

I learnt at uni that two flip-flops is generally sufficient for synchronising an asynchronous signal. But what if the phase of the sampled signal isn't uniformly random? In particular, how would I deal with synchronising two different clock domains where one clock is the reference of a PLL, and the second clock is the output of that PLL, say 8 times faster. Also, the frequency of the input clock, and consequently the output clock is FM modulated - although the frequency variation is slight. The frequency of the fast clock is on the order of GHz. I figure that since the two clocks are related, the chance of metastability is drastically higher.

How should one deal with such a scenario?

Thanks in advance,

Michael.

Reply to
Michael Chan
Loading thread data ...

This is a synchronoeus design. Note that the phase of input clock and feedback of a PLL is approximately zero and the uncertainty can be well defined, as well as the setup and hold times of the clock divider (3 ffs for 8 times faster output). So you can statically analyze your design, with a static timing analyzer or manually and insert appropriate delay gates to fulfill your setup/hold time requirements so that no metastability occurs at all.

Hubble.

Reply to
Hubble

If the two clock domains are related and the two rising edges matches, you could clock one domain with a rising clock and the next with a falling clock. This way (depends on the frequency and the margin on the setup/hold times) you are always sampling when output of the first domain is stable and you can avoid synchronisation at all.

Regards Klaus

Reply to
Klaus Falser

Actually, ignore the 8 times multiplication, as that makes the problem trivial to solve. In the problem I was trying to solve, I couldn't treat the two clock domains as synchronised, since one clock sometimes led, and sometimes lagged the other clock. This resulted in data changing just as it was being sampled. I was told to add some flipflops to fix up the problems, but it didn't seem like a very good solution. As it was, I sampled data on the falling edge of the clock, but I wonder what I could have done if there wasn't sufficient timing margin for that to work (taking into account the jitter between the two domains). Actually, thinking about it now I think it would have been sufficient to simply sample the output of the negative edge triggered flip-flop with a positive edge triggered flip-flop.

Reply to
Michael Chan

"Michael Chan" schrieb im Newsbeitrag news:newscache$tz0zni$bj6$ snipped-for-privacy@lbox.itee.uq.edu.au...

I guess you are right. When I construct the case that a Fo FF is sampling the Fref and the actual phase is hitting the sampling window permanently giving metastable behaviour you get a analog circuit. You should investigate on the metastable behaviour of the FF's you are going to use.

In CMOS a FF is made of transmission gates and a high gain +1 feedback amplifier (two inverters).

formatting link

Usually they don't stay long in a metastable case, but I never checked this myself. You should also be able to google for some coarse numbers.

74' TTL Technologies were reported to eventually stay very long in the metastable state. CMOS is reported not to stay long in such a metastable state. So if you are sure that the first FF can't stay longer in metastable state than Tperiod-Tsu, you are fine.

In a CMOS FF you could avoid the hypothetical persisting metastable state by constructing the feedback (of the output stage) with a schmitt-trigger. Such a FF should never - by construction - stay in the metastable state, only the CK->Q time may be affected. But the construction of modern CMOS FF's maybe already giving a similar effect. The (analog) key is here the loop gain / phase of the two inverters in the output stage.

Raymund Hofmann

Reply to
Raymund Hofmann

Still synchronoues and sovable by static timing, as long as the jitter is not greater as the clock period.

However, there are several methods to pass information between asynchroneous domains, which will also apply here, assuming not uniformly distributed asynchroneus domains:

*dual ported rams *using metastability hardened ffs *trying to delay into a safe(r) region (if it is not uniformly distributed, there are safer regions and unsafer regions) - as I proposed earlier.

Hubble.

Reply to
Hubble

The whole point is that you can never be sure how long the first FF will stay metastable. The maximum time it can take to resolve is infinite.

This doesn't help fix the problem.

This is why the problem isn't fixed by the Schmitt idea. The CK->Q time can be anything up to infinite. So, Q can be changing just as the next stage of the circuit tries to sample it. A FF in a metastable state doesn't necessarily have to have a funny output voltage. It's in a state where it hasn't made up its mind what its output should be.

May I suggest you take a look at this?

formatting link
Cheers, Syms.

Reply to
Symon

Yes, but the probability that it will take an infinite time to resolve is zero. Or at least, the probability of a black hole from outer space smashing into the circuit is higher.

One has to pick some realistic reliability level (9 9's over 10 years?) in order to design finite cost hardware. Then one solution to any synchronizer is merely to find a flip-flop circuit that resolves in N clock periods (hopefully only 1) with much higher probability than needed for you target reliability, and use that time as your designed-in flop-to-flop synchronization delay.

As for the Schmitt trigger suggestion, yes it might (or might not) resolve faster; but it's still an analog circuit with finite gain. Therefore there's still a threshold voltage somewhere.

IMHO. YMMV.

--
rhn A.T nicholson d.O.t C-o-M
Reply to
rhnlogic

I think this is know as isochronous design (not quite asynchronous, but the same frequency with an unknown phase between clock domains). The common solution to minimize cycle jitter (random alternation in synchronizing both before and after the receive clock) is to pick a receive clock phase farthest from the point most likely to cause metastable behavior. Then, at least, you lower the probability of failing to meet setup and hold, and thus have a more predictable circuit. DLL's a commonly used for this in DDR and SerDes type applications.

IMHO. YMMV.

--
rhn A.T nicholson d.O.t C-o-M
Reply to
rhnlogic

Well, of course. But you're quoting me a little out of context. I was replying to Raymond's post in which he said:- "So if you are sure that the first FF can't stay longer in metastable state than Tperiod-Tsu, you are fine." My point is that you can never be 'sure'. You have to design the system using probabilities, as you say. Cheers, Syms.

Reply to
Symon

All,

The problem being described is a very practical one. Many lifetimes ago, in a different job, I designed telecom synchronization systems.

These systems looked at references from two separate redundant feeds (east-west, or north-south, as they are usually called in the literature), and (tried) to keep a local oscillator locked in phase to one (or the other, but usually not both) references.

The local oscillator might be pretty good (Stratum 4, just a plain old crystal), or might be really quite good (a rubidium steered quartz oscillator).

It was inevitable that somewhere, sometime, the phase detectors, frequency counters, etc. would get to just the right point, and metastable outputs would happen (which led to bad counts, or bad phase measurements). When the phase was "just right" the naturally occurring jitter would rock you back and forth across the metastable threshold ....

The result would be that the clock system would suddenly think it was terribly out of sync, and slew like crazy to go find phase lock (with what it thought was the right phase now).

This was, of course, unacceptable, as all systems sync'd to this one would dump their buffers (overflow or underflow). As well, alarms were turned in, references switched, and so on. Not pretty.

A two stage solution was initially used, and found to be not good enough. We then used a series of what we thought were clever arrangements of flip flops and clock edges, all no help (as noted above in the other thread, it is easy to make it worse, not better).

Finally, a simple software patch solved the whole problem: if you suddenly think you are WAY OFF, stop, throw the result out, and check again. If you still think you are WAY OFF, then just call the new spot your reference (if it really is WAY OFF, then all the damage is done, and why should you continue to make all sync'd equipment suffer), and turn in a "notification" of poor sync quality (so if someone at the network control center feels we are doing the wrong thing, they can override and take over control).

As long as this little patch executed about once every 6 months, no one cared.

So, the solution to this little problem: build the best synchronizer you can, and also have another means to deal with the inevitable "failure" to get a valid result.

Another solution that we never tried was to build three separate detection packages for phase and frequency, each offset by a portion of the period (like 0, 1/3, and 2/3) and then vote. If two out of three of the detectors said the phase was 0x1234h (yes, it was a 16 bit phase detector, 8 bits for the raw number of clocks, and 8 bits for the fraction of a clock), then we might go ahead and use that number. If there was no majority, the value would be ignored, and the reading taken again.

Austin

Reply to
Austin Lesea

Austin described the difficult case where the two frequencies are supposed to be identical, but are really generated by different oscillators and thus have an unknown and changing phase relationship.

I think the original question dealt with the simpler case where both frequencies come from a common source, but have developed a certain delay difference that -worst case- could be drifting around zero. Which of course invites metastabilty. The simple (simplistic?) solution is to offset the edges deliberately, e.g. by using oppsite polarities. That avoids metastability, as long as the delay uncertainty never approaches half a period. Peter

Reply to
Peter Alfke

"Symon" schrieb im Newsbeitrag news:43468fc4$0$49012$ snipped-for-privacy@news.sunsite.dk...

Yes, our whole life has to deal with probabilities. Lukily they are different and selectable. And the lifetime of our Earth may not be long enough to get a good, fast CMOS FF (.18um technology) in metastability for longer than 20ns.

Do you hint at the schmitt trigger going metastable >20nS ? OK, i think on a 7414 this may be demonstrated, but in modern CMOS ? So the Question would be:

What is the probability distribution of the metastable duration comparing the normal FF with a schmitt trigger output state feedback FF? I guess the schmitt output stage will be significantly better and even practically metastable free after 20nS in the lifetime of our Planet.

This brings another Idea to my mind:

What about injecting noise in the FF feedback loops which is small enough not to alter their (static)performance, but large enough to drive the feedback loops (and maybe schmitt triggers) into clipping and thus their stable state ? Practically this is what you get in a FPGA/ASIC due to crosstalk in and out of the chip, although it's not uncorrelated white noise. And the inherent noise of CMOS technology also helps, with the high gain of the feedback loops.

Raymund Hofmann

Reply to
Raymund Hofmann

Back in 1977, some unfortunate soul wrote to IEEE Transactions on Computers with a proposal to eliminate metastability through the use of Schmitt triggers. A while later, Thomas Chaney, one of the pioneers in the investigation of metastable operation, wrote a reply. Chaney went to the trouble of building up a Schmitt-trigger-based circuit that he deliberately made as clean as possible--good bypassing and the like--and measured performance with and without the Schmitt trigger in place. He concluded that not only did the Schmitt trigger circuit not eliminate metastability, but it made the metastable performance of the circuit significantly *worse*. Even the original proposer of the idea admitted that, yes, Chaney was right.

This is an idea that has been proposed before. Unfortunately, it's just as likely that noise will drive you into a metastable state as out of it.

If you sense some frustration on the part of the old hands in this group, it's because metastable-fix mania sweeps through here on a regular basis, and every time the same "fixes" and "improvements" are trotted out, virtually all of which were disproved ages ago.

Please, please, please, everybody, go to:

formatting link

and read the whole thing. Then look at the bibliography at the end and read some more.

The subject has been well-researched. The point is, you don't *have* to guess, at least not if the vendor gives you a little information on their metastable performance. And if there isn't enough information from the vendor, there are simple ways to trade latency for lower metastable failure rate.

Let's move on, folks. Let the healing begin.

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

It is an idea I proposed before, without any claim that it would reduce the occurence metastable states only that it would reduce their duration.

Reply to
nospam

"Bob Perlman" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

I was talking about a FF containing a schmitt trigger _in_ it's feedback loops. And I was talking about a 7414 schmitt trigger eventually not suitable for this (and how to get it inside a FF feedback loop), although maybe not detailed enough.

Metastability is not the question, it's "duration probability" is. Every FF has some CK->Q uncertainty(jitter) you could also call "Metastable", even with proper setup/hold.

So I can't second this.

I guess you sense some illusion of superiority.

I get partial dyslexia reading the whole thing. This is where I also want to expose my Ignorance and explain everything (in my way).

The ether has also been "well researched" until Albert Einstein. You are free to defame me of thinking I am a Genius. Can you also think on your own or do you only quote "well researched" subjects ? Is there a reason individual life is finite by conception ?

Who's healing do you mean ?

Raymund Hofmann

Reply to
Raymund Hofmann

Raymund -

Best of luck to you.

For others who want to learn about metastability and avoid the mistakes and misconceptions of the past, my advice holds; please read:

formatting link

Bob Perlman Cambrian Design Works

---------- "But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." - Carl Sagan

Reply to
Bob Perlman

nospam wrote: (someone wrote)

As I understand it, the area under the (probability of going metastable) vs. (time staying metastable) tends to be constant. It might be that you can change the distribution enough to make it more useful.

-- glen

Reply to
glen herrmannsfeldt

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.