On 11/29/05, Peter TB Brett <[EMAIL PROTECTED]> wrote: > Timothy Miller <theosib <at> gmail.com> writes: > > > Also, in dealing with domain crossing, I have seen other people use a > > chain of two registers in the receiving domain as a means to "deal > > with metastability", although I'm not entirely sure how that all > > works. > > Metastability is an unstable state, and getting a register to be metastable is > akin to balancing a marble on the peak of a sombrero. ;) > > So basically, if the first register manages to become metastable, the > probability that the second will become metastable is very low -- so the > probability of the pair becoming metastable is close to infinitesmal. > > I've used this technique in asynchronous buses before, and it seems to work > really well... *shrug*
That makes sense. The next question is whether my sync fifo design is liable to suffer from metastability. If a bit in tail5 becomes metastable, that could be a problem, since it's being used directly by the comparator. The thing is, I'm not sure that it matters, because the result of the comparison is going to see one bit be 0, 1, or metastable. What happens when the logic tries to compare a 0 or a 1 to a metastable bit? Is that horrible? Or does it actually come up with an answer? If it comes up with an answer, it doesn't matter what the answer is, but if we have logic replication, then two branches may come up with two different answers. In that case, it would be best to put both tail4 and tail5 into the out_clock domain. That also deals nicely with the race condition I was trying to fix in the first place. Taking that a step further, the comparison between tail and head0 could have problems too, so we should register head0 twice just to be safe. What do you think? _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
