It’s no surprise that non-volatile RAM has been making a play to upstage hard disks. The promise of SSDs comes ever closer to being realized. But even as we watch the intrusion of solid state memories into the domain of rotating media, another quieter movement has been underway: the intrusion of non-volatile memory into the domain of DRAMs.
Whoa there Nellie! Yeah, that’s just a tad hard to swallow. Somehow we’re used to thinking that DRAM is a relatively inexpensive technology (even as we wince at the price of an upgrade module). But in a presentation by Spansion at Denali’s Memcon several weeks ago, a provocative picture was painted of a world where non-volatile memory took center stage and relegated DRAMs to the technology museums alongside their core brethren of yore. OK, maybe it wasn’t that dramatic, and in fact we’re not completely getting rid of DRAMs any time soon, as we’ll see, but the possibilities are tantalizing.
According to Spansion, their MirrorBit cell, which uses a newer charge-trapping mechanism that can store two bits per cell, moved below the cost of a DRAM cell in 2006. DRAM still has its speed of read and write going for it, of course, and that’s critical for execution time. But within the non-volatile world, NOR technology is cheaper than DRAM and can be read (but not written) very quickly, making it suitable for so-called “execute-in-place” (EIP or XIP) applications, since executing code requires only reading code and not writing data. NAND architectures are the cheapest and are fast to write and erase, which makes them useful for storage applications like USB drives and camera storage cards.
Of course Spansion has a horse in this race – they’re putting their money behind their charge-trapping technology, which requires fewer layers and has more of a visible roadmap beyond 45 nm than do its more august floating-gate forebears; this augurs well for continued cost and density improvements as they move down the nm scale.
They have proposed a new architecture that they claim will reduce components, reduce power, and reduce cost particularly in phone applications, although there’s nothing that says it can’t be used more broadly. They’ve positioned it as an alternative to a configuration called “store and download” (SnD). An SnD setup has a NAND memory alongside a DRAM – they illustrate an example with 2 GB of NAND memory alongside 1 GB of DDR DRAM. The code is stored in the NAND memory, where it resides permanently, including when the power is off. But because of the NAND memory’s slow read speed, the code can’t be executed directly out of the NAND memory (that is, it can’t be executed in place), so it’s downloaded to the DRAM and executed there instead.
The alternative proposed is their Eclipse memory (which uses MirrorBit cells), which has a NOR interface but actually integrates their ORNAND technology – for data storage – and their NOR technology – for EIP – on a single die. They illustrate an alternative configuration that still has 2 GB of Eclipse memory, but with only 512 MB of DRAM as a scratch pad. The code executes in place instead of being downloaded to the DRAM, meaning the DRAM no longer needs to be big enough to hold code, meaning the DRAM can be downsized, saving cost and power.
Aside from the DRAM space required, the main downside of SnD is the download part of it. You have to make a copy of the code in the DRAM before you can get going. It’s like being a painter raring to go, but you’ve got to get your paints out and mix them, you’ve got to stretch your canvas, you’ve got to get your brushes and lay them out within convenient reach, and by the time you’ve done all that, well, you’re just not feeling quite so inspired anymore, and maybe you need a nap or a beer. If you can execute in place, you power up ready to go. It’s like you walk into your studio, and your paints are all mixed and laid out for you, your brushes are lined up neat and tidy, and a fresh new canvas is stretched and ready to accept your every immediate inspiration. (Oh come on, stop gagging; it’s not that bad. Is it?)
Another configuration avoids the SnD boot-up delay by adding another chip in a “3-in-1 EIP” configuration. It has a NAND memory for data storage, a NOR memory where code can be executed in place, and a DRAM for a scratch pad. The combination of technologies in the Eclipse device means that the two chips for NAND and NOR can be replaced by the single Eclipse chip.
Of course the sizes of the memories used in the examples from Spansion’s presentation are just that: examples. In a given application, the size of the DRAM required would be determined by the amount needed by the application and – this is not trivial – the smallest DRAM on the market.
Don’t look at me funny like that. As memories of all kinds have gotten cheaper and bigger, it’s stops making sense to produce the really small ones, even if all you need is a really small one. So you may end up buying more than you need just because that’s all that’s available. SRAM is another alternative, although it takes a much smaller memory to make the numbers add up – a quick unscientific check on one distribution website showed a couple examples with SRAM being 16 – 140 times more expensive per bit than DRAM (and I’m conveniently hand-waving away the differences in types of SRAM and DRAM – did I mention unscientific?).
If the working memory could ever completely eliminate DRAM by becoming suitable even as a scratch pad, a function challenged now by the granularity of erasing and writing non-volatile memories, then maybe a new memory upgrade could start to look as cheap as a USB memory stick.
But before our eyes get too misty as we envision a future utopia where no refresh is required, there’s one other major gotcha that has to be overcome before non-volatile memory could ever replace DRAM completely: the whole issue of data retention and endurance. DRAM bits can more or less be rewritten infinitely many times. In fact, no matter how many times you think your application writes to memory, the refresh circuitry is writing constantly, over and over, lest it get distracted and lose its contents. (Hmm… I wonder if anyone ever thought of branding it as ADDRAM…) The issue of data retention is kind of nonsensical for DRAM; it’s infinite while the power is on due specifically to the refresh and is zero when the power goes off.
Not so simple with non-volatile memory. It starts with a respectable enough data retention, say, 10 or 20 years or so (and we won’t quibble here about the distinction between powered up and on the shelf). Probably long enough for your application. But with each write you wear out the cell a bit more, accelerating data loss; at some point, after you’ve written enough times, the data will leak away very quickly. Endurance is typically specified on the order of 10,000 or even 100,000 cycles, which sounds like a lot but is nothing for a scratch-pad kind of application. So even if the block-erase/write barrier could be overcome, endurance would need to be transformed dramatically.
The only reason the DRAM replacement works in the EIP applications is simply that you are eliminating DRAM used to hold code and the system has only to read that memory. There’s no frequent writing. So this is the time when the record playing the soaring orchestra music suddenly scratches and stops, dumping us unceremoniously back into the real world. And we realize that while SSDs may completely replace rotating media in a system, we may be able to reduce DRAM use significantly, but we won’t likely eliminate it.
