From time to time The Memory Guy is asked to explain why the NAND flash business doesn’t immediately convert to the next larger number of bits per cell once it becomes available. Many people tend to think that a significant cost benefit will necessarily result from migrating to the next number of bits. It surprises these folks to find that the cost advantage of moving from TLC to QLC is only half as great as the benefit of moving from SLC to MLC.
There is a diminishing advantage in moving to the next number of bits per cell, as is illustrated in this post’s graphic. (Click on it to see a larger rendition.) This post will explain why.
Flash started out as single-level cell (SLC), and in the 1990s MLC gained favor, followed in the early 2000s by TLC. QLC became viable with 3D NAND, and is now used even in enterprise SSDs. Meanwhile there’s a lot of talk about PLC.
But the conversion from one of these to the next doesn’t occur immediately. Each time a new one is adopted it performs more slowly than the past versions, has lower endurance, and it requires better error correction. This has to do with both the difficulty in getting sufficiently precise charges onto the floating gate or charge trap, and of reading those charges accurately.
While the speed issue, and reduced endurance can be addressed in various ways (explained in a series of blog posts on The SSD Guy), the additional error correction always adds cost.
The key factor in any move from QLC to PLC is that the cost savings are small compared to those gained by moving from TLC to QLC. Many people don’t clearly understand why the cost savings wouldn’t be the same, and why they are smaller with each generation. As the industry progresses from SLC to MLC to TLC to QLC, and finally to PLC, the benefit of each move decreases. I like to use the following example to explain how this works.
This argument will use a lot of assumptions for the sake of convenience. These numbers aren’t at all intended to be taken as an accurate, but they will give you an idea of why and how there are diminishing returns when you increase the number of bits per cell.
Assume that a chip costs the maker $1.00 to produce. Let’s say that it’s a 128Gb (gigaBIT) SLC part, which is 16GB (gigaBYTES). I’ll keep things simple by saying that the chip is sold to OEMs at the producer’s $1.00 cost.
Some OEM uses 120 of these chips to make a 1,920GB array for a cost of $120.
The same size/cost chip can be made to store 2 bits per cell (MLC) to provide 32GB/chip, and it still costs $1.00 to produce, because the logic to do this consumes a negligible die area. The array can use 60 of these MLC chips to reduce the OEM’s production cost to $60. That’s a 50% cost saving.
Later on, that SAME chip is made to store 3 bits per cell. It’s now a 48GB TLC chip. The additional logic is still negligible, so the cost is still $1.00, and the OEM’s system needs only 40 chips at a cost of $40. (I’m not paying due respect to the test engineers who have to get enormously creative to find a way to get this thing to yield, but they do, and that doesn’t add much, if anything, to the test costs.)
And now management drives the product team to use the same chip once again, to get 4 bits per cell, since some prescient chip designer put 4-bit QLC A/D convertors into the chip rather than 3-bit convertors when it was designed. This means that the same chip now can store 64GB. It still only costs $1.00 to make. The same 1,920GB array can be built using only 30 of these for a cost of $30.
By now upper management has become spoiled and has decided to ask once more for the product management team to perform superhuman feats to get 80GB/chip. It seems that someone let them know that the chip’s 4-bit A/D convertor actually had 5 bits of resolution. The chip still costs only $1.00 to produce, or maybe a little more, since yields aren’t quite as good and the test cycle is a little longer. The 1,920GB array can be built with only 24 chips for a cost of $24.
What kind of savings has the OEM enjoyed?
- Going from SLC to MLC the array’s cost went from $120 to $60 for a 50% savings
- From MLC to TLC the cost dropped from $60 to $40 to save 33% ($20/$60)
- The move from TLC to QLC took the cost from $40 to $30, saving $10/$40 or 25%
- And finally, going from QLC to PLC dropped to cost from $30 to $24 saving $6/$30 = 20%
The cost of including a 5-bit A/D convertor and multilevel programming logic onto the chip is tiny. Getting past noise issues is a problem that costs nothing once it’s been tackled, although the OEM is likely to need better error correction outside of the array, and maybe more overprovisioning to counter the chip’s increased sensitivity to wear, and that will eat into savings a bit. One important part of dealing with noise is that the internal signals will require more time to settle down – more bits require more time – so the chip gets slower. Also, the chip programs the bits to their precise target voltage by ramping the programming voltage, and this takes longer to do for higher resolutions.
But the chip still costs about $1.00 to produce.
By now the reader should have a better understanding of why PLC’s cost savings might not be all that important. Consider, too, that it takes some time to qualify the chip to the tighter tolerance, and by the time this characterization effort has been completed it is very likely that a newer NAND chip design will have entered production with a higher layer count and a lower cost structure. The 20% saved by moving from QLC to PLC is likely to be much smaller than the cost reduction achieved by a increasing the number of layers by 50%.
And that 20% savings will partly be offset by requiring a more sophisticated controller with better error correction, so the actual savings will be less.
In the end, these diminishing returns may slow the adoption of PLC, and could even cause producers to stop there, without even considering going one step further to save another 16% by using six bits per cell. As far as I know, six bits per cell has not even been given a name yet. Readers are welcome to suggest their favorites as comments to this post.