Post by thread:[EE]: Interfacing PIC to a DIMM using FPGAs

I'd appreciate any ideas on the following design concept... For a fast data logging application, I need to connect a microcontroller to a *lot* of external memory (at least 64MBytes) so it can repeatedly read and write streams of bytes in sequence from a starting location. Processing of the data by the microcontroller is fairly trivial (okay for a PIC) but the burst transfer speed needs to be high (up to 200kB per second). I think there are plenty of single-board PCs that would meet these needs, but power consumption and unit cost are both issues. My initial thoughts are as follows: 1. Use a single DIMM (i.e. dynamic RAM module) for storage rather than individual DRAM chips (fiddly), static RAM (smaller capacity), flash memory (?speed/endurance issues?) or a SIMM (?becoming obsolete?). 2. Devolve management of the addressing, refresh and control of the DIMM to an FPGA and some bi-directional buffers (e.g. 74xx245) so the PIC sees the memory predominantly as an 8-bit port to which streams of bytes can be written or read at speed. The questions in my mind at this point are: 1. Is this a sensible approach? It seems like overkill to use a 64-bit wide memory device (with associated number of connections) but I imagine this may have advantages in terms of cost-per-bit, ongoing availability and future scalability. 2. Which is the best type of DIMM to use? I'm aware of at least five forms - of which 144-pin SO-DIMMs or 168-pin DIMMs appear most popular. Physical size of the DIMM isn't a direct issue, but are some connectors more readily available (or solderable, for a prototype!) than others? 3. What FPGAs *and* development tools should I consider? I am familiar with digital design and, to me, ABEL looks like a good way of expressing the required logic. The Lattice/Vantis MACH 4 devices look capable and cost-effective, as do their associated starter tools, but I don't want to find myself "locked in" at the end of the trial period. The cost of full licenses appear disproportionate for what to me will probably only be occasional use of one of the smaller devices for "glue logic". 4. Are there any obvious design traps to avoid with this approach? I'm aware that DRAMs require good decoupling, and that it's common practice to add series resistors (33R) to the outputs driving the array (not sure exactly which ones or why - can someone elaborate?). I'm also wondering whether I really need to use eight 74xx245s to multiplex the appropriate byte onto the 8-bit bus to the PIC. The DIMM data suggests that each byte from the 64-bit word can be individually enabled onto the 3-state data I/O lines by suitable manipulation of \RAS and \CAS lines - but I'm nervous about wiring them together in groups of eight and hoping that my timing logic always behaves properly! Any constructive views on the above will be gratefully received. Many thanks in advance. -- Ian Chapman -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Ian, as far as FPGA/CPLDs, Lattice provides the ispDesignExpert software software with a free 6 month license which is easy to renew for free. This is an incredibly powerful free software suite. It provides schematic, ABEL-HDL, VHDL, and Verilog entry. Also included is a gate-level functional and timing simulator with detailed timing analysis and a waveform viewer. There are too many features to list here. The starter software supports their ispLSI (up to 600 Macrocells), ispGAL, MACH (formerly Vantis), GAL, and PAL devices. There is a large library of device models (gates, counters, etc). Using schematic entry, you can add pre-defined modules or make your own from another schematic or using one of the above HDL languages. Or, you can do the whole thing in HDL. Lattice also has a reference DRAM controller design on their web site. Programming the ISP (In-System-Programming) devices is trivial with just a 5V supply. The Lattice software to do this is free and is included in the ispDesignExpert package or as a separate ispDownload program. The buffered ISP download cable uses a 74HC/LS367 and a few passives and connects to a PC parallel port. Most folks already have the parts in their `stash'. To build the Lattice ispDownload cable, and see some simple designs that have been tested with a PIC, see my web page at: http://www.teleport.com/~thandley/Wilbure.htm For more information about Lattice Semiconductor's products and to download the ispDesignExpert or ispDownload software, see: http://www.latticesemi.com - Tom At 06:46 PM 5/17/01 +0100, Ian Chapman wrote: {Quote hidden}>I'd appreciate any ideas on the following design concept... > >For a fast data logging application, I need to connect a microcontroller >to a *lot* of external memory (at least 64MBytes) so it can repeatedly >read and write streams of bytes in sequence from a starting location. >Processing of the data by the microcontroller is fairly trivial (okay >for a PIC) but the burst transfer speed needs to be high (up to 200kB >per second). I think there are plenty of single-board PCs that would >meet these needs, but power consumption and unit cost are both issues. > >My initial thoughts are as follows: > >1. Use a single DIMM (i.e. dynamic RAM module) for storage rather than >individual DRAM chips (fiddly), static RAM (smaller capacity), flash >memory (?speed/endurance issues?) or a SIMM (?becoming obsolete?). > >2. Devolve management of the addressing, refresh and control of the >DIMM to an FPGA and some bi-directional buffers (e.g. 74xx245) so the >PIC sees the memory predominantly as an 8-bit port to which streams of >bytes can be written or read at speed. > >The questions in my mind at this point are: > >1. Is this a sensible approach? It seems like overkill to use a 64-bit >wide memory device (with associated number of connections) but I imagine >this may have advantages in terms of cost-per-bit, ongoing availability >and future scalability. > >2. Which is the best type of DIMM to use? I'm aware of at least five >forms - of which 144-pin SO-DIMMs or 168-pin DIMMs appear most popular. >Physical size of the DIMM isn't a direct issue, but are some connectors >more readily available (or solderable, for a prototype!) than others? > >3. What FPGAs *and* development tools should I consider? I am familiar >with digital design and, to me, ABEL looks like a good way of expressing >the required logic. The Lattice/Vantis MACH 4 devices look capable and >cost-effective, as do their associated starter tools, but I don't want >to find myself "locked in" at the end of the trial period. The cost of >full licenses appear disproportionate for what to me will probably only >be occasional use of one of the smaller devices for "glue logic". > >4. Are there any obvious design traps to avoid with this approach? I'm >aware that DRAMs require good decoupling, and that it's common practice >to add series resistors (33R) to the outputs driving the array (not sure >exactly which ones or why - can someone elaborate?). I'm also wondering >whether I really need to use eight 74xx245s to multiplex the appropriate >byte onto the 8-bit bus to the PIC. The DIMM data suggests that each >byte from the 64-bit word can be individually enabled onto the 3-state >data I/O lines by suitable manipulation of \RAS and \CAS lines - but I'm >nervous about wiring them together in groups of eight and hoping that my >timing logic always behaves properly! > >Any constructive views on the above will be gratefully received. > >Many thanks in advance. >-- >Ian Chapman ------------------------------------------------------------------------ Tom Handley New Age Communications Since '75 before "New Age" and no one around here is waiting for UFOs ;-) -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads