* Timothy Miller <[EMAIL PROTECTED]> [2005-08-16 15:49]: > On 8/16/05, Brian Magnuson <[EMAIL PROTECTED]> wrote: > > * Timothy Miller <[EMAIL PROTECTED]> [2005-08-16 13:40]: > > > On 8/16/05, Brian Magnuson <[EMAIL PROTECTED]> wrote: > > > > * Timothy Miller <[EMAIL PROTECTED]> [2005-08-15 16:45]: > > > > > > > > > > Let's begin by having an open discussion about what's going into the > > > > > Lattice chip. > > > > > > > > > > Since I have much of the PCI logic done, let's work on some of the > > > > > other stuff. Two things on the plate right now: (a) SPI PROM reading > > > > > and writing, and (b) how to program a Xilinx chip. > > > > > > > > > > We could program the Xilinx serially or using its parallel interface. > > > > > Probably should go with the latter if we can get data out of the PROM > > > > > fast enough. The sooner the Xilinx is online during the boot process, > > > > > the better. > > > > > > > > > > Let's talk about the logic involved and how they're going to interface > > > > > with the host controller. > > > > > > > > If you're planning on using a serial PROM I don't see any reason not to > > > > use > > > > the slave serial programming mode for the Xilinx part. I pulled up a > > > > couple > > > > of serial PROM datasheets and they all have read bitrates on the order > > > > of > > > > Kbps. Might as well save the IOs and keep it serial. > > > > > > This an issue my partners and I were discussing. Not only will it > > > take a long time to program the FPGA, just imagine trying to read the > > > BIOS from it. I can see that being a problem, having the video BIOS > > > being slow as a snail. > > > > > > Do we need a faster prom? It needs to be cheap, though. > > > > How big is a Video BIOS typically? As long as it's cachable I don't see it > > as > > being a huge problem. A couple of seconds for the initial read and then > > it's > > all in system RAM. I'm not super knowledgable in this area. > > Well, basically what'll happen when the host tries to read a word from > the BIOS is that it'll time out a bunch (target abort with retry, I > think). For most PC's, there doesn't seem to be a limit, but I have > encountered SPARC workstations that put a time limit on that and would > panic the kernel.
Based on a quick glance at the spec you reference below we may be good here. > > > > > > > > > > > > > > Did you have any specific parts in mind for the FPGA, CPLD, and PROM? > > > > Are we > > > > going to need multiple PROMs to hold the bitfile? > > > > > > The Xilinx is a 3S4000. The other FPGA is a smaller Lattice. We > > > chose that because it's flash-programmable and therefore instant-on at > > > power-up. We want to put both the BIOS and the bitfile into the same > > > PROM, and it should be quite large. We'd like to be able to hold BIOS > > > for more than one platform, however much space is necessary for the > > > bitfile, and in addition, any kind of other stuff that people want to > > > hack into there (ie. some nonvolatile info on preferred graphics > > > modes, timing numbers, etc.). > > > > > > > > > > > > > > Reading the PROM and programming the FPGA should be pretty > > > > straightforward > > > > after part selection since the interface on both ends (Xilinx and PROM) > > > > is > > > > fully speced for us. For host reads/writes a config bit could map the > > > > PROM > > > > into the PCI address space. Other config bits could initiate reprogram > > > > cycles, etc... > > > > > > How long does it take to program a Xilinx serially? > > > > Ouch. THe 3S4000 bitfile is 11Mb. That's about 22 seconds to program at > > 500kpbs. We may want to seriously consider a parallel solution which could > > do > > the same job in approx 0.5s. > > Even 0.5s is a bit slow, although since the BIOS has control, we can > let it just busy-wait until the Xilinx comes online. Most users won't > notice. :) > > > Actually, at these sizes EEPROM really isn't an option. We really have to > > go > > to Flash. That will easily take care of capacity and speed problems but is > > unlikely to be cheap. > > I just checked with Howard. The SPI prom is 16 megabit. A 3S4000 > bitfile is 11 megabit. That gives us 5 megabit for other stuff, which > should be just fine. > > Apparently, lots of other vendors use a serial PROM like this for > BIOS. So I think we're okay. Let's puch forward. I need a state > machine to talk to an SPI PROM. Reading and rewriting. > > Where do we start looking for that? > > Note: The SPI part number is: SST25VF016B > > BTW, the lattice part number is: LFXP15 Thanks for this I'll check it out. As for a state machine I could probably put together something fairly complete within a week. Looks pretty good though. This should definitely allow for a subsecond program of the FPGA. > > > > > > > > > > Are there free tools avaiable for Lattice development? The only thing > > > > I saw > > > > on their website was something to download bitfiles rather than > > > > synthesis. > > > > > > I think there are. But that's not imporant. We'll get it to > > > simulate, and synthesize for a Xilinx first. Anything quirky will be > > > handed in modules that we substitute later. > > > > Fair enough. > > > > > What we need to do right now is get a good DESIGN. I tend to be a > > > good designer and a good coder, but right now, with time constraints, > > > I'm not doing well as either one. If I can get help with the design > > > (something people on the list have no shortage of interest in, > > > generally), I'm perfectly happy to be a code-slave. > > > > > > Making and documenting a good design is hard, and it's clear to me > > > that I can't just hack this together. > > > > Can do. Just trying to get a fix on what this Lattice part needs to do. > > Right now it appears that we've got three interfaces. > > > > 1) PCI Host Bus > > 2) Flash Memory > > 3) FPGA > > a) Programming interface > > b) The "real" interface > > There is also typically a "peripheral bus" on these cards. With TROZ, > we have an i2c bus, and we have an 8-bit bus that we use to > communicate with things like DACs that want to use an interface like > that. On ATC cards, we used that bus to communicate with various CPLD > chips, MOX chips, and DACs that have LUTs in them. > > Should this interface go on the Lattice or the Xilinx? It would be > simpler probably on the Lattice. Can't think of any really strong reasons to put it in either device. I suppose I'd lean towards the CPLD since from what I've seen you want every last LUT you can get for the graphics pipeline. > > How complete is 3b? Any requirements/features (port list?) > > Ok, in addition to the Xilinx programming interface that I don't know > anything about, we have these things: It's pretty simple. I have the interface for Virtex parts. I can't imagine Spartan being all that much different. Probably identicle. > > address (28 bits or 14 bits DDR) > data (32 bits or 16 bits DDR) > access_target (6) > write_enq (1) > write_full (1) > req_enq (1) > req_full (1) > read_deq (1) > read_valid (1) > > I don't know if you want to go into usage at the moment, but writes > always go through a queue interface (I need to check that into svn, > but we've discussed it on the list, and I've posted signal diagrams). > Reads from memory queue up requests (req) and then get results from a > queue (read). Reads from engine registers put an address on the but, > wait N cycles, and then expect data to appear. > > Some of the code for this is in pci_send.v. > > > > > As for PCI I have a copy of the spec though my employer. > > YAY! Maybe you can help with writing test matrixes. Since the > interface is there, what we need is another state machine or set of > tasks (like what I have in there) that people can use to imitate a > host. > > > IANAL but as far as > > I can see there aren't any legal issues with my using it for projects > > outside > > of work provided I don't distrubute the spec itself. > > Well, you're certainly not violating copyright. And I'm not aware of > any terms of usage for the spec that say you can't use it for a > project outside of the company that paid for it. I mean, if you can > find it in a library, I don't see a problem. I don't see any > restrictions mentioned in my copy. > > > I only mention it > > because this has probably come up before and you may know something I don't. > > No. I don't want to have anything to do with anyone making illegal > copies, but as far as I know, everyone on the list who has a copy has > one legally. Copyright may have its challenges, and I very much > believe in (responsible) fair use, but it also has its good points. > Without strong copyright law, the GPL would not be strong. The GPL > and copyright law are our friends. Plus, as the leader of this > project, I need to set a good example. :) > > As far as I can tell, we're doing okay. If not, and someone tells us, > we'll fix it. We're acting in good faith, which can go a long way. Sounds good. I have virtually no practical experiance with PCI so this is going to be a learning experiance for me. -Brian _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
