CN109669800B - Efficient data recovery for write path errors - Google Patents

Abstract

The present invention discloses a system and method for a flash memory device to improve write performance and hide write path error correction delays in the case of write path errors. Some embodiments may provide on-the-fly parity correction to allow user data that shares the same stripe as the data block with errors to be programmed into the flash memory before the erroneous data is corrected. Additionally, selected stops may allow some independent data in different flash memory chips or planes to be programmed during write path error correction.

Description

Efficient data recovery for write path errors

Technical field

The present invention relates to an apparatus, method and computer readable instructions for a flash memory device to provide efficient data recovery in the event of write path errors by accelerating write performance and hiding write path error correction delays.

Background technique

Non-volatile memory devices such as solid-state drives (SSDs) are finding new applications in consumer electronics. For example, they are replacing hard disk drives (HDDs) which typically include fast spinning disks (platters). Non-volatile memory, sometimes referred to as "flash memory" or "flash memory devices" (eg, NAND flash memory devices and NOR flash memory devices), is used in media storage, cameras, mobile phones, mobile computers , laptops, USB flash drives, etc. Non-volatile memory can provide a relatively reliable, compact, cost-effective and easily accessible method of storing data when the power is turned off.

Flash memory controllers are used to manage data stored in non-volatile memory and serve as the interface between the host system and the non-volatile memory. Data received from the host system can be stored in a buffer, and simple error detection and correction can be performed on the data before writing it to flash memory. Typically, a write path within a flash memory controller can provide access to program the flash memory. However, in some cases, the write path can be error-prone. When an error is detected in the write path of a data block received from the buffer, the flash memory controller typically stops all write operations to the flash memory issued after the data block with the write path error. The flash memory controller must correct errors in the write path, resend the corrected data blocks, and then resume writing to the flash memory. This can introduce unnecessary delays in write operations to flash memory.

In some cases, parity bit data can be used to provide error detection and correction for the write path. For example, the parity bit data can be calculated by performing an XOR operation on the received data block and the previously received data block. However, errors in a data block can cause errors in parity bit data calculations. Therefore, the parity bit data may also need to be corrected, which may introduce additional delays in the data path.

Contents of the invention

Embodiments of the present invention are directed to a system, method, and computer-readable instructions for a flash memory device to provide efficient write performance by accelerating write performance and hiding write path error correction delays in the event of write path errors. Data Recovery. Some embodiments may provide on-the-fly parity correction to allow user data that shares the same stripe as the data block with errors to be programmed into the flash memory before the erroneous data is corrected. Additionally, stalling of selected data may allow some independent data in different flash memory chips or planes to be programmed during write path error correction.

According to some embodiments, the device may include a write path error detector configured to detect whether data blocks received from a set of data blocks have errors. The device may further include a parity calculator configured to calculate parity bit data for the data block. The apparatus may further include a processor configured to execute instructions stored in the memory, wherein the instructions stored in the memory cause the processor to perform error correction on the data blocks having errors. The device may also include a write path manager. The write path manager can be configured to stop storing data blocks with errors into the flash memory buffer and allow subsequent data blocks received after the data block with errors to be stored during error correction of the data blocks with errors. Data blocks without errors are stored into the flash memory buffer. The parity calculator may further be configured to recalculate the parity bit data for the set of data blocks based on the error-free data blocks and the error-corrected data blocks. The device may be part of a back-end flash memory controller, where the back-end flash memory controller may be part of a flash memory controller coupled to the flash memory and the host system.

According to some embodiments, a method may include receiving, by a flash memory controller coupled to the flash memory, one data block at a time from a first set of data blocks stored in volatile memory. The volatile memory may store multiple sets of data blocks including a first set of data blocks and a second set of data blocks. The method further includes detecting an error in one of the received data blocks and calculating parity data based on the one or more data blocks received from the first set of data blocks. The method further includes stopping storing data blocks with errors into the flash memory buffer and performing error correction on the data blocks with errors. The method further includes storing subsequent error-free data blocks received after the data block with errors into the flash memory buffer during error correction of the data block with errors.

The method may further include determining that errors in the data blocks with errors have been corrected, and recalculating parity data of the first set of data blocks based on the error-corrected data blocks and the error-free data blocks. The method further includes storing the recalculated parity data for the first set of data blocks and the error-corrected data blocks in a flash memory buffer.

Some embodiments relate to a flash memory controller including one or more processors configured to implement various methods. Other embodiments relate to computer-readable media having instructions stored thereon that, when executed by a processor, perform processes.

Description of the drawings

Figure 1 is a simplified block diagram illustrating a system including a host system coupled to a flash memory device in accordance with some embodiments.

FIG. 2 is an example diagram of a configuration of a flash memory.

3 illustrates a block diagram of a flash memory controller that may provide improved write performance in the event of write path errors in some embodiments.

Figure 4 shows an example diagram of processing a data block with errors by a flash memory controller in one embodiment.

Figure 5 shows an example diagram for processing an error-free data block after a data block with errors in one embodiment.

Figure 6 shows an example diagram for storing error corrected data in one embodiment.

Figure 7 shows an example diagram for storing error-corrected data blocks and error-free data blocks in flash memory in one embodiment.

Figure 8 shows an example diagram of calculating partial parity bit data for a data block with errors in one embodiment.

Figure 9 shows an example diagram for storing partial parity data for a strip in flash memory in one embodiment.

Figure 10 shows an example diagram of storing data blocks of a second stripe while correcting errors in the data blocks of a first stripe in one embodiment.

Figure 11 shows an example diagram of correcting errors in the data blocks of the first stripe while continuing to store the data blocks of the second stripe in one embodiment.

