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

[Michael Meeuwisse]

On 7 Dec 2007, at 23:04, Timothy Normand Miller wrote:
>
> I can do memory.  I'm hoping I can work with Patrick on video.  That
> reminds me that we need a "special" kind of fifo for video.  Since the
> data better be there in time (or else!), we don't have to qualify the
> dequeue into the fifo.  That saves some logic and makes it faster.

I'm not really an verilog expert but I am pretty vocal, so I want to  
take a shot at this. Don't put my name down yet though, I can't  
commit myself to working it out completely right now.

> Another thing I haven't resolved is how to manage the separate memory
> controllers.  For the demo, we had them working in lock-step, so we
> had all these 256 bit words flying around.  For most things (except
> video!) we don't want that.  One problem here is that we can quickly
> run out of block rams for these really big fifos.  One place where I
> want to eliminate some fifos is for video requests.  I want some
> address counters that LOOK like fifos.

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.

> 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.

>
>> About your picture: can the drawing engine bypass the arbiter, and  
>> if so
>> doesn't that cause problems when drawing engine and PCI or drawing
>> engine and video controller try to access memory at the same time?
>
> The memory controller can only be given one command at a time.  There
> are four memory controllers, and each can get an independent command.
> The arbiter's job is to act as a scheduler for the memory controllers,
> arbitrating between PCI, video, and engine accesses.  The engine talks
> to memory through the arbiter.  Each module wanting access to memory
> is an "agent", and they have priorities.  Note that OGA therefore
> constitutes something on the order of 9 agents (2 writers and 7
> readers), maybe more.  I forget exactly.  PCI _could_ be modeled as
> two agents (read vs. write), but it's probably better to just
> completely serialize it.

Agreed. Again I'm looking from a video fifo perspective and don't  
care about all the other agents or how many commands the memory  
controller can receive.

>> Lourens
>>
>
> -- 
> Timothy Normand Miller
> http://www.cse.ohio-state.edu/~millerti
> Open Graphics Project
> _______________________________________________
> Open-graphics mailing list
> Open-graphics at duskglow.com
> http://lists.duskglow.com/mailman/listinfo/open-graphics
> List service provided by Duskglow Consulting, LLC (www.duskglow.com)

So the idea is roughly like so;

module video_fifo {
	// connected to the memory arbiter
	inout [addrspace] address,
	output need_data, // High if I want attention, stays high until  
completely satisfied
	input give_address, // High if we have drive the address lines
	
	input [INSIZE] input_data,
	input data_valid, // At this point, address is offset from initial  
address received
	// If buffer is filled, need_data will go low, arbiter will forget  
about us.

	// Not going to specify a raster scanner interface, I believe  
there's already such a thing somewhere.
	// Will need some way to set the base address (from register-module  
perhaps?)
};

Internally, the video_fifo will have x amount of buffers, and keep  
them filled by setting them to a particular address. The raster  
scanner on the other side will be working it's way through these  
buffers, if a buffer runs out, it'll signal this. This in turn is  
used to add (or wrap to base) an offset and re-set the address of  
this buffer. This signal is simultaneously* used as an enable for the  
next buffer to start providing data on the bus to the raster scanner,  
so it'll get it's result from the next buffer as if there wasn't  
anything happening at all.
If a buffer address is changed, it'll drive need_data high until the  
buffer is full again.

So, for the video scanner, there's a big buffer with always data  
available, for the arbiter, there's a fifo with a medium-high  
priority that requests 'large' chunks of continuous data and can  
signal this when it wants attention. Will that do?

It might need some tooling since I didn't consider the whole clock  
domain transition in this scheme. I guess all buffers can be proper  
fifos from dual port block ram but it might be too expensive.

Mike
www.projectvga.org

* probably needs to be generated a cycle early to not keep the  
scanner waiting.