Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Memory/Storage

Exploring the future for SSDs

Posted: 31 Aug 2015 ?? ?Print Version ?Bookmark and Share

Keywords:Low-Density Parity-Check? LDPC? Error Correction Codes? ECCs? SSDs?

In the first article in this series, I talked about the transition to Low-Density Parity-Check (LDPC) Error Correction Codes (ECCs) in enterprise SSD controllers. I hinted that this transition has some interesting implications for the latency of next-generation SSD controllers.

The latency associated with LDPC ECC in SSDs comes from three main sources:
???The LDPC encoding process
???The LDPC decoding associated with the first read of the data on the NAND flash
???The LDPC decoding associated with subsequent reads of the data on the NAND flash.

In a high-performance SSD, the latency associated with the first source is negligible and is often hidden from the user using techniques such as a write-back cache. However, the latency associated with the second and third sources cannot be hidden from the user and can dominate under read-intensive workloads.

Let's break down the latency for the second two a little more. The table below shows the major latency components associated with a random read on an enterprise SSD. It is interesting to see that only two of these have any variability (t_read and t_ldpc) and that the variability for t_read is much larger than that for t_ldpc (60us versus 19us).

Only two of the latency components for a random read on an enterprise SSD have any variability (t_read and t_ldpc). That variability for t_read is much larger than that for t_ldpc (60us versus 19us).

The variability of the flash read time (t_read) is, in part, determined by the page index (some pages are inherently faster to read than others), while the remainder is a variability in randomness that varies from one read of the same page to another. Note that this variability is the same for both LDPC-based and BCH-based SSDs.

The variability of the LDPC decode time is a function of how many iterations it takes to decode the data from the flash. LDPC decoders typically employ an iterative decoding process and the number of iterations is usually not known at the beginning of the decode. We often bound the number of iterations to some upper limit to constrain t_ldpc in the case where a decode is unsuccessful.

Where things get interesting is when we note that the number of iterations in an LDPC decode depends on the parameters of the LDPC code and the number of errors on the section of NAND flash where the read occurs. This implies we can influence t_ldpc by controlling either one or both of these two items.

1???2?Next Page?Last Page

Article Comments - Exploring the future for SSDs
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top