Timothy Normand Miller wrote:
On 9/5/07, Patrick McNamara <[EMAIL PROTECTED]> wrote:
Timothy Normand Miller wrote:
My suggestion is to check for PCI requests only at those points where
we have no pending requests. We can check for a significant number of
them. We can do that between every pair of characters when
translating 80x25. Then between frames, we can poll a few thousand
times before going to the next.
Hmmm. I think I have missed something somewhere. What exactly does
the nano controller have to handle during a PCI transaction?
One situation has to do with VGA graphics mode where the memory
accesses are not simple reads and writes. There's other logic
involved that makes them do more. The other has to do with the fact
that both the nanocontroller and PCI are competing for access to
graphics memory. So we gate memory access through the nanocontroller.
Could you be more specific about how VGA graphics mode memory accesses
aren't standard reads and writes? I'm reading up on VGA, but I haven't
got there yet.
Up to now, my impression was that, e.g., 320x200x256 VGA was just a
linear array of 64000 bytes that was accessed using standard memory
reads & writes. Then, (traditionally), the VGA hardware driving the
display would read from that linear array and do some translation on the
value read (basically a table lookup to the palette). Are the
320x200x16 and 640x480x16 modes also laid out as linear arrays of bytes?
Or are they linear arrays of nibbles? Or something else totally?
What VGA graphics modes will this card support? Will the "planar"
mode(s?) be supported (whatever that means)? What about "programming
tricks" to get "704×528, 736×552, 768×576, and even 800×600"?
(http://en.wikipedia.org/wiki/VGA)
What about VGA text modes? Will anything besides 80x25 be supported?
Is the 80x25 screen laid out as a linear array of 2000 16-bit words?
When we talk about VGA compatibility, do we just mean wrt the PC-adapter
interface or do we also mean wrt the adapter-monitor interface?
It seems to me, perhaps due to my own ignorance, that talking about
"legacy VGA compatibility" is pretty vague. Could we hammer out a list
of precisely what modes we want to support, maybe with a
required/desired kind of ranking for each bullet?
Normally the nanocontroller wouldn't be involved. Usually, PCI is
connected (more) directly to the memory system. But we need to make
it switchable so that PCI accesses are queued and wait ready for the
nanocontroller to process them. We could queue up a good number of
writes, while reads would have to be queued singly.
Could you be more specific about how the PCI is normally connected to
the memory system? Is there a diagram somewhere showing that
architecture? Is there any information on the interface between the
XP10 and the XC3S4000 (e.g., how wide/fast is it, is it buffered, does
it adhere to some protocol or standard or is it just straight parallel
I/O, etc.)?
Any idea what the latency is to access that memory via PCI (i.e., # bus
clock cycles from the PCI request arriving to it being satisfied)? I'm
interested in knowing the max/typ/min latency, if possible ("way more
than 20 nanocontroller cycles" is pretty vague). But won't this be
affected by the memory controller design? Will a DDR controller be
written for this project or is there one out there that'll be used
(e.g., the one on OpenCores or whatever Xilinx provides with CoreGen or
EDK)? There will obviously be multiple memory access sources; how will
these simultaneous requests be scheduled? How many sources will be
initiating requests (anything besides PCI and the display driver)?
Am I right in assuming that developers hoping to work with OGD1 will
need a free 64-bit PCI-X slot? What PCI-X bus speeds are expected to be
supported (and am I right in understanding it could be 33MHz, 66MHz, or
133MHz)? I suppose this seems a little off-topic, but it is prescient
in my mind insofar as the bus speed and width will affect how frequently
memory requests arrive over PCI and how much data each request entails.
Plus, I'm shopping around for a new MB. ;)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
