Timothy Normand Miller wrote:
As I'm sure most of you are aware, we're testing OGD1 by putting a
semi-complete design into it with PCI, video, memory controller, etc.
We've run into a challenge with video, and we could use some
brain-storming help to solve it.
The problem has to do with async fifos. Check out the existing designs:
https://svn.suug.ch/repos/opengraphics/main/trunk/rtl/fifos/
The fifos of interest are the "async" fifos, which have head and tail
ends at different clock rates, and fifo_DxW.v, which uses one clock
domain and can be mapped to one or more of the large block RAMs on the
chip.
I can give more specific detail later, but the bottom line is that we
need a fast 512-entry async fifo. That is, the head end needs to run
at 200MHz. The problem is that we can't both compare two 9-bit
addresses and use that as a control to increment a 9-bit address in
5ns.
I'm assuming the problem is in determining whether the FIFO is non-empty
in order to allow reads. Perhaps it is possible to only allow reads
every other cycle when the FIFO is below a watermark?
So, I'm looking for more novel approaches.
For a frame of reference, the way the 16-entry async fifo works is as
follows: There are gray-code head and tail pointers. When something
is enqueued, the tail pointer is "advanced". We can determine if the
fifo has entries in it by retiming the tail pointer into the head
clock domain and comparing them. If they differ, the fifo contains
something, and we can dequeue.
So, what we need are two independent head and tail pointers, each in
its own clock domain. On the write end, we need to know if the fifo
is full or not. On the read end, we need to know if an entry in the
RAM is new data (valid) or old data (the fifo is empty). One idea
I've thought of is to encode validity info into the fifo data itself,
but it's not fully fleshed out.
Thoughts?
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
