9
\$\begingroup\$

I'm looking into interfacing standard PC form-factor SDRAM or DDR sticks to a microcontroller, but I can't find any definitive details on how they work in terms of how the bus works. I guess it's similar to how any standard SPI or I²C interface works - send some instructions to the device, then read back some results until a particular pin state is met. Except in this case the data and address buses are parallel instead of serial.

I have three related questions on the topic:

  • What interface does standard PC memory, e.g. SDRAM or DDR, run on? I remember reading something about JEDEC being responsible for the spec, but I can't find any specific details. I'd like to use DDR (or DDR2) since it's cheaper right now, but I'll settle for SDRAM.
  • Can standard PC memory be bought down to more "comfortable" clock speeds? The standard bus speeds for these things tend to be around 133MHz, but I'm hoping to run them at less than 1MHz. My understanding is that SDRAM wait for clock edges before responding to commands, so a low clock frequency should result in it being manageable by a microcontroller.
  • What's the name of the physical interface? I tried looking on Farnell for sockets for such memory devices, but I only found some really tiny pitch surface-mount stuff. I could probably build my own through-hole version if I spent long enough, but I'd prefer to just buy one pre-built.
\$\endgroup\$
7
  • \$\begingroup\$ Given the large number of connectors, you're not going to find it in through-hole. You may hit problems with DRAM refresh: each bit needs to be rewritten at a particular minimum frequency if it is not to be lost. You might be best off finding an ARM with a DRAM interface .. \$\endgroup\$ – pjc50 Feb 11 '13 at 15:12
  • \$\begingroup\$ Go to Micron.com and look for their excellent datasheets and technical notes. The DIMM datasheets give some information, but the real meat is in the datasheets for the chips fitted to those DIMMs. \$\endgroup\$ – user_1818839 Feb 11 '13 at 15:14
  • \$\begingroup\$ What kind of mcu are you using that will give you 100+ gpio for the data, address, parity, and control pins needed for SDram? \$\endgroup\$ – Passerby Feb 11 '13 at 21:36
  • \$\begingroup\$ @Passerby I was hoping to reduce the necessary pin counts by feeding the address and data buses with shift registers. Looks like a micro won't be quick enough, though. \$\endgroup\$ – Polynomial Feb 11 '13 at 22:47
  • \$\begingroup\$ @Polynomial well, what is your memory needs? You could salvage a single ram chip off a dimm instead. Especially older memory (before sdram pc100). Still get a meg or two, from a single memory chip. \$\endgroup\$ – Passerby Feb 12 '13 at 0:42
7
\$\begingroup\$

Unless your microcontroller has a direct bus support for interfacing to DDR/DDR2/DDR3 type RAM or your microcontroller is interfaced through an FPGA which has been programmmed to provide the RAM interface then it is likely that futzing around with DIMMs is not a useful exercise. There are several strong reasons why this is the case....

1) DDR memory chips may be operating at lower voltages than your microcontroller.

2) The interface to the DDR memory is multiplexed and requires precise clocking whilst the multiplexed lines change states in sync with said clock.

3) Modern DIMMs are designed to operate at very high frequency clocks of 800MHz, 1066MHz, 1333MHz, or 1600MHz. Signal integrity is extremely extremely important when designing the circuit connections to the DIMM. It is not a trivial exercise and the memory chips can be extremely sensitive to noise as a result.

4) DDR memories require constant refresh to keep the memory cells data valid. Without refresh the memory content fades away over time from milliseconds to seconds.

5) The command structure to operate modern DDR RAMs is complex. The most complicated part is getting the initialization sequence correct which consists of some 13 to 20 individual steps.

6) Modern DIMMs are designed to feed data to modern PC type computers very fast. The typical DIMM has a data path width of 64-bits. Multi rank DIMMs also require multiple clocks and chip select signals to access all of the memory chips on the memory stick. It is unlikely that the typical small microcontroller can make effective use of this wide data format without an excessive amount of external circuitry.

