Storage device operations based on bit error rate (BER) estimate

A data storage device may include a non-volatile memory and a controller. According to a first aspect, a bit error rate (BER) estimate may be determined at a memory interface of the controller based on hard bit data from the non-volatile memory. The BER estimate may be used to determine, prior to transfer of the hard bit data to an error correction coding (ECC) decoder of the controller, whether to request transfer of soft bit data from the non-volatile memory. According to a second aspect, the ECC decoder may be instructed to initiate decoding of a codeword or sub code using a particular operating mode based on the BER estimate for the codeword or sub code. According to a third aspect, sub codes of an ECC codeword may be reordered based on BER estimates for the sub codes, and the reordered sub codes may be provided to the ECC decoder.

FIELD OF THE DISCLOSURE

The present disclosure is generally related to data storage devices and more particularly to operations based on bit error rate (BER).

BACKGROUND

Storage devices enable users to store and retrieve data. For example, some storage devices include non-volatile memory to store data and a controller that coordinates access to the non-volatile memory and performs error detection/correction. Low-density parity-check (LDPC) is a type of error correction coding (ECC) mechanism that can be performed by a storage device. When bit error rate (BER) is high, the LDPC ECC engine may use a combination of soft bits and hard bits to decode data read from the non-volatile memory. Using the soft bits may improve an error correction capability of the LDPC ECC engine. However, additional sense and data transfer operations used to determine the soft bits may increase overall latency at a storage device. Moreover, when average BER is high, soft bits may be provided and used for an entire page of data, even though the BER for individual data portions (e.g., sub codes) may be low enough to perform successful decoding without the use of soft bits. Additionally, sub codes are usually processed in the same order, regardless of the individual BER, which may contribute to the latency increase.

DETAILED DESCRIPTION

The present disclosure describes storage device operations based on a BER estimate. A first aspect of the present disclosure involves relocating BER estimation within the controller of a storage device. To illustrate, a controller may include a memory interface configured to communicate data to and from a non-volatile memory, such as a flash memory. The controller may also include a host interface configured to communicate data to and from an access device, and an ECC decoder disposed between the flash interface and the host interface. In some examples, the controller includes a data path management unit (DPMU) coupled to the memory interface, the ECC decoder, and the host interface. For LDPC ECC decoding, the ECC decoder may include a syndrome weight calculator. Because syndrome weights may generally indicate a number of expected bit errors in a data sequence, calculating a syndrome weight can be considered a form of BER estimation. In accordance with the first aspect of the present disclosure, BER estimation, such as syndrome weight calculation, may be moved out of the ECC decoder and into the memory interface instead. For example, a BER estimator in the memory interface may compute a BER estimate on-the-fly based on hard bits received at the memory interface from the flash memory. Based on the BER estimate for received hard bits, the DPMU may determine whether or not to request soft bits from the flash memory, before either the hard bits or the soft bits are provided to the ECC decoder. Thus, in situations where the BER estimate for a codeword or sub code is low, soft bits for the codeword or sub code may not be requested, thereby reducing the overall decoding time for the codeword or sub code.

A second aspect of the present disclosure involves using a BER estimate for a codeword or sub code to select an initial ECC decoding mode for the codeword or sub code. To illustrate, an ECC decoder may support multiple modes of operation, such as an ultra-low power (ULP) mode, a low power (LP) mode, and a full power (FP) mode. Typically, the ECC decoder may always attempt to decode a received codeword/sub code in the ULP mode first. If ULP decoding is unsuccessful, the ECC decoder may try to decode the codeword/sub code in LP mode. If LP decoding is also unsuccessful, then the ECC decoder may use the FP mode. In accordance with the second aspect of the present disclosure, a BER estimate for a sub code may be used to select an initial ECC decoding mode for the codeword/sub code upfront, rather than always starting in ULP mode first and using successively higher power modes if needed. For example, the ULP, LP, or FP mode may be selected for a particular codeword/sub code based on comparing the BER estimate for the codeword/sub code to one or more thresholds. Selecting the decoding mode based on the BER estimate may improve throughput at the storage device. To illustrate, when FP mode is selected as the starting mode for a codeword/sub code with high estimated BER, decoding time for the codeword/sub code may be reduced by skipping the ULP and LP decoding attempts, which would likely be unsuccessful.