Figure 12 illustrates a method performed by a flash memory controller to improve write performance in the event of a write path error.

Detailed ways

Certain aspects and embodiments of the present disclosure are provided below. Some of these aspects and embodiments may be applied independently, and some of them may be applied in combinations that will be apparent to those skilled in the art. In the following description, for purposes of illustration, specific details are set forth in order to provide a thorough understanding of the embodiments. It may be apparent, however, that various embodiments may be practiced without these specific details. The drawings and descriptions are not limiting.

The following description provides examples and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with a useful description for implementing the exemplary embodiments. It will be understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the claims.

Specific details are given in the following description to provide a thorough understanding of the embodiments. However, one of ordinary skill in the art will understand that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form so as not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

Furthermore, it should be noted that various embodiments may be described as processes depicted as flowcharts, program diagrams, data flow diagrams, structural diagrams, or block diagrams. Although a flowchart can describe operations as a sequential process, many operations can be performed in parallel or simultaneously. Additionally, the order of operations can be rearranged. A process terminates after its operations are complete, but there may be additional steps not included in the diagram. A process can correspond to a method, function, program, subroutine, subroutine, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or to the main function.

The term "computer-readable medium" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing, or carrying instructions and/or data. Computer-readable media may include non-transitory media in which data may be stored and do not include carrier waves and/or transient electronic signals that propagate wirelessly or over wired connections. Examples of non-transitory media may include, but are not limited to, magnetic disks or tapes, optical storage media such as compact disks (CDs) or digital versatile disks (DVDs), flash memory, memory or memory devices. A computer-readable medium may have code and/or machine-executable instructions stored thereon, which instructions may represent a process, function, subroutine, program, routine, subroutine, module, software package, class, or any instruction , data structure or combination of program statements. A code segment may be coupled to another code segment or hardware circuitry by passing and/or receiving information, data, parameters, parameters, or storage. Information, arguments, parameters, data, etc. may be communicated, forwarded, or sent by any suitable means including memory sharing, message passing, token passing, network transmission, and the like.

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, program code or code segments for performing necessary tasks (eg, a computer program product) may be stored in a computer-readable medium or a machine-readable medium. The processor can perform necessary tasks.

In the following detailed description and the accompanying drawings, the same reference numerals are sometimes used to refer to structural elements of similar or identical structure to provide a better understanding of the nature and advantages of the present invention.

Embodiments of the present invention relate to systems, methods, and computer-readable instructions for quickly recovering data from write path errors in the data. The methods, systems, and computer-readable media described in the disclosure may be used, for example, in NAND flash memory devices.

The embodiments disclosed herein are not limited in scope to the specific embodiments described herein. Various modifications to the embodiments of the invention in addition to those described herein will be apparent to those of ordinary skill in the art based on the foregoing description and accompanying drawings. Furthermore, while some embodiments of the invention have been described in the context of particular implementations in particular environments for particular purposes, those of ordinary skill in the art will recognize that their usefulness is not so limited and that embodiments of the invention may Implemented beneficially in many environments for many purposes.

Certain aspects of the present disclosure provide methods for improving write performance of flash memory devices when write path errors exist. When an error of a data block is detected in the write path, some embodiments may cause the data block with the error to stop being stored in the flash memory buffer and may perform error correction on the data block with the error. Embodiments may also allow subsequently received error-free data blocks to be programmed into the flash memory buffer during correction of data block errors.

1 is a simplified block diagram illustrating a system including a host system coupled to flash memory via a flash memory controller. Figure 2 illustrates a configuration of a flash memory in accordance with some embodiments. Figure 3 shows an example block diagram of a back-end flash memory controller in one embodiment. Figures 4-11 illustrate different steps for improving write performance in the presence of write path errors in some embodiments. Figure 12 illustrates a method performed by a flash memory controller in one embodiment.

FIG. 1 is a simplified block diagram illustrating a system 100 including a host system 102 coupled to a flash memory 104 via a flash memory controller 106 . In some implementations, flash memory controller 106 and flash memory 104 may be part of a flash memory device (not shown). Flash memory controller 106 may be implemented as a system on a chip (SoC), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or any suitable circuit.

Host system 102 may include any suitable hardware device, software application, or combination of hardware and software. In some embodiments, host system 102 may include a host-side controller (not shown). Host system 102 may send requests to flash memory controller 106 to access flash memory 104 , such as to write data to or read data from flash memory 104 .

Flash memory controller 106 may be configured to receive various commands from host system 102 and communicate with flash memory 104 based on these commands. Flash memory controller 106 may cause flash memory 104 to perform various operations based on commands received from host system 102 . For example, host system 102 may communicate with flash memory controller 106 to program, erase, read, or trim portions of flash memory 104 . Flash memory controller 106 may include volatile memory 108 and back-end flash controller 112 . Write path 110 may provide a data path or channel to program flash memory 104 or write data to flash memory 104 via back-end flash controller 112 . The term "channel" can be used to refer to the path between two physical components. It should be understood that channels may include other physical components.

Volatile memory 108 may include any type of static random access memory (SRAM), dynamic random access memory (DRAM), or any other type of memory that may require power to retain its data. Volatile memory 108 may be used to store data 108a received from host system 102 for writing to flash memory 104 by backend flash controller 112 . In this specification, data 108a may also be referred to as "user data."

