On 7 Nov 2007, at 01:59, Timothy Normand Miller wrote:
Well, it doesn't HAVE to be. They're just pins on chips, after all.
You can assign them whatever meanings you want. However, the way
we've been using it is DDR. This has to do with a combination of
things, including signal integrity on the clock line and the clocks
that are actually available to us. Given that we had a 100MHz clock
but wanted to do 200MHz, we just made all the buffers to DDR.
Yeah, ok. :)
I just want to recap in my own words to make sure I
understood everything. So we'll end up with a more-or-less PCI
controller on the FPGA, which has C/BE[3:0] and AD[0:31] lines.
We have a full-blown PCI controller that you can look at in the SVN
repository. That talks to verious bits of logic in the XP10,
implementing things like PCI config space, the bridge logic, HQ (not
yet, but eventually), and that sort of thing. The bridge is a local
bus between the two FPGAs, using our own custom protocol (or whatever
you want) just for accessing memory and engine address spaces.
Ok, but this is the controller for PCI on the XP10, not the FPGA. I
was suggesting our own custom bridge-protocol would be very similar
to PCI, so we could re-use bits and pieces of this module. Also
instantly gives us things like full signal waveforms for read/write
operations etc - just look at the PCI docs.
I assume this 'scratchpad' memory is in the XP10 and only a few
(hundred, tops) bytes big.
VGA text mode requires more than one text buffer. I think it's like
8, and then there's the font. That's enough that we need to put it
into graphics memory.
The HQ translates it, and then does a 'pci
write' to a framebuffer on the FPGA.
Exactly, although it's, what you might call our 'bridge protocol', but
I think you knew that.
Wait, what? What do you mean with 'graphics memory'? Is it our big
chunk of main memory, on the other side of the FPGA? I can hardly
imagine having something like;
Step 1, write to initial buffer: CPLD -> FPGA -> DDR
Step 2, read initial buffer: DDR -> FPGA -> CPLD
Step 3, crunch data with HQ.
Step 4, write to frame buffer: CPLD -> FPGA -> DDR
That would put quite some traffic on the bridge. Can I make the
suggestion that (if above is correct) we don't do that 'font
translation' with the HQ, but in realtime in the video controller?
Finally, there's a separate
(which isn't part of HQ or the VGA controller) module on the FPGA
constantly reading that framebuffer and passing it on to the DAC.
Yes. This is the video controller (also in SVN already).
I missed that, is that vid_ctl?
The video controller has a local register space that is defined. We
just haven't settled where it'll start in the engine address space.
Ok :)
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
Mike
www.wacco.mveas.com - Project VGA
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
