Understanding TLC NAND
by Kristian Vättö on February 23, 2012 1:14 PM EST- Posted in
- Storage
- SSDs
- OCZ
- Indilinx Everest
- TLC
Availability and Controller support
Just to make this clear, TLC isn't anything new. For example Hynix had a 32Gb 48nm TLC die in 2008. This is because TLC was originally used for devices like USB flash drives, where its poor endurance would be negligible. Most SSD OEMs have been toying with TLC SSDs for at least a year now but we haven't seen any commercial products. OCZ had originally planned to introduce its first TLC based SSD in the Q1 2012, however TLC pricing simply hasn't made sense yet. Unless OCZ can leverage a significant cost savings over 2-bit-per-cell MLC, the added headaches of bringing a lower performing TLC part to market don't make sense.
However there's still significant motivation to migrate towards TLC NAND. Further bringing down costs, particularly for consumer SSDs aimed at light, particularly read heavy workloads makes a lot of sense. Increasing pressure from Intel to deliver cheaper SSD enabled Ultrabooks, and Apple's desire to move all mainstream Macs to solid state storage are two major motivations. MLC NAND pricing will eventually get low enough to meet these (and more) needs, but TLC definitely accelerates the process.
TLC does require controller and firmware support. In the client SSD space only OCZ has been aggressive with announcing that its Indilinx Everest controller supports 3-bit-per-cell NAND.
Adding controller support for an extra bit per cell is more than just updating the datasheet and claiming it works. The ECC engine needs to be updated as the controller will face more frequent and more severe errors with TLC NAND (and its associated lower endurance rating).
Maintaining low write amplification is even more important with TLC NAND. With significantly fewer available program/erase cycles, burning through them due to high write amplification isn't acceptible. While NAND endurance isn't really an issue for most client MLC drives, it may be an issue for TLC based drives.
Facebook
Twitter
RSS
90 Comments
View All Comments
Kristian Vättö - Thursday, February 23, 2012 - link
That's definitely a very interesting idea, I haven't actually thought about it. Maybe we will see something like that in the future. It should be feasible since we have products like Momentus XT.marraco - Thursday, February 23, 2012 - link
That's what I was planning to write, so I agree, but it should be taken further: A weared out TLC cell should not be taken away by the controller/firmware. Instead it should be "degraded" to a MLC, and once it degrades, it should be used a s SLC.hechacker1 - Friday, February 24, 2012 - link
While that's an interesting concept, you would have to over provision it even more to account for storage loss as it is unable to store as many bits. It would be easier to define at creation that some of the NAND would be MLC, and some TLC.With really large SSD's, I think the life of TLC will be pretty good simply because we'll have so much storage to work with.
Imagine if you had a 1TB SSD, with a low 750 cycles. You could still potentially get around 750TB (minus amplification) of writes onto it.
xrror - Monday, February 27, 2012 - link
Hah, I had this same thought also.What would be great fun (but a nightmare for OEMs to validate) is if you as a user could arbitrarily choose what "modes" to run the flash in.
It'd also be ironic that as an SSD "wore out" it would drastically lose capacity but yet become faster while doing it ;p
ViRGE - Friday, February 24, 2012 - link
It seems like this would play hell with wear leveling though. Even though you're trying to segregate (largely) static data into TLC NAND, you're still going to periodically write to TLC NAND and as such need to do wear leveling to keep from burning out a smaller number of the TLC NAND cells too soon. It seems like the need to wear level would largely negate the segregation of data.Mr. GlotzTV - Thursday, February 23, 2012 - link
Since SLC, MLC & TLC are physically the same why not make the firmware dynamic?e.g.
A new (empty) starts storing information as SLC, when more storage is needed saves it as MLC or TLC. To ensure good performance and a long life of the drive it should store frequently modified & temporary files as SLC, other things like movies and music (files where speed is not important and aren't modified a lot) should be stored as TLC.
other thoughts:
when a TLC cell is too worn change it to MLC and later to SLC!
I know this would require a new very complex (and probably buggy) firmware. But are there any concepts or something?
jjj - Thursday, February 23, 2012 - link
http://www.anandtech.com/show/4284/sandisktoshiba-...Mr. GlotzTV - Thursday, February 23, 2012 - link
as far as I understood it is about removing DRAM and using some kind of pseudo SLC cache instead. Not exactly what I was thinking about but good to know anyway.THX for the link.
Kristian Vättö - Thursday, February 23, 2012 - link
Interesting idea, though I'm not sure if it's possible. While SLC, MLC and TLC are physically the same (i.e. they consist of the same transistors), I'm not sure what kind of process needs to be used to turn a NAND array into MLC or TLC instead of SLC. I would guess that it's more than what a simple SSD controller can do.I can try to dig up more info on NAND manufacturing and hopefully it will shed some light to this. Either way, it does sound very complicated and the possibility of data loss is huge if the NAND type is changed during use (you can't really go from TLC to SLC without having a huge cache).
ckryan - Thursday, February 23, 2012 - link
There is MLC-1, which is MLC which stores only 1 bit like SLC. It's almost as good as SLC, but I assume is much cheaper -- MLC is much cheaper than SLC (even if you're discarding half the capacity). I believe FusionIO uses this in some applications.