On 11/27/05, Viktor Pracht <[EMAIL PROTECTED]> wrote: > Am Samstag, den 26.11.2005, 12:25 -0500 schrieb Timothy Miller: > > > Thank you, Victor, for pointing out the race condition in the sync > > fifo. What I did was add an additional cycle delay on tail0 (calling > > it tail4). This way, the data will change before the tail pointer. > > This may be overkill, but what I decided to do was first add a delay > > in in_clock so as to ensure that the delay is sufficient (if I did it > > only in out_clock, the edge could arrive too soon), and then add > > another delay in out_clock so as to eliminate race conditions in the > > logic of the comparators. Tell me what you think: > > Is the delay in out_clock really necessary? All pointers are gray-coded, > so the race condition is supposed to occur between the single changing > bit and... what?
Generally, it's not strictly necessary, but there is more than one level of logic in the comparator, with no constraints on the propagation delay. Lacking constraints, the synthesizer may favor the routing of other logic to the extent that the delay here is greater than a clock period in out_clock, and in particular, with delays for some bits being much greater than for others. On the other hand, direct reg-to-reg is less likely to suffer from that problem. 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. But I am probably being too conservative here. I don't know. > > The FIFO has way too many states to examine them manually, so while it > was useful for proving the existence of a race condition, it's useless > for proving their absence. A testbench for the FIFO would really help > here. I have one, but it's digital and RTL-based. We'd have to synthesize it and run a gate-level simulation. Even then, routing delays will vary. Now, the person who knows about this stuff is Howard. I'll have to get him in on this. Thanks. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
