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