CASTalk.com

Hi,

The cheapest I've seen 144-pin SODIMM sockets is on the secondary
market at about $1.50 each. In production quantity of course they are
cheaper than this. Digi-Key sells them at $5.98 qty 1, going down
rapidly with quantity. WM18501-ND is the part#. 64Mb PC66 or PC100
SODIMMs - if you can find them - start at around $10 in surplus
quantities.

I was using ARM devices with on-chip SDRAM controllers, e.g. Cirrus
7312, Sharp LH79520. Async DRAM is virtually a dead product line, no?
If I had to add SDRAM to a micro that didn't have an on-chip
controller, I would either change micros (most likely) or if ABSOLUTELY
necessary I would think about doing the controller in an FPGA.
opencores has an SDRAM controller.

larwe@larwe.com wrote:

I would think about doing the controller in an FPGA.
opencores has an SDRAM controller.

I was thinking about doing this. Do you happen to know how many gates would be needed
for a basic SDRAM controller? I have a project in mind where I'll need to put an SDRAM
controller (among a few other things) into a cheap CPLD, but at this point I'm not even
sure if that will be possible. I don't need to implement all of the functionality of
the SDRAM - just reads and writes of single locations, as well as refreshing when necessary.

larwe@larwe.com wrote:

Digi-Key sells them at $5.98 qty 1 [...]

Thanks. I'll take a closer look.

Async DRAM is virtually a dead product line, no?

The part # I spec'd earlier is sync, but older single data rate stuff
(SDR SDRAM). Still viable, but relatively dead technology. I'm not
familar with Async DRAM - another name for SDR?

DDR being the next generation, the clock needs to be too regular and the
signals too well timed to bit-bang. Yet to be proven if I can even get
SDR to work, but there are encouraging projects that show it can be
done.

If I had to add SDRAM to a micro that didn't have
an on-chip controller, I would either change micros
(most likely)

This seems like the logical course of action, since most MCUs that'd be
used with SDRAM have integrated DRAM controllers. But this is one of
those personal quests to work the impossible. :-)


Thanks!
Richard

Alex Parkinson wrote:

I have a project in mind where I'll need to put an
SDRAM controller (among a few other things) into a
cheap CPLD, but at this point I'm not even sure if
that will be possible.

Not sure that this can be done with a CPLD, at least not without driving
it from the MCU. My limited knowledge of CPLD and FPGA leads me to
think you'll need an FPGA to make it run autonomously.

I don't need to implement all of the functionality
of the SDRAM - just reads and writes of single
locations, as well as refreshing when necessary.

I don't think there's much more, except burst modes for higher
performance I/O. But refreshing is no small task - it's a huge overhead
to bit-bang without a controller.

See if the SDRAM you're looking at supports self-refresh mode. I'm not
sure if it's a standard capability, but I know Micron supports an
internal self-refresh that's 'set & forget'.

If you're looking at newer SDRAM technologies, you'll probably have to
use a DRAM controller of some sort because of the tightness and
consistency of the timing specs. What type of SDRAM are you exploring?

Richard

Hi,

Asynchronous DRAM is what we had before SDR. When you say "DRAM" with
no leading S, I assume you mean asynchronous DRAM. It's much simpler to
use than SDR. I haven't used DDR in a design, I kind of think of it as
a "PC component" because the micros I work with don't support it.

Sorry, programmable logic is not my specialty, but I second Richard in
the belief that you likely can't do it in a CPLD. It's complicated.

On Tue, 28 Dec 2004 10:54:41 -0700, "Richard H." <rh86@no.spam> wrote:

larwe@larwe.com wrote:
If I have to do it again, I think I'll design in a
SODIMM socket anyway (at least for prototypes).
Being able to upgrade the RAM ex post facto
is a Good Thing :)

Lewin,

When I last looked into this, I discovered SIMM sockets were very
expensive through the Usual Sources - ballpark USD$25. Even if the SDR
SIMM was free, the solution was much more expensive than just buying an
oversized chip. Have you found a source for SIMM & DIMM sockets that's
reasonably priced?

Also, you mention SODIMMs - are you using a DRAM controller? SDR seems
to be the end of the road without one (timing stability, clock speed,
etc.), but apparently they aren't available as discrete parts anymore -
know of any discrete DRAM controllers?

