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

Abstract

A system and method are provided for a flash memory device to improve write performance and to hide write path error correction delays in the event of write path errors. Some embodiments may provide for immediate parity correction to allow user data sharing the same stripe as the data block with the error to be programmed into flash memory before the data with the error is corrected. Furthermore, the selected stall 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 a write path error by accelerating write performance and hiding write path error correction delay.

Background

It is a new application in consumer electronics to find non-volatile memory devices such as Solid State Drives (SSDs). For example, they are replacing Hard Disk Drives (HDDs) that typically include fast rotating disks (platters). Nonvolatile memory, sometimes referred to as "flash memory" or "flash memory devices" (e.g., NAND flash memory devices and NOR flash memory devices), is used for media memory, cameras, mobile phones, mobile computers, notebook computers, USB flash drives, and the like. Non-volatile memory can provide a relatively reliable, compact, cost-effective, and easily accessible method of storing data when power is turned off.

The flash memory controller is used to manage data stored in the nonvolatile memory and serves as an interface between the host system and the nonvolatile memory. Data received from the host system may be stored in a buffer and simple error detection and correction may be performed on the data prior to writing the data to the flash memory. In general, a write path within a flash memory controller may provide a channel for programming the flash memory. However, in some cases, the write path may be prone to error. 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 that were issued after the data block with the write path error. The flash memory controller must correct the error in the write path, resend the corrected data block, and then resume the write operation to the flash memory. This may introduce unnecessary delay in the write operation to the flash memory.

In some cases, parity bit data may be used to provide error detection and correction for the write path. For example, parity bit data may be calculated by performing an exclusive-or operation on the received data block and the previously received data block. However, errors in one data block may result in errors in the calculation of parity data. Thus, correction of the parity bit data may also be required, which may introduce additional delay in the data path.

Disclosure of Invention

Embodiments of the present invention relate to a system, method, and computer readable instructions for a flash memory device to provide efficient data recovery by accelerating write performance and hiding write path error correction delay in the event of a write path error. Some embodiments may provide for immediate parity correction to allow user data sharing the same stripe as the data block with the error to be programmed into flash memory before the data with the error is corrected. Furthermore, the stopping of selected data may allow some of the individual data in different flash memory chips or planes to be programmed during write path error correction.

According to some embodiments, an apparatus may include a write path error detector configured to detect whether a data block received from a set of data blocks has an error. The apparatus may further include a parity calculator configured to calculate parity bit data of 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 block having the error. The apparatus may further include a write path manager. The write path manager may be configured to stop storing the data block with the error into the flash memory buffer and allow a subsequent data block without the error received after the data block with the error to be stored into the flash memory buffer during error correction of the data block with the error. The parity calculator may be further 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 a flash memory, one data block at a time from a first set of data blocks stored in a 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 of one of the received data blocks and calculating parity bit data based on the one or more data blocks received from the first set of data blocks. The method further includes stopping storing the data block with the error in the flash memory buffer and performing error correction on the data block with the error. The method further includes storing subsequent error-free data blocks received after the error-bearing data block into the flash memory buffer during error correction of the error-bearing data block.

The method may further include determining that errors in the data blocks with errors have been corrected and recalculating parity bit data for the first set of data blocks based on the error corrected data blocks and the data blocks without errors. 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.

Drawings

FIG. 1 is a simplified block diagram illustrating a system including a host system coupled to a flash memory device, according to some embodiments.

Fig. 2 is an exemplary diagram of a configuration of a flash memory.

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

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

FIG. 5 illustrates an example diagram of an error-free data block after being used in one embodiment to process a data block with errors.

FIG. 6 illustrates an example diagram for storing error corrected data in one embodiment.

FIG. 7 illustrates an example diagram for storing error corrected and error free data blocks in flash memory in one embodiment.

FIG. 8 illustrates an example diagram of computing partial parity bit data for a data block having errors in one embodiment.

