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)
Attila Kinali
--
郷に入れば郷に従え
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
