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:
>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