FIG. 9 illustrates an example diagram for storing a portion of parity bits for a stripe (stripe) in flash memory in one embodiment.

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

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

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

Detailed Description

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

The following description provides examples, but 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 an enabling description for implementing an exemplary embodiment. It being understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the appended claims.

In the following description, specific details are given to provide a thorough understanding of the embodiments. However, it will be understood by those of ordinary skill in the art 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 in order not to obscure the unnecessary detail of the embodiments. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

Further, it is noted that the various embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. Further, the order of operations may be rearranged. A process terminates after its operations are completed, but may not include additional steps in the figure. A process may correspond to a method, a function, a program, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to the function returning to the calling function or 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 instruction(s) and/or data. A computer-readable medium may include a non-transitory medium that may store data therein and that does not include a carrier wave and/or transitory electronic signals propagating through a wireless or wired connection. 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 Discs (DVDs), flash memory, or memory devices. The computer readable medium may store code and/or machine executable instructions thereon, which may represent processes, functions, subroutines, procedures, routines, subroutines, modules, software packages, classes, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, parameters, or storage. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

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, the program code or code segments to perform the necessary tasks (e.g., a computer program product) may be stored in a computer readable medium or machine readable medium. The processor may perform the necessary tasks.

In the following detailed description and drawings, like reference numerals are sometimes used to designate structural elements of similar or identical structure in order to better understand 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 in, for example, NAND flash memory devices.

The embodiments disclosed herein are not limited in scope by the specific embodiments described herein. Various modifications of the embodiments of the invention in addition to those described herein will be apparent to those skilled in the art from the foregoing description and accompanying drawings. Furthermore, although some embodiments of the present invention have been described in the context of a particular implementation in a particular environment for a particular purpose, those of ordinary skill in the art will recognize that its usefulness is not limited thereto and that the embodiments of the present invention can be beneficially implemented in any number of environments for any number of purposes.

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

Fig. 1 is a simplified block diagram illustrating a system including a host system coupled to flash memory via a flash memory controller. Fig. 2 illustrates a configuration of a flash memory according to some embodiments. FIG. 3 illustrates an example block diagram of a back-end flash memory controller in one embodiment. Fig. 4-11 illustrate different steps for improving write performance in the presence of write path errors in some embodiments. FIG. 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, the flash memory controller 106 and the 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 devices, software applications, or a combination of hardware and software. In some embodiments, host system 102 may include a host-side controller (not shown). Host system 102 may send a request to flash memory controller 106 to access flash memory 104, for example, to write data to flash memory 104 or to read data from flash memory 104.

The flash memory controller 106 may be configured to receive various commands from the host system 102 and communicate with the flash memory 104 based on these commands. The flash memory controller 106 may cause the flash memory 104 to perform various operations based on commands received from the 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. The flash memory controller 106 may include volatile memory 108 and a back-end flash controller 112. The write path 110 may provide a data path or channel to program the flash memory 104 or to write data to the flash memory 104 via the back-end flash controller 112. The term "channel" may be used to refer to a path between two physical components. It should be understood that the channel may include other physical components.

The 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. The volatile memory 108 may be used to store data 108a received from the host system 102 for writing to the flash memory 104 via the back-end flash controller 112. In this specification, data 108a may also be referred to as "user data".

In some examples, an error may be introduced into write path 110 prior to writing data 108a to flash memory 104. For example, errors may occur due to internal errors in the volatile memory 108 or during the transfer of the data 108a from the volatile memory 108. Accordingly, it is desirable to protect the data path between the volatile memory 108 and the back-end flash controller 112. In some examples, an Error Correction Code (ECC) method may be performed to protect the data path between the volatile memory 108 and the back-end flash controller 112 using simple error correction parity data. For example, parity bits 108b may be added to data 108b, which data 108b may be used to provide ECC detection and correction in the event that data 108b is corrupted in write path 110.

