On 10/7/05, Attila Kinali <[EMAIL PROTECTED]> wrote: > On Thu, 6 Oct 2005 17:41:00 -0400 > Timothy Miller <[EMAIL PROTECTED]> wrote: > > > First, there's the Lattice: > > > > (1) PCI 32-bit > > There are 84 pins defined, but lots of them are reserved or ground, > > and some others don't connect to the chip. We can itemize them here > > just for general interest. I won't do that just yet, because I > > believe Andy has that worked out. I also need to check to see if > > PCI-X has any extras, because for that, I have only been considering > > clock rate, not how the card indicates it can do the speed. > > The TROZ spec lists 49 (plus the 64-bit extension), but it only did > > target, so we'll have to add like 5 more pins to get mastering. > > Do you mean here the "interface" between PCI-* and the Lattice chip?
Yes, that's right. > > > (3) Local bus to the Xilinx > > (3.1) Address bus (out): 32 pins > > (3.2) Data bus (bidirectional): 32 > > 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. 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. One thing I forgot to mention: The interface to control and program the Xilinx. > > It would enable us to keep up with the hardware development > (like going to PCI-Express) by just changing the Lattice chip. > I think we should be at least prepared for the developments > that can be seen at the horizon, but leave them out of the > design for the moment as we first need a (simple) product. Yeah. I'm going for doing double datarate if we need more bits. Also, Andy's going to provide more than just those 80 between the two chips. These are just the NAMED ones. > > Then there's the Xilinx: > > > > (1) Memory > > There are eight 256 megabit chips with 16-bit busses. There are eight > > data busses and four address busses (data busses run at 2x speed, so > > we want point-to-point). These are regular DDR chips. > > (1.1) Memory address bus > > (1.1.1) Address: 13 > > (1.1.2) Bank: 2 > > (1.1.3) Chip select: 1 > > (1.1.4) Clock enable: 1 > > [17 pins each, total 68] > > (1.2) Memory data bus > > (1.2.1) Data: 16 > > (1.2.2) Data mask: 2 > > (1.2.3) Clock: 2 > > (1.2.4) Data strobe: 2 > > [22 pins each, total 176] > > The whole memory bus then uses 244 pins. > > > If we have excess pins, how about using them to feed two > "banks" of DRAM that can be independently accessed? > I can imagine that this would give some performance, > though i can not put it into numbers. Actually, there are four memory controllers. Memory is arranged in stripes of pixel pairs interleaved with adjacent pairs over adjacent memory controllers. > > > (3) Misc > > Additional signals will > > (3.1) Peripheral bus > > Usually 8 to 32 data pins, plus maybe 10 address pins, plus some sync > > stuff. TROZ defined 24 pins for this, and I think that interface was > > modeled after the interface required for most RAMDACs. There will be > > one on either the Xilinx or the Lattice or both. But OGA will have > > only one, so we'll probably define two and then enable only one in the > > design. > > (3.2) I2C > > This is 5 pins: Data in, data out, mode, clock, enable. > > (3.3) Clock pins > > There will be some additional clock signals that are used around the board. > > (3.4) General I/O > > Whatever is left > > 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. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
