Thanks to the efforts of the standards-setting organization JEDEC, designers of systems-on-chip (SoCs) requiring external memory storage have access to inexpensive commodity DRAMs, such as DDR2 and DDR3 SDRAM, that are primarily developed to service the PC, server and workstation markets. However, unless you attend the relevant JEDEC meetings (between four and six times a year), the typical SoC designer is left woefully unprepared for the task of developing a DDR memory interface for his or her SoC. 

Unlike the various USB and PCI® interfaces, DDR has no standard for the controller (or “master”) end of the interface.  JEDEC does a great job of standardizing the DRAMs (or “slaves”), but the design of the memory controller is left entirely open to interpretation.  One thing will become clear in this article – memory controllers should be developed to operate with JEDEC standard DRAMs; they should not be developed to the JEDEC DRAM standards.

For designers developing DDR interfaces or incorporating DDR IP into their SoC, most of their attention goes to the bus that gives “DDR” its name – the data bus that operates at double data rate, where data is transferred on the rising and falling edges of the source synchronous data strobes.  After all, this high-speed bus pumps data back and forth at data rates of up to 1.6 Gb/s per pin for DDR3 SDRAMs, giving the perception that it is the most complicated part of the interface. Often this is true, but there are many cases where the lowly single data rate (SDR) address and command buses become the “long poles in the tent” that ultimately limit the performance of the entire DDR interface.

If we look at the DRAMs, they have a bidirectional DDR data bus and unidirectional SDR address and command buses (unidirectional as input only).  However, a DDR memory controller embedded in a SoC has a similar bidirectional DDR data bus (which may drive a small number of loads if the system is multi-rank), and a unidirectional SDR address and command buses that only output signals to the DRAMs.  Thus, the address and command buses are typically point-to-multipoint nets.  For systems that use a modest amount of DRAM, this can be as simple as one memory controller driving two DRAMs.  If unbuffered DIMMs enter the equation, however, the number of loads on the address and command buses can grow to 16 or 18 DRAMs if two UDIMMS are supported!  Many SoC designers may not be aware that for similar situations in PCs, the memory controller found in the processor or the Northbridge often uses “2T timing” on the address and command buses to circumvent the signal integrity problems associated with this heavily loaded net.  2T timing is the simple process of extending the data eyes on these nets by setting up the signals one extra clock cycle in advance, which utilizes two clock cycles for every data sample on the address and command nets.  This is represented in Figure 1 both conceptually and with simulated waveforms of the data eyes.  In the figure, a heavily loaded net’s data eye on the left fails to reach reliable AC thresholds for the DRAMs (DDR3 in this case), and the system will fail.

Figure 1: 1T versus 2T Timing for DDR Address & Command Buses

The use of 2T timing is not entirely without its drawbacks.  The clock enable (CKE), on-die termination (ODT) and chip select (CS) signals cannot use 2T timing, as it is critical which clock edge samples these signals.  For these heavily loaded interfaces, there are typically multiple clock nets to reduce the loading on any one clock net.  In addition, the clocks are differential signals, and there are situations where the variation between loading and single-ended versus differential signaling results in flight time discrepancies between the clocks and the address/command signals.  At higher data rates, the embedded DDR PHY should be capable of calibrating this skew out of the system.

Even for more modest systems that use fewer DRAMs soldered on the motherboard, the address and command bus warrants special attention.  DDR3 SDRAMs have been developed to accommodate “fly-by” routing on the DIMMs used in computers.  Ideally, embedded systems should use the same fly-by routing approach for multi-DDR3 SDRAM applications with data rates above 1066 Mb/s.  The fly-by routing technique has the clock, address and command nets routed such that they connect to each DDR3 SDRAM in a daisy chain topology (this is in contrast to the “star” topology of previous DDR generations that attempt to have the signals arrive at each DRAM synchronously).  Since every DDR3 SDRAM in a fly-by routed system receives its clock, address and command information skewed in time, the data will be similarly skewed in time.  In order to offset this problem, the DDR3 SDRAMs have a training mode that permits the DDR3 SDRAM controller to effectively zero-out this skew and re-align the data in time by adding delay to the data paths to align the data to that of the worst-case DDR3 SDRAM furthest down the chain.

The address and command buses are also terminated differently from the data bus.  The DDR3/2 data bus is terminated by the ODT in the SDRAM and the controller – no external components are required.  The ODT is also turned off when it is not being used, leaving the bus unterminated during idle cycles and thus saving power.  However, the unidirectional address and command buses are terminated using external resistors on the motherboard.  In addition, the DDR3/2 controller must continue to drive these nets unless the DRAMs are in power-down or self-refresh modes as required by the DDR3/2 SDRAMs (because their input receivers remain enabled).  This is obviously a waste of power during idle cycles, and it is very tempting to think of omitting the address and command bus termination altogether.  This is not recommended, however, because the signal integrity of the nets will likely deteriorate to the point of system failure (refer to Figure 2), and the CV2F pumping power can actually add up to more power consumption than that of a properly terminated system.

Figure 2: Sample DDR2 SDRAM Address & Command Bus Data Eyes -
Terminated (left) & Unterminated (right)

The value of the address and command bus termination should also be carefully selected in unison with the output drive strength of the memory controller address and command output buffers.  By forgoing unnecessary series termination, the output drive strength can often be set to match the impedance of the transmission lines and therefore absorb the reflections on the line, freeing up the termination value to be selected to optimize power consumption and data eye height.

Given that the JEDEC specifications for SDRAMs only detail the input requirements for the address and command buses, one can see that there is no correlation between the JEDEC SDRAM standards and the memory controller’s address and command specifications.  Thus, as previously stated, the memory controllers should be developed to operate with JEDEC standard DRAMs and should not be developed to the JEDEC DRAM standards.  Each DDR-based memory subsystem should be simulated from a signal integrity viewpoint to optimize the system for robust operation and low power consumption.

And don’t forget to pay attention to the address and command buses!