I've updated the files at http://www.delorie.com/electronics/sdram/
These files include the on-chip logic analyzer I wrote to debug the internal workings of the fpga. Note that it assumes a generic old-school memory bus (address, data, nRD/nWR). It has two 512x36 channels. You can give both channels the same clock and different samples (512x72) or opposide clocks (CLK0 and CLK180) and the same samples (1024x36). The samples and control registers are mapped to the MCU's address space. I included the diagnostic software, console monitor, and conversion scripts - the samples are pulled out of the FPGA to the MCU, across USB to the PC, and converted into VCD files so you can view them with gtkwave (yes, I'm using gtkwave with physical hardware :) The SDRAM part seems to work correctly - my tests ran for six hours without a single failure, then unexplainably started failing miserably. By "miserable" I mean it was doing things that even the diagnostic's software shouldn't have allowed, like dumping 4000 trace files when I told it to stop at 12 :-( There's no effort at caching or optimizing the SDRAM interface. It's dumb. Each MCU cycle incurs a full read/write cycle, including opening the row and precharging it. Future optimization options include bursting, keeping rows open, and I left one of the BRAMs available for a cache. I am, however, running it at 133MHz (full speed!), and did desolder all the vias so there are no stubs on the sdram lines any more. Actually, I don't use either of the logic analyzer ports any more, now that I have the on-chip LA. The sources there include a microsd interface, trivial "load file from FAT16" interface, CRC7 and CRC16 functions, a trivial DLL system, and how to program a spartan-3a from an MCU. Basically, I'm declaring it a success and moving on to something else ;-) (until it's time to use it on a real project, of course) DJ _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
