Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Controls/MCUs

Grasp soft-decoding in SSD controllers

Posted: 23 Dec 2015 ?? ?Print Version ?Bookmark and Share

Keywords:Low-Density Parity-Check? LDPC? Solid-State Drive? SSD? NAND flash?

In the previous article in this series, I talked about how we can control the parameters of Low-Density Parity-Check (LDPC) error correction codes in order to manage the latency associated with reads from a Solid-State Drive (SSD). However, we only looked at the latency associated with a single decode of the LDPC codeword. In this post, we will take a look at what happens when that initial decode fails and how soft data can be used to recover data on the SSD.

Hard and soft data decoding
In October 1948, Claude Shannon published his seminal paper "A Mathematical Theory of Communication," which kick-started the discipline of information theory. The work in this paper is still used today to determine how good or bad an error correction code is because it defined a performance bound beyond which no error correction code can go. Interestingly for any given channel there exists two bounds, one for decoding using hard data and one for decoding using soft data. A few examples of this are given in table 1.

Table 1: The hard-data and soft-data decode limits for a range of code rates. The bit error rates were calculated using hard slicing and the underlying channel was assumed to be Additive White Gaussian Noise (AWGN).

When we perform a read from NAND flash we typically only get back the ones and zeros associated with the data on the flash. As such, an initial LDPC decode of that data is a decode based on hard data, since it has no knowledge about which of those ones and zeros are good and which are dubious (there are a few tricks that people play here, but for now let's assume my statement is true). In this case, the performance of that initial decode is limited to the second row in table 1.

LDPC and soft-data decoding in NAND flash
If we assume that a hard-data LDPC decode fails, then things start to get very interesting for the SSD. We could decide to return an "Unrecoverable Read Error" and tell the user that their data is lost forever, but end-users typically don't like that ;-). If the SSD has an internal RAID system, we could use it to attempt to recover the user's data at the expense of additional complexity and NAND capacity to calculate and store the RAID parity. However, with LDPC, there is a third option, which is to soften the data and attempt a soft-data LDPC decode. Note that this third option is not available in controllers that use less advanced error correction (for example BCH codes) because they cannot leverage soft information. This option allows us to move from the second column in table 1 to the third column and operate in more noisy environments.

I like to think of a soft-data LDPC decode in three parts: A re-read strategy, soft-data construction and the soft LPDC decode.

Let's look at each one of these in turn.

Re-read strategy: The re-read strategy consists of reading one or more sections of the flash to assist in the construction of soft data. There are a lot of different options here, both in terms of which section of the flash to read and in terms of how those reads are performed. What we are trying to do is maximise the mutual information of the read and the original hard data in order to generate the best soft data we possibly can.

1???2?Next Page?Last Page

Article Comments - Grasp soft-decoding in SSD controlle...
*? 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