A third aspect of the present disclosure involves modifying the order in which sub codes of an ECC codeword are decoded. To illustrate, the sub codes of an ECC codeword may typically be decoded in sequential order. In some cases, however, it may be beneficial to decode the sub codes in a different order. For example, consider an ECC codeword having four sub codes. There may be three sets of parity bits computed and/or stored in a flash memory for the ECC codeword. Each sub code of the ECC codeword may be used to calculate first parity (“Parity1”) bits and second parity (“Parity2”) bits. The Parity2bits of each sub code may also be used to calculate joint parity bits for the ECC codeword. The Parity1bits and the joint parity bits may be stored in (or alongside) the ECC codeword in the flash memory, but the Parity2bits may not be stored in the flash memory. The ULP and LP decoding modes of an ECC decoder may attempt to decode a sub code using the Parity1bits for the sub code. In FP mode, the ECC decoder may attempt to recover the Parity2bits for the sub code (which were not stored in the flash memory), which may be a time-consuming operation. However, the joint parity bits stored in the flash memory may be calculated such that if three of the four sub codes of the ECC codeword are already decoded, the Parity2bits of the remaining sub code can be computed using a relatively computationally inexpensive Boolean exclusive-or (XOR) operation involving the joint parity bits. Thus, in accordance with the third aspect of the present disclosure, the decoding order of the sub codes of an ECC codeword may be determined based on respective BER estimates of the sub codes. For example, a sub code having a high estimated BER (and therefore being likely to require FP decoding using Parity2bits) may be reordered such that the sub code will be decoded last. Reordering in such fashion may enable the ECC decoder to reconstruct the Parity2bits of the last sub code using the XOR operation after the other three sub codes have already been decoded, which may be faster than using the time-consuming FP Parity2recovery operation.

Although various aspects of the present disclosure may be described or illustrated individually, it is to be understood that one or more aspects of the present disclosure may be combined. For example, a data storage device according to the present disclosure may be capable of operating in accordance with one, two, or all three of the aspects described above.

Particular aspects of the disclosure are described below with reference to the drawings. In the description, common or similar features or components may be designated by common reference numbers. As used herein, “exemplary” may indicate an example, an implementation, and/or an aspect, and should not be construed as indicating a preference or a preferred implementation.

Referring toFIG. 1, a particular illustrative example of a system is depicted and generally designated100. The system100includes a data storage device110and an access device150(e.g., a host device, a test device, a computing device, or a combination thereof). The data storage device110and the access device150may be operationally coupled via a connection, such as a peripheral component interconnect (PCI) bus compliant with a PCI Express (PCIe) specification. In some implementations, the data storage device110corresponds to or includes a solid state drive (SSD) data storage device that is configured to be embedded within the access device150or a removable flash memory data storage device that is configured to be removably coupled to the access device150. In other implementations, the data storage device110corresponds to another device, such as an application-specific integrated circuit (ASIC) or a system-on-chip (SoC) device, as illustrative non-limiting examples.

In some implementations, the system100, the data storage device110, one or more components of the data storage device110, such as a memory device112, or a combination thereof, may be integrated within a network-accessible data storage system. Examples of network-accessible data storage systems include an enterprise data system, a network-attached storage (NAS) system, or a cloud data storage system, as illustrative examples.

The access device150may be configured to provide data to be stored at the memory device112(e.g., as part of a write command) and to request data to be read from the memory device112(e.g., as part of a read command) In an illustrative embodiment, the access device150may include a mobile telephone, a music player, a video player, a gaming console, an electronic book reader, a personal digital assistant (PDA), a computer (e.g., a laptop computer, a desktop computer, a tablet computer, etc.), another electronic device, or any combination thereof.

In some examples, the memory device112may be a non-volatile memory device. To illustrate, the memory device112may include a flash memory (e.g., a NAND flash memory) or a resistive memory, such as a resistive random access memory (ReRAM), as illustrative examples. In some examples, the memory device112may have a three-dimensional (3D) memory configuration. As used herein, a 3D memory device may include multiple physical levels of storage elements (instead of having a single physical level of storage elements, as in a planar memory device). As an example, the memory device112may have a 3D vertical bit line (VBL) configuration. In a particular implementation, the memory device112is a non-volatile memory having a 3D memory array configuration that is monolithically formed in one or more physical levels of arrays of memory cells having an active area disposed above a silicon substrate. Alternatively, the memory device112may have another configuration, such as a two-dimensional (2D) memory configuration or a non-monolithic 3D memory configuration (e.g., a stacked die 3D memory configuration).

In some examples, the memory device112includes multiple memory dies. In such examples, when data is stored in the memory device112, the data may be “striped” across one or more of the memory dies. Similarly, reading such data may include accessing one or more of the memory dies. In a particular aspect, the memory device112may include storage cells that are arranged in a plurality of word lines. Each word line, such as an illustrative word line113inFIG. 1, may be present on a single die or may span multiple dies of the memory device112. The word line113may store a plurality of ECC codewords, which may alternatively be referred to as an ECC block. In a particular aspect, an ECC codeword may include header information, seed information, data, flags, cyclic redundancy check (CRC) or parity information, or any combination thereof. In a particular example, an ECC codeword may be 2 kilobytes (KB) or 4 KB in length, and may be divided into multiple sub codes (SCs). InFIG. 1, an illustrative ECC codeword116is divided into four sub codes (designated SC0140, SC1141, SC2142, and SC3143), each of which may be 512 bytes or 1 KB in length. In alternative examples, ECC codewords may be divided into a different number of sub codes, sub codes may have different lengths, or both.