In some implementations, the flash memory 104 may be any non-volatile memory, such as a NAND flash memory. In some implementations, the flash memory 104 may be a NOR flash memory configured to interact externally as a NAND flash memory. The flash memory 104 may be designed to store data without a continuous or substantially continuous external power supply. In some examples, flash memory 104 may be used for secondary data storage, for example, in a computer system such as a notebook computer. In some such examples, flash memory controller 106 may interact with multiple flash memories. In some embodiments, other non-volatile memory may be used in place of flash memory 104 or in addition to flash memory 104. Examples may include read-only memory (ROM), mask 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, and the like.

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

The back-end 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 108 a. For example, the write path error detector 114 may perform ECC detection using parity data 108b associated with the data 108 a. The write path error corrector 116 may be configured to perform ECC correction to correct data having errors. Data protection of data to be stored in flash memory 104 may be achieved using any ECC algorithm, such as reed-solomon codes, hamming codes, bose-chard-johner (BCH) codes, low Density Parity Check (LDPC), or any other suitable algorithm.

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

In some embodiments, a data protection method, such as RAID (redundant array of inexpensive disks), may be used to recover data stored in the flash memory 104 when data on a plane or die is corrupted. For example, RAID may utilize mirroring, data striping, parity, or a combination thereof to provide data redundancy and error correction. In some implementations, a set of data blocks may be partitioned into different stripes such that each stripe may represent user data on multiple dies or planes, as well as parity bit data on one or more dies and planes. Parity bit data may be generated by performing an exclusive or operation on user data in the stripe. In some implementations, each stripe can represent a superblock. For example, the 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 of the die or the plane is corrupted and cannot be corrected, other data in the same stripe on a different die or plane can be read. An exclusive-or operation may be performed on the read data and the parity data to recover the data for the uncorrectable die or plane. Further described with reference to fig. 2.

Fig. 2 is an exemplary diagram of the structure of the flash memory 104. It should be noted that the structure 200 shown in fig. 2 is for illustration purposes only, and that the actual physical structure of the flash memory 104 may differ substantially from the description.

In some embodiments, the flash memory 104 may include a plurality of flash memory die flash (flash) 1 104a, flash 2 104b, flash 3 104c, flash 4 104d, flash 5 104e … …, flash N104N. Each of the flash memory dies flash memory 1 104a through flash memory N104N may include multiple planes. Each plane may store a plurality of data blocks. In some embodiments, a separate flash memory die, such as parity flash memory 206, may be used to store parity bits for data stored on flash memories 1-104 a through N104N.

In some implementations, the first stripe 202 can represent a plurality of data blocks, such as data 01, data 02, data 03, data 04, data 05 … …, data 0n. The first stripe 202 may also include blocks for parity, such as data 0. For example, data 0 may represent parity bit data of a 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 parity bit data for a data block (e.g., data 11-data 1 n) associated with the second stripe 204. In some implementations, a first block from each stripe may be stored on a first die, a second block from each stripe may be stored on a second die, and so on. For example, data 01 and data 11 may be stored on flash memory 1 104a, data 02 and data 12 may be stored on flash memory 2 104b, data 03 and data 13 may be stored on flash memory 3 104c, data 04 and data 14 may be stored on flash memory 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 N104N. In some embodiments, data 0 and data 1 of the parity bit data may be stored on separate parity bit flash memories 206.

In some embodiments, data 01 and data 11 may be stored in different planes on flash memory 1104 a. Similarly, data 02 and data 12 may be stored in different planes on flash memory 2 104b, data 03 and data 13 may be stored in different planes on flash memory 3 104c, data 04 and data 14 may be stored in different planes on flash memory 4 104d, 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 may be written in parallel in different dies or planes. For example, each of the user data (e.g., data 01-data 0N) and parity bit data (e.g., data 0) in the first stripe 202 may be written in parallel to the flash 1104 a-flash N104N and parity bit flash 206 in the flash memory 104. However, if a write path error is detected in a data block received from host system 102, back-end flash controller 112 may typically cease writing any subsequent data block received from host system 102 after the received data block with the error to flash memory 104. The back-end flash controller 112 may first correct the write path error, recalculate the parity, and then allow subsequent blocks of data received from the host system 102 to be written to the flash memory 104. However, during this time, other data on the stripe cannot be written to the flash memory 104, which may introduce additional delay in the data path.

