Practical Chip Design

Following an active panel on DDR3 DRAM, last week's Denali Memcon offered up a second panel topic: low-power memory design. That's a wide enough topic to allow for a range of discussions, and the panelists--Mostafa Abdulla of Numonyx, Roger Isaac of Silicon Image, Areski Maklouf from ST-Ericsson, and Howard Sussman of Etron—ranged all over it.

In opening statements, Maklouf said that LPDDR is a major issue for the platform architect. "Architects must work with memory providers to find a good solution," he said. Moving in a different direction, Isaac pointed out that no matter how cleverly you architected it, LPDDR was not going to make it for much longer. "We can get 3.2 GB/s per chip out of LPDDR2," he said, "but for the next generation of handsets, we need 12.2 GB/s at the same power levels we are seeing now. I think the answer is going to be either fast serial or a new wide-I/O standard."

Taking a third direction, Abdulla pointed out that by extrapolating current growth, by 2011 we will be consuming the output of seven or eight nuclear power plants just to run the main memory in the world's servers. "We believe that this is a problem non-volatile memory can address, and that phase-change memory is the way to address it," he said.

Sussman politely attempted to pour a little skepticism on the conversation. "I think this green trend is mostly marketing," he said. "In fact, with good system partitioning, and not pushing performance over energy consumption, you might be able to gain much more efficiency than by using green components."

The mention of wide I/O stirred up quick interest in the audience, and one questioner asked if it wouldn't be possible to use a wide-I/O memory next to a CPU in place of cache. Isaac replied that yes, you could do exactly that by stacking a wide-I/O DRAM die on top of the processor die—if you could control the temperature. "100 C puts the hurt on DRAM, he warned. "At high temperatures you even have to refresh Flash arrays. But for applications like a high-end handset, that one die stacked with the CPU could be the only DRAM in the system."

Asked to discuss stacking further, Maklouf and Isaac agreed that there were serious thermal-design issues in putting a potentially hot DRAM right on top of a potentially hot-spot-filled SoC. "But that's just one of the problems," Isaac said. "Who's going to test what, and who takes the liability if the stack doesn't work? Current solutions using through-silicon vias typically stack the same kind of dice from the same vendor, so you have some control."

Sussman was not so concerned about the testing problem, saying that about a third of Etron's shipments today are known-good dice, in part due to internal circuits in their memory chips that accelerate the effects of burn-in. But he did warn that LPDDR2 might not be the best thing to stack if you were concerned about heat. "The power-gating granularity on LPDDR2 is not very fine, so the chip doesn't really have the right internal architecture for low power," he said.

At this point Abdulla interjected that mixing non-volatile and DRAM memory in the subsystem could help considerably with the standby power. But Sussman retorted with data from an unnamed cell phone manufacturer about energy, as opposed to power, consumption. He said that in this study, in a 24 hour period the LPDDR memory was in standby for 17 of the 24 hours. The handset spent 1 hour in voice mode, in which the DRAM consumed 100 times the energy it used in the entire standby period. And the handset spent 20 minutes transferring data, at a cost of 180 times the DRAM energy used in standby. So overall, the standby energy consumption of the memory was 4 percent of the total memory consumption, and less than 1 percent of the total handset consumption. "Don't fuss about standby power," he concluded.

Shifting attention from handsets to server farms, Sussman warned that benchmarks on DRAMs were often nothing close to the way users actually used servers. "Reality is that in servers, most of the memory is powered-up most of the time," he complained, blaming the software-developers' need for instant response to a memory command. "If you could give me just a few more picoseconds to respond, I could use the power-down modes more often," he said.

Other panelists joined in the call for software developers to be sensitive to the energy-saving modes of the hardware. "A server owner spends $1200 per year per server on DRAM power," Abdulla said. "We really need a collaboration of memory, systems, and software developers to crack this problem. We could do something."

"I believe we could use intelligent partitioning of the software to allow most of the DIMMs in a system to go to self-refresh mode most of the time," added Isaac.