On 6/11/05, Attila Kinali <[EMAIL PROTECTED]> wrote: > On Tue, 7 Jun 2005 16:29:56 -0400 > Timothy Miller <[EMAIL PROTECTED]> wrote: > > > http://opengraphics.gitk.com/sync.gif > > Looks nice, but as it always passes the token around, > we'll have an additional delay when new data arrives until > the token passes from the first clock domain to the second. > Moreover, this delay is prety much random, depending on > where the token currently is and as it passes the clock > domain border twice, we can have an additional delay of > c1+c2 in the worst case (ie when on both border crossings > of the token the timing constraints are violated and thus > a metastable state is created)
You're right that this is an issue, but the only things ever passed across are fifo heads and tails. This does cause latency, but the only one that we could improve is the first write to the fifo. All subsequent ones are going to have 'gaps' in them where the data seems to change in jumps. > > How about using an req/ack system ? > Ie the first clock domain sets his req line to signal > that there is new data to fetch, the second clock domain > fetches the data on seeing the req signal assertion, and > after it ensured that all data has been copied correctly, > it sets the ack line, signaling that it got everything. This is kinda like what I posted, except that it adjusts timing based on input data. I didn't bother, because I consider the input data change to be random also. Perhaps we could detect non-change and halt the ring until we detect change. > Another system that could be used is, to add an additional > register on the side of the second clock domain and compare > it's input and ouptut, if it differs, we are in the transition > between two data items and thus have to wait for another clock > cylce. Ofcourse this only works if the rate of arriving > data items is much lower than the clock of the second domain. In a lot of cases, the data will change almost continuously, and it can be at a very high speed. For instance, when PCI is running at 33MHz, the memory controller is still running at 200. That means that data returned for reads is coming in 6 times faster than it's going out. There's always room for improvement. Here's the real problem: Our usual fifo is only 16 entries. The latency of the sync block can be quite high. Let's say it's nine. That means we fill an empty fifo to 16 entries, then wait a lot for the tail to propagate to the receiver. The receiver then starts draining, then we have to wait another nine cycles for the head to get back to the sender. That makes a 16-entry fifo very inefficient. Two solutions include finding a better sync block and increasing the fifo size to 32 entries. Your solution of controlling the ring based on change only helps for the first write to the fifo. The opencores PCI block uses a graycode counter. As far as I can see, that's more efficient than an adder AND it won't glitch so much since only one bit changes per cycle. But I don't know enough about it. If someone here understands this, I would love to have a conversation about it, because I never worked with graycodes before. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