In a particular aspect, the sub codes140-143of the ECC codeword116may be used to calculate various sets of parity bits, which may or may not be stored in the memory device112. For example, as shown inFIGS. 1-2, each of the sub codes140-143may be used to calculate a first set of parity bits (Parity1(P1) bits) and a second set of parity bits (Parity2(P2) bits). The P1bits for each sub code140-143may be stored in the memory device112(e.g., the P1bits145for SC0140), but the P2bits may not be stored in the memory device112. The P2bits of the sub codes140-143may be used to determine joint parity (JP) bits146for the ECC codeword116, and the JP bits146may be stored in the memory device112, as shown. In the example ofFIG. 2, the JP bits146are determined based on an XOR operation202on the P2bits, although it is to be understood that in alternative examples one or more other logical operations may be used instead.

The memory device112may also include read/write circuitry114and latches115. In some examples, read/write circuitry114and latches115are provided around the memory device112in symmetrical fashion (e.g., on opposite sides of a memory array), so that densities of access lines and circuitry on each side can be reduced (e.g., by half). Alternatively, the read/write circuitry114and latches115can be laid out in non-symmetric fashion with respect to the memory device112, as shown inFIG. 1. According to a particular aspect, the read/write circuitry114includes multiple sense blocks to enable a page of storage elements (e.g., memory cells) to be read or written in parallel based on row/column addressing. In one example, each storage element (e.g., memory cell) stores one bit of data for an upper page, one bit of data for a middle page, and one bit of data for a lower page.

During a read operation, the read/write circuitry114may sense data values stored in memory cells of one or more word lines based on a comparison to one or more sense thresholds. For example, hard bit data may be sensed using state thresholds (e.g., erase state, A state, B state, etc.) and soft bit data may be sensed using “delta” thresholds that correspond to the state thresholds plus or minus an offset value. The sensed data values for each cell of a word line, such as the word line113, may be stored in the latches115. In the example shown inFIG. 1, hard bit data for each of the four sub codes has been stored in the latches115, and is designated H0, H1, H2, and H3. Soft bit data for each of the four sub codes, designated S0, S1, S2, and S3, may also be stored in the latches115during certain operations, as further described herein.

The data storage device110may include a controller120coupled to the memory device112. In some implementations, the controller120corresponds to a semiconductor die (distinct from semiconductor die(s) of the memory device112) that includes components of the controller120. In the example ofFIG. 1, the controller120includes a memory interface121(e.g., a flash memory interface), an ECC decoder125, and a host interface136. The controller120also includes a data path management unit (DPMU)130configured to control the overall flow of data and sequence of operations at the controller120.

In a particular aspect, the host interface136supports communication in accordance with a non-volatile memory express (NVMe) protocol. In some examples, the data storage device110may include or correspond to a solid-state drive (SSD) that is accessible via NVMe protocol(s). The host interface136interface may facilitate transfer for data, control signals, timing signals, and/or power transfer between the access device150and the data storage device110.

The memory interface121includes a memory122. In an illustrative example, the memory122is a random access memory (RAM) that is configured to communicate with the latches115of the memory device112via a bus. In some aspects, the bus may have a toggle mode frequency that represents how often data from the latches115is (or can be) transferred to the memory122via the bus. In a particular aspect, the memory122at least temporarily stores data that is received from the latches115. For example, as shown inFIG. 1, the memory122may at least temporarily store the hard bit data H0-H3, the soft bit data S0-S3, or both.

The ECC decoder125may, in some examples, correspond to a LDPC decoding engine that is configured to decode data read from the memory device112based on LDPC decoding principles. To illustrate, during a read operation, the ECC decoder125may configured to decode data stored in the word line113based on hard bit (HB) data (e.g., one or more hard bits sensed from the word line113), soft bit (SB) data (e.g., one or more soft bits sensed from the word line113), or both. The ECC decoder125may be configured to operate in multiple modes. To illustrate, the ECC decoder125may support decoding operations in an ultra-low power (ULP) mode126, a low-power (LP) mode127, and a full power (FP) mode128. The ECC decoder125may be configured to decode sub codes individually, i.e., a “sub code” may correspond to a decoding granularity of the ECC decoder125. In the example ofFIG. 1, using the ULP mode126to decode a sub code includes using hard bit (HB) data and P1bits for the sub code. Similarly, using the LP mode127to decode a sub code includes using HB data and P1bits for the sub code. In some examples, the LP mode127and the ULP mode126differ in terms of the operations, or the complexity of such operations, that are performed using the HB data and the P1bits.

