节选内容转载自https://www.design-reuse.com/articles/13805/the-love-hate-relationship-with-ddr-sdram-controllers.html
Keep the DRAMs Simple, Put Complexity in the Controller
There are three critical decisions that forever complicated the DDR SDRAM memory controller. DLLs or equivalent circuits actually first appeared in some of the single data rate SDRAMs in the late 1990s to eliminate some of the clock insertion delay between the clock pin and the data output buffers. Using a DLL to reduce the data access time from clock (tAC) specification greatly improved timing budgets significantly. However, most DRAM vendors were able to just get by without the use of a DLL and as such, those that relied upon the DLL quickly followed suit and revised their designs to manage without one. By the time DDR SDRAM was being developed, the DLL became a requirement within the design as the clock insertion delay was insurmountable at the required clock frequencies for DDR SDRAM. Incorporating a DLL or equivalent circuitry into the DDR SDRAM also required a logical specification between the edges of the output data eye and the edges of the input clock. This was the first of three critical decisions that, as we will see, complicated the memory controller design. JEDEC decided to align the edge of the output data with the edge of the clock.
To facilitate high bandwidth operation, DDR SDRAMs use a source synchronous design where one or more data strobes (DQS) are generated by the same SDRAM chip that is transmitting data. The advantage with this system is that the data signals and the DQS strobe(s) have similar loading and physical characteristics and the DDR SDRAM can easily drive the DQS strobe with minimal skew relative to the data pins. Using the DQS strobe to sample the read data at the memory controller facilitates higher bandwidth. However, the adoption of the data strobes required the second critical decision affecting the memory controller – where to place the edges of the data strobes in relation to the data eye. In an ideal world, the most logical alignment is to place the data strobe edges exactly in the middle of the data eye – thus facilitating the ease of data capture at the controller. However, this would have significantly complicated the DLL used on the SDRAM, as it was only utilized to eliminate clock insertion delay. Centering the data strobe edges in the DDR data eyes would have required the SDRAM DLL to perfectly shift the strobe edges by 90 degrees. Logically, it makes little sense to add a cost burden to multiple memory components when they typically interface to one memory controller. Thus, the decision was made to make life easier (and cheaper) for the DDR SDRAM (and more complicated for the controller) by aligning the edges of the read data eye and the data strobes. The burden of shifting the data strobe into the center of the read data eye to properly sample the data was left to the controller. Conversely, for write data sent to the DDR SDRAM, the decision was made to require that the data strobe be centered within the write data eyes making it easy for the SDRAM to sample the data. Again, this requires the DDR controller to incorporate the complex circuitry required to precisely time the placement of the data strobe edges.
The final critical decision affecting the memory controller was related to the data strobes themselves - should the data strobes be unidirectional (have one strobe signal for reads and another strobe signal for writes) or bi-directional (use one strobe that gets turned around between reads and writes). Ultimately, to conserve pins and for other reasons, JEDEC adopted a bi-directional data strobe for the standard. This decision resulted in data strobes that are not free-running clocks but rather are driven by the DDR SDRAM only when data is being output and must be driven by the memory controller when write data is presented to the DDR SDRAM.
In hindsight, these key decisions were entirely valid looking at a memory subsystem from a total cost point of view – keep the complicated elements in the fewest chips. However, the result is that these three critical decisions placed all of the heavy lifting onto the shoulders of the memory controller. For write operations to the DDR SDRAM, the memory controller must place the data strobe in the middle of the data eye. For read operations from the DDR SDRAM, the memory controller must shift the data strobe into the middle of the data eye to properly capture the data. Add to this that the data strobe is not a free-running periodic signal, and the requirement for a master/slave DLL within the memory controller is created. Typically, a memory controller uses a master DLL to lock to the free-running, periodic system clock and a slave DLL to shift the non continuous data strobe such that the data strobe edges are centered in the DDR data eyes.
DDR2 SDRAMs have further complicated the data strobe functionality by offering an option to have the strobe be a differential signal. Meant to track the single ended data signals, differential data strobes incorporate a different logical threshold making the system more sensitive to slew rates. This has been largely corrected with extensive derating tables based on signal slew rates.
The bi-directional data strobe pins are tristated (undriven, they get pulled to the termination voltage level, VTT) if neither the memory controller nor the SDRAM are driving data. To prevent noise on a tristated DQS from generating false DQS edges, the data strobe input buffers are typically enabled within the memory controller such that they are active only during read cycles. The DQS input buffer enable scheme implemented within a memory controller should compensate for different delays and uncertainties such as I/O delays, board delays, CAS latency, additive CAS latency, and general timing uncertainties. Typically, a data training sequence is performed at startup to find the optimum position for the DQS input buffer enable signal. This can be accomplished by performing reads with deterministic patterns while sweeping through the possible system latency values.
The DDR PHY – More Than Just I/Os
For SoCs that require an interface to an external DDR (DDR or DDR2) SDRAM, the physical interface (PHY) requirement includes, at a minimum, application specific SSTL I/Os and some solution for handling the timing requirements of the data strobes. DDR2 SDRAM PHYs use SSTL I/Os that incorporate programmable on die termination (ODT) resistors that replace those previously required as external components. In addition, some form of PLL, DLL or calibrated delay circuitry is required to shift the data strobes into the center of the data eyes as previously outlined.
Solutions that use a calibrated delay circuit typically use a training sequence where the delay line is swept from minimum to maximum with expected data used to find the edges of fail and pass regions with the final setting placed in the middle of the pass region. This approach is more sensitive to temperature and voltage variation as the delay line variation is not self correcting. Periodic recalibration is one way to address this problem but this can consume precious memory channel bandwidth. In addition, calibrated delay circuits do not accommodate spread spectrum clocking as the delay remains fixed while the clock frequency is modulated.
PHYs incorporating DLLs or PLLs do not require external calibration as they are entirely self-calibrating. The PLL/DLL is locked to the clock frequency and is therefore immune to temperature and voltage variation as the delay line or VCO is constantly adjusted to match the clock frequency. PLLs and DLLs also track frequency changes in spread spectrum clocking and self-correct their respective delays. Using a master/slave DLL with precise 90 degree phases of the input clock, along with a slave (mirror) delay line controlling the strobes, the edges of the data strobes can be accurately shifted into the center of the data eyes. The mirror or slave delay line is required because the data strobes are not free-running clocks. Using a PLL often requires that the memory channel clock be multiplied by 4 to generate the 90 degree phases of the clock. However, a PLL still requires some form of slave delay line to time the data strobe edges.
The DDR Controller – More Brains than Brawn
The brains behind any DRAM controller is the logic associated with the command timing and execution. DDR SDRAMs are not straightforward devices. They contain multiple independent banks and every random read or write access must be preceded by a bank activate command and ultimately followed by a bank precharge command. Once a bank has been activated, the result is an open page of data that permits more than one read or write operation to a small subset of the bank.
In order to maximize the memory channel bandwidth, it is advantageous to look ahead into the queue of commands and group all those together that access any open page in an open bank. Reducing the overhead of bank activate and precharge “downtime” via command reordering and scheduling can significantly improve the performance of the SoC to memory channel.
The memory controller should also make every attempt to “hide” the bank activate and precharge commands in command slots that would otherwise go unused. Minimizing command contention also optimizes the channel performance.
The DDR SDRAM controller logic must also facilitate the refresh requirements for the DRAMs. Arbitrating between a latency intolerant command and an overdue refresh requirement requires complex prioritization within the controller. The controller must also frequently arbitrate between multiple sub blocks in the SoC that use the memory resource. Such arbitration requires the ability to prioritize traffic in the memory channel without starving low priority commands via an endless queue of high priority commands. Ultimately, this process can never be perfect and is frequently tailored to specific applications.