In some instances, errors may be introduced into write path 110 before data 108a is written to flash memory 104 . For example, errors may occur due to internal errors in volatile memory 108 or during the transfer of data 108a from volatile memory 108. Therefore, it is desirable to protect the data path between volatile memory 108 and back-end flash controller 112. In some examples, an error correction code (ECC) approach may be implemented to protect the data path between volatile memory 108 and back-end flash controller 112 using simple error correction parity bit data. For example, parity bit 108b may be added to data 108b, which may be used to provide ECC detection and correction in the event data 108b is corrupted in write path 110.

In some implementations, flash memory 104 may be any non-volatile memory, such as NAND flash memory. In some implementations, flash memory 104 may be a NOR flash memory configured to interact externally as NAND flash memory. Flash memory 104 may be designed to store data without a continuous or substantially continuous supply of external power. In some examples, flash memory 104 may be used for secondary data storage, such as in a computer system such as a laptop computer. In some such examples, flash memory controller 106 may interact with multiple flash memories. In some embodiments, other non-volatile memories may be used instead of or in addition to flash memory 104 . Examples may include read-only memory (ROM), masked ROM (MROM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), ferroelectric RAM (F -RAM), magnetoresistive RAM (RAM), polymer-based organic memory, holographic memory, phase change memory, etc.

In some implementations, flash memory 104 may include multiple blocks, with blocks including pages. Multiple blocks may include blocks that may be on different planes, such as blocks on plane 0 or plane 1. Plane 0 may include the first group of blocks and plane 1 may include the second group of blocks. Each flash memory die may have a different number of planes. Multiple such dies may be included in a flash memory such as flash memory 104 . In some implementations, main blocks may be used to store data, and extension blocks may be used to store auxiliary information, such as error correction codes or parity bits.

Backend flash controller 112 may include a write path error detector 114 and a write path error corrector 116 . Write path error detector 114 may be configured to detect errors in data 108a. For example, write path error detector 114 may use parity data 108b associated with data 108a to perform ECC detection. The write path error corrector 116 may be configured to perform ECC correction to correct data with errors. Any ECC algorithm such as Reed-Solomon code, Hamming code, Bose-Chadhuri-Hokungam (BCH) code, Low Density Parity Check (LDPC) or any other suitable algorithm can be used to implement Data protection of data stored in flash memory 104.

When backend flash controller 112 receives data 108a, write path error detector 114 can determine whether there are any errors in data 108a based on parity bits 108b. If there are no errors in data 108a, the data can be written to flash memory 104. If write path error detector 114 detects an error in data 108a, write path error corrector 116 may perform error correction on data 108a. Error correction can be performed by software or firmware. In most cases, since the error rate in write path 110 is relatively low, error correction can be performed in software to save chip area and power. However, error correction-based software can be time-consuming and can introduce additional delays in the data path.

In some implementations, data protection methods, such as RAID (Redundant Array of Inexpensive Disks), may be used to recover data stored in flash memory 104 when the data on the plane or die is corrupted. For example, RAID can provide data redundancy and error correction using mirroring, data striping, parity, or a combination thereof. In some embodiments, a set of data blocks may be segmented into different stripes such that each stripe may represent user data on multiple dies or planes, and parity on one or more dies and planes. Verification data. Parity data can be generated by performing an XOR operation on the user data in the stripe. In some implementations, each strip may represent a superblock. For example, a super block may include a first block in a first die, a second block in a second die, a third block in a third die, and so on. When data on one die or plane is corrupted and cannot be corrected, other data in the same strip on a different die or plane can be read. An XOR operation can be performed on the read data and the parity bit data to recover the data for the uncorrectable die or plane. Further explanation will be given with reference to FIG. 2 .

FIG. 2 is an example diagram of the structure of the flash memory 104. It should be noted that the structure 200 shown in FIG. 2 is for illustrative purposes only and the actual physical structure of the flash memory 104 may differ materially from that described.

In some implementations, flash memory 104 may include multiple flash memory dies flash 1104a, flash2 104b, flash3 104c, flash4 104d, flash5 104e, ... flash N 104n. Each flash memory die Flash 1 104a through Flash N 104n may include multiple planes. Each plane can store multiple data blocks. In some implementations, a separate flash memory die, such as parity flash 206, may be used to store parity for data stored on Flash 1 104a through Flash N 104n.

In some implementations, the first stripe 202 may represent multiple data blocks, such as data01, data02, data03, data04, data05...data0n. The first stripe 202 may also include blocks for parity, such as data zeros. For example, data 0 may represent the parity bit data of the data block associated with the first stripe 202, such as data 01 - data 0n. Similarly, the second stripe 204 may represent a plurality of data blocks, such as data 11, data 12, data 13, data 14, data 15, ... data 1n. The second stripe 204 may also include blocks for parity, such as Data 1. Data 1 may represent the parity bit data of the data block associated with the second stripe 204 (eg, Data 11 - Data 1n). In some implementations, a first block from each strip can be stored on a first die, a second block from each strip can be stored on a second die, and so on. For example, data 01 and data 11 can be stored on flash memory 1 104a, data 02 and data 12 can be stored on flash memory 2 104b, data 03 and data 13 can be stored on flash memory 3 104c, and data 04 and data 14 can be stored on flash memory 104c. On 4 104d, data 05 and data 15 may be stored on flash memory 5 104e, and data 0n and data 1n may be stored on flash memory N 104n. In some implementations, Data 0 and Data 1 of parity data may be stored on separate parity flash memory 206 .

In some embodiments, Data 01 and Data 11 may be stored in different planes on Flash 1 104a. Similarly, Data 02 and Data 12 may be stored in different planes on Flash 2 104b, Data 03 and Data 13 may be stored in different planes on Flash 3 104c, and Data 04 and Data 14 may be stored in different planes on Flash 4 104d. Of the planes, data 05 and data 15 may be stored in different planes on flash memory 5104e, and data 0n and data 1n may be stored in different planes on flash memory N104n.