Richard

I've been looking into the details of SDRAM recently, and if you don't need to squeeze the last drop
of performance out of them by doing clever stuff like interleaving commands between banks (in which
case FPGA would be the only way to go), they aren't actually all that tricky to deal with, and a
relatively simple state-machine, easily doable in a CPLD, could do the job - I'm pretty sure you
could do it with 3.3v 22V10 or two and maybe some muxes at a pinch. ..
If possible I'd avoid DDR as things do get significantly more fiddly, partly due to the DDR stuff,
and partly due to the 2.5v supply and SSTL interface levels.

I doubt you'll find a standalone controller, as the speeds involved mean that it's not really
realistic due to the interface constraints.

I found the Micron datasheets to be about the clearest ones I found in terms of explaining the
interface.

On Tue, 28 Dec 2004 14:00:14 -0700, "Richard H." <rh86@no.spam> wrote:

larwe@larwe.com wrote:
Digi-Key sells them at $5.98 qty 1 [...]

Thanks. I'll take a closer look.


Async DRAM is virtually a dead product line, no?

The part # I spec'd earlier is sync, but older single data rate stuff
(SDR SDRAM). Still viable, but relatively dead technology. I'm not
familar with Async DRAM - another name for SDR?

DDR being the next generation, the clock needs to be too regular and the
signals too well timed to bit-bang. Yet to be proven if I can even get
SDR to work, but there are encouraging projects that show it can be
done.

The datasheets I've seen show no upper limits on the timings, so if you don't need anything like the
the full speed you can run them as slow as you like, as long as you observe the refresh requirement.
bit-bashing from a microcontroller would certainly be do-able, although I hate to think how long it
would take to read/write all of even the smallest SDRAM this way...!

larwe@larwe.com wrote:

I haven't used DDR in a design, I kind of think of
it as a "PC component" because the micros I work
with don't support it.

Interesting. My impression from Micron was that everything prior to DDR
was on the way out, SDR included.

On one hand, I'm surprised to hear than an on-board DRAM controller
wouldn't support DDR etc., if that's the future. (What does it support?)
OTOH, DDR speeds are certainly tailored to PCs...

Do you know what direction DRAM is headed for embedded apps? Does SDR
DRAM have longer prospects, or is another RAM technology more common?

On Tue, 28 Dec 2004 17:05:12 -0700, "Richard H." <rh86@no.spam> wrote:

larwe@larwe.com wrote:
I haven't used DDR in a design, I kind of think of
it as a "PC component" because the micros I work
with don't support it.

Interesting. My impression from Micron was that everything prior to DDR
was on the way out, SDR included.

On one hand, I'm surprised to hear than an on-board DRAM controller
wouldn't support DDR etc., if that's the future. (What does it support?)
OTOH, DDR speeds are certainly tailored to PCs...

Do you know what direction DRAM is headed for embedded apps? Does SDR
DRAM have longer prospects, or is another RAM technology more common?

I think SDR will hang around for quite a while, albeit probably at a price premium, as it is the
'last' generation that works entirely at standard 3.3v levels, which is still pretty widespread
outside of the PC marketplace, and it is probably the 'best fit' for most apps that don't need
state-of-the-art capacity or speed.

On Tue, 28 Dec 2004 17:05:12 -0700, "Richard H." <rh86@no.spam> wrote:

larwe@larwe.com wrote:
I haven't used DDR in a design, I kind of think of
it as a "PC component" because the micros I work
with don't support it.

Interesting. My impression from Micron was that everything prior to DDR
was on the way out, SDR included.

On one hand, I'm surprised to hear than an on-board DRAM controller
wouldn't support DDR etc., if that's the future. (What does it support?)
OTOH, DDR speeds are certainly tailored to PCs...

Do you know what direction DRAM is headed for embedded apps? Does SDR
DRAM have longer prospects, or is another RAM technology more common?

I think SDR will hang around for quite a while, albeit probably at a price premium, as it is the
'last' generation that works entirely at standard 3.3v levels, which is still pretty widespread
outside of the PC marketplace, and it is probably the 'best fit' for most apps that don't need
state-of-the-art capacity or speed.

