Fwd: [Open-graphics] Mad dash to finish VGA by Jan 7 -- who's with me?

[Michael Meeuwisse]

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