In some cases, all data in a stripe can be written to different dies or planes in parallel. For example, each user data (eg, data 01 - data 0n) and parity data (eg, data 0) in first stripe 202 may be written in parallel to flash memory 1104a - flash memory N 104n in flash memory 104 Parity bit flash memory 206. However, if a write path error is detected in a data block received from the host system 102, the back-end flash controller 112 may typically halt any subsequent data blocks received from the host system 102 that would follow the data block received with the error. The data blocks are written to the flash memory 104. Backend flash controller 112 may first correct the write path errors, recalculate parity, and then allow subsequent data blocks received from host system 102 to be written to flash memory 104 . However, during this time, other data on the strip cannot be written to flash memory 104, which may introduce additional delays in the data path.

As an example, the backend flash controller 112 may receive one data block at a time from the volatile memory 108, such as Data01, Data02, Data03, ... Data0n. As each data block is received, the parity bit data can be calculated by performing an XOR operation on one or more received data blocks. If Data 02 has an error, the backend flash controller 112 may stop writing Data 03, Data 04, ... Data On to the flash memory 104 until the error in Data 02 is corrected, which may cause additional delays. Furthermore, due to an error in Data 02, the parity bit Data 0 calculated by performing an XOR operation on Data 01 and Data 02 may include an erroneous value and may need to be recalculated. Recalculating parity bits can further reduce performance.

Certain embodiments of the invention may speed data recovery by allowing error-free data to be written to flash memory while data with errors is being corrected. For example, when an error is detected in a data block, writing of the data block with the error and associated parity bit data to the flash memory 104 is stopped until the error is corrected. Although errors are corrected in the block with errors, other error-free blocks associated with different dies or planes can be programmed. When errors are corrected, the parity bits for the data blocks of the stripe can be recalculated. The corrected data blocks and recalculated parity data may be written to flash memory 104 . This is further explained with reference to Figure 3 .

Figure 3 shows a block diagram of a flash memory controller 300 that may provide improved write performance in the event of write path errors in some embodiments.

Flash memory controller 300 may include volatile memory 108 and backend flash controller 302 . Note that, for simplicity, flash memory controller 300 may include additional or different components not shown in FIG. 3 . For example, in some implementations, flash memory controller 300 may include a host interface (not shown) to communicate with host system 102 via interface 118 . Volatile memory 108 may be internal or external to flash memory controller 300 . For example, in some implementations, volatile memory 108 may be part of system memory (eg, DRAM).

Volatile memory 108 may store sets of data blocks received from host system 102 via interface 118 . As an example, first stripe 202 may represent a first set of data blocks including Data01, Data02, Data03, Data04, and Data05 received from host system 102. Buffer 0 may be used to store parity data for the data blocks in the first stripe 202 . Similarly, second stripe 204 may represent a second set of data blocks including data 11 , data 12 , data 13 , data 14 , and data 15 received from host system 102 . Buffer 1 may be used to store parity data for the data blocks in the second stripe 204 .

In some embodiments, each of Data01 - Data05 in first stripe 202 may include corresponding parity bit data associated therewith, which may be similar to parity bits 108b discussed with reference to FIG. 1 . Similarly, each of data 11 - data 15 may include corresponding parity bit data associated therewith that may be similar to parity bit 108b. The parity bit data associated with each data block may be used by write path error detector 114 to detect errors in a given data block. For example, the error may be due to a storage error in volatile memory 108 or an error due to a transmission error in write path 110 .

In addition to write path error detector 114 as discussed with reference to FIG. 1 , backend flash controller 302 may include write path manager 304 , parity calculator 306 , processor 308 , memory 312 and flash Memory buffer 310. Note that some or all components of backend flash controller 302 may be part of the device.

Write path manager 304 may be configured to receive data one block at a time from volatile memory 108 via write path 110 for writing to flash memory 104 . For example, write path manager 304 may receive data 01, data 02, data 03, data 04, or data 05 for first stripe 202 or data 11, data 12, data 13, data 14, or data for second stripe 204. Data 15. Write path manager 304 may provide received data blocks to write path error detector 114 and parity calculator 306 . If an error is detected in a received data block by the write path error detector 114, the write path manager 304 may further be configured to stop storing the data block with the error into the flash memory buffer 310. The stop data may indicate that the data block is stopped or not allowed to be stored in flash memory buffer 310 . The stops selected by write path manager 304 may allow some independent data in different flash memory dies or planes to be programmed during write path error correction. For example, the write path manager 304 may also be configured to store subsequent error-free data received after receiving a data block with an error into the flash memory buffer 310 during error correction of the data block with an error. Therefore, some embodiments may provide efficient data recovery in the event of write path errors by accelerating write performance and hiding write path error correction delays.

Parity calculator 306 may be configured to calculate parity bit data for data blocks received from one or more of a set of data blocks. For example, the set of data blocks may include data blocks in a stripe such as first stripe 202 or second stripe 204 . Parity calculator 306 may include parity buffer 306a. Parity buffer 306a may be configured to store parity bit data calculated by parity calculator 306. In some embodiments, parity calculator 306 may calculate New parity bit data. Data blocks from the set of data blocks may include error-free data blocks received from volatile memory 108 or error corrected data blocks by error corrector 116 . As an example, parity buffer 306a may initially be all zeros. When data 01 is received and no errors are found in data 01 , the parity calculator 306 may calculate the parity of data 01 by performing an XOR operation on the value of data 01 and the data stored in the parity buffer 306 a Check digit data (e.g., all zeros). The calculated parity bit data may be stored in the parity buffer 306a for use in calculating the parity bit of the next data, for example, data 02. For example, when Data 02 is received and no errors are found in Data 02, the parity calculator 306 may perform an XOR by performing an XOR on the value of Data 02 and the parity bit data previously stored in the parity buffer 306a. Operation to calculate new parity bit data (for example, parity bit data for data 01).