Using the FP128mode to decode a sub code may include using one or more of P1bits, P2bits, HB data, or soft bit (SB) data for the sub code. As further described herein, decoding operations at the ECC decoder125for a particular sub code may be based at least in part on a syndrome weight for the sub code, where the syndrome weight estimates a number of bit errors likely to be present in the sub code. Completion of decoding operations at the ECC decoder125may result in generation of error-corrected data, which may, in some examples, be provided to the access device150via the host interface136(e.g., as illustrated by data152inFIG. 1).

The present disclosure enables several operations based on bit error rate (BER) estimates. According to a first aspect of the present disclosure, the memory interface121includes a BER estimator123, which may determine BER estimate(s)124for data that is read from the memory device112. In an illustrative example, the BER estimator123is configured to determine a BER estimate124for an individual sub code, ECC codeword, or word line. To illustrate, during operation at the data storage device110, the memory interface121may receive the HB data H0-H3117corresponding to the sub codes140-143of the ECC codeword116. The BER estimator123may determine a BER estimate124for each of the four sub codes140-143based on the corresponding hard bits. The BER estimates124for the sub codes may be determined “on-the-fly” based on the hard bits as the hard bits are received, and prior to the hard bits being provided to the ECC decoder125for decoding. In some examples, the BER estimate124for a sub code corresponds to, or is based on, a syndrome weight. Thus, according to the first aspect of the present disclosure, syndrome weight calculation may be performed in the memory interface121instead of (or in addition to) in the ECC decoder125. The calculated syndrome weight (e.g., the BER estimate124) for a sub code may be provided to the ECC decoder125along with the sub code (e.g., hard bits and/or soft bits for the sub code).

In a particular implementation, a syndrome weight may be calculated based on the formulas:

S_=⁢[s0⋮sp-1]=⁢H⁢V_=⁢[h0,0…hn-1,0⋮⋱⋮h0,p-1…hn-1,p-1]⁡[v0⋮vn-1]andSW=∑i=0i=p-1⁢⁢si
where S-bar is a syndrome vector, H is a parity check matrix of a code having codeword length n, including k data bits and p parity bits (n=k+p), V-bar corresponds to vectors of data received from the memory device112, and SW is the syndrome weight.

The BER estimate124(e.g., syndrome weight) for a sub code may be used to determine whether to request soft bits for the sub code. For example, the DPMU130may store or have access to multiple thresholds, such as an illustrative first threshold131, second threshold132, and third threshold133. The DPMU130may determine, based on a comparison of the BER estimate124for a sub code to one or more of the thresholds131-133, whether a soft bit request118should be sent to the memory device112to request soft bits for the sub code. In response to the soft bit request118, the memory device112may provide the soft bits for the sub code, such as soft bit data119.

The DPMU130may provide hard bit data and soft bit data to the ECC decoder125for decoding. In a particular aspect, the DPMU130determines whether the soft bit request118should be sent for a particular sub code (or ECC codeword, word line, etc.) prior to the hard bit data or the soft bit data for the particular sub code (or ECC codeword, word line, etc.) being provided to the ECC decoder125. Inclusion of the BER estimator123in the memory interface121may thus enable requesting soft bit data on an as-needed basis, which may reduce data traffic on the bus between the controller120and the memory device112. To illustrate, if the BER estimate124for a codeword or sub code does not exceed a threshold (e.g., the third threshold133), the ECC decoder125may perform error correction for the codeword or sub code based on the hard bits (and not soft bits) for the codeword or sub code. Alternatively, if the BER estimate124for the codeword or sub code exceeds the threshold (e.g., the third threshold133), the DPMU130may request soft bits for the codeword or sub code using the request118, and the ECC decoder125may perform error correction for the codeword or sub code based on both the hard bits and the soft bits for the codeword or sub code.

According to a second aspect of the disclosure. The DPMU130may use the BER estimate124for a codeword or sub code to select an initial decoding mode134of the ECC decoder125for the codeword or sub code, and may instruct the ECC decoder125to initiate decoding of the codeword or sub code in the initial decoding mode134. For example, the DPMU130may compare the BER estimate124for the codeword or sub code to one or more of the thresholds131-133, as shown inFIG. 3. When the BER estimate124for a codeword or sub code is less than the first threshold131, the DPMU130may skip transfer of soft bit data for the codeword or sub code (e.g., the request118may not be sent) and may select the ULP mode126as the initial decoding mode134. The ECC decoder125may initiate decoding of the codeword or sub code in the ULP mode126using the hard bit data for the codeword or sub code. The ULP mode126may be selected for codewords or sub codes having low BER, because of the high likelihood that the ULP mode126is sufficient to decode such codewords or sub codes without requesting soft bit data.

When the BER estimate124for a codeword or sub code is greater than or equal to the first threshold131and less than the second threshold132, the DPMU130may skip transfer of soft bit data for the codeword or sub code and may select the LP mode127as the initial decoding mode134. The ECC decoder125may initiate decoding of the codeword or sub code in the LP mode127using the hard bit data for the codeword or sub code.