Keep this in mind too. Companies that make PC style processors that utilize DIMMs have onboard controllers to interface to the memory sockets. There is an engineering specialty for programmers that work in the BIOS field called MRC (memory reference code). This is the program code module that initializes the DDR controller and all the attached DIMMs. This specialty employs the best and some of the most senior BIOS programmers that do nothing but MRC coding as a full time job.

\$\endgroup\$
7
\$\begingroup\$

Some single data rate (SDR) SDRAM can be run at slower rates - check the Clock Period (max) spec. However, you have to issues refresh commands on a regular basis, and if you clock at 1MHz you might find you have no time for anything else!

DDR SDRAM typically has a minimum (yes, minimum) clock frequency in the high tens of MHz... and the physical interface would be very challenging to implement on a micro as it returns a clock/strobe-like signal along with the data and you have to find the middle of that clock period to know when to sample the data.

Micron is a great source for datasheets which document the interfaces very well.

As for physical connectors, they are called SIMM and DIMM (single and dual inline memory module)

\$\endgroup\$
3
  • \$\begingroup\$ This is first sane answer to a question about DDR and MCUs I read here. DDR has minimum clock frequency, damn! That's constraint which precludes usage with low-freq MCUs, not trivialities like pin count or Vcc (ATtiny can do 1.8V). As for refresh, I wish that some of pro guys described why "auto refresh" typically found in DDR datasheets won't work here (or why "auto refresh" isn't really auto refresh). \$\endgroup\$ – pfalcon Jun 9 '13 at 1:26
  • \$\begingroup\$ Wouldn't minimum clock period be maximum clock frequency? I also bumped into this micron.com/~/media/Documents/Products/Technical%20Note/DRAM/… which says "Unlike DDR, there is no minimum clock frequency for SDRAM regardless of the speed grade." That document made it sound like you only need to look at the refresh related parameters. \$\endgroup\$ – Aleksi Torhamo May 29 '14 at 0:00
  • \$\begingroup\$ Yes, the basic circuit still consists of a capacitor. If it has a charge, it's "1" otherwise it's "0". The charge on a capacitor decays over time, and the capacitors are small. The circuitry and timing to "refresh" the charge is an overhead. \$\endgroup\$ – Alan Campbell Nov 8 '14 at 23:25
4
\$\begingroup\$

There is a type of DRAM which includes an onboard refresh controller. It allows for large memory densities while allowing an MCU without a DRAM controller to treat it like an SRAM. It is called Pseudo SRAM, PSRAM, or Cellular DRAM by various vendors.

An example example part number would be...

\$\endgroup\$
3
\$\begingroup\$

In order to use SDRAM, you need to have a chip that contains an SDRAM controller, period. Either get a microcontroller that has one, or attach an FPGA that has one to your microcontroller.

Either way, it isn't a project for a beginner.

\$\endgroup\$
1
\$\begingroup\$

Back in the times of magnetic core memory, the core drivers and receivers had to be adjusted for the core temperature, or the core had to be kept at a fairly steady operating temperature. This was because the memory operated close to the physical limits imposed by its design. As a counterexample, the 6116 static RAM doesn't operate anywhere near where nominal the die temperature would affect its operation so much that it had to measure it and adjust its operation. Alas, modern SDRAM is again back to where the magnetic core memory was: the performance of silicon is temperature dependent, and also dependent on the layout of the circuit board, and it operates with such small margins that various tuning ("training") procedures have to be performed during normal operation of the RAM to maintain proper operation. We've gone full circle: houskeeping the SDRAM is more like dealing with a very fast analog circuit :)

Generally, the standard DRAM interfaces are JEDEC standards - you can register a free user account on jedec.org, and use it to download those standards. So, let's talk about something concrete: LPDDR4 (low power double data rate 4) DRAM standard JESD209-4 (dated August 2014). Older DRAM gets obsolete rather quickly, so if you want to design-in some SDRAM, it's best to focus on the current generation of chips. Since the standard is readily accessible, I won't cover it in much detail, but just expose the "alien" nature of the SDRAM interfaces (when compared to RAM devices in common use in the 70s/80s).

Pinout

the data and address buses are parallel instead of serial.

