I have a feeling that explanation of wear mechanism is little wrong. As far I know the problem is not with trapped electrons, electrons could be always moved with force (apropriate voltage) but each time when memory is programmed or erased, move of electrons degrades the isolation properties of oxider.
Charlie, really enjoyed reading your article here. The differences between SLC and MLC Flash have been a topic for discussion for quite some time and as a flash industry professional, we are constantly trying to mimic the advantages of SLC Flash in our MLC-based Solid State Drives. To add to your article, I would also like your readers to consider certain new endurance enhancement technologies that can substantially increase the native endurance and bolster reliability in MLC Flash devices. These types of innovations are blurring the lines between the SLC and MLC output and is making MLC a viable option for even the most write intensive application. Check out this white paper as a great resource for this type of technology on our website: http://smartstoragesys.com/pdfs/WP003_Guardian_Technology.pdf.
-John Scaramuzzo, President, SMART Storage Systems
Ok, maybe the answer is obvious to me because I have been working closely with NAND for the last 10 or so years...Clearly SLC has wider margins and can thus tolerate more degradation than MLC. Clearly SLC will give a huge reliability advantage.
You can sometimes use MLC parts as if they were SLC parts. Many MLCs write two adjacent pages into the same cells, so if you only write every second page you can sometimes achieve SLC-like reliability in MLC.
This opens up the possibility to do things like using MLC for the cost benefit, storing critical code etc in the fake-SLC area and less critical data/code in the regular MLC area.
NAND is goofy stuff.For example most electronic parts tend to be more reliable at the lower end of their temperature range. NAND, OTOH, is often more prone to errors at lower temperatures.
One failure mechanism you missed is read disturb. Yes, even reading NAND can corrupt data. That is particularly relevant to MLC. This has particular implications for static data like boot code which is typically not rewritten during the lifetime of the product but is read (and slowly corrupted) on every boot cycle.
If you want to ensure that your NAND-based solutions are robust, ensure that the software you are using with it (file systems, boot loaders, etc) have mechanisms to mitigate against the bad side of NAND.
Good catch--that's what I get for focusing on the text of the article rather than the graphics. I communicated with the author and we are in the process of getting an updated version of the table. Look for a revised version by tomorrow morning. Thank you for your patience and apologies for any confusion.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...