As an example, the back-end flash controller 112 may receive one block of data at a time from the volatile memory 108, e.g., data 01, data 02, data 03, …, data 0n. As each data block is received, parity bit data may be calculated by performing an exclusive-or operation on one or more of the received data blocks. If data 02 has an error, the back-end flash controller 112 may stop writing data 03, data 04, … data 0n to the flash memory 104 until the error in data 02 is corrected, which may cause additional delay. Further, due to an error in the data 02, the parity bit data 0 calculated by performing an exclusive or operation on the data 01 and the data 02 may include an error value, and may need to be recalculated. Recalculating the parity bits may further degrade performance.

Some embodiments of the present invention may speed up 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 data to the flash memory 104 is stopped until the error is corrected. While errors are corrected in the data blocks with errors, other error-free data blocks associated with different dies or planes may be programmed. When the error is corrected, the parity bits of the data block of the stripe may be recalculated. The corrected data block and the recalculated parity data may be written to the flash memory 104. Further explanation is made with reference to fig. 3.

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

The flash memory controller 300 may include the volatile memory 108 and the back-end 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 embodiments, flash memory controller 300 may include a host interface (not shown) to communicate with host system 102 via interface 118. The volatile memory 108 may be internal or external to the flash memory controller 300. For example, in some implementations, the volatile memory 108 may be part of a system memory (e.g., DRAM).

The volatile memory 108 may store multiple sets of data blocks received from the host system 102 via the interface 118. As an example, the first stripe 202 may represent a first set of data blocks including data 01, data 02, data 03, data 04, and data 05 received from the host system 102. Buffer 0 may be used to store parity bit data for a block of data in the first stripe 202. Similarly, the 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 the host system 102. Buffer 1 may be used to store parity bit data for blocks of data in the second stripe 204.

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

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

The write path manager 304 may be configured to receive one block of data at a time from the volatile memory 108 via the write path 110 for writing to the flash memory 104. For example, write path manager 304 can 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 15 for second stripe 204. The write path manager 304 may provide the received data blocks to the write path error detector 114 and the 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 be further 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 the flash memory buffer 310. The selected stall of the 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 be further configured to store subsequent error-free data received after receiving the data block with error into the flash memory buffer 310 during error correction of the data block with error. Thus, some embodiments may provide efficient data recovery by accelerating write performance and hiding write path error correction delays in the event of write path errors.

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

If an error is found in any data block received from the volatile memory 108, the parity data calculated by the parity calculator 306 may be inaccurate, and thus the parity buffer 306a may store the erroneous parity data. In this case, the write path manager 304 may be configured to read the data block having the error into the parity buffer 306a again. This may cause the parity calculator 306 to perform an exclusive-or operation again using the same data having the error to correct the erroneous parity bit data stored in the parity buffer 306a. Once the parity data in the parity buffer 306a has been restored to the correct parity data, the parity calculator 306 may continue to calculate parity data for all error-free data blocks in the group of data blocks received from the volatile memory 108. Once the errors in the data blocks have been corrected, the parity calculator 306 may be further configured to calculate parity bit data for the error corrected data blocks and the error free data blocks stored in the parity buffer 306a. Once the parity bit data for the set of data blocks has been calculated, the parity bit data may be sent to the flash memory buffer 310 along with the error corrected data block 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 having errors. For example, error corrector 116 may be implemented as software as part of memory 312. In some implementations, the error corrector 116 may perform ECC correction to correct errors in the data block with errors. In some embodiments, the instructions stored in memory 312 may further cause processor 308 to determine that errors in the data block have been corrected and store the recalculated parity data and the error corrected data block in flash memory buffer 310.

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

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

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

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

(data 01) exclusive OR (data 02) equation (1)