....and remember that there are many pretty high-volume markets for DRAM like PDAs, high-end mobile
phones, digital set-top boxes, DVD recorders, digital cameras etc. where the cost of a special bus
and complicated things like DDR to squeeze more speed is simply not justified. My guess is that SDR
will fill these lower ends of the memory market for quite some time to come.

Mike Harrison wrote:

I've been looking into the details of SDRAM
recently, and [...] they aren't actually all that
tricky to deal with

Agreed, up through SDR SDRAM.

I've seen one bit-banged implementation with EDO, where the MCU did the
refreshing, but with a fair amount of overhead. I'm making an attempt
at an bit-banged SDR interface, and it all looks promising on paper. :-)

A PAL or CPLD might come in handy to cut a few MCU cycles out of command
time, but otherwise seems unnecessary at MCU speeds. Using the
self-refresh mode to offload the MCU, it's looking pretty low overhead
too.

What's yet to be seen is if my definition of a 'stable clock' is
acceptable to SDR... If not, then a CPLD may come to play to help manage
the signaling.

If possible I'd avoid DDR as things do get
significantly more fiddly

IIRC, the analog-level specs alone put it out of the range of mere MCUs
to drive. It would seem to need the add'l controls available in an FPGA
for rise times, etc.

I found the Micron datasheets to be about the
clearest ones I found in terms of explaining the
interface.

Agreed. Their datasheets for SIMM modules are equally good.

Mike Harrison wrote:

The datasheets I've seen show no upper limits on
the timings, so if you don't need anything like the
the full speed you can run them as slow as you
like, as long as you observe the refresh
requirement.
bit-bashing from a microcontroller would certainly
be do-able, although I hate to think how long it
would take to read/write all of even the smallest
SDRAM this way...!

:-)

It all depends on where that data is going. In my case, the MCU is a
DMA controller much of the time, triggering one device on the bus to
read while another is writing. You can transfer pretty fast when you
don't need to actually do anything with the data. Especially in block
mode, where you only do address setup for every 4K.

Yes, the open upper-limit of SDR timing is what's making it seem
possible. (DDR has an upper limit on timing that I recall isn't
possible with bit-banging, even with a timer output.)

SDR does have a requirement for "stable timing" on the clock line, which
I was planning to do some manipulation on. "Stable" isn't defined in
terms of cycle time or length of stability before access. That's where
my fingers are crossed. :-)

SDR also has an auto-refresh feature that runs the refresh process
internal to the SDRAM chip between accesses, instead of via CAS/RAS
signalling. You just need to be conscious about turning it on
frequently enough and letting it run long enough. (You have to
interrupt it for I/O.)

Cheers,
Richard

Mike Harrison wrote:

I think SDR will hang around for quite a while,
albeit probably at a price premium, as it is the
'last' generation that works entirely at standard
3.3v levels, which is still pretty widespread
[...]
...and remember that there are many pretty high-
volume markets for DRAM like PDAs, high-end mobile
phones, digital set-top boxes, DVD recorders,
digital cameras etc.

All good points. I'd wondered if I'd missed the turnoff somewhere, or
if the DRAM vendors were just wishful thinking. Sounds like the latter.

Thanks,
Richard

Interesting. My impression from Micron was that everything prior to
DDR
was on the way out, SDR included.

You've got to be REALLY careful who you talk to at vendors like this,
and don't believe anything you hear - especially not sweeping
generalizations like "The industry is moving towards/away from..." -
unless you get it confirmed by independent engineers. I have had
/extremely/ negative experiences in this field. (For instance, after
spending several entire days trying to talk to Samsung about their ARM
micros, I didn't find anyone in Samsung's North American empire that
even knew they made such products).

The person you speak to has a certain product focus. Since most of the
volume of high-speed RAM chips goes into PC applications, the droids on
the phone tend to be oriented towards those applications. It is true
that DDR is the path that PC chipsets have taken. But there are
practically no microcontrollers that use DDR. SDRAM is used widely in
all kinds of non-PC applications (some of those applications also use
EDO, too). DDR would add nothing but complexity to those sorts of
devices, and it's most unlikely that they will migrate. They CAN'T
migrate, in fact, until the microcontroller vendors add DDR support to
their SDRAM controller cells. And that is not happening, at least not
yet. One simply doesn't need gigabaud throughputs in an appliance that
plays DVDs, remembers phone numbers or serves up content to a LAN off a
hard disk.