The data and address busses are parallel indeed, but the interface is not something that you can directly attach to a microcontroller. First of all, the logic is HS_LLVCMOS (high speed low voltage CMOS), and the I/O ring (the silicon that drives the pins) runs at 1.1V nominal, 1.06V minimal, 1.17V maximal. So you definitely need logic level translators, since few low-speed MCUs can support such levels natively.

Furthermore, the "parallel" bus organization is designed to make sense for high-speed computer memory, and is not like that of a typical "slow" DRAM chip from the 1970s that had /RAS and /CAS lines, a chip enable (maybe), row/column address inputs, read/write select, and data I/O lines.

All SDRAM families have a bus designed to send commands to the RAM, and many of those commands (in fact - the vast majority of them!) have nothing to do with reading or writing the data. There are several mode control registers that you can access - they are not "memory mapped", i.e. they are not visible in the address space of the memory, but are accessed using dedicated commands.

LPDDR4 chips each have one or two completely independent "channels", i.e they are effectively split into one or two independent SDRAM devices, and each one has a synchronous parallel I/O bus. The signals are:

  1. Control/command/address section

    • CK_t/CK_c - differential clock input for the address, command and control signals (i.e. all signals other than DQ). This section is always single-data-rate, i.e. the signals are sampled by the RAM on the rising clock edge only.
    • CKE - clock enable, used to inhibit the clock internally without having to externally turn it off
    • CS - chip select/command nibble select - the deselect command is activated when CS is low on the rising clock edge, and then the CA bus is ignored until the next clock cycle; otherwise CS must be high on the rising clock edge and low on the falling clock edge
    • CA[5:0] - command/address input bus - yes, you only provide 6 bits at a time
    • ODT_CA - on-die termination enable for the CA bus - can be overridden in the MR22 register
    • /RESET - used to bring all channels on the die to the RESET state
  2. Data section

    • DQS1_t/DQS1_c - differential clock I/O for the upper data bus byte (DQ[15:8])
    • DQS0_t/DQS0_c - differential clock I/O for the lower data bus byte (DQ[7:0])

    During the READ command, the memory chip drives the DQS clocks. During the WRITE command, the user drives the DQS clocks. The data bus is double-data-rate, i.e. on each clock cycle, new DQ values are clocked by both the rising and the falling clock edges.

    • DQ[15:0] - 16-bit data I/O bus
  3. Power and miscellaneous

    • VDDQ, VDD1, VDD2 - 1.1V supply voltages
    • ZQ - calibration reference, connect to VDDQ through a 240Ω ± 1% resistor.

Clock Speed

Can standard PC memory be bought down to more "comfortable" clock speeds?

Yes. In the standard, table 88 - Clock AC Timings - specifies the maximum average clock period tCK(avg) of 100ns. Thus to run the RAM, you need to provide it with a 10MHz clock at minimum. This clock can be turned off according to Input Clock Stop protocol (ibid., sec 4.37). This minimum clock applies to all speed grades of LPDDR4 memory.

The jitter specification tJIT(cc) (ibid., table 88) is 140ps maximum for LPDDR4-1600, and gets tighter for faster devices. It is only critical with fast clock speeds - for the most part: as long as the clock period +/- jitter doesn't exceed specs, things will be OK but DDR2+ devices contain delay locked loops (DLLs) that need to synchronize with the clock period. Those loops won't achieve good lock if the clock jitter is excessive. Using an externally-derived clock and synchronizing the microcontroller with it is thus preferable. See the 3-part article "Dealing with clock jitter in embedded DDR2/DDR3 DRAM designs" for more insights into clock jitter's effects on DDR2+ memories.

The 10MHz clock doesn't mean that the RAM has to be "doing something" all the time: on many of the clock cycles, the DESelect command can be given (CS = 0 on a rising clock edge).

Refresh

