Hi, I've gotten as far as printing out the relevant portions of the PCI spec. I wanted to actually get into it by now but I've been in gate level hell for the past couple of days. I just got a test inserted netlist and I've been trying to work it into our verification environment. Tons o' fun. :( Once I get some free time (hopefully next week) I'll start really digging into it.
Anyway, just thought I'd check in and let you know what's up. I've got a pretty good model going for the flash interface and I wanted to check some of my assumptions before going any further. The IOs look like this: input clock; //The usual suspects input reset_n; //The usual suspects //System interface input [31:0] wdata; //Write data from host input [23:0] addr; //Starting address input [2:0] cmd; //Command - Non-zero starts a transaction input done; //Stops a running read or write output [31:0] rdata; //Read data output rdv; //Asserted with valid data on rdata output ready; //Asserted when ready to accept commands output wdacc; //wdata must be stable until this is asserted //PROM interface input sin; output sout; output sclk; output shold; output sce; I've made all data transfers as multiples of 32 bits. There's no size in the command. Reads and writes continue until done is asserted. I did this since it seems like PCI transactions aren't sized either. wdacc is asserted as an indication that the current wdata can be changed rdv will be asserted for one clock each time 32 bits is read Only full chip erase is supported for now. Getting the block erases are trivial but takes more command encoding. Do we care about block erase? sclk will be a 1/2 version of clock which I'm taking to be the PCI clock (66 MHz?) At this speed the steady state read bandwidth is 4.125MB/s so the FPGA program will take about 0.33s which should be fine. This also means that between each read data word from PCI there will be 64 wait states. Can we do this? 21 state, one-hot state machine. Lots of states but the next state logic for the most part is dead simple. I don't have much in the way of a verification environment yet. Apparently SST does not provide a model of this part. You have to go through Denali and use their commercial tool which even if we could get it for free probably won't play all that well with iverilog. So somebody needs to get a BFM together to see if this thing really works. Speaking of verification have you given any thought to a generalized test framework? Unit tests, regressions, C test interface, etc... There will be two clients (PCI and FPGA) but I haven't built any arbitration into the module. The basic idea is that the FPGA gets priority and the flash is unavailable to PCI while programming is in progress. Can't see how this would be a problem since it's probably bad form to be programing the flash as it's written into the FPGA. :) There's a single, 8 bit status/control register in the flash. We could make this available at an address just above the top of the flash. -Brian P.S. gtkwave *sucks*. You can't argue with free, but going from Debussy to gtkwave was a bit of a shock. Whew... want to develop a decent wave viewer while we are it. :) _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
