On 10/7/05, Attila Kinali <[EMAIL PROTECTED]> wrote: > On Fri, 7 Oct 2005 08:45:14 -0400 > Timothy Miller <[EMAIL PROTECTED]> wrote: > > > > > How about using here 64bit for both address and data ? > > > Or 64bit data and 48bit address (though i doubt that these 16bit > > > would make much difference) ? > > > > Why do we need that? Is there something special about PCI Express? > > Ok, I see your point on the address, but keep in mind that OGA's > > internal address space really only needs 28 bits, and if we have a > > PCIe controller that can do 64-bit addressing, it's going to translate > > down. > > Yes, i realized too after i send the mail. > > > The only reason for 64-bit data is speed. If we had a 64-bit > > PCI interface, it might help, but even then, we could just double the > > data rate on the local bus. > > How much up can the data clock go? I mean a single lane of > PCI-E IIRC gives 2.5Gbit/s, which is about 80MWords/s at 32bit word size. > This would mean that we would need 80MHz per PCI-E channel.
Frankly, the first support we have for PCIe isn't going to be stellar. Mind you, there's only so fast the GPU can run, so that may not be a problem. But basically, we intend to put a PCIe to PCIX bridge on a board and let it translate. That'll add some latency, but our dependency on DMA will mitigate that to a large extent. That's one of the reasons for supporting PCI-X. PCI-X typically runs at 133 MHz (At 32-bit, that's 533 MB/sec). There's also a PCI-X 266. If the bridge chip allows us to clock the PCI-X side arbitrarily, and it supports speeds faster than 133, we'll overclock it to as fast as either chip will handle. I would be surprised if TRV10 could not run its controller at 266MHz or faster, but we'll see based on what I can get out of the FPGA version. > > > > What about JTAG ? > > > > Yeah, that's part of what I was missing above with the control > > interface. Oh, and we need to not forget some headers to reprogram > > the Lattice. > > Maybe it would be a good idea to have some pins to be used > to represent some internal states for debugging. Sure, and we can use unassigned I/O headers for that. > Apropos, have you thought about a way to clock the whole card slower > so that it could be debugged with a cheap digital analyser? Well, we can clock OUR stuff however we want. The issue is underclocking the PCI bus, which would require hacking the motherboard. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