If an error is found in any data block received from volatile memory 108, the parity bit data calculated by parity calculator 306 may not be accurate and therefore parity buffer 306a may store incorrect parity bit data. In this case, the write path manager 304 may be configured to read the data block with the error into the parity buffer 306a again. This may cause the parity calculator 306 to perform an XOR operation again with the same data with errors to correct the erroneous parity bit data stored in the parity buffer 306a. Once the parity bit data in the parity buffer 306a has been restored to the correct parity bit data, the parity calculator 306 can continue to calculate all of the data blocks received from the volatile memory 108. Parity bit data for error-free data blocks. Once the errors in the data block have been corrected, the parity calculator 306 may be further configured to calculate parity bit data for the error-corrected data block and the error-free data block stored in the parity buffer 306a . Once the parity data for the set of data blocks has been calculated, the parity data may be sent to the flash memory buffer 310 along with the error-corrected data blocks to be written to the flash memory 104 .

Processor 308 may be configured to execute instructions stored in memory 312 . Memory 312 may include SRAM, DRAM, SDRAM, ROM, EEPROM, or any suitable memory configured to store instructions executable by processor 308 . In some embodiments, memory 312 may include a non-transitory computer-readable medium configured to store instructions for performing error correction on data blocks with errors. For example, error corrector 116 may be implemented as software as part of memory 312 . In some implementations, error corrector 116 may perform ECC correction to correct errors in data blocks with errors. In some embodiments, the instructions stored in memory 312 further cause the processor 308 to determine that errors in the data block have been corrected and to store the recalculated parity bit data and the error-corrected data block to the flash. in memory buffer 310.

Flash memory buffer 310 may be configured to receive one data block at a time from a group of data blocks that includes parity data for the group of data blocks. Once all data blocks of the data block group have been received by flash memory buffer 310, the data blocks may be sent to flash memory 104 for storage in flash memory 104, and flash memory buffer 310 may be Released to store the next set of data blocks.

FIG. 4 shows an example diagram for processing data blocks with errors by flash memory controller 302 in one embodiment. Note that, for the sake of simplicity, FIG. 4 only shows certain components of the backend flash controller 302.

In some implementations, back-end flash controller 302 may receive data one block at a time from volatile memory 108 . For example, in one case, data 01 may be received by backend flash controller 302. Write path manager 304 may forward data 01 to both write path error detector 114 and parity calculator 306 . If the write path error detector 114 detects no errors in data 01, error-free data 01 may be stored in the flash memory buffer 310. The parity calculator 306 may calculate the parity bit data of the data 01 by performing an XOR operation on the data 01 and the contents of the parity buffer 306a. As an example, parity buffer 306a may be reset to all zeros before storing the first data block for each set of data blocks. Therefore, parity buffer 306a can now store data 01 as parity bit data. The calculated parity bit data may be written back into the parity buffer 306a.

Next, data 02 may be received by the backend flash controller 302. Write path manager 304 may forward data 02 to both write path error detector 114 and parity calculator 306. If write path error detector 114 detects an error in data 02, write path manager 304 may stop storing erroneous data 02 into flash memory buffer 310. However, the parity calculator 306 may calculate the parity bit data by performing an XOR operation on the data 02 with the error and the previously stored data 01 as the parity bit data, as follows:

(Data 01) XOR (Data 02) Equation (1)

Therefore, parity buffer 306a may store incorrect parity bit data calculated using equation (1). Error corrector 116 may perform ECC correction to correct errors in data 02. In some embodiments, data 02 with errors may be read again from volatile memory 108 into parity buffer 306a to perform a parity check to correct the parity bit data stored in parity buffer 306a. Parity calculator 306 may be configured to recalculate the parity bit data by performing another XOR operation on the corrupted data 02 and the incorrect parity bit data stored in parity buffer 306a, as follows Shown:

(Data 01) XOR (Data 02) XOR (Data 02) Equation (2)

Parity buffer 306a can now store the correct parity bit data (eg, data 01) calculated using equation (2). In some embodiments, write path manager 304 may allow subsequently received error-free data to be stored in flash memory buffer 310 during error correction of data 02 with errors. This discussion is further discussed with reference to Figure 5 .

Figure 5 shows an example diagram of an error-free data block after processing a data block with errors in one embodiment. Note that for the sake of simplicity, only certain components of the back-end flash controller 302 are shown in FIG. 5 .

In some embodiments, write path manager 304 may allow subsequently received error-free data blocks to be stored into flash memory buffer 310 during error correction of data blocks with errors. As discussed with reference to Figure 4, during error correction of Data 02, some embodiments may allow error-free data blocks received after corrupted Data 02 to be stored into the flash memory buffer 310.

When errors in data 02 are corrected by error corrector 116, data 03 may be received by backend flash controller 302. Write path manager 304 may forward data 03 to both write path error detector 114 and parity buffer 306a. If no errors are detected in data 03 by write path error detector 114 , write path manager 304 may forward data 03 for storage in flash memory buffer 310 . The parity calculator 306 may recalculate the parity bit data by performing an XOR operation on the received data 03 and the data 01 previously stored in the parity buffer 306a, as follows:

(Data 03) XOR (Data 01) Equation (3)

