Source for SDRAM chips

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.

Reply to
larwe
Loading thread data ...

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.

Reply to
Mike Harrison

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

Reply to
Mike Harrison

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?

Reply to
Richard H.

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.

Reply to
Mike Harrison

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.

Reply to
Mike Harrison

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.

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.

Agreed. Their datasheets for SIMM modules are equally good.

Reply to
Richard H.

:-)

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

Reply to
Richard H.

[...]

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

Reply to
Richard H.

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.

Reply to
larwe

I did a SDRAM controller for an AD 2185 DSP and a 1Mx16 SDRAM in a xilinx 95108 along with some clock generation and DAC interface logic some while back. IIRC the cpu handled refresh, the sdram was run at 33 Mhz cas latency 1.

Reply to
Andrew Dyer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.