When the BER estimate124for a sub code is greater than or equal to the second threshold132and less than the third threshold133, the DPMU130may skip transfer of soft bit data for the codeword or sub code and may select the FP mode128as the initial decoding mode134. The ECC decoder125may initiate decoding of the codeword or sub code in the FP mode128using the hard bit data for the codeword or sub code.

When the BER estimate124is greater than or equal to the third threshold133, the DPMU130may request soft bit data for the codeword or sub code (e.g., via the request118) and may select the FP mode128as the initial decoding mode134. The ECC decoder125may initiate decoding of the codeword or sub code in the FP mode126using both the hard bit data and the soft bit data for the codeword or sub code.

In particular implementations, two bits per codeword or sub code may be used to indicate the value of the initial decoding mode134of the codeword or sub code. The indication of the initial decoding mode may be provided to the ECC decoder125by the DPMU130(e.g., as a descriptor in a command or instruction) or may be provided by the memory interface121along with transfer of hard bits and/or soft bits to the ECC decoder. It should therefore be understood that although various operations may be described herein as being performed by the DPMU130, one or more of the described operations may instead be performed by the memory interface121. Using the BER estimate124for a codeword or sub code to determine the initial decoding mode134for the codeword or sub code may save energy and reduce decoding latency at the data storage device110. To illustrate, soft bit data may not be requested unless the BER estimate is high. Further, ULP or both ULP and LP decoding operations may skipped when the BER estimate is high.

According to a third aspect of the present disclosure, the BER estimates124for the sub codes (e.g., the sub codes140-143) of an ECC codeword (e.g., the ECC codeword116) may be used to determine that the sub codes should be decoded by the ECC decoder125in non-sequential order. As explained above, the ULP mode126and the LP mode127may use P1bits during decoding, whereas the FP mode128may use P2bits instead of or in addition to P1bits. Because P2bits for a sub code may not be stored in the memory device112, if FP decoding using P1bits fails, the ECC decoder125may recover the P2bits for the sub code. When a sub code is decoded successfully, its P2bits may be generated via a relatively simple encoding operation. In addition, the JP bits for the ECC codeword may be implemented such that, if at least a certain number of sub codes (e.g., three sub codes) of the ECC codeword have been successfully decoded, the P2bits for the remaining undecoded sub code(s) (e.g., a fourth sub code) may be reconstructed using a Boolean XOR operation, the JP bits, and the P2bits of the decoded sub codes.

For example, as shown inFIG. 4, the DPMU130may reorder the sub codes140-143such that the sub codes140-143are in order of increasing BER estimate124. The DPMU130may provide the reordered sub codes135to the ECC decoder125for decoding (or may instruct the memory interface121to provide hard bits and/or soft bits to the ECC decoder125according to the reordering). The sub codes having low and medium BER may be decoded first using their P1bits. The P2bits for the decoded sub codes may be available when decoding of the last (high BER) sub code begins, so that if P2bits for the last sub code are needed, the P2bits for the last sub code can be recovered using a XOR operation based on the JP bits146and the P2bits of the decoded sub codes. Such recovery of P2bits using a XOR operation is illustrated inFIG. 1as a P2recovery operation129. After the P2bits for the last sub code are recovered, the ECC decoder125may decode the last sub code using its P1bits and the recovered P2bits. Using the XOR-based recovery operation for a sub code may decrease decoding latency as compared to conventional P2recovery techniques, which may involve zeroing out the P2bits and running FP decoding operations.

The system100ofFIG. 1thus illustrates various operations based on BER estimates. Use of one or more of the operations may reduce energy consumption, improve decoding latency, and increase throughput at the data storage device110. Although various aspects, such as the first, second, and third aspects described with reference toFIG. 1may be illustrated individually, it is to be understood that one or more aspects of the present disclosure may be combined. For example, during execution of a read command at the data storage device110, the BER estimate124for a codeword or sub code may be used to determine whether to request soft bits for the codeword or sub code. Hard bits and soft bits (if requested) for the codeword or sub code may be provided to the ECC decoder along with an indication of the initial decoding mode134for the codeword or sub code, where the hard bits and soft bits (if requested) are reordered based on the BER estimates124so that a codeword or sub code that is likely to require FP mode decoding will be decoded last.

Although various aspects may be described herein as operating on a sub code basis or on a codeword basis, such descriptions are for illustration only, and are not to be considered limiting. Techniques and aspects of the present disclosure may be used in conjunction with data storage designs that are not codeword-based or sub code-based. For example, an “early” BER estimate (e.g., determined at a memory interface or other component external to an ECC decoder) may be used to determine whether or not to request soft bits for a portion of data other than a codeword or sub code. As another example, a BER estimate may be used to determine an initial decoding mode for a portion of data other than a codeword or sub code. As yet another example, portions of data other than sub codes (whose parity bits are mathematically related) may be reordered based on BER estimates.

