Fwded to list.
Begin forwarded message:
From: "Timothy Normand Miller" <snip>
Date: 9 December 2007 20:49:36 GMT+01:00
To: "Michael Meeuwisse" <snip>
Subject: Re: [Open-graphics] Mad dash to finish VGA by Jan 7 --
who's with me?
On Dec 7, 2007 7:50 PM, Michael Meeuwisse <snip> wrote:
Good. But for the record, what is exactly your definition of a fifo
interface? In the 'RFC pipeline' you also mentioned it but I'm not
too sure what a fifo has and what it doesn't have. I get that it's
based on dual port block ram so it can do the whole clock domain
transition.
Click on the "FIFO" button on this page:
http://www.traversaltech.com/download.phtml
This describes an interface for moving data through a chip, with flow
control. We use it as the interface for dealing with fifos and
computation pipelines.
This is somewhat in the spirit of the Wishbone interface used by all
the opencores.org blocks. I just like this better, because it seems
simpler, is designed for high throughput with short combinatorial
delays, and doesn't incur any latency to start or stop "bursts".
So instead of pushing
addresses into a request fifo (or four), we have a small fifo that
accepts an address and count to transport the request from the video
clock domain into the memory clock domain. Then these counters
appear
as read request agents. Each memory controller spills its return
data
into the correct return fifo, and the video controller dequeues them
at the right time. (This also implies that the arbiter has four
schedulers. Oh, and we can't forget the "memory refresh" agent that
is the timer for DRAM refresh.)
Wouldn't it make sense to let the arbiter know we want a chunk of
memory starting at an address, and let that be translated to the
correct controllers? Same for the memory refresh, a don't-care
problem from the video fifo perspective. Just keep an eye on the
output-valid line from the arbiter.
When it comes to reads, it may or may not help to have that batch-size
metadata. At SOME point, we have to break things into individual word
requests because that's how the memories and memory controllers work.
If, for some reason, all requests from all agents hit the same memory
row for each access, we could schedule long runs of reads and long
runs of writes, interleaved between different agents, with no penalty.
There are small penalties for switching between reading and writing.
And there's a rather large penalty for having to change memory rows.
Batching or not, a batch could cross a row boundary, and we might want
the scheduler to do something smart when that happens, say switching
to another agent that happens to be wanting to access the exact same
row. (We don't have any data on how likely that is, in order to
determine how much logic it's worth spending on it.)
For video, due to latencies, we need to make requests well in advance.
Then the data has to be sitting there in a queue, waiting for us to
pull it out at EXACTLY the right time.
So the idea is roughly like so;
[snip your description of how video works]
You have the general idea. I'll describe our specifics.
We have a memory controller whose function you can look up. What
matters here is that, for a given scanline on the display, it makes
the memory request for the corresponding data one scanline in advance.
That request is broken down into individual word requests and handed
to the memory controllers. When the data comes back, it's put into a
queue. At the time when the video rasterscan needs the data, it'll
pulled from the queue.
Our video controller is a programmable state machine that can be
programmed to do a wide variety of different video modes. The same
download page I mentioned earlier
(http://www.traversaltech.com/download.phtml) has a link to its
documentation. Likewise, the queues I describe are linked to from
there.
Read requests are, effectively or literally, made by putting addresses
into one queue. The data comes back through another.
Note that there are no tristates inside of an FPGA. (Well, there
could hypothetically be, but we never use them.)
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
Mike
www.projectvga.org
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
