Speeding up Flash... in a flash

Nebojsa Novakovic
13 October 2007

Tweet
Facebook
Google plus
Send to

WE ALL KNOW that if you put together four or eight flash devices together, you'll get a storage medium with performance far superior to any HDD: read or write, latency or bandwidth - name it. Only DRAM with battery backup would be faster.

However, the current interfaces and related controller ICs are the main roadblock from unlocking all that performance potential. Yeah, Firewire (OCZ has one) and e-SATA or even old IDE PATA are way better than USB 2 in both real performance and CPU usage, but, neither of these interfaces was really optimised for the flash (NAND or NOR) memory.

Not to mention the controllers currently used: there is more potential to be gained by ganging many flash memory ICs in parallel, multiplying the bandwidth or even adding ECC while keeping that low latency. Also, while similar, none of these are identical in terms of protocol or command set - why not standardise it and make life easier for everyone?

During one of those obscure hidden tech sessions at the recent IDF, Intel showed something that caught my eye: ONFI. What the hell is that? By the name alone, one would think of Paris Hilton's next puppy...

Well, ONFI is more than that - it is a part of an initiative to optimise the flash memory integration and performance in the PCs, starting with NVMHCI "Non Volatile Mem Host Controller Interface" akin to SATA AHCI.

NVMHCI is a standard programming interface for multiplatform OS support for flash as native storage at low level, enabling a single driver for both hard disks and flask memory. It can be used to support both the cache-like flash drive supplements like ReadyBoost or ReadyDrive, and full SSD storage devices.

Now, ONFI, or Open NAND Flash Interface, is a flash-optimised, uniform electical and protocol interface, with 1.0 ratified spec since end of last year. Intel and Micron are right now shipping ONFI-compliant chips. The current 60+ ONFI members include pretty much all major names, including ATI, Nvidia and a host of memory and controller vendors.

That's just the start - the upcoming ONFI 2.0 improves performance drastically by changing the NAND interface to almost quadruple the transfer rate from the NAND array to the memory buffer - from 40 MB/s to 150 MB/s per die, not bad eh?

Then, they borrow some thingies from SDRAM and DDR DRAM, like source synchronous data strobes and dual data rate timings with a clock speedup generational chart, ranging from Gen1 at 133 MB/s to Gen2 at 266 MB/s and Gen3 at 400 MB/s - or 10x above the current flash dies. The only pinout change? An extra source sync pin, that's it.

With that in place, why not follow the DRAM one step further, and create a standard ONFI DIMM connector for direct mainboard insertion? Rather than, say, cumbersome USB or eSATA or PCIe to NAND conversion, you might see future chipsets incorporate a few ONFI channels directly on the South Bridge. Once the ONFI controller is in there, you just need to add flash dies on a DIMM module - just like normal DRAM.

In a few months, you'll see a standardised ONFI NAND flash DIMM connector, for both horizontal and vertical module mounting. Take a look at the early concept here from the Intel presentation - I hope it enables multichannel DIMMs, i.e up to four ONFI channels per DIMM, one for each die or two - plus maybe an extra ECC channel too.

That would enable up to half a gigabyte per second net transfer rate our of, say, a single 32 GB four-chip ONFI 2.0 Gen1 flash DIMM next year, with near DRAM latencies too. Compare that to any current hard drives, and the picture is clear - you wouldn't want to boot your OS from a hard disk anymore, even if RAID 10.

With standardisation come higher volumes, easier implementation and, yeah, lower prices. I believe hard disks will still have their place as second storage device to handle data, etc, but, nevertheless, ONFI brought in the last piece of the puzzle needed to make NAND flash the primary storage device of most PCs from late next year onwards. µ