Referring toFIG. 5, an illustrative example of a method500of operation is shown. The method500may be performed at a data storage device that includes a controller coupled to a non-volatile memory, the controller including an error correction coding (ECC) decoder. In a particular aspect, the method500may be performed at the data storage device110ofFIG. 1.

The method500may include receiving, at a memory interface of the controller, hard bit data from the non-volatile memory device, at502. For example, the hard bit data may correspond to hard bits read from non-volatile memory device112ofFIG. 1that correspond to one or more of the sub codes140-143of the ECC codeword116ofFIG. 1.

The method500may include determining, at the memory interface, a bit error rate estimate based on the hard bit data, at504. The bit error rate estimate may correspond to a syndrome weight calculated based on the hard bit data. For example, the bit error rate estimate may correspond to the BER estimate124that is determined by the BER estimator123ofFIG. 1.

The method500may include determining, based on comparing the bit error rate estimate to a threshold and prior to transfer of the hard bit data to the ECC decoder, whether to request transfer of soft bit data from the non-volatile memory to the memory interface, at506. For example, prior to the hard bit data being provided to the ECC decoder125ofFIG. 1, the memory interface121or the DPMU130may compare the BER estimate124to a threshold (e.g., the third threshold133) to determine whether to send the soft bit request118to request transfer of soft bit data.

In some implementations, the method500may also include providing the hard bit data, the soft bit data, or both, to the ECC decoder. For example, the method500may include generating error corrected data at the ECC decoder based on the hard bit data, the soft bit data, or both. The method500may further include sending the error corrected data to an access device, such as the access device150ofFIG. 1, via a host interface of the controller, such as the host interface136of the controller120ofFIG. 1.

By determining the BER estimate at the memory interface, a determination of whether to request soft bits may be performed prior to an initial decoding of the hard bits. As a result, soft bits may be requested and received from the non-volatile memory when a relatively high bit error rate estimate indicates that ECC decoding latency may be reduced using the soft bits so that the hard bits and the soft bits are available to the ECC decoder for the initial decoding of the data. Thus, ECC decoding with soft bits may be performed with reduced latency as compared to systems that do not request soft bit information until after initial decoding of the hard bits has begun.

Referring toFIG. 6, an illustrative example of a method600of operation is shown. The method600may be performed at a data storage device that includes a controller coupled to a non-volatile memory, the controller including an error correction coding (ECC) decoder configured to operate in a plurality of modes. In a particular aspect, the method600may be performed at the data storage device110ofFIG. 1.

The method600may include determining, at the controller, a bit error rate estimate for a particular codeword or sub code based on hard bit data received from the non-volatile memory device, at602. For example, the bit error rate estimate may be the BER estimate124determined by the BER estimator123at the memory interface121ofFIG. 1. In other implementations, the bit error rate estimate may be determined at one or more other components of the controller, such as at the ECC decoder125or another component of the controller120ofFIG. 1.

The method600may include instructing the ECC decoder to initiate decoding of the particular codeword or sub code using a particular mode of the plurality of modes, at604. The particular mode is selected based on a comparison of the bit error rate estimate to at least one threshold. For example, the DPMU130ofFIG. 1may compare the BER estimate124to one or more of the thresholds131-133to determine the initial decoding mode134.

As an illustrative example, when the bit error rate estimate is less than a first threshold, the method600may include skipping transfer of soft bit data for the particular codeword or sub code from the non-volatile memory and selecting a ULP mode of the plurality of modes as the particular mode. For example, in response to the BER estimate124being less than the first threshold131, the DPMU130may generate a control signal to cause the ECC decoder125to decode hard bits of the particular codeword or sub code according to the ULP mode126ofFIG. 1.

When the bit error rate estimate is greater than or equal to the first threshold and less than a second threshold, the method600may include skipping the transfer of the soft bit data for the particular codeword or sub code from the non-volatile memory and selecting a LP mode as the particular mode. For example, in response to the BER estimate124being greater than or equal to the first threshold131and less than the second threshold132, the DPMU130may generate a control signal to cause the ECC decoder125to decode hard bits of the particular codeword or sub code according to the LP mode127ofFIG. 1.

When the bit error rate estimate is greater than or equal to the second threshold and less than a third threshold, the method600may include skipping the transfer of the soft bit data for the particular codeword or sub code from the non-volatile memory and selecting a FP mode of the plurality of modes as the particular mode. For example, in response to the BER estimate124being greater than or equal to the second threshold132and less than the third threshold133, the DPMU130may generate a control signal to cause the ECC decoder125to decode hard bits of the particular codeword or sub code according to the FP mode128ofFIG. 1.

When the bit error rate estimate is greater than or equal to the third threshold, the method600may include requesting transfer of the soft bit data for the particular codeword or sub code from the non-volatile memory and selecting the FP mode as the particular mode. For example, in response to the BER estimate124being greater than or equal to the third threshold133, the DPMU130may request transfer of soft bit data from the memory device112(e.g., via the request118) and may generate a control signal to cause the ECC decoder125to decode hard bits and soft bits of the particular codeword or sub code according to the FP mode128ofFIG. 1.

