In designing DDR interface, look before leaping

But that thinking can be a trap for two reasons. First, as has been argued often in these pages, memory activity is often a dominant variable in both system-on-chip performance and SoC power consumption. In some circles, it is so critical that a whole flow of system-level analysis is done just to optimize memory references. Second, and equally important, is that DDR DRAM optimization is extraordinarily complex. Some SoC design teams, if pressed, will admit that their real core competency isn't data paths or integration or even their superb test bench. Rather, it is their accumulated experience at designing optimizing memory controllers.

But I don't use DRAM, you protest. Perhaps you should, replies Michael Pearson, director of enabling at Samsung Semiconductor (San Jose, Calif.). Not only is there approximately a 30:1 advantage in cost-per-bit for DRAM, he notes, but in some apps, organizational tricks can produce SRAM-like throughput from DDR DRAM.

But these tricks, like the bandwidth estimates Pearson documents in a contributed online paper, depend on understanding the timing of the DDR DRAM devices. With multiple banks, precharge requirements and a strong precedence of operations, the actual bandwidth of memory controller depends highly on the flow of transactions from the SoC and upon the memory controller's ability to organize and time them.

Worst-case, Pearson says, occurs when the controller requests consecutive reads or writes from different rows in the same bank, forcing precharges between accesses. Best case occurs when precharges can be hidden behind burst reads to successive banks. To get the most out of the memory interface, either the application hardware designers or the software coders must take responsibility for ensuring such details.

http://www.eet.com