On 6/11/05, Attila Kinali <[EMAIL PROTECTED]> wrote: > On Sat, 11 Jun 2005 09:53:10 -0400 > Timothy Miller <[EMAIL PROTECTED]> wrote: > > > > 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 ? > > [...] > > 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. > [...] > > 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. > > Hmm.. i'm lacking some information here. > What do you want to pass here ? And between which clock domains ? > And which FIFO are we talking about? > (alternatively you can point me to some discussion i've missed)
Ok, we want to communicate data between clock domains. In order to streamline things, we like to use fifos for buffering, etc. It turns out that everything we want to pass between clock domains is exactly the sort of thing we'd like to buffer in fifos. Communicating a single piece of data between domains is problematic because of metastability issues, so we need to do things like hold data constant in one domain before clocking it in the other, which means we cannot pass data quickly or stream it without data loss. The solution to this is to queue data in a RAM and just sync up the head and tail pointers. Since there's a delay on those numbers, the writer always thinks there's less free space and the reader always thinks there are fewer available entries than there really are, which adds latency but does not suffer from any data loss in the actual data being streamed. The sorts of things that need to cross clock domains include things like stuff going to/from the PCI controller, or between the video controller and memory, etc. Our four clock domains are the host interface, memory, GPU engine, and video. All of the stuff going back and forth between them is streaming data that goes into fifos anyhow. Oh, that reminds me... I'm not going to try to fix the metastability problem for engine register readsbacks. Those readbacks are for debugging only. Either wait until it's idle, or single-step the engine (assuming I implement that capability). Sorry for the rambling. Long day, need nap. :) _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
