This is DRAM-and-the-DSP56001 in view mode; [Up]
Date: Sun 05-May-1991 00:18:25 From: andrey@beyond.cs.caltech.edu (Andre Yew) Subject: DRAM and the DSP56001 (Summary) Sorry about the very long delay of this summary, if anyone's still interested. But a while ago, I asked about interfacing the DSP56001 to DRAM and promised I would post a summary. Well here it is. Personally, I will probably be trying the Motorola method. Thanks to everyone who sent me advice. ------------------------------ In article <andrey.670552848@beyond> you write: > I'm starting to design a project around the Motorola DSP56001 and need >more memory than the 64K of SRAM that the 56001 can see. So, has anyone out >there hooked up DRAM, by any means, to the 56001? I'm using 256kx4bit DRAMs with the 56001. These are DRAMs that know about fast pagemode cycles. 6 RAMs give a 24bit word. I pass the low 10 address bits directly to the RAMs and use a PAL to decode two 1K areas in the address space. In Space 1, a write to 'X' memory starts a RAS cycle, a write to 'Y' memory stops the RAS cycle. In Space 2, a read or write is used to strobe CAS. I'm using the /BS signal directly as CAS. Since the /WR signal is too early for the RAMs it has to be delayed about 30-40 ns. The processor does all refresh cycles that are interleaved with regular accesses in the program. As you can see it is much more efficient to read DRAM pages sequentially since each RAS consumes two extra cycles (plus the CAS cycle). The logic described above makes it possible to use a single write to L:-space to generate a refresh cycle. The RAMs are Hitachi 514256-10S which are fast enough for a 20MHz main clock. When using a 27MHz clock you can't use writes to L: space since that violates the minimum RAS precharge time of the DRAMs but they are fast enough for no-waitstate pagemode cycles. Hope this helps,
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.