How to use DRAM

[HardBoot]

So I've been using SRAM and ARM/MIPS computers with external memory for quite a while.

This time around I want to use DDR/DDR2/DDR3 straight up on a really cheap micro with a large number of I/O pins.

The problem is I can't make sense of the datasheets and can't find easy to read guides beyond HDL examples.

It seems to boil down to boot it with some codes to set it, then send address, then wait for data to return... although it gets far more complicated and every chip varies. Wish it was just plain dumb async FIFO-like, how I made my slow SRAM behave.

[westfw]

For modern DRAM, you usually use it by connecting it to  the DRAM controller built into your chip.
Classically, you provide some of the address bits (row), latch them internally (RAS), provide additional address bits (column, latched with CAS), and the provide or read data after the appropriate time.  This is followed by numerous possibilities for "burst" access - get the next bit by toggling some signal, reload the column without reloading the row, etc.  AFAIK, a lot of the modern DRAM alternatives mainly implement ways of speeding up these burst access mechanisms, rather than changing the core logic.  But I haven't paid much attention.  (for instance, "DDR" is double data rate - able to transfer data on both edges of one of the clock signals.) (wikipedia seems to have good explanations.)

I've seen a couple of projects where DRAM has been accessed via the IO ports of a microcontroller, notably an App Note from Signetics describing a 256k print buffer implemented using their 80c451 micro; you can still find the code online (PRN256K.ASM), but I don't see the schematic (it's described as being in their databook.) (But Signetics is long since out of the microcontroller business.)  That was all old-style DRAM.

[AndyC_772]

Using DDR memory is a whole topic in its own right, it's far from trivial I'm afraid.

As a design engineer looking to use a DDR device, there's a good chance that you don't really need to understand the details of the transactions which take place on the bus, though. Yes, there are row and column addresses, bank addresses, bursts, refresh cycles, opening and closing of pages - but all that stuff is generally implemented for you as part of the DDR controller in your chosen processor.

If you don't have a DDR controller, there's a good chance you can stop reading now, because DDR is not a static interface - there are minimum clock rates for DDR devices which you need to provide, and it's unlikely that you'll be able to achieve them without the necessary hardware inside your CPU. This could well be the show-stopper, so before you go any further, check the limits on the clock frequency for your chosen DRAM device and work back from there. 'Bit-banging' the interface with GPIO pins just isn't going to work.

If you do have a CPU with a DDR controller in it, then what you do need to worry about is timing and board layout. You need to understand and follow the manufacturers' layout guidelines for DDR, and there are a lot of them. The length matching rules are particularly stringent, and I know from personal experience that the PCB stack-up is critical too. If you're not already completely comfortable with the concepts of controlled impedance traces, differential pairs, termination and the need for solid, unbroken power and ground planes, then they're the first topics you should start reading up on.

Layout topology is different between DDR2 and DDR3, especially in terms of how the address and control buses are routed. I'd avoid using DDR(1) if at all possible, its termination requirements are more complex and will make for a busier and more difficult PCB.

When your board is complete, the other thing you'll need to do is program up the DRAM controller in your chosen processor to match the DRAM chips you're using. Some parameters are straightforward, like the bus width and number of row & column address bits, but there's a lot of timing information that also needs to be read from the DRAM data sheet, interpreted and converted into the proper values for the controller's registers. Getting it right is hard, and the consequences of any mistakes are obscure and unhelpful. Some errors will break the interface entirely (ie. nothing you write reads back correctly), while others will cause errors only under certain conditions. An intensive memory test program might work fine for a few seconds, or minutes, or hours before stopping with an error, and it's not necessarily because your board is faulty - it's because some rarely encountered timing parameter has been set wrong.

[HardBoot]

Micros in the hundreds of MHz are common so minimum clock isn't a huge issue... it's all of the cpu time wasted poking around the ram that's an issue. Wish there was a CPLD board with DDR slot you could use.

I don't get why DRAM is so popular and so much cheaper than SRAM.

The capacitive part of a DRAM cell eats up so much space you could fit the transistors needed for a flip-flop, and the circuitry needed for DRAM chips is relatively large, and dram needs tons more power.

DRAM seems antiquated by modern fab tech, despite SRAM coming long before.
DRAM solves a problem which no longer exists, 6 transistors too big, go for 1 transistor and some capacitive space, well as that capacitive space gets smaller the memory gets more unreliable.

If SRAM was 6x larger than DRAM, that's $48 per GB instead of $8... but it's not 6x larger... it's more like 2:1... $20 per GB, superior performance, superior latency, superior efficiency...

I'm almost convinced hardware companies are just sitting around until they accept capacity is no longer an issue and performance/efficiency is.

[DrGeoff]

I think Lattice Semi had a generic controller for the old DDR (SDRAM) devices. Other than that the controller functions appear to be incorporated into other LSI support devices. The ColdFire processors had support for SDRAM in some of the devices as well.

[amyk]

http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit
Interfacing async DRAM to an AVR. And using that to emulate an ARM and boot Linux

I think the main issue you'll have with DDR is the signaling; it's low-voltage, high-speed, and double-clocked.

Here is some interesting reading about the minimum frequency:
http://www.fpgarelated.com/comp.arch.fpga/thread/62547/how-low-ddr2-clock-frequency-can-be-to-make-it-work-on-fpga.php
and apparently it's common to disable the DLL and run this unsupported mode on PC motherboards, for overclocking purposes.

[mikeselectricstuff]

anything more than SDR SDRAM is very complex - SDR is pretty straighforward. I'd reccommend the Micron datasheets as very readable & comprehensive.
higher end stuff tends to have minimum clock rates due to internal PLLs etc. from memory I think the only limit with  SDR is being able to meet refresh and cas/ras hold times.

[HardBoot]

anything more than SDR SDRAM is very complex - SDR is pretty straighforward. I'd reccommend the Micron datasheets as very readable & comprehensive.
higher end stuff tends to have minimum clock rates due to internal PLLs etc. from memory I think the only limit with  SDR is being able to meet refresh and cas/ras hold times.

Hmm, you're right, much easier, I can pull that off straight on a high clocked micro.

Although the cost per MB is so much higher than consumer DDR3 I wonder if I should use a CPLD to interface with the RAM, an extra $1.80 would still be cheaper, a lot more work though.

Too bad noone has made a memory controller module for ~$10, cheap CPLD/FPGA with a DIMM slot and configuration jumpers.

[free_electron]

I don't get why DRAM is so popular and so much cheaper than SRAM.

The capacitive part of a DRAM cell eats up so much space you could fit the transistors needed for a flip-flop, and the circuitry needed for DRAM chips is relatively large, and dram needs tons more power.

DRAM seems antiquated by modern fab tech, despite SRAM coming long before.
DRAM solves a problem which no longer exists, 6 transistors too big, go for 1 transistor and some capacitive space, well as that capacitive space gets smaller the memory gets more unreliable.

If SRAM was 6x larger than DRAM, that's $48 per GB instead of $8... but it's not 6x larger... it's more like 2:1... $20 per GB, superior performance, superior latency, superior efficiency...

I'm almost convinced hardware companies are just sitting around until they accept capacity is no longer an issue and performance/efficiency is.

You really have no clue have you ? what a pile of drivel.  you got all your facts confused.

Go check out how small a dram cell is compared to an sram cell in the same technology...
also power consumption wise dram is less power hungry than sram.
as for cell size : its 4:1 the switch gate is constructed using a vertical process. they stack the switch on the cap. you cant stack mosses ... but you can stack a mos and a cap. the sense amps are only at the boundaries.

[HardBoot]

You really have no clue have you ? what a pile of drivel.  you got all your facts confused.

Go check out how small a dram cell is compared to an sram cell in the same technology...
also power consumption wise dram is less power hungry than sram.
as for cell size : its 4:1 the switch gate is constructed using a vertical process. they stack the switch on the cap. you cant stack mosses ... but you can stack a mos and a cap. the sense amps are only at the boundaries.

Yes it's 4 per flop not 6, shouldn't use numbers when I'm tired.

How can DRAM be more power efficient if it needs regular refreshing... I can see it be more efficient in heavy use situations, but for caching, awful.

T-RAM and TTRAM matches DRAM in size, although T-RAM needs an efficient current source and TT is SOI. I hope one catches on so the abysmal latency of DRAM can go away.

EDIT: Wait a tick, I remembered correctly, CMOS SRAM is 6T, 4T is the ancient stuff that has internal resistors. Mmmmm CMOS SRAM, 0.2 nanoseconds anyone?

[marshallh]

These days what you want is a MCU/MPU with integrated ram controller. Almost all do. And if they don't, well, you're not going to be able to manually poke the ram along anyway. You need dedicated silicon, whether it's ondie or on FPGA.

Said memory controller on chip will probably be a general-case one size fits all design. On CPUs you will be running through some code in the IPL to poke the DRAM control regs and set up timing parameters, tell it what your organization is, etc.
Vendors usually provide detailed examples and samples for reference designs. Micron is basically the industry benchmark. They have the best datasheets, behavioral models, and nearly every RAM controller will have Micron parts as a template.
Other mfgs also make ram, conforming to JEDEC standards, there may be very slightly different timings or PVT allowances. Hynix, Samsung, Elpida are high volume fabs and the datasheets are basically pinouts and timing - they assume you know what you're doing. ISSI makes high volume commodity low-spec RAM.
The idea is that you can throw in whatever brand RAM you can get for the batch, and have it work.


SDRAM is easy to wire up. All single ended 3v3 signaling. Writing a HDL controller is possible with some effort.
DDR1 adds voltage referenced DDR signaling via SSTL_2, (2v5) differential clocks, and source synchronous data group strobes. Last family available in non-bga TSOP package. External termination is required for >1 discrete chip.
DDR2 runs at SSTL_18 (1v8), adds optional differential data strobes and is more complex to set up. On-die termination.

All of the above three variants can be grouped up on DIMMs (or just laid out on the main pcb) with the command and address signals routed in a split-T topology. This allows all those signals to have equal propagation delay to each module and minimize clock-data skew.

Here are two DDR1 chips in BGA package (1mm x 0.8mm grid) routed like that. The series terminations are on the data lines.


DDR3 uses 1.5v signaling and takes it further. DIMMs that are DDR3 are essentially always routed with the control and address lines wired up serially. Called fly-by topology, there is no skew between the clock and control signals. However each part has a different DQ/clock skew, so extra signals are used to latch in the data. Proper flyby support is still not very common, and only higher-end parts will support it (high end FPGAs, CPUs with integrated memory controllers, etc).
You can still route DDR3 if you are using discrete modules in the split-T topology. Most embedded stuff using DDR3 does this.


If you're curious you can go to the JEDEC site and download the Cadence board files for reference DDR DIMMs. Look at your memory sticks from your PC sometime. Almost all of them are carbon copies.

Basicaly, buy a chip that supports your RAM with dedicated hardware, read every single appnote/guide the manufacturer has on the implementation of RAM with their product, and read more stuff about routing it. You will need 4layer PCBs for DDR1 and up, and more layers for more chips you throw on the PCB. DDR2/DDR3 have a ball pitch of 0.8mm x 0.8mm so you will need 5/6mil traces and vias that can fit between the ball lands (I've found 12mil is barely enough)

[free_electron]

You really have no clue have you ? what a pile of drivel.  you got all your facts confused.

Go check out how small a dram cell is compared to an sram cell in the same technology...
also power consumption wise dram is less power hungry than sram.
as for cell size : its 4:1 the switch gate is constructed using a vertical process. they stack the switch on the cap. you cant stack mosses ... but you can stack a mos and a cap. the sense amps are only at the boundaries.

Yes it's 4 per flop not 6, shouldn't use numbers when I'm tired.

How can DRAM be more power efficient if it needs regular refreshing... I can see it be more efficient in heavy use situations, but for caching, awful.

T-RAM and TTRAM matches DRAM in size, although T-RAM needs an efficient current source and TT is SOI. I hope one catches on so the abysmal latency of DRAM can go away.

EDIT: Wait a tick, I remembered correctly, CMOS SRAM is 6T, 4T is the ancient stuff that has internal resistors. Mmmmm CMOS SRAM, 0.2 nanoseconds anyone?

TTram and Z-ram cells are larger than dram and you need SOI to get the floating body capacitance effect. in essence it is a DRAM technology for SOI without needing double poly layers to form the capacitor. it can also be made on fully depleted silicon.

static ram these days is a 4T cell. basically two inverters biting each others tail. the doping of the channels is different with the top two being relativiley high-ohmic ( kiloohm range ) when 'on'. The toggle drive is no longer in the cell. an external current pump sends the toggle current ot the cells selected by the decoder. when not in use the cells are off the grid so consumption is very low ( that's why you can keep an sram 'alive' for years off a coin cell ). the moment you write them consumption goes up as you have the resistances to deal with. reading costs nothing. writign does cost. for the entire duration of the write strobe.

DRAM needs refresh but the charge displaced is very tiny so overall these are , for an equal read/write duty cycle , more efficient than an SRAM. only in pure idle is an sram more effective.

Anyway, even a 4T cell is still 3 to4 times the surface area of an sdram cell. you can't beat it. its not the actual structure but the metallisation on top that dictates this. an dram cell can be made as narrow as the width of the top metal. for an sram cell you need 4 widths . there is no escaping the geometry. the actual buried cell below may be small but by the time you bring the steering signals up you hit top layer metal and that ain't 18 nanometer anymore ...

[amyk]

If you're curious you can go to the JEDEC site and download the Cadence board files for reference DDR DIMMs. Look at your memory sticks from your PC sometime. Almost all of them are carbon copies.

Interesting. I suppose it's a layout that works, and one that took a lot of time to get right, so everyone else just copies them and doesn't need to make any changes. I've read the JEDEC standards before but didn't notice they provided the PCBs too.

[poorchava]

You could try PSRAM. It's actually a DRAM with all the non-static and refresh logic on chip. So essentially a DRAM which you use as an SRAM. It's used for example in iphones.

You also need to take into consideration that DRAM requires at least 4 layers to make a proper layout (someone may correct me on that one).

As for DRAM layout, this guy has some interesting things to say: https://www.youtube.com/user/matarofe/videos