The LPDDR4 chips with 4Gb, 6Gb and 8Gb (gigabits) dies have 8 banks, and each of the banks has to be refreshed periodically. The refresh rate requirement depends on the die temperature: the higher the temperature, the faster the refresh rate has to be. The RAM helps you here: as a user, you have to periodically read the MR4 register to determine the refresh rate the RAM requires at its current operating temperature. The RAM has a built-in temperature sensor. The fastest refresh rate is 0.9us per bank. The banks can be refreshed individually - when one of the banks is being refreshed, the others can be used. There's also a Refresh All command, to refresh all banks at the same time.

Addressing

All memory data accesses - reads or writes - proceed as follows:

  1. The row is activated using the Activate-1 and Activate-2 commands. Those provide the row address to the RAM.

  2. A column within the row is then selected for reading or writing by the Read-1 or Write-1 command followed by the Read-2 or Write-2 commands, also called CAS-2 since they are identical for reading and writing. CAS-2 must be sent no earlier than tRCD (RAS-to-CAS delay) after Activate-2 - i.e. no earlier than after 18ns or 4 tCK cycles - whichever is later.

  3. Until now, the DQS clock has been dormant. The clock becomes active after the read or write latency has passed, followed by passing of the preamble time. For reads, the RAM supplies the DQS clock; for writes, the user supplies the DQS clock. The preamble can be configured via the MR1 register, and it can be a "static" preamble where DQS doesn't toggle, or a dynamic one where DQS toggles one cycle before the data gets exchanged.

Everything Else

As the clock rates go above the minimum, and as the operating temperature changes, various training routines have to be performed.

And the final kicker: the power-up and power-down supply voltage sequencing is critical. The RAM is only guaranteed to survive 400 unplanned power down cycles, i.e. shutdown while the device was in the middle of an active command, and even those have to observe proper supply ramp-down. So, if you plan on using LPDDR4, you have to detect power loss before the supply voltages go out of regulation, the RAM must be brought to an idle state (this generally takes less than 1us, so not a big deal), and then all the inputs have to be "parked" in valid low logic states, and the regulators have to ramp down the voltages in a controlled fashion.


I've been running LPDDR3 (according to JESD209-3 standard) with a rather "slow" 100MHz microcontroller that doesn't have a DDR controller - one of the two auxiliary low-complexity cores in the microcontroller performs the RAM controller functions and voltage monitoring and bring-up/shut-down according to the standard.

It's not the most complex thing to do, so all those other answers imploring that it's "out of reach" of a beginner are overblowing it a bit.

Even DDR4 is something that you could interface with in late 1970s - sure, it wouldn't run anywhere near its own full speed, but it would easily keep pace with any and all digital systems of that age, with no wait states, and with next to no overhead (it'd work almost like SRAM would). All it would take to make it work would be a bit of discrete glue logic, and some analog level shifters and power supply controllers.

I'm confident that if you gave any of the DDR specs, up to and including DDR4 to, say, a DEC engineer in the late 1970s/early 1980s, they could make a working interface in a couple of months at most. And that would be to run the memory fully in accordance with the JEDEC standard. If all you wanted to do was just a proof of concept, it'd probably take no more than a couple of weeks of work. When the system starts up, various command sequences can be written into bipolar SRAM (in 1979, that would have been e.g. the Fairchild 13ns F10415A 1kbit ECL 10k family SRAM), and then "streamed" to the SDRAM using a state machine. During read and write cycles, the appropriate row and column address, as well as write data would be latched on the computer's bus and driven towards the SDRAM at appropriate times, and the read results would be similarly latched and driven back onto computer bus. Given the otherwordly DDR4 performance (vs. what was usual back in the late 70s), all the latencies in the SDRAM would be of little consequence, and the memory would be essentially a zero-wait-state DRAM for a vast majority of systems. Even the fastest systems of that time could access it in a single bus cycle, easily.

In practice, a DDR4 controller IP (intellectual property - a core you buy and stick into your ASIC, or comes standard in the SoC or FPGA you are using) sure saves time, but it's not too hard to implement if you aren't running at the full speed of the RAM chip. The main reason to favor fast SDRAM over slow SDRAM is that the fast SDRAM is cheap and widely available, whereas older SDRAM is becomes more expensive and eventually only available on secondary market as time goes on.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.