Source for SDRAM chips - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Source for SDRAM chips
Quoted text here. Click to load 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?

Re: Source for SDRAM chips

Quoted text here. Click to load it

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.

 


Re: Source for SDRAM chips

Quoted text here. Click to load it

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.
 


Re: Source for SDRAM chips
Quoted text here. Click to load it
[...]
Quoted text here. Click to load it

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

Re: Source for SDRAM chips
Quoted text here. Click to load it
DDR

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.


Re: Source for SDRAM chips

Quoted text here. Click to load it

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...!


Re: Source for SDRAM chips
Quoted text here. Click to load it

:-)

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

Re: Source for SDRAM chips

Quoted text here. Click to load it

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.



  

Re: Source for SDRAM chips
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

Agreed.  Their datasheets for SIMM modules are equally good.

Re: Source for SDRAM chips
Quoted text here. Click to load it

I've been able to source Micron's 256Mbit SDR DRAM from Arrow
electronics on one-off quantities for ~$10 ea. (MT48LC16M16A2TG-7E, the
4Mx16-bit version).  They seem to have been on allocation forever, but
in small qty it hasn't been a problem.

Re: Source for SDRAM chips

Quoted text here. Click to load it
be purchased?

In the UK: Farnell

Wim



Site Timeline