By initiating decoding using an ECC mode that is selected based on the BER estimate, decoding attempts using one or more lower-power ECC decoding modes may be bypassed for data that is predicted to have a higher error rate than is correctable by the lower-power ECC decoding mode(s). As a result, an average decoding latency may be reduced as compared to systems that initiate data decoding using a lowest-power ECC mode for all data and that only progress to a higher-power ECC mode after decoding has failed in a lower-power ECC mode.

Referring toFIG. 7, an illustrative example of a method700of operation is shown. The method700may be performed at a data storage device that includes a controller coupled to a non-volatile memory, the controller including an error correction coding (ECC) decoder configured to operate in a plurality of modes. In a particular aspect, the method700may be performed at the data storage device110ofFIG. 1.

The method700may include determining, based on hard bit data received from the non-volatile memory, a bit error rate estimate for each of a plurality of sub codes of an ECC codeword, at702. For example, the bit error rate estimate may be the BER estimate124determined by the BER estimator123at the memory interface121ofFIG. 1. In other implementations, the bit error rate estimate may be determined at one or more other components of the controller, such as at the ECC decoder125or another component of the controller120ofFIG. 1.

The method700may include reordering the plurality of sub codes based on the bit error rate estimates, at704, and providing the reordered plurality of sub codes to the ECC decoder, at706. To illustrate, the DPMU130may at least partially sort the sub codes so that sub codes that are estimated to be decodable using a lower power ECC mode (e.g., the ULP mode126or the LP mode127ofFIG. 1) are decoded prior to decoding any sub codes that are estimated to be undecodable using the lower power ECC mode. For example, the DPMU130may compare one or more of the BER estimates to one or more of the thresholds131-133to determine a sort order of the reordered sub codes135. In some implementations, the sub codes may be sorted by BER and decoded in order of increasing BER to reduce an average decoding latency of the sub codes.

Sub codes that are predicted to require FP decoding that uses P2bits may be positioned after the other sub codes in the sort order to reduce delays in generating the P2bits. For example, the method700may include determining, based on a particular bit error rate estimate for a particular sub code of the plurality of sub codes, that the particular sub code is to be decoded in a full power (FP) mode of the plurality of modes (e.g., by determining that the BER estimate124of the sub code is greater than the third threshold133ofFIG. 1). The particular sub code may be set as a last sub code of the reordered plurality of sub codes135.

In implementations where each sub code of the plurality of sub codes is associated with first parity bits calculated based on the sub code, second parity bits calculated based on the sub code, and joint parity bits calculated based on the second parity bits associated with each of the plurality of sub codes, the second parity bits associated with a last sub code of the reordered plurality of sub codes may be reconstructed based on an exclusive-or (XOR) operation and the joint parity bits.

Reordering sub codes based on bit error rate estimates may reduce average decoding latency of the sub codes. For example, sub codes estimated to be more quickly decodable may be decoded before sub codes estimated to have longer decoding times to reduce delays caused by longer decoding times on a serial decoding order (e.g., due to time-consuming reconstruction of P2bits in FP mode). By adjusting a decoding order of the sub codes to delay decoding of sub codes that may use P2bits until after other sub codes have been decoded, delays during decoding using the P2bits may be reduced or avoided.

In some implementations, a computer-readable medium stores instructions executable by a processing module to perform operations described herein. For example, the computer-readable medium, the processing module, or both may be included in the data storage device110, the memory device112, the controller120(or one or more components thereof), the access device150, or any combination thereof.

Although various components depicted herein are illustrated as block components and described in general terms, such components may include one or more microprocessors, state machines, or other circuits configured to enable such components to perform one or more operations described herein. For example, components of the controller120may represent physical components, such as hardware controllers, state machines, logic circuits, or other structures, to enable the controller120to perform operations described herein.

Alternatively or in addition, one or more components described herein may be implemented using a microprocessor or microcontroller programmed to perform operations, such as one or more operations of the methods500,600, and700ofFIGS. 5-7. Instructions executed by the controller120and/or the data storage device110may be retrieved from a memory, such as a RAM or a read-only memory (ROM).

In some examples, the data storage device110may be coupled to, attached to, or embedded within one or more accessing devices, such as within a housing of the access device150. For example, the data storage device110may be embedded within the access device150in accordance with a Joint Electron Devices Engineering Council (JEDEC) Solid State Technology Association Universal Flash Storage (UFS) configuration. To further illustrate, the data storage device110may be integrated within an electronic device, such as a mobile telephone, a computer (e.g., a laptop, a tablet, or a notebook computer), a music player, a video player, a gaming device or console, a component of a vehicle (e.g., a vehicle console), an electronic book reader, a personal digital assistant (PDA), a portable navigation device, or other device that uses internal non-volatile memory.