Accordingly, the 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, the data 02 with errors may be read into the parity buffer 306a again from the volatile memory 108 to perform parity to correct the parity bit data stored in the parity buffer 306 a. The parity calculator 306 may be configured to recalculate the parity bit data by performing another exclusive-or operation on the corrupted data 02 and the incorrect parity bit data stored in the parity buffer 306a, as follows:

(data 01) exclusive OR (data 02) equation (2)

The parity buffer 306a may now store the correct parity bit data (e.g., data 01) calculated using equation (2). In some embodiments, write path manager 304 may allow subsequently received error-free data to be stored into flash memory buffer 310 during error correction of error-bearing data 02. Discussed further with reference to fig. 5.

FIG. 5 illustrates an example diagram of an error-free data block after processing a data block with errors in one embodiment. Note that for 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 data blocks without errors to be stored into flash memory buffer 310 during error correction of the data blocks with errors. As discussed with reference to fig. 4, during error correction of data 02, some embodiments may allow error-free blocks of data received after corrupted data 02 to be stored into flash memory buffer 310.

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

(data 03) exclusive OR (data 01) equation (3)

Similarly, after processing data 03, back-end flash controller 302 may receive data 04. The write path manager 304 may forward the data 04 to both the write path error detector 114 and the parity calculator 306. If the write path error detector 114 does not detect an error in data 04, the write path manager 304 may forward data 04 for storage in the flash memory buffer 310. The parity calculator 306 may recalculate the parity bit data by performing an exclusive-or operation on the received data 04 and the parity bit data stored in the parity buffer 306a, as follows:

(data 04) exclusive OR (data 03) exclusive OR (data 01) equation (4)

Next, after processing data 04, back-end flash controller 302 may receive data 05. The write path manager 304 may forward the data 05 to both the write path error detector 114 and the parity calculator 306. If the write path error detector 114 does not detect an error in the data 05, the write path manager 304 may forward the data 05 for storage in the flash memory buffer 310. The parity calculator 306 may recalculate the parity bit data by performing an exclusive-or operation on the data 05 and the parity bit data stored in the parity buffer 306a as follows:

(data 05) exclusive OR (data 04) exclusive OR (data 03) exclusive OR (data 01) equation (5)

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

FIG. 6 illustrates an example diagram of data used to store error correction in one embodiment. Note that for 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 data "parity 0" of the first stripe 202 by performing an exclusive or operation on the error-corrected data 02 and the parity data stored in the parity buffer 306a, as follows:

(error corrected data 02) exclusive OR (data 05) exclusive OR (data 04) exclusive OR (data 03) exclusive OR (data 01) equation (6)

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

FIG. 7 illustrates an example diagram for storing error corrected and error free data blocks in flash memory 104 in one embodiment. Note that for 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 the 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 104. Referring back to fig. 2, data 01 may be stored in flash memory 1 104a, corrected data 02 may be stored in flash memory 2 104b, data 03 may be stored in flash memory 3104c, data 04 may be stored in flash memory 4 104d, data 05 may be stored in flash memory 5 104e, and parity bit 0 may be stored in parity bit flash memory 206. If errors in data 02 are not corrected and all other data blocks in the first stripe 202 have been stored in flash memory 104, the data blocks of the other stripes may be sent to flash memory buffer 310, as discussed with reference to FIG. 8.

FIG. 8 illustrates an example diagram of computing partial parity bit data for a data block having errors in one embodiment. Note that for simplicity, only certain components of the back-end flash controller 302 are shown in fig. 8.

As shown in fig. 8, an embodiment may allow sending data blocks of the second stripe 204 if errors in the data 02 are not corrected and all other data blocks in the first stripe 202 are already stored in the flash memory buffer 310. In one embodiment, a 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 bit data may be calculated using data 01, data 03, data 04, and data 05 using equation (5). This may allow for releasing the parity buffer 306a to be used to store the parity bit data of the second stripe 204. 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.

