David Kinsell wrote:
> > 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.

Hmmm... I need to explore this a bit more.

On the surface, it seems like manipulating the CS lines (there are 2 per
DIMM for high vs. low data groups), plus the DQM lines (one per chip),
one might be able to read and write to individual chips, all sharing the
same 8 I/O lines.  (Although needing an aweful lot of contol lines.)

I'm not sure what effect this might have on issuing commands to the
DRAMs, but if they really act like individual x8 chips, this should
work.


> Intel has documents on their site showing the
> architecture for the various DIMM's.  It's a good
> starting place.

Thanks for the pointer!


> > Where does the complexity lie?
> 
> There's the black magic factor.  There's very little
> design margin in DRAM implementations.
[...]
> Memory design is not nearly as Plug and Play as you
> might imagine.

Got it, thanks.  This makes more sense.


> For a practical product, I'd look at individual
> chips, either DDR or pseudo-static.

I'm dabbling with individual chips now, but at least Micron is warning
on long-term availability of SDR, since the industry is moving to DDR
and beyond (which pushes this project into a whole new class of MCU).

I'm guessing that DIMMs may remain available for some time to support
the consumer market.  However, the cost of the socket is very high -
over $20 in low quantity, I recall.  And despite consumer volumes on
DIMMs, it seems an equal quantity of chips is actually cheaper for now.

An interesting project regardless...

Thanks again!
Richard

"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

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

"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

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

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

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.

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.

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

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.