In one or more other implementations, the data storage device110may be implemented in a portable device configured to be selectively coupled to one or more external devices, such as a host device. For example, the data storage device110may be removable from the access device150(i.e., “removably” coupled to the device). As an example, the data storage device110may be removably coupled to the access device150in accordance with a removable universal serial bus (USB) configuration.

In some implementations, the system100, the data storage device110, or a component thereof may be integrated within a network-accessible data storage system, such as an enterprise data system, an NAS system, or a cloud data storage system, as illustrative examples. In some implementations, the data storage device110may include a solid state drive (SSD). The data storage device110may function as an embedded storage drive (e.g., an embedded SSD drive of a mobile device), an enterprise storage drive (ESD), a cloud storage device, a network-attached storage (NAS) device, or a client storage device, as illustrative, non-limiting examples. In some implementations, the data storage device110may be coupled to the access device150via a network. For example, the network may include a data center storage system network, an enterprise storage system network, a storage area network, a cloud storage network, a local area network (LAN), a wide area network (WAN), the Internet, and/or another network.

To further illustrate, the data storage device110may be configured to be coupled to the access device150as embedded memory, such as in connection with an embedded MultiMedia Card (eMMC®) (trademark of JEDEC Solid State Technology Association, Arlington, Va.) configuration, as an illustrative example. The data storage device110may correspond to an eMMC device. As another example, the data storage device110may correspond to a memory card, such as a Secure Digital (SD®) card, a microSD® card, a miniSD™ card (trademarks of SD-3C LLC, Wilmington, Del.), a MultiMediaCard™ (MMC™) card (trademark of JEDEC Solid State Technology Association, Arlington, Va.), or a CompactFlash® (CF) card (trademark of SanDisk Corporation, Milpitas, Calif.). The data storage device110may operate in compliance with a JEDEC industry specification. For example, the data storage device110may operate in compliance with a JEDEC eMMC specification, a JEDEC Universal Flash Storage (UFS) specification, one or more other specifications, or a combination thereof.

The memory122and/or the memory device112may include a resistive random access memory (ReRAM), a flash memory (e.g., a NAND memory, a NOR memory, a single-level cell (SLC) flash memory, a multi-level cell (MLC) flash memory, a divided bit-line NOR (DINOR) memory, a high capacitive coupling ratio (HiCR) device, an asymmetrical contactless transistor (ACT) device, or another flash memory), an erasable programmable read-only memory (EPROM), an electrically-erasable programmable read-only memory (EEPROM), a read-only memory (ROM), a one-time programmable memory (OTP), another type of memory, or a combination thereof. In a particular embodiment, the data storage device110is indirectly coupled to the access device150via a network. For example, the data storage device110may be a network-attached storage (NAS) device or a component (e.g., a solid-state drive (SSD) component) of a data center storage system, an enterprise storage system, or a storage area network. The memory122and/or the memory device112may include a semiconductor memory device.

The semiconductor memory elements located within and/or over a substrate may be arranged in two or three dimensions, such as a two dimensional memory structure or a three dimensional memory structure. In a two dimensional memory structure, the semiconductor memory elements are arranged in a single plane or a single memory device level. Typically, in a two dimensional memory structure, memory elements are arranged in a plane (e.g., in an x-z direction plane) which extends substantially parallel to a major surface of a substrate that supports the memory elements. The substrate may be a wafer over or in which the layer of the memory elements are formed or it may be a carrier substrate which is attached to the memory elements after they are formed. As a non-limiting example, the substrate may include a semiconductor such as silicon.

A three dimensional memory array is arranged so that memory elements occupy multiple planes or multiple memory device levels, thereby forming a structure in three dimensions (i.e., in the x, y and z directions, where the y direction is substantially perpendicular and the x and z directions are substantially parallel to the major surface of the substrate). As a non-limiting example, a three dimensional memory structure may be vertically arranged as a stack of multiple two dimensional memory device levels. As another non-limiting example, a three dimensional memory array may be arranged as multiple vertical columns (e.g., columns extending substantially perpendicular to the major surface of the substrate, i.e., in the y direction) with each column having multiple memory elements in each column. The columns may be arranged in a two dimensional configuration, e.g., in an x-z plane, resulting in a three dimensional arrangement of memory elements with elements on multiple vertically stacked memory planes. Other configurations of memory elements in three dimensions can also constitute a three dimensional memory array.

One of skill in the art will recognize that this disclosure is not limited to the two dimensional and three dimensional exemplary structures described but cover all relevant memory structures within the spirit and scope of the disclosure as described herein and as understood by one of skill in the art. The illustrations of the embodiments described herein are intended to provide a general understanding of the various embodiments. Other embodiments may be utilized and derived from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. This disclosure is intended to cover any and all subsequent adaptations or variations of various embodiments. Those of skill in the art will recognize that such modifications are within the scope of the present disclosure.