I've got an application that's RAM-hungry (64MB+), but doesn't need a lot of horsepower. Does anyone have experience using a memory controller to connect an 8- or 16-bit GPIO bus to DDR or DDR2 RAM? We've looked at hacking the timing for SDRAM - it looks workable via GPIO, but it also seems to have a short future. The option of using cheap DIMMs looks great (even though the sockets are pricey), or at least use DDR/DDR2 chips to get better longevity. The question pops up occasionally about using SIMMs or DIMMs with embedded systems. Generally, the consensus is "don't do it" - but why? I've seen comments about the variety of modes, but don't memory controllers handle this?
DDR / DDR2 memory controllers
Started by ●June 24, 2004
Reply by ●June 24, 20042004-06-24
Richard <rh86@azglobal.com> wrote:> The question pops up occasionally about using SIMMs or DIMMs with > embedded systems. Generally, the consensus is "don't do it" - but why?Because you almost certainly don't want all the pains and effort it takes to build your own full-featured SDRAM memory controller. Even less so for DDR stuff. It usually takes PC chipset manufacturers that have a *ton* of experience with this particular job on the order of a full year's worth of hardware design and BIOS coding work to get that right --- are you sure you're up to that kind of project?> I've seen comments about the variety of modes, but don't memory > controllers handle this?They do. But the way you describe your plan, you'ld be doing that memory controller on your own. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Reply by ●June 24, 20042004-06-24
Hans-Bernhard Broeker wrote:> Because you almost certainly don't want all the > pains and effort it takes to build your own full- > featured SDRAM memory controller. Even less so for > DDR stuff.Agreed. Bit-banging looks workable up to a point with SDRAM, but at some point the refresh process would take 100% of the MCU's time if an SDRAM controller isn't used (and SDRAM seems to be short-lived). DDR seems to offer better longevity, but from my reading of DDR specs the timing alone precludes bit-banging its interface.> > I've seen comments about the variety of modes, > > but don't memory controllers handle this? > > They do. But the way you describe your plan, you'ld > be doing that memory controller on your own.Actually, I'm hoping to hear that someone's successfully added an external SDRAM controller to an MCU to use DDR SDRAM - to offload the refresh process and access timing. I've seen suggestions to use an FPGA for this, but I'm trying to avoid rolling my own solution. Thanks, Richard
Reply by ●June 25, 20042004-06-25
On Thu, 24 Jun 2004 05:44:25 -0700, Richard wrote:> Actually, I'm hoping to hear that someone's successfully added an > external SDRAM controller to an MCU to use DDR SDRAM - to offload the > refresh process and access timing. > > I've seen suggestions to use an FPGA for this, but I'm trying to avoid > rolling my own solution.SDRAM is relatively easy, and can be done in a moderate size CPLD without much trouble. I've done a reasonably complete SDRAM controller for an Analog devices DSP in a Xilinx 95108 a while ago, and had room for some other interface glue logic left over. If you stick with a x8 or x16 organization and tsop packaging you should be able to get parts for a reasonable amount of time. DDR is more problematic all the way around - the signalling levels, clocking and particularly data recapture on reads are a bit ugly, and really point more to an FPGA implementation.
Reply by ●June 25, 20042004-06-25
Andrew Dyer wrote:> DDR is more problematic all the way around - the > signalling levels, clocking and particularly data > recapture on reads are a bit ugly, and really point > more to an FPGA implementation.Thanks, Andrew! Yes, I'd really rather not roll my own DDR - it seems like too much to bite off. I'd much rather find a DDR controller that someone's had good experience with. That'd seem like a good mix of longevity and fast development.
Reply by ●June 25, 20042004-06-25
On Wed, 23 Jun 2004 21:10:06 -0700, Richard <rh86@azglobal.com> wrote:>I've got an application that's RAM-hungry (64MB+), but doesn't need a >lot of horsepower. Does anyone have experience using a memory >controller to connect an 8- or 16-bit GPIO bus to DDR or DDR2 RAM? > > >We've looked at hacking the timing for SDRAM - it looks workable via >GPIO, but it also seems to have a short future. The option of using >cheap DIMMs looks great (even though the sockets are pricey), or at >least use DDR/DDR2 chips to get better longevity. > >The question pops up occasionally about using SIMMs or DIMMs with >embedded systems. Generally, the consensus is "don't do it" - but why? >I've seen comments about the variety of modes, but don't memory >controllers handle this?Not answering your question about DDR and SDRAM, but maybe the big Pseudo static ram chips from Toshiba and others might be usefull ? Last I looked they had a 32MB version available with plans for bigger. 64, 128 and 256MB if I recall correctly. Regards Anton Erasmus
Reply by ●June 25, 20042004-06-25
On Fri, 25 Jun 2004 21:31:12 +0200, Anton Erasmus <nobody@nowhere.net> wrote:>On Wed, 23 Jun 2004 21:10:06 -0700, Richard <rh86@azglobal.com> wrote: > >>I've got an application that's RAM-hungry (64MB+), but doesn't need a >>lot of horsepower. Does anyone have experience using a memory >>controller to connect an 8- or 16-bit GPIO bus to DDR or DDR2 RAM? >> >> >>We've looked at hacking the timing for SDRAM - it looks workable via >>GPIO, but it also seems to have a short future. The option of using >>cheap DIMMs looks great (even though the sockets are pricey), or at >>least use DDR/DDR2 chips to get better longevity. >> >>The question pops up occasionally about using SIMMs or DIMMs with >>embedded systems. Generally, the consensus is "don't do it" - but why? >>I've seen comments about the variety of modes, but don't memory >>controllers handle this? > >Not answering your question about DDR and SDRAM, but maybe the big >Pseudo static ram chips from Toshiba and others might be usefull ? >Last I looked they had a 32MB version available with plans for bigger. >64, 128 and 256MB if I recall correctly.Just checked again, and the sizes are in Mbit, hence maybe not big enough. Regards Anton Erasmus
Reply by ●July 1, 20042004-07-01
"Richard" <rh86@azglobal.com> wrote in message news:40DA541E.D02AAC00@azglobal.com...> I've got an application that's RAM-hungry (64MB+), but doesn't need a > lot of horsepower. Does anyone have experience using a memory > controller to connect an 8- or 16-bit GPIO bus to DDR or DDR2 RAM? > > > We've looked at hacking the timing for SDRAM - it looks workable via > GPIO, but it also seems to have a short future. The option of using > cheap DIMMs looks great (even though the sockets are pricey), or at > least use DDR/DDR2 chips to get better longevity. > > The question pops up occasionally about using SIMMs or DIMMs with > embedded systems. Generally, the consensus is "don't do it" - but why? > I've seen comments about the variety of modes, but don't memory > controllers handle this?They can be made to work. I wanted to use a SO-DIMM on a CPU card, but they're inherently 64 bits wide and didn't have the versatility to do 32 bits without wasting half the capacity. Ended up soldering two chips on the board for 64 MBy. Memory controllers generally have the ability to handle a variety of modes, but have to be programmed appropriately to do so. In a PC, the BIOS generally reads a serial prom (Serial Presence Detect) on the DIMM, which gives it RAM parameters which have to be programmed back into the controller. A fair amount of coding/testing/qualification would go into supporting a variety of memory sticks. If you can re-architect your system, using a processor with a memory controller built in (such as IBM 440 series) might be attractive. -Dave
Reply by ●July 2, 20042004-07-02
Thanks for the reply! I'm glad to hear from someone who's done this before. David Kinsell wrote:> They can be made to work. I wanted to use a > SO-DIMM on a CPU card, but they're inherently 64 > bits wide and didn't have the versatility to do 32 > bits without wasting half the capacity.Yes, I've noticed this too. My I/O is 16-bits. I was thinking about maybe a buffer or bus switch to toggle between bus "banks" to get the full capacity. What kind of DIMMs did you use, and how did you handle the DRAM access? Did you have memory I/O in your chip, or did you bit-bang it?> Memory controllers generally have the ability to > handle a variety of modes, but have to be > programmed appropriately to do so.Are you familiar with any external, MCU-friendly DRAM controllers? So much today is either integrated or PCI.> In a PC, the BIOS generally reads a serial prom > (Serial Presence Detect) on the DIMM, which gives > it RAM parameters which have to be programmed back > into the controller.So I gathered from reading Micron's DIMM specs. It looks like they're just a pre-wired set of SDRAM chips (standardized, no doubt), plus a serial EPROM with the specs - is that your experience? My specs are so loose that (at least for SDR) I'm thinking a simple read-out of the SPD and check for valid ranges - maybe not even in the unit, but in a separate "DIMM validator" before installing them.> A fair amount of coding/testing/qualification > would go into supporting a variety of memory > sticks.Where does the complexity lie? I.e., if the memory controller handles the details, is there more than reading the settings and configuring the memory controller?> If you can re-architect your system, using a > processor with a memory controller built in (such > as IBM 440 series) might be attractive.Yes, I realize this is a very unnatural act for an 8-bitter. :-) Like many feats of engineering, this is almost just to prove it can be done. Thanks! Richard
Reply by ●July 7, 20042004-07-07
"Richard" <rh86@azglobal.com> wrote in message news:40E4DD6E.E4761FDD@azglobal.com...> Thanks for the reply! I'm glad to hear from someone who's done this > before. > > David Kinsell wrote: > > They can be made to work. I wanted to use a > > SO-DIMM on a CPU card, but they're inherently 64 > > bits wide and didn't have the versatility to do 32 > > bits without wasting half the capacity. > > Yes, I've noticed this too. My I/O is 16-bits. I was thinking about > maybe a buffer or bus switch to toggle between bus "banks" to get the > full capacity.I think you'd need to pack 4 writes into a 64 bit buffer, and write it at once.> What kind of DIMMs did you use, and how did you handle the DRAM access? > Did you have memory I/O in your chip, or did you bit-bang it? >I wanted to use 128 megs SDRAM (SO-DIMM) with an IBM 405GPr processor, with the controller built in.> > Memory controllers generally have the ability to > > handle a variety of modes, but have to be > > programmed appropriately to do so. > > Are you familiar with any external, MCU-friendly DRAM controllers? So > much today is either integrated or PCI.Didn't look into that, sorry.> > In a PC, the BIOS generally reads a serial prom > > (Serial Presence Detect) on the DIMM, which gives > > it RAM parameters which have to be programmed back > > into the controller. > > So I gathered from reading Micron's DIMM specs. It looks like they're > just a pre-wired set of SDRAM chips (standardized, no doubt), plus a > serial EPROM with the specs - is that your experience?That's it. Intel has documents on their site showing the architecture for the various DIMM's. It's a good starting place.> My specs are so loose that (at least for SDR) I'm thinking a simple > read-out of the SPD and check for valid ranges - maybe not even in the > unit, but in a separate "DIMM validator" before installing them. > > > > A fair amount of coding/testing/qualification > > would go into supporting a variety of memory > > sticks. > > Where does the complexity lie? I.e., if the memory controller handles > the details, is there more than reading the settings and configuring the > memory controller?There's the black magic factor. There's very little design margin in DRAM implementations. If you're trying to run at full speed (maybe not a factor for you), you may need phase shifting of the clock just to get basic functionality. Then you have the factor that memory controllers support most, but not all of the memory organizations used. Even combinations that 'ought' to work don't work reliably. Memory design is not nearly as Plug and Play as you might imagine.> > > If you can re-architect your system, using a > > processor with a memory controller built in (such > > as IBM 440 series) might be attractive. > > Yes, I realize this is a very unnatural act for an 8-bitter. :-) Like > many feats of engineering, this is almost just to prove it can be done. >That's up to you. 64 megs+ is not a lot of memory in the context of current DIMM's. For a practical product, I'd look at individual chips, either DDR or pseudo-static. But if you're just having fun, go with whatever feels good. Regards Dave> > Thanks! > Richard