Similarly, after processing data 03, backend flash controller 302 may receive data 04. Write path manager 304 may forward data 04 to both write path error detector 114 and parity calculator 306 . If write path error detector 114 detects no errors in data 04 , write path manager 304 may forward data 04 for storage in flash memory buffer 310 . The parity calculator 306 may recalculate the parity data by performing an XOR operation on the received data 04 and the parity data stored in the parity buffer 306a, as follows:

(Data 04) XOR (Data 03) XOR (Data 01) Equation (4)

Next, after processing data 04, the backend flash controller 302 may receive data 05. Write path manager 304 may forward data 05 to both write path error detector 114 and parity calculator 306. If write path error detector 114 detects no errors in data 05 , write path manager 304 may forward data 05 for storage in flash memory buffer 310 . Parity calculator 306 may recalculate the parity data by performing an XOR operation on data 05 and the parity data stored in parity buffer 306a, as follows:

(Data 05) XOR (Data 04) XOR (Data 03) XOR (Data 01) Equation (5)

If Data 02 has been corrected during processing of Data 03 , Data 04 , and Data 05 , write path manager 304 may forward corrected Data 02 for storage in flash memory buffer 310 , as discussed with reference to FIG. 6 of.

Figure 6 shows an example diagram for storing error corrected data in one embodiment. Note that for the sake of simplicity, only certain components of the back-end flash controller 302 are shown in FIG. 6 .

Error corrected data 02 may be received by parity calculator 306 . The parity calculator 306 may calculate the parity bit data "parity" of the first stripe 202 by performing an XOR operation on the error-corrected data 02 and the parity bit data stored in the parity buffer 306a. Check bit 0", as shown below:

(Error corrected data 02) XOR (data 05) XOR (data 04) XOR (data 03) XOR (data 01) Equation (6)

Write path manager 304 may forward parity bit 0 and error corrected data 02 for first stripe 202 stored in flash memory buffer 310 . Once all data blocks in the first stripe 202 are stored in the flash memory buffer 310 with parity bit 0, the corresponding memory space in the volatile memory 108 may be freed.

FIG. 7 shows an example diagram for storing error-corrected data blocks and error-free data blocks in flash memory 104 in one embodiment. Note that for the sake of simplicity, only certain components of the back-end flash controller 302 are shown in FIG. 7 .

As shown in FIG. 7 , the error-corrected data block data 02 and error-free data block data 01 , 03 , 04 , 05 of the first stripe 202 may be released from the flash memory buffer 310 and may be stored in the flash memory buffer 310 . in memory 104. Referring back to Figure 2, data 01 can be stored in flash memory 1 104a, corrected data 02 can be stored in flash memory 2 104b, data 03 can be stored in flash memory 3 104c, data 04 can be stored in flash memory 4 104d, and data 05 can stored in flash memory 5104e, and parity bit 0 may be stored in parity bit flash memory 206. If the error in Data 02 has not been corrected, and all other data blocks in the first stripe 202 are already stored in the flash memory 104, the data blocks of the other stripes may be sent to the flash memory buffer 310, as discussed with reference to Figure 8.

Figure 8 shows an example diagram of calculating partial parity bit data for a data block with errors in one embodiment. Note that for the sake of simplicity, only certain components of the back-end flash controller 302 are shown in FIG. 8 .

As shown in Figure 8, if the error in data 02 has not been corrected and all other data blocks in the first stripe 202 are already stored in the flash memory buffer 310, embodiments may allow the second stripe 204 to be sent data block. In one embodiment, the portion of the parity bit data stored in the parity buffer 306a of the first stripe 202 may be stored in the volatile memory 108. For example, the partial parity data can be calculated using Equation (5) using Data01, Data03, Data04, and Data05. This may allow the parity buffer 306a to be used to store the parity bit data for the second stripe 204 to be freed. Embodiments may further allow the data blocks of the first stripe 202 to be stored in the flash memory 104 as discussed with reference to FIG. 9 .

Figure 9 shows an example diagram for storing partial parity data of a stripe in flash memory in one embodiment. Note that for the sake of simplicity, only certain components of the back-end flash controller 302 are shown in FIG. 9 .

As shown in FIG. 9 , if the error in Data 02 has not been corrected, all other data of the first stripe 202 (eg, Data 01 , Data 03 , Data 04 and Data 05 ) may be sent for storage in the flash memory 104 in without sending data 02 with error. This may allow memory space for the partial data to be freed in volatile memory 108 while the partial parity data is stored in volatile memory 108 until the error in Data 02 is corrected. Some embodiments may allow data for the second stripe 204 to be sent, as discussed with reference to FIG. 10 .

Figure 10 shows an example diagram for storing data blocks of a second stripe while correcting errors in the data blocks of the first stripe in one embodiment. Note that for the sake of simplicity, only certain components of the back-end flash controller 302 are shown in FIG. 10 .

As shown in Figure 10, some embodiments may allow error-free data blocks of the second stripe 204 to be stored into the flash memory buffer 310 if the errors in data 02 have not been corrected. For example, write path manager 304 may forward data 11 to both write path error detector 114 and parity calculator 306. If write path error detector 114 detects no errors in data 11 , write path manager 304 may forward data 11 for storage in flash memory buffer 310 . The parity calculator 306 may calculate the parity bit data of the received data 11 and store the parity bit data in the parity buffer 306a.

Figure 11 shows an example diagram of correcting errors in the data blocks of the first stripe while continuing to store the data blocks of the second stripe in one embodiment. Note that for the sake of simplicity, only certain components of the back-end flash controller 302 are shown in FIG. 11 .