FIG. 9 illustrates an example diagram for storing partial parity bit data for a stripe in flash memory in one embodiment. Note that for 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 (e.g., data 01, data 03, data 04, and data 05) of the first stripe 202 may be transmitted to be stored in the flash memory 104 without transmitting the data 02 having the error. This may allow memory space for a portion of the data to be freed up in the volatile memory 108 while storing a portion of the parity data in the volatile memory 108 until the error in data 02 is corrected. Some embodiments may allow for the transmission of data for the second stripe 204, as discussed with reference to fig. 10.

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

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

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

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

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

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, the back-end flash controller 302 may receive one data block at a time from a first set of data blocks (e.g., data 01-data 05) of the first stripe 202 stored in the volatile memory 108. The volatile memory 108 may also store a second set of data blocks (e.g., data 11-data 15) for the second stripe 204. The write path manager 304 may forward each received data block to the write path error detector 114 and the parity calculator 306.

In step 1204, the back-end flash controller 302 may detect an error in one of the received data blocks. For example, the write path manager 304 may receive the first data block data 01 and may forward the data 01 to the write path error detector 114 and the 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 parity data by performing an exclusive or operation on the data 01 and the contents (e.g., zero) of the parity buffer 306a, and may store the calculated parity data in the parity buffer 306 a. Next, the write path manager 304 may receive the second data block data 02 and may forward the data 02 to the write path error detector 114 and the 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 detect errors using ECC data associated with data 02.

In step 1206, the back-end 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 parity bit data based on the received data block data 01 and data 02. For example, the parity calculator 306 may perform an exclusive-or operation on the received data block data 02 and the parity bit data (e.g., data 01) stored in the parity buffer 306a, as shown in equation (1). The parity calculator 306 may store the calculated parity bit data in the parity buffer 306 a. In some embodiments, steps 1204 and 1206 may be performed in parallel.

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

In step 1210, the back-end flash controller 302 may perform error correction on the data block with the error. As discussed with reference to fig. 3, error corrector 116 may perform ECC correction to correct errors in data 02. In addition, parity correction may be performed to correct the parity data stored in the parity buffer 306a by reading the data 02 having an error into the parity buffer 306a again and recalculating the parity data using equation (2).

In step 1212, the back-end flash memory controller 302 may store subsequent data blocks received after the data block with error into the flash memory buffer during error correction of the data block with error. 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 the volatile memory 108. If no error is detected in any of data 03, data 04, or data 05, data 03, data 04, and data 05 may be stored in flash memory buffer 310. Thus, embodiments may minimize the stopping of data in the event of a write path error by being limited to stopping data blocks with errors and allowing data blocks without errors to pass. Thus, the selected stop may improve the write performance when the write path is erroneous.

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

If errors in data 02 have not been corrected during the subsequent storage of data 03, data 04, and data 05 in flash memory buffer 310, data 03, data 04, and data 05 may be transmitted to be stored in flash memory 104 without transmitting corrupted data 02. The parity calculator 306 may recalculate the partial parity bit data for the first set of data blocks based on data 03, data 04, and data 05. As discussed with reference to fig. 8, partial parity bit data for the first set of data blocks without data 02 may be stored in the volatile memory 108. Some embodiments may allow data blocks in a second set of data blocks that do not share the same die or plane as data 02 to be stored into flash memory buffer 310 during error correction of data 02. When the error in the data 02 has been corrected, the parity calculator 306 may recalculate the parity data for the first set of data blocks based on the error corrected data 02 and the partial parity data stored in the volatile memory 108. 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.

Thus, some embodiments may allow for the transmission of data blocks without errors for storage in flash memory during error correction of data blocks with errors. This can speed up the write performance for user data stored in the flash memory. Furthermore, performing an immediate parity check before the erroneous data is corrected to allow user data sharing the same stripe as the data block with the error to be programmed can hide the delay of writing the error correction. Some embodiments may provide for selecting stop data to allow programming of some individual blocks of data on different planes or dies 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.