0
\$\begingroup\$

There are so much hype and concern over metastability in cross clock domain. If the goal as an ASIC/FPGA designer is to ensure that the signal in source clock get propagated to destination clock even with metastability, consider the case below.

Suppose the input pulse or window signal into the synchronizer is stretched long enough to get latched by the destination clock of the synchronizer FFs twice or more, this ensures that setup & hold are met when the same signal which has been asserted get latched by the same FF 2nd time around; thus the circuit may experience metastability on leading edge of the input signal but the signal will make it out of FF of destination clk. The question is if I can ensure that this happens, do I even need synchronizer FFs (double FFs)? Wouldn't a single FF be sufficient? I guess it depends on what one needs to do with the signal after FF. If I create pulse based on trailing edge signal out of a destination clocked FF, that would work and I would not need to be concerned over whether the circuit experienced metastable condition or not.

\$\endgroup\$
1
  • \$\begingroup\$ No you need at least two sync flip-flops in the chain where the first flop is almost always metastable while the second one is not. And this depends on clock frequency, if you are working at higher frequencies like GHz, pretty sure you need MORE THAN just two flip-flops to achieve better MTBF at the destination clock domain. \$\endgroup\$ – Mitu Raj Jul 1 at 6:36
1
\$\begingroup\$

How can you guarantee that the hold time requirement of the receiving flip-flop will be met at the end of your wide pulse?

You still need at least two synchronizing flip-flops, I think.

\$\endgroup\$
1
\$\begingroup\$

The issue is that the length of time for a metastable flop to resolve could be longer than even your proposed 3x interval. Sure, a metastability event at 3x the clock period will be statistically rarer than if the clock were 1x or 2x, but it will never be zero.

Intel has a useful introductory paper on metastability, here: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/wp/wp-01082-quartus-ii-metastability.pdf

\$\endgroup\$
2
  • \$\begingroup\$ The paper is helpful info; based on this paper, it says that "In both cases, the output transition to a defined 1 or 0 state is delayed beyond the register’s specified tCO." tCO is significantly smaller than any clock period. Thus extra settling time is not a big issue here. If you extend the input long enough (3x or even 2x of clk period), it is guaranteed to get at least one solid latching of input without violation of setup & hold time. \$\endgroup\$ – Dan Man Jun 11 at 7:06
  • \$\begingroup\$ You misunderstand. The definition of metastable is that the flop doesn't resolve its state in the tCO period. It sticks somewhere in the middle for a while, until it gets a shove one way or another (from noise for example.) The statistical distribution will be that longer 'stuck' periods will be rarer than short ones. That's why slower clocks have higher MTBF figures. But make no mistake: if there's metastables happening, MTBF will never be infinity: there will always be failures. The dual-flop approach reduces the probability (increases MTBF) enough that it isn't a concern. \$\endgroup\$ – hacktastical Jun 11 at 7:46
0
\$\begingroup\$

Looking at this from a qualitative standpoint...

The thing with metastability and its effects is that it is fairly linear with respect to source and destination clock frequencies, but highly non-linear with respect to the setup and hold times and the resolve time of the destination flip flop (highly process/speed dependent).

Say you have a semiconductor process that resolves a metastability condition in 100 ps, and has a setup and hold time of 1 ns. If the source and destinations clocks are 100 Hz and asynchronous wrt one another, the likelyhood of being affected by a metastability event is, very small (though not zero).

On the other hand, if the source and destination clocks are 100 MHz, then the likelyhood of a metastable event occurring at the receiving FF is very much greater, as the equations in the Intel paper hacktastical referenced indicate.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.