As shown in Figure 11, if the error in data 02 has not been corrected, some embodiments may stop data from being on the same plane or on the same die as data 02 with the error for storage in flash memory buffer 310. Send data chunks in another set of data chunks. As shown in FIG. 11 , data 12 may be stopped from being stored in flash memory buffer 310 , but embodiments may allow subsequent data after data 12 to be sent to flash memory buffer 310 . Therefore, data 13 may be stored in flash memory buffer 310. At any time, when the errors in Data 02 have been corrected, Data 02 and Data 12 may be stored in flash memory 104 along with the recalculated parity bits. Without departing from the scope of the disclosed technology, embodiments of the present invention may also be applied to improve write performance in the case of write path errors with multiple data blocks.

Figure 12 illustrates a method 1200 performed by flash memory controller 300 to improve write performance in the event of write path errors in one embodiment.

In step 1202, the flash memory controller may receive one data block at a time from a first set of data blocks stored in volatile memory. The volatile memory may store multiple sets of data blocks including a first set of data blocks and a second set of data blocks. Referring back to FIG. 3 , backend flash controller 302 may receive one data block at a time from a first set of data blocks (eg, Data01 - Data05 ) of first stripe 202 stored in volatile memory 108 . Volatile memory 108 may also store a second set of data blocks for the second stripe 204 (eg, Data 11 - Data 15). Write path manager 304 may forward each received data block to write path error detector 114 and parity calculator 306.

In step 1204, the backend flash controller 302 may detect an error in one of the received data blocks. For example, write path manager 304 may receive first data block data 01 and may forward data 01 to write path error detector 114 and parity calculator 306 . As discussed with reference to FIG. 4 , write path error detector 114 may not detect an error in received data block Data 01 , and Data 01 may be stored in flash memory buffer 310 . The parity calculator 306 may calculate the parity bit data by performing an XOR operation on data 01 and the contents of the parity buffer 306a (eg, zero), and may store the calculated parity bit data in the parity in the check buffer 306a. Next, write path manager 304 may receive second data block data 02 and may forward data 02 to write path error detector 114 and parity calculator 306 . As discussed with reference to FIG. 5, write path error detector 114 may detect errors in received data block data 02. For example, write path error detector 114 may use ECC data associated with data 02 to detect errors.

In step 1206, the backend flash controller 302 may calculate parity data based on the one or more data blocks received from the first set of data blocks. The parity calculator 306 may calculate the parity bit data based on the received data blocks Data01 and Data02. For example, the parity calculator 306 may perform an XOR operation on the received data block data 02 and the parity bit data (eg, data 01) stored in the parity buffer 306a, as expressed in equation (1) Show. Parity calculator 306 may store the calculated parity bit data in parity buffer 306a. In some implementations, steps 1204 and 1206 may be performed in parallel.

In step 1208, the backend flash controller 302 may stop storing data blocks with errors in the flash memory buffer. As discussed with reference to FIG. 3 , write path manager 304 may stop storing data 02 with errors in flash memory buffer 310 to avoid writing corrupted data in flash memory 104 .

In step 1210, the backend flash controller 302 may perform error correction on the data blocks with errors. As discussed with reference to FIG. 3, error corrector 116 may perform ECC correction to correct errors in Data 02. Additionally, parity correction may be performed to correct the data stored in the parity buffer 306a by reading the data 02 with errors into the parity buffer 306a again and recalculating the parity bit data using Equation (2) parity bit data in .

In step 1212, the backend flash memory controller 302 may store subsequent data blocks received after the data block with errors into the flash memory buffer during error correction of the data block with errors. As discussed with reference to FIG. 5 , during error correction of Data 02 , subsequent data blocks Data 03 , Data 04 , and Data 05 may be received from volatile memory 108 . If no error is detected in any one of Data 03, Data 04, or Data 05, Data 03, Data 04, and Data 05 may be stored in the flash memory buffer 310. Thus, embodiments may minimize stalling of data in the event of a write path error by limiting stalling to data blocks with errors and allowing data blocks without errors to pass. Therefore, selected stopping can improve write performance when write path errors occur.

If the error in Data 02 has been corrected during subsequent storage of Data 03, Data 04, and Data 05 in the flash memory buffer 310, the parity calculator 306 may be based on the error-corrected Data 02, error-free Data 03, Data 04 and Data 05 recalculate the parity bit data of the first group of data blocks. The recalculated parity data and the error-corrected data block 02 of the first set of data blocks may be stored in the flash memory buffer 310 . In a next step, the recalculated parity data and error corrected data block 02 of the first set of data blocks may be sent for storage in flash memory 104 and the flash memory buffer 310 may be released to Store the next set of data blocks.

If the error in Data02 has not been corrected during subsequent storage of Data03, Data04, and Data05 in flash memory buffer 310, Data03, Data04, and Data05 may be sent for storage in flash memory 104 without sending corrupted data 02. The parity calculator 306 may recalculate the partial parity bit data of the first group of data blocks based on data 03, data 04, and data 05. As discussed with reference to FIG. 8 , partial parity data for the first set of data blocks without data 02 may be stored in volatile memory 108 . Some embodiments may allow data blocks from the second set of data blocks that do not share the same die or plane as Data 02 to be stored into the flash memory buffer 310 during error correction of Data 02. When the errors in data 02 have been corrected, the parity calculator 306 may recalculate the parity of the first set of data blocks based on the error-corrected data 02 and the partial parity bit data stored in the volatile memory 108 Check digit data. The recalculated parity data and error-corrected data 02 of the first set of data blocks may be stored in the flash memory buffer 301 to be sent to the flash memory 104 .

Therefore, some embodiments may allow error-free data blocks to be sent for storage in flash memory during error correction of data blocks with errors. This accelerates write performance for user data stored in flash memory. Additionally, performing an on-the-fly parity check before the erroneous data is corrected to allow user data that shares the same stripe as the data block with the error to be programmed can hide the latency of write error correction. Some embodiments may provide selective stop data to allow several independent blocks of data on different planes or dies to be programmed during write path error correction.

Claims (20)

1. A flash memory device, comprising:

a write path error detector configured to detect whether a data block received from a set of data blocks has an error;

a parity calculator configured to calculate parity bit data of the data block;

a processor configured to execute instructions stored in a memory, wherein the instructions stored in the memory cause the processor to perform error correction on a block of data having an error; and

a write path manager configured to:

Stopping storing the data block with the error in a flash memory buffer; and

allowing subsequent error-free data blocks received after the error-bearing data block to be stored into the flash memory buffer during error correction of the error-bearing data block,

wherein the parity calculator is further configured to recalculate the parity bit data of the set of data blocks based on the error-free data blocks and error-corrected data blocks.

2. The flash memory device of claim 1, wherein the set of data blocks is stored in a volatile memory communicatively coupled to the flash memory device.

3. The flash memory device of claim 2, wherein the volatile memory receives the set of data blocks from a host system communicatively coupled to the volatile memory for storage in a flash memory coupled to the flash memory device.

4. The flash memory device of claim 1, wherein the parity calculator further comprises a parity buffer configured to store the parity bit data.

5. The flash memory device of claim 4, wherein the parity calculator calculates the parity bit data for the data block by performing an exclusive-or operation on the received data block and the contents of the parity buffer.

6. The flash memory device of claim 4, wherein the recalculated parity bit data is stored in the parity buffer.

7. The flash memory device of claim 1, wherein the write path manager is further configured to allow error corrected data blocks and recalculated parity data to be stored into the flash memory buffer.

8. The flash memory device of claim 1, wherein the flash memory device is communicatively coupled to a flash memory, and wherein the instructions stored in the memory further cause the processor to send error corrected data blocks, the error free data blocks, and recalculated parity bit data stored in the flash memory buffer to program the flash memory.

9. The flash memory device of claim 1, wherein the flash memory buffer and the flash memory device are part of a back-end flash memory controller.

10. A method of operating a flash memory device, comprising:

receiving, by a flash memory controller coupled to a flash memory in the flash memory device, one data block at a time from a first set of data blocks stored in a volatile memory, wherein the volatile memory stores a plurality of sets of data blocks including the first set of data blocks and a second set of data blocks;

detecting, by the flash memory controller, an error of one of the received data blocks;

calculating, by the flash memory controller, parity bit data based on one or more data blocks received from the first set of data blocks;

stopping, by the flash memory controller, storing the data block having the error in a flash memory buffer;

performing error correction on the data block with the error by the flash memory controller; and

during error correction of the data block with errors, a subsequent data block without errors received after the data block with errors is stored by the flash memory controller into the flash memory buffer.

11. The method of claim 10, the method further comprising:

Determining, by the flash memory controller, that the error in the block of data having the error has been corrected;

recalculating, by the flash memory controller and based on the error corrected data blocks and the error free data blocks, the parity bit data for the first set of data blocks; and

the recalculated parity data for the first set of data blocks and the error corrected data blocks are stored in the flash memory buffer by the flash memory controller.

12. The method of claim 11, the method further comprising:

the parity data, the error corrected data block, and the error free data block of the first set of data blocks are transmitted by the flash memory controller for storage in the flash memory.

13. The method of claim 10, the method further comprising:

determining, by the flash memory controller, that the errors in the data blocks with errors have not been corrected after all of the data blocks are received from the first set of data blocks; and

the first set of data blocks of the error-free data blocks are sent by the flash memory controller for storage in the flash memory.

14. The method of claim 13, the method further comprising:

recalculating, by the flash memory controller, the parity data for the first set of data blocks without the error corrected data block; and

the recalculated parity data for the first set of data blocks is stored by the flash memory controller into the volatile memory.

15. The method of claim 14, the method further comprising:

receiving, by the flash memory controller, a data block from the second set of data blocks of the plurality of data blocks stored in the volatile memory;

determining, by the flash memory controller, that the data block from the second set of data blocks does not include an error; and

the data blocks from the second set of data blocks are stored into the flash memory buffer by the flash memory controller.

16. The method of claim 10, wherein the flash memory comprises a plurality of flash memory dies, and wherein individual data blocks in each set of data blocks are stored in a same flash memory die or a same flash memory plane.

17. The method of claim 16, wherein the data blocks sharing the same flash memory die or the same flash memory plane and the data blocks having errors are stopped from being stored in the flash memory buffer until the errors are corrected.

18. The method of claim 10, the method further comprising:

the parity bit data is stored in a parity buffer, wherein the parity bit data is calculated by performing an exclusive-or operation on the received data block and the contents of the parity buffer.

19. A non-transitory computer-readable medium having instructions stored thereon, which when executed by a processor performs a method comprising:

determining that an error exists in a data block of a set of data blocks, wherein the set of data blocks is stored in a volatile memory communicatively coupled to the processor, wherein the data block having the error is stopped from being stored in a flash memory buffer coupled to the processor;

performing error correction on the data block with the error; and

during error correction of the data block with errors, a subsequent data block without errors received after the data block with errors is stored into the flash memory buffer.

20. The non-transitory computer-readable medium of claim 19, wherein the processor is part of a flash memory controller for a flash memory device.