Payload overflow boundary table assisted read in solid state drives

Abstract

The present invention relates to payload overflow boundary table assisted reading in solid state drives. A method performed by a controller of a solid state drive includes receiving a read request from a host for read data stored in non-volatile semiconductor storage of the solid state drive. The method includes identifying a first codeword and a second codeword, the first and second codewords including the read data corresponding to the read request. In response to the read request, the method includes reading a first portion of the read data included in the first codeword and reading a second portion of the read data included in the second codeword, combining the first and second portions as combined read data, and transmitting the combined read data to the host in response to the read request. The first and second codewords are stored adjacent, and the combined read data has a length greater than a length of the first and second codewords.

Description

Technical Field

[0001] This disclosure relates to solid-state drives and methods that provide a common infrastructure, which dynamically adjusts according to changes in the bitrate of the solid-state drive to efficiently transfer data when processing read requests from a host. Background Technology

[0002] Compared to conventional disk drives, solid-state drives (SSDs) typically offer faster performance, smaller size, and are less sensitive to vibration or physical shock. Given these advantages, SSDs are increasingly being used in computing devices and other consumer products to replace or supplement disk drives, even though the cost per GB of storage capacity for SSDs is significantly higher than that for disk drives.

[0003] SSDs use physical memory cells, including non-volatile semiconductor memory devices (such as NAND devices), to store data. An SSD uses a controller to manage data transfer between the host and the SSD's memory cells. Writing data to and reading data from the SSD's physical memory cells typically involves shuffling data between the various memory cells.

[0004] Until now, the size of memory pages (such as NAND pages) in SSD memory cells has been configured to allow each data unit of the memory page to hold multiple data payloads, with error correction code (ECC) bits residing in the primary reserved spare area of ​​the memory page used for error correction. However, this has changed drastically as current memory technologies increasingly tend to compress more data bits per memory cell. Simultaneously, the bit error rate (BER) on such data pages within memory increases with memory aging, necessitating an increase in the number of ECC bits, which exceeds the available space in the reserved area of ​​the memory page.

[0005] To maintain good throughput and latency for workloads and without degrading memory efficiency through fine-grained error correction, more Error Correction Code (ECC) bits are built into each data cell. Increasing the number of ECC bits per data cell reduces the physical space available for storing payload data from the host. While the physical space for the payload data from the host in memory decreases over time, the size of the payload itself remains unchanged. For example, in a 16-kilobyte (KB) NAND memory page, increasing the BER means that a larger portion of the 16KB NAND memory page will be dedicated to ECC for the data stored in the page, which will be an addition of any bits dedicated to ECC in reserved or secure areas of the page. This reduces the physical NAND memory space for the payload data, which was originally 16KB, but is now significantly reduced due to the need for a larger ECC size. It is therefore concluded that each data payload will overflow across more than one data cell in memory. This poses a challenge to how to manage the stored data during data transfers, such as during read or write requests from the host. Summary of the Invention

[0006] According to embodiments of this disclosure, a method executed by a controller of a solid-state drive (SSD) is provided. The method includes receiving from a host a read request for read data stored in one or more of a plurality of non-volatile semiconductor storage devices of the SSD. The method further includes identifying a first codeword and a second codeword from a plurality of codewords stored in the plurality of non-volatile storage devices, the first codeword and the second codeword including the read data corresponding to the read request. In response to the read request, the method includes reading a first portion of the read data contained in the first codeword and reading a second portion of the read data contained in the second codeword. Furthermore, the method includes: combining the first portion and the second portion as combined read data; and in response to the read request, transmitting the combined read data to the host. Here, the second codeword is stored adjacent to the first codeword in one or more of the plurality of non-volatile storage devices, and the combined read data has a data length greater than a first data length of the first codeword or a second data length of the second codeword.

[0007] In some embodiments, the read data includes a logical cluster address (LCA). In a particular embodiment, the method further includes converting the LCA of the read data into a media cluster address (MCA) in the non-volatile semiconductor memory device in which the read data is stored. In a further embodiment, the method further includes determining a codeword offset corresponding to the MCA, the codeword offset identifying a first codeword among a plurality of codewords in which the read data begins. In other embodiments, the method further includes identifying an overflow offset associated with the first codeword offset, the overflow offset identifying a position within the first codeword in which the read data begins. In some embodiments, the method further includes reading the first portion of the read data from the overflow offset of the first codeword to the end of the first codeword.

[0008] In a particular embodiment, the method further includes calculating the second portion of the read data to be read. In a further embodiment, the method includes identifying an overflow offset of the second codeword in response to the second portion of the read data being non-zero, and reading the second portion of the read data from the beginning of the second codeword to the overflow offset of the second codeword. In other embodiments, the method includes determining whether the second portion of the read data has overflowed into the next adjacent codeword. In some embodiments, the method includes identifying an overflow offset of the next adjacent codeword in response to the second portion of the read data overflowing into the next adjacent codeword, and reading the overflowed second portion of the read data from the beginning of the next adjacent codeword to the overflow offset of the next adjacent codeword. In a particular embodiment, the method further includes indexing into an address lookup table that maps the LCA to the MCA in the non-volatile semiconductor memory device in which the read data is stored.

[0009] In a further embodiment, the method further includes indexing into a codeword lookup table that maps the MCA to the codeword offset of the non-volatile semiconductor memory device in which the read data is stored. In other embodiments, the method includes indexing into a payload overflow boundary lookup table that maps codewords in the non-volatile semiconductor memory device to overflow offsets. In some embodiments, the first data length and the second data length are equal, and the method further includes: determining per-codeword data overflow by subtracting the first data length from the data length of the read data; determining the total overflow of each codeword offset in the non-volatile semiconductor memory device by multiplying the per-codeword overflow by the codeword offset; and determining the overflow offset by dividing the total overflow by the first data length.

[0010] In other embodiments, the plurality of codewords are stored on one or more word lines in the non-volatile semiconductor memory device. In some embodiments, each of the word lines has a different code rate. In a particular embodiment, the controller generates a payload overflow boundary lookup table for each code rate. In a particular embodiment, the read data continues across multiple word lines, and the method further includes determining the word line associated with each codeword and selecting a payload overflow boundary lookup table based on the associated word line. In a further embodiment, the method further includes storing the code rate of the non-volatile semiconductor memory device in a configuration file in a read-only memory within the controller.

[0011] In some embodiments, the method further includes: determining a bit error rate associated with each of the plurality of non-volatile semiconductor memory devices; adjusting the code rate of at least one of the non-volatile semiconductor memory devices based on the bit error rate; and updating the code rate in the configuration file. In a particular embodiment, combining the read data includes combining the first and second portions of the read data with a header, error correction code (ECC), and parity check code before transmitting the read data to the host. In a further embodiment, each of the plurality of non-volatile semiconductor memory devices includes NAND memory. Attached Figure Description

[0012] The above and other objects and advantages will become clear from the following detailed description taken in conjunction with the accompanying drawings, wherein like element symbols refer to all like parts, and wherein:

[0013] Figure 1 A schematic diagram illustrating a solid-state drive (SSD) configured according to one or more embodiments of the present disclosure;

[0014] Figure 2 This describes the storage of a data payload in a codeword of a non-volatile semiconductor memory device according to one or more embodiments of the present disclosure;

[0015] Figure 3A This describes the general characteristics of storing a data payload in a codeword of a non-volatile semiconductor memory device according to one or more embodiments of the present disclosure;

[0016] Figures 3B to 3C This section describes specific examples of storing a data payload in a codeword of a non-volatile semiconductor memory device according to one or more embodiments of the present disclosure;

[0017] Figure 4 This is a flowchart of a first method for processing a read request from a host according to one or more embodiments of the present invention;

[0018] Figure 5 This is a flowchart of a second method for processing a read request from a host, according to one or more embodiments of the present disclosure;

[0019] Figure 6 This is a flowchart of a method for generating an overflow boundary table when processing a read request from a host, according to one or more embodiments of the present disclosure;

[0020] Figure 7 This describes an example of a word line to code rate mapping table according to one or more embodiments of this disclosure; and

[0021] Figure 8 This is a flowchart of a method for handling different bitrates for each word line according to one or more embodiments of the present disclosure. Detailed Implementation

[0022] To provide a general understanding of the apparatus described herein, specific illustrative embodiments will be described. Although the embodiments and features described herein are specifically described for use in conjunction with an SSD having a controller, it should be understood that all components and other features outlined below can be combined with each other in any suitable manner and are suitable and applicable to other types of SSD architectures containing memory with smaller data frames due to their higher BER.

[0023] Figure 1 This is a block diagram of a computing system 100 including at least one host 110 communicating with storage device 120. Host 110 includes components well-known in the art but not described for simplicity. Figure 1 The computing system shown includes a processor, memory, and other components. Storage device 120 provides non-volatile storage functionality used by host 110. Storage device 120 is an SSD, which is a non-volatile storage device that typically includes an integrated circuit including controller 130. Controller 130 is communicatively coupled to a non-volatile semiconductor-based storage element 140, which serves as the storage medium. For example, such a semiconductor-based storage element 140 may include NAND-based flash memory devices 141 to 143. SSD 120 also includes memory external to controller 130, such as random access memory (RAM) 150. In some embodiments, RAM 150 may include dynamic RAM (DRAM). DRAM 150 includes several buffers for buffering data during read and write operations between host 110 and storage element 140.

[0024] Storage element 140 may include multiple NAND chips or semiconductor dies, such as 32, 64, 128, or 256 individual NAND chips or dies. Each NAND chip or die may include multiple blocks, each of which includes multiple pages. Each page stores payload data from host 110 in a codeword, each codeword containing the original payload data from the host and error correction bits. Furthermore, when the memory cells of the NAND die store more than one bit per cell, each page may be divided into subpages, for example, when TLC (Three-Level Cell) memory cells are used to store three data bits per cell, they are divided into a lower page, a middle page, and a upper page. Storage element 140 consists of memory cells connected together in strings containing 16, 32, 64, or more cells, each string connected to a bit line. A large number of these strings form a memory block, with word lines connecting corresponding cells in each string. This structure of storage element 140 facilitates the formation of memory pages for data transfer, with one or more memory pages in each word line. The memory pages of this sequence determine the minimum amount of data that can be transferred to and from storage element 140 during write (programming) and read operations.

[0025] For example, controller 130 includes a host interface 132 capable of communicating with host 110 to receive read and write requests. Controller 130 also includes an interface 134 for communicating with storage element 140. Interface 134 can communicate with storage element 140 via multiple channels, such as channels CH0, CH1, ..., CHn, etc. Figure 1 As shown in the diagram. Controller 130 may also include a RAM interface (not shown) for communicating with RAM 150 external to controller 130. For example, host interface 132 in controller 130 may include a Serial Advanced Technology Attachment (SATA) connector or use NVMe. TM NVMe protocol TM It is an abbreviation for "NVM express," where "NVM" stands for "Non-volatile memory" (PCIe). TM (“Peripheral Component Interface High Speed”) connector. For example, interface 134 may include an Open NAND Flash Interface (ONFI) or a manufacturer’s proprietary interface. For example, the interface for communicating with external RAM may include, but is not limited to, interfaces according to (but not limited to) the following: Double Data Rate (DDR) memory bus standards, such as DDR3, DDR4, or DDR5; Low Power Double Data Rate (LPDDR) memory bus standards, such as LPDDR3, LPDDR4, or LPDDR5; Hybrid Memory Cube (HMC) memory bus standards.

[0026] like Figure 1As shown, controller 130 may include a flash translation layer 160 that enables controller 130 to perform various functions that facilitate the processing of read and write requests from host 110. Controller 130 may also include a read-only memory (ROM) 170 that stores instructions for managing controller functions, such as allocating payload data to storage elements 140, as detailed in the following description. ROM 170 stores such instructions in the form of programmable firmware 172. This allows the operation of memory controller 130 to be periodically updated throughout the lifetime of SSD 120. Firmware 172 takes into account changes in characteristics (e.g., BER) of storage element 140 during its lifetime to optimize the performance of SSD 120. Such characteristics include the BER of the NAND device, which then determines the code rate (the ratio between information data bits and the total number of bits (including ECC bits)) of the NAND devices 141 to 143 that make up storage element 140, the length of the ECC and the parity check code (e.g., cyclic redundancy check (CRC) parity check code), the data frame size, and the codeword size. The characteristics of NAND devices (such as BER) can change over time, temperature, or program / erase (P / E) cycle count. Therefore, firmware 172 enables controller 130 to adjust its operation based on the lifetime, temperature, or P / E cycle count of NAND devices 141 to 143. Controller 130 can also store metadata in NAND devices 141 to 143, some of which may be critical metadata requiring significantly better protection than ordinary metadata (which still requires better protection than payload data from host 110). Therefore, firmware 172 enables controller 130 to adjust its operation based on the type of data, payload data, metadata, and the lifetime, temperature, or P / E cycle count of NAND devices 141 to 143.

[0027] Flash translation layer 160 may include a lookup table 162 that maps the logical address of payload data received from host 110 to a physical address within any of NAND devices 141 to 143. In a particular embodiment, the logical address may include a logical cluster address (LCA), and the physical address may include a media cluster address (MCA). Thus, lookup table 162 maps the LCA of the payload to the MCA in storage element 140. Flash translation layer 160 may also include a codeword offset module 164. Codeword offset module 164 is generated by firmware 172 when SSD 120 is booted to manage the code-related constructs of the payload stored in codewords in NAND devices 141 to 143. Based on the characteristics of NAND devices 141 to 143 (e.g., code rate), firmware 172 performs calculations to determine the offset within each codeword in which the beginning of the payload data is stored. In some embodiments, firmware 172 generates a codeword offset lookup table 166 based on the code rate of the memory pages for each word line in NAND devices 141 to 143. In some embodiments, the code rate of each word line or each memory page in the NAND devices 141 to 143 may be stored in configuration file 167. Flash translation layer 160 may also include a combination module 168. Combination module 168 is a code-related construct generated by firmware 172 for combining data transferred from storage element 140 to host 110. Here, when the SSD processes a read request from host 110, combination module 168 combines the payload before transferring the payload to host 110.

[0028] Additionally, controller 130 may include local memory 180 within memory controller 130, such as static random access memory (SRAM). Like DRAM 150, SRAM 180 may also include several buffers that can be utilized by flash translation layer 160 of controller 130 during operation. According to embodiments of this disclosure, SRAM 180 may store lookup table 182 (e.g., a payload overflow boundary table) that enables controller 130 to manage data allocation to and from codewords stored in NAND devices 141-143. In some embodiments, the payload overflow boundary table informs controller 130 of the location within each codeword where payload data begins.

[0029] Figure 2 Description of storage in NAND devices (e.g.) Figure 1 Data 200 is stored in NAND devices 141 to 143. Data 200 may have been received from host 110 during a separate write process. Figure 2 The data is represented as multiple payloads P0 to P13, which are stored in multiple codewords CW0 to CW15 within a page of a word line in the NAND device. Note that... Figure 2Only the data storage portion of the codewords is shown. Other peripheral bits for ECC, parity, metadata, and headers are not shown in codewords CW0 to CW15. However, after data is read, these peripheral bits are used to perform error correction, RAID reconstruction, and other actions required to reconstruct the payload segment from the codewords in codeword offset module 164, so that combination module 168 reconstructs the complete payload from the payload segment. The ECC bits in codewords CW0 to CW15 are not shown. Codewords CW0 to CW15 are stored on four NAND pages (NAND pages 0 to 3), where each NAND page contains four codewords. For example, in... Figure 2 In the NAND page, page 0 includes codewords CW0 to CW3, page 1 includes codewords CW4 to CW7, page 2 includes codewords CW8 to CW11, and page 3 includes codewords CW12 to CW15.

[0030] Typically, a NAND page is approximately 16KB in size, and each payload is 4,096 bytes (approximately 4KB). If the NAND device has a low BER (Bit Rate of Change), the ECC (Electronic Code Correction) bits in each codeword can be placed in the spare area of ​​the page; therefore, an integer number of payloads will be placed into the corresponding codeword. However, if the NAND device has a high BER, the ECC bits in each codeword increase in size to the point that the ECC bits in the codeword encroach on the space available for storing the payload data. This means that the ECC bits reduce some physical NAND space from the payload area, resulting in less space available for data storage. This effectively means that the data size per codeword of the NAND device decreases. This can be seen in... Figure 2 In this case, each of the codewords CW0 to CW15 has a data size smaller than the payloads P0 to P13. In this situation, it is impossible to fit an integer number of payloads into a page because the data in each page actually overflows to at least the next adjacent codeword. The number of codewords from the beginning of the word line is called the codeword offset, and the portion of the payload stored in the next adjacent codeword is called the overflow offset.

[0031] For example, in Figure 2In this example, payloads P0 through P13 each have a size of 4096 bytes, and codewords CW0 through CW15 each have a size of 4096-X bytes, where X is the number of ECC bytes within each codeword. For example, payload P0 is stored in two codewords CW0 through CW1, where the data in payload P0 is stored in the entire codeword CW0 and a small portion of codeword CW1. Here, the codeword offset of payload P0 is "0", and the overflow offset is 0 bytes because the payload begins at the beginning of the codeword. The data in payload P1 is stored starting from codeword CW1, so its codeword offset is "1", but the beginning of the data is offset by X bytes from the beginning of codeword CW1 (because this is occupied by X bytes from the end of payload P0), so its overflow offset is X bytes. As another example, Figure 2 The payload P7 is stored across three codewords CW7 to CW9, where the data in payload P7 is stored in a portion of codeword CW7, the entire codeword CW8, and a portion of codeword CW9. Here, the codeword offset for payload P7 is codeword "7", and the payload then overflows into codewords CW8 and CW9. The overflow offset for P7 is 7 × X bytes. The overflow offset for each consecutive payload is increased by X bytes until the beginning of one payload coincides with the beginning of another codeword, if the number X is chosen such that the codeword size (payload data + ECC data) is divisible. If not, a remainder less than X, not occupied by data, is left so that the next payload coincides with the beginning of another codeword.

[0032] The amount of data overflowing from the payload to the next adjacent codeword depends on the code rate of the word line in the NAND device. In some implementations, it may depend on the code rate of each page within the word line. As an example, a typical word line comprises 16 NAND pages, each with four codewords, and the word line thus spans 64 codewords. For NAND devices with a low BER (e.g., for newer memory), the payload will be able to fit within the codewords and the ECC bits will be in spare areas of the NAND pages (i.e., a 1:1 mapping between the payload and the codewords), resulting in a 64 / 64 code rate, where 64 payloads fit into 64 codewords. However, as memory ages over time, the BER increases, requiring an increase in the number of ECC bits per codeword. This means less space per codeword is available for storing data, resulting in a lower code rate. The exemplary reduction in code rate is achieved by placing 63 / 64 of 64 codewords with 63 payloads, 62 / 64 of 64 codewords with 62 payloads, 60 / 64 of 64 codewords with 60 payloads, and so on. This means that the 1:1 mapping between payload and codewords has now changed, allowing fewer payloads to fit into the codewords within the NAND page.

[0033] It should be noted that the basic number of codewords in each NAND device is fixed (e.g., 64 in the aforementioned example); however, depending on the required ECC level, this reduces the NAND device's ability to store an equal number of payloads. Therefore, as the code rate decreases, a portion of each payload overflows into the next adjacent codeword. As an example, in Figure 2 In the example, the main portion of the 4,096-byte to 128-byte payload P0 has a codeword offset of "0", and the remaining portion of the 128-byte payload P0 overflows and is stored in the next adjacent codeword CW1. As a further example, in... Figure 2 In the middle, the main part of the payload P1, which consists of 4,096 bytes - 2x128 bytes, has a codeword offset of "1", and the remaining part of the payload P1, which consists of 2x128 bytes, overflows and is stored in the next adjacent codeword CW2. Figure 2 As can be seen, the amount of data overflowing into the next adjacent codeword increases downwards along the word line as the codeword offset increases. In some examples, the payload can be distributed across three adjacent codewords, with N bytes (assuming) in the first codeword, (4,096-128) bytes in the second codeword, and (128-N) bytes in the third codeword.

[0034] The codeword offset and overflow offset are managed by firmware 172 and controller 130, so that when SSD 120 receives a data read request from a specific payload, the controller manages the read request and retrieves the main part and some of the remaining parts of the requested payload from the appropriate codeword. Figure 3A This describes data 300 stored in the NAND device. Figure 3A In this context, the payload has been covered by the codewords on the word line. As mentioned above, the codeword offset is a measurement of the number of codewords at the beginning of the word line and indicates the codeword where the payload begins. For example, codeword offset x indicates that the payload (e.g., payload P(A)) begins with codeword CW(x), and the codeword offset is measured along the word line from codeword zero. As the code rate decreases in NAND devices, the ratio of the number of payloads that can be placed along the word line into the number of codewords is less than 1:1. To accommodate this mismatch, each codeword has an overflow offset. For codeword CW(x), the overflow offset is the point within codeword CW(x) where the payload begins, such as... Figure 3A As described in [the document]. Overflow offsets are measured in bytes. Therefore, it can be concluded that each codeword has an associated overflow offset, and the magnitude of the overflow offset depends on the code rate.

[0035] When a payload is stored in a NAND device, the data contained within the payload is placed across multiple adjacent codewords. Distributing the payload across multiple adjacent codewords is within the scope of this disclosure. It should be noted that the "adjacent" nature of a codeword refers to its logical address. Therefore, if the logical addresses of two codewords are sequentially arranged (i.e., one after the other), then the two codewords are considered adjacent, even if the codewords may reside on different pages, blocks, planes, and / or dies of the NAND device. For example, in Figure 3A In this context, the payload P(A) spans codewords CW(x) and CW(x+1), where codeword CW(x+1) is the next adjacent codeword of codeword CW(x). It should be noted that codewords CW(x) and CW(x+1) may reside on the same word line, or they may reside on different word lines, pages, blocks, planes, and / or dies of the NAND device, but the logical addresses of codewords CW(x) and CW(x+1) are contiguous. For example... Figure 3A As shown, the main part of the payload P(A) is stored in the codeword CW(x), and the remaining part of the payload P(A) is stored in the next adjacent codeword CW(x+1). Here, the data in the main part of the payload P(A) is stored in the codeword CW(x), from the overflow offset of the codeword CW(x) to the end of the codeword CW(x), and the data in the remaining part of P(A) is stored in the next adjacent codeword CW(x+1), from the beginning of the codeword CW(x+1) to the overflow offset of the codeword CW(x+1). Similarly, Figure 3A The data in the main part of the payload P(B) is stored in the codeword CW(y-1), from the overflow offset of the codeword CW(y-1) to the end of the codeword CW(y-1), and the data in the remaining part of P(B) is stored in the next adjacent codeword CW(y), from the beginning of the codeword CW(y) to the overflow offset of the codeword CW(y).

[0036] like Figure 3A As seen, the remainder of the payload overflows into the next adjacent payload. Therefore, when the firmware processes a read request from the host, once the main portion of the payload is located in a specific codeword within the NAND device, the remainder of the payload will be located in the next adjacent codeword. As mentioned earlier, the "adjacent" nature of a codeword refers to its logical address. Therefore, two codewords are considered adjacent if their logical addresses are sequentially arranged along word lines (i.e., one after the other). With respect to the last codeword in a word line, the next adjacent codeword can be at the beginning of the next word line, which can be in the same physical block or in a different physical block, plane, and / or die within the NAND device.

[0037] refer to Figure 3AThe last codeword on the word line is codeword CW(y). According to embodiments of this disclosure, the remaining portion of the payload continues to overflow into the next adjacent codeword until the end of the word line. Therefore, the portion of codeword CW(y) offset from the overflow of codeword CW(y) to the end of codeword CW(y) remains unused. The next payload after payload P(B) is stored in the codeword on the next word line. For example, if Figure 3A In the NAND device, word line 7 is used. When all codewords on word line 7 are filled with data, the firmware increments to word line 8 and begins storing data in the codewords on word line 8. There are several reasons for this. One reason is that each word line has a unique parity check code, thus simplifying the generation of overall parity checks in the firmware for data stored in codewords on the same word line (i.e., no payload overflows from a codeword on one word line to a codeword on the next word line). Another reason is that the BER can vary with word lines, and the code rate of each word line can therefore be different. In this way, this disclosure minimizes space waste in the NAND device because codewords on each word line are archived sequentially until the last codeword. Only the portion of the last codeword on the word line is unused. This significantly reduces unused space compared to moving to a new codeword after each payload. Therefore, the unused space according to embodiments of this disclosure is per word line rather than payload / per codeword, which is a significant reduction.

[0038] Because this disclosure relies on the logical address sequence of codewords (i.e., the logical address of codeword CW(x) and the next logical address of codeword CW(x+1)), the overflow offset of each codeword follows the order in which the payload is stored in the NAND device. Therefore, if data has been written from the lower NAND page to the middle NAND page, and then to the upper NAND page, the overflow offset within each page will follow the same sequence. This allows for better use of the NAND device by minimizing wasted space within pages.

[0039] Figure 3B illustrate Figure 2 The diagram illustrates the distribution of payload data 320 in codewords CW2 to CW4 of the NAND device. Codewords CW2 to CW4 are logically adjacent to each other, meaning their logical cluster addresses are contiguous. During the write process, payloads P1 to P4 are distributed across codewords CW2 to CW4 in the NAND device. When the code rate in the NAND device is less than 1:1, each codeword has an associated overflow offset where a new payload begins. For example, the remainder of payload P1 is stored in codeword CW2, from the beginning of codeword CW2 to the overflow offset of codeword CW2. Although... Figure 3BNot shown, but the main part of payload P1 is stored in codeword CW1, from the overflow offset of codeword CW1 to the end of codeword CW1. Similarly, payload P2 has its main part stored in codeword CW2, from the overflow offset of codeword CW2 to the end of codeword CW2. The remaining part of payload P2 cannot be put into codeword CW2, therefore, it overflows and is stored in the adjacent codeword CW3, from the beginning of codeword CW3 to the overflow offset of codeword CW3. Furthermore, payload P3 has its main part stored in codeword CW3, from the overflow offset of codeword CW3 to the end of codeword CW3. The remaining part of payload P3 cannot be put into codeword CW3, therefore, it overflows and is stored in the adjacent codeword CW4, from the beginning of codeword CW4 to the overflow offset of codeword CW4. For completeness, the remainder of codeword CW4 (from the overflow offset in codeword CW4 to the end of codeword CW4) is filled with data from payload P4. (As from...) Figure 3B It is evident that as the codeword offset increases, the overflow offset within each codeword becomes increasingly larger.

[0040] When data from payloads P1 to P4 is stored in codewords CW2 to CW4 of the NAND device according to the write sequence (e.g., regarding...), Figure 3B When processing a read request from host 110, controller 130 can quickly locate data from any payload. Controller 130 retrieves the requested data after knowing the physical (MCA) addresses of codewords CW2 to CW4 and their associated overflow offsets. When controller 130 receives a data read request from the payload, it obtains the LCA associated with the requested data from the read request and determines the associated MCA, codeword offset, and overflow offset. This determination can be accomplished using multiple lookup tables, as detailed below.

[0041] For example, when controller 130 receives a data request from payload P3, the controller uses the LCA contained in the read request to obtain the MCA and the associated overflow offset of codeword offset 3 and codeword CW3. Next, controller 130 retrieves the main portion of payload P3 from codeword CW3, from the overflow offset of codeword CW3 to the end of codeword CW3. Then, the controller determines whether there is a remaining portion of payload P3 to be read. Next, controller 130 obtains the overflow offset of the next adjacent codeword CW4 and reads the overflow data in codeword CW4 up to the overflow offset of codeword CW4. Then, the controller combines the requested data from the main portion and the remaining portion of payload P3, appending headers, metadata, parity bits, and ECC bits to the data, and transmits the combined data to host 110.

[0042] Figure 3CThe distribution of payload data 340 in codewords CW7 to CW9 of the NAND device is shown in further detail. Due to the code rate of the NAND device, the overflow offset increases cumulatively with the codeword offset, causing the payload P7 to span three codewords CW7 to CW9. Here, the payload P7 has the main portion stored in codeword CW7, from the overflow offset in codeword CW7 to the end of codeword CW7. The remaining portion of the payload P7 cannot be put into codeword CW7, so it overflows. However, the remaining portion of the payload P7 is larger than the codeword size of the next adjacent codeword CW8, therefore, the remaining portion of the payload P7 is stored in the entire codeword CW8 and the next adjacent codeword CW9, from the beginning of codeword CW9 to the overflow offset of codeword CW9.

[0043] When controller 130 receives a data request from payload P7, it uses the LCA contained in the read request to obtain the MCA and the associated codeword offset "7" and overflow offset. Next, controller 130 retrieves the main portion of payload P7 from codeword CW7, from the overflow offset of codeword CW7 to the end of codeword CW7. Then, controller 130 determines if there is a remaining portion of payload P7 to be read. Next, controller 130 obtains the overflow offset of the next adjacent codeword CW8 and reads the overflow data in codeword CW8 up to the overflow offset. For codeword CW8, the overflow offset is the size of the codeword. Next, controller 130 repeats itself and determines if there is a remaining portion of payload P7 to be read, which comes from codeword CW9. Next, controller 130 obtains the overflow offset of the next adjacent codeword CW9 and reads the overflow data in codeword CW9 up to the overflow offset of codeword CW9. Next, the controller combines the request data from the main part of the payload P7 in codeword CW7 and the remaining part of the payload P7 from codewords CW8 and CW9, and transmits the combined data to host 110.

[0044] When the SSD 120 boots, the controller 130 and firmware 172 perform several calculations to determine the overflow offset for each codeword. Parameters (such as payload size PL and code rate CR) are stored in configuration file 167, which is read by the firmware 172 at boot time. The firmware 172 then determines the codeword size CW_Siz and the overflow per codeword Spill_per_CW using the following methods:

[0045] CW_Size=PL×CR=PL×(Number of payloads ÷ Number of codewords) (1)

[0046] Spill_per_CW = PL - CW_Size (2)

[0047] For example, with a bitrate of 62 / 64 and a payload size of approximately 4kB (specifically, 4,096 bytes), the codeword size is 3,968 bytes and the per-codeword overflow offset is 128 bytes. As another example, a bitrate of 60 / 64 and a payload of 4kB will result in a codeword size of 3,840 bytes and a per-codeword overflow offset of 256 bytes.

[0048] To read payload from multiple codewords in a NAND device, firmware 172 determines the portion of the payload on each codeword (e.g., the main portion or the remaining portion). To do this, firmware 172 determines the size of the payload on each codeword and the overflow offset within the codeword from which to read the payload data. Here, firmware 172 calculates the total cumulative overflow Total_Spill and the overflow offset Spill_Offset at the codeword offset CW_Offset using the following:

[0049] Total_Spill=CW_Offset×Spill_per_CW (3)

[0050] Spill_Offset=Total_Spill%CW_Size (4)

[0051] The % operator is the modulo operator, which returns the remainder of the division. That is, the overflow offset is the remainder of the total accumulated overflow divided by the codeword size.

[0052] As an example, assuming a code rate of 62 / 64, if the read request contains LCA information pointing to the payload P10 stored in codeword CW11, then using equation (1), the codeword size is 4,096 × 62 / 64 = 3,840 bytes; using equation (2), the overflow per codeword is 4,096 - 3,840 = 128 bytes; using equation (3), the total overflow is 11 × 128 = 1,408 bytes; and using equation (4), the overflow offset is 1,408 % 3,840 = 1,408 bytes. Using similar calculations, the overflow offset of the next adjacent codeword CW12 is 1,536 bytes. This means that the main part of the requested payload P10 is located 1,408 bytes from the beginning to the end of codeword CW11, and the remaining part of the payload P10 is located in the first 1,536 bytes of the next adjacent codeword CW12.

[0053] Firmware 172 repeatedly uses equations (1) through (4) for each codeword to perform calculations to determine the associated overflow offset, so that corrected read data requested by host 110 can be retrieved by controller 130 from NAND device 140. However, such repeated calculations are computationally intensive and can burden the processor of SSD 120. This disclosure includes an embodiment of a payload overflow boundary lookup table 182 generated by firmware 172 during the initial initialization and startup of SSD 120. The payload overflow boundary lookup table 182 includes overflow offset values ​​for each codeword offset calculated using equations (1) through (4) for a specific code rate. These values ​​are stored in SRAM 180 of controller 130. An exemplary payload overflow boundary lookup table 182 is shown in Table 1. It can be seen that the overflow offset values ​​cycle after a total overflow equal to the size of a payload of 4,096 bytes, that is, the overflow offset values ​​cycle back to 128 bytes after 32 codewords. By indexing into the payload overflow boundary lookup table 182, the controller can quickly process read requests from host 110.

[0054] As previously mentioned, the code rate may be different across all word lines in NAND device 140. The reliability and BER of each word line in the NAND memory may vary from page to page. Some word lines may require more error correction than others. Such word lines can accommodate less data payload than word lines requiring less error correction. For example, where less than 10% of the word lines exhibit high BER while the remaining 90% are healthy enough for 1:1 mapped memory, the firmware may ultimately set all word lines to short data frames to accommodate the high ECC required by the word lines exhibiting high BER. In this case, the performance loss is determined by the word line with the highest BER. Therefore, according to some embodiments of this disclosure, firmware 172 may generate a payload overflow boundary lookup table 182 for each code rate in NAND device 140, thus generating multiple payload overflow boundary lookup tables 182 stored in SRAM 180. In a further embodiment of this disclosure, controller 130 may measure the bit rate of each word line in NAND device 140 after SSD 120 is powered on and write the measured bit rate to configuration file 167 for generating payload overflow boundary lookup table 182.

[0055] Figure 7 Description of embodiments according to this disclosure Figure 1The configuration file 167 shown herein comprises 700. Configuration file 167 may contain a word line to code rate mapping table 710. During read and write operations, CW offset module 164 indexes the word line to code rate mapping table 710 and obtains pointers to payload overflow boundary tables 720, 730 appropriate for the code rates associated with the word lines. For example, in table 710, word lines 0 to 3, 47, 48, 94, and 95 relate to code rates 60 / 64, and the entries in table 710 corresponding to these word lines contain pointers to the payload overflow boundary table (60 / 64) 720. As another example, in table 710, word lines 4 to 9, 46, and 49 relate to code rates 62 / 64, and the entries in table 710 corresponding to these word lines contain pointers to the payload overflow boundary table (62 / 64) 730. Therefore, this disclosure provides a common, flexible and customizable infrastructure that allows for changes in the bit rate of the NAND device 140 during the initialization of the SSD 120 without requiring reprogramming of the firmware 172.

[0056]

[0057] Table 1 Exemplary Payload Overflow Boundary Lookup Table

[0058] Figure 4 This section illustrates an exemplary flowchart of a method 400 for processing a read request from host 110 according to embodiments of the present disclosure. The method begins at step 410, where controller 130 receives a read request from host 110 via host interface 132. The read request contains the LCA of the read data and the payload size PL. In some embodiments, controller 130 may use the LCA in the read request to index into a logic-to-physical (L2P) lookup table 162 stored in flash translation layer 160 to obtain the MCA of the NAND device 140 in which the read data is stored. L2P lookup table 162 may also identify NAND channels 144 to 146 through which data can be accessed.

[0059] In step 420, controller 130 uses the MCA of the read data to obtain the codeword offset CW_Offset from codeword offset module 164, where the MCA is used to index into a lookup table 166 that maps each MCA in NAND device 140 to a codeword offset along the corresponding word line in the NAND device. As discussed above, the codeword offset is a measurement of the number of codewords at the beginning of the word line from which the codeword containing the read data begins. Once the codeword offset of the payload (e.g., codeword offset x) is obtained, the controller can use equations (1) to (4) to calculate the spill offset Spill_Offset of codeword CW(x) at codeword offset x. In some embodiments, firmware 172 uses codeword offset x to index into a payload spill boundary lookup table 182 (e.g., the lookup table in Table 1) stored in SRAM 180 of controller 130 to obtain the spill offset of codeword CW(x). Controller 130 also obtains the spill offset of the next adjacent codeword CW(x+1).

[0060] In step 430, the controller uses the codeword offset x and the associated overflow offset to read the main portion of the payload from the codeword CW(x). Here, the main portion of the payload is read from the overflow offset of the codeword CW(x) to the end of the codeword CW(x). Next, the controller uses the codeword offset x+1 and the associated overflow offset to read the remaining portion of the payload from the next adjacent codeword CW(x+1), from the beginning of the next adjacent codeword CW(x+1) to the overflow offset of the next adjacent codeword CW(x+1).

[0061] In step 440, the combination module 168 of the flash translation layer 160 of the controller 130 combines the read data read from the NAND device 140 from the payload. The payload includes the main portion from the codeword CW(x) and the remaining portion from the next adjacent codeword CW(x+1), similar to... Figure 3B The scenario depicted is for payload P3. The combining module 168 also appends a header, metadata, ECC bits, and parity bits to the read data. In step 450, the controller transmits the combined read data to the host 110.

[0062] Figure 5An exemplary flowchart illustrates a method 500 for processing a read request from host 110 according to another embodiment of this disclosure. The method begins at step 510, where controller 130 receives a read request from host 110 via host interface 132. The read request includes the LCA of the read data and the payload size PL. In some embodiments, controller 130 may use the LCA in the read request to index into a logic-to-physical (L2P) lookup table 162 stored in flash translation layer 160 to obtain the MCA of the NAND device 140 in which the read data is stored (step 520). L2P lookup table 162 may also identify NAND channels 144 to 146 through which data can be accessed.

[0063] In step 530, controller 130 uses the MCA of the read data to obtain the codeword offset CW_Offset from codeword offset module 164, where the MCA is used to index into a lookup table 166 that maps each MCA in NAND device 140 to a codeword offset along the corresponding word line in the NAND device. As discussed above, the codeword offset is a measurement of the number of codewords at the beginning of the word line from which the codeword containing the read data begins. Once the codeword offset of the payload (e.g., codeword offset x) is obtained, the method proceeds to step 540, where the controller uses equations (1) to (4) to calculate the spill offset Spill_Offset of codeword CW(x) at codeword offset x. In some embodiments, firmware 172 uses codeword offset x to index into a payload spill boundary lookup table 182 (e.g., the lookup table in Table 1) stored in SRAM 180 of controller 130 to obtain the spill offset of codeword CW(x). Controller 130 also obtains the spill offset of the next adjacent codeword CW(x+1).

[0064] In step 550, the controller uses the codeword offset x and the associated overflow offset to read the main portion of the payload from the codeword CW(x). Here, the main portion of the payload is read from the overflow offset of the codeword CW(x) to the end of the codeword CW(x). Next, the controller calculates the remaining portion of the payload to be read from the NAND device by subtracting the main portion from the payload size PL (step 560) and determines whether the remaining portion is zero (step 570). In step 570, the controller actually determines whether the entire payload is contained in the codeword CW(x) or whether some payload data has overflowed into the next codeword CW(x+1). If there is no remaining portion of the payload to be read (i.e., "Y" in step 570), then the combination module 168 of the flash translation layer 160 of the controller 130 combines the read data from the NAND device 140 from the payload (step 580). Here, the combination module 168 also appends the header, metadata, ECC bit and parity bit to the read data, and the controller transmits the combined read data to the host 110.

[0065] If a remaining portion of the payload to be read exists (i.e., 'N' in step 570), then the controller obtains the overflow offset of the next adjacent codeword CW(x+1) in step 572. This can be done by calculating using equations (1) to (4) or by indexing the codeword offset x+1 into the payload overflow boundary lookup table 182. In step 574, the controller reads the portion of the payload that has overflowed into the next adjacent codeword CW(x+1). The controller then loops back to step 570, where it determines whether a portion of the payload data to be read exists, and if so (i.e., 'N' in step 570), it repeats steps 572 and 574 until all payload data has been read (i.e., 'Y' in step 570). The controller then combines the main portion and the remaining portion of the payload and returns the read data to the host 110.

[0066] As an example, if the host requests data from payload P3 (e.g.) Figure 3BAs shown in the diagram, in step 550 of method 500, the controller reads the main portion of P3 from the overflow offset of codeword CW3 to the end of codeword CW3. Next, in step 560, the controller 130 determines whether there is a remaining portion of the payload P3 (i.e., "N" in step 570). Then, the controller 130 obtains the overflow offset of the next adjacent codeword CW4 (step 572) and reads the overflow data portion of codeword CW4 from the beginning of codeword CW4 to the overflow offset of codeword CW4 (in step 574). The overflow data portion in codeword CW4 is the remaining portion of the payload P3. Method 500 loops back to step 560, where the controller 130 calculates the remaining payload to be read. For the portion of P3 in the next adjacent codeword CW4, there is no remaining payload to be read (i.e., "Y" in step 570), therefore, the combination module of the controller 130 then combines the read data from the main portion and the remaining portion of the payload P3 in step 580. The module also appends the header, metadata, ECC bit, and parity bit to the payload P3, after which the read data is returned to the host.

[0067] As another example, if the host requests data from payload P7 (e.g.) Figure 3CAs shown in the diagram, in step 550 of method 500, the controller reads the main portion of P7 from the overflow offset of codeword CW7 to the end of codeword CW7. Next, in step 560, the controller 130 determines whether there is a remaining portion of the payload P7 (i.e., 'N' in step 570). Then, the controller 130 obtains the overflow offset of the next adjacent codeword CW8 (step 572) and reads the overflow data portion of codeword CW8 from the beginning of codeword CW8 to its overflow offset (in step 574). It should be noted that the overflow offset of codeword CW8 spans the size of the codeword. This is due to the cumulative and cyclical nature of the overflow offset, as illustrated in Table 1, where the overflow offset accumulates until it reaches the size of the codeword, after which it cycles back and begins to accumulate again. Then, method 500 loops back to step 560, where the controller 130 calculates the remaining payload to be read. For the portion of codeword CW8 containing P7, there is remaining payload to be read (i.e., 'N' in step 570). Controller 130 obtains the overflow offset of the next adjacent codeword CW9 (step 572) and reads the overflow data portion of codeword CW9 from the beginning of codeword CW9 to the overflow offset of codeword CW9 (in step 574). Then, method 500 loops back to step 560, where controller 130 calculates the remaining payload to be read. For the portion of codeword CW9 containing P7, there is no remaining payload to be read (i.e., 'Y' in step 570). The overflow data portions in codewords CW8 and CW9 form the remaining portion of payload P7. Next, the combination module of controller 130 combines the read data from the main portion and the remaining portion of payload P7 in step 580. The combination module also appends the header, metadata, ECC bits, and parity bits to payload P7, after which the read data is returned to the host.

[0068] As mentioned above, firmware 172 can access configuration file 167 stored in the controller to determine the bit rate of NAND device 140 before performing any calculations (e.g., the calculations described in equations (1) to (4)). The bit rate is also used to generate a payload overflow boundary lookup table 182 stored in SRAM 180 of controller 130. Additionally, the controller can periodically measure the bit rate of NAND device 140 and update the bit rate stored in configuration file 167. Figure 6 This is an exemplary flowchart illustrating method 600 for using bitrate when generating payload overflow boundary lookup table 182.

[0069] Method 600 begins at step 610, at which point SSD 120 boots. Controller 130 detects the boot of SSD 120 and determines whether it is the first boot since manufacturing (step 620). If it is the first boot (i.e., 'Y' in step 620), then controller 130 uses a preset bitrate in profile 167. This preset bitrate may be written to profile 167 by the manufacturer during the assembly of SSD 120. However, if it is not the first boot since manufacturing (i.e., 'N' in step 620), then controller uses the most recently stored bitrate in profile 167. The bitrate is then read from profile 167 (step 640).

[0070] In step 650, controller 130 reads the BER of NAND device 140 and determines whether the bit rate is sufficient (step 660). As mentioned above, the bit rate indicates how much smaller each codeword needs to be than the payload to accommodate ECC bits in each codeword to match the BER of the NAND device. If controller 130 determines that the bit rate is sufficient (i.e., 'Y' in step 660), then controller 130 generates a payload overflow boundary lookup table 182 using equations (1) to (4) in step 670 for use during operation of SSD 120. If controller 130 determines that the bit rate is insufficient for the BER of NAND device 140 (i.e., 'N' in step 660), then controller 130 updates the bit rate in step 665, writes the new bit rate value to configuration file 167, and generates a payload overflow boundary lookup table 182 on an ad-hoc basis using equations (1) to (4) in step 670 for use during operation of SSD 120.

[0071] Figure 8 This description is for use with word line to code rate tables (e.g.) Figure 7The following is an exemplary flowchart of a method 800 for determining an overflow offset from a code rate-specific payload overflow boundary lookup table (710) shown in the diagram. Method 800 begins with controller 130 receiving a host read request containing a payload with an LCA (step 810). In some embodiments, controller 130 may use the LCA in the read request to index into a lookup table (LUT) 162 stored in flash translation layer 160 to obtain the MCA of the NAND device 140 where the read data is stored (step 820). In step 830, controller 130 uses the MCA of the read data to obtain the codeword offset CW_Offset from codeword offset module 164, where the MCA is used to index into a lookup table 166 that maps each MCA in NAND device 140 to a codeword offset in the NAND device. Controller also uses the MCA of the read data to obtain the word line (WL) along which the codeword storing the read data is located (step 840). In step 845, word lines are used to index into the word line-to-code rate mapping table (e.g., Figure 7 In steps 850, the pointer to the appropriate payload overflow boundary lookup table is obtained from tables 710 and 720. In step 850, the payload overflow boundary table is indexed using the codeword offset CW_Offset to obtain the overflow offset.

[0072] In the foregoing, all descriptions of "module" or "layer" should be understood to mean multiple circuits within the controller that facilitate the described function. Such circuits may include electronic components formed on a semiconductor chip, such as transistors and resistors. Furthermore, all descriptions of "codeword size" should be understood to mean the data length of a codeword, and such terms are used interchangeably throughout this disclosure. It should be noted that the terms "about" or "approximately" indicate a range of ±20% of the stated value.

[0073] Those skilled in the art will appreciate other objects, advantages, and embodiments of the invention, which are within the scope of this description and drawings. For example (but not limited to), structural or functional elements can be rearranged according to the invention. Similarly, the principles of the invention can be applied to other instances, even those not specifically described herein, but which are within the scope of the invention.

Claims

1. A method executed by a controller of a solid-state drive, the method comprising: Receives a read request from the host for reading data stored in one or more of the plurality of non-volatile semiconductor storage devices of the solid-state drive; A first codeword and a second codeword are identified from one or more codewords stored in the plurality of non-volatile semiconductor memory devices, the first codeword and the second codeword including the read data corresponding to the read request; Retrieve the first code rate associated with the first codeword and the second code rate associated with the second codeword from the configuration file stored in the controller; Indexed to a payload overflow boundary lookup table, the payload overflow boundary lookup table maps codewords in the non-volatile semiconductor memory device to overflow offsets based on the first code rate and / or the second code rate, the overflow offsets identifying the position within the first codeword where the read data begins; In response to the read request, a first portion of the read data contained in the first codeword is read using the first code rate, and a second portion of the read data contained in the second codeword is read using the second code rate; The first part and the second part are combined to form the combined read data; and In response to the read request, the combined read data is transmitted to the host. in The second codeword is stored adjacent to the first codeword in one or more of the plurality of non-volatile semiconductor memory devices, and The combined read data has a data length greater than the first data length of the first codeword or the second data length of the second codeword.

2. The method of claim 1, wherein the read data includes a logical cluster address (LCA).

3. The method according to claim 2, further comprising: The LCA of the read data is converted into the Media Cluster Address (MCA) in the non-volatile semiconductor memory device where the read data is stored.

4. The method of claim 3, further comprising: Determine the codeword offset corresponding to the MCA, the codeword offset identifying the first codeword among the plurality of codewords where the read data begins.

5. The method of claim 4, further comprising: Identify the overflow offset associated with the first codeword offset.

6. The method of claim 5, further comprising: The first portion of the read data is read from the overflow offset of the first codeword to the end of the first codeword.

7. The method of claim 6, further comprising: Calculate the second portion of the data to be read.

8. The method of claim 7, further comprising: In response to the second portion of the read data being non-zero, Identify the overflow offset of the second codeword, and The second portion of the read data is read from the beginning of the second codeword to the overflow offset of the second codeword.

9. The method of claim 8, further comprising: Determine whether the second part of the read data has overflowed into the next adjacent codeword.

10. The method of claim 9, further comprising: In response to the second portion of the read data overflowing into the next adjacent codeword. Identify the overflow offset of the next adjacent codeword, and The overflowed second portion of the read data is read from the beginning of the next adjacent codeword to the overflow offset of the next adjacent codeword.

11. The method of claim 3, further comprising: The index is directed to an address lookup table that maps the LCA to the MCA in the non-volatile semiconductor memory device in which the read data is stored.

12. The method of claim 4, further comprising: The index is directed to a codeword lookup table, which maps the MCA to the codeword offset of the non-volatile semiconductor memory device in which the read data is stored.

13. The method according to claim 5, wherein the first data length and the second data length are equal, the method further comprising: Data overflow per codeword is determined by subtracting the first data length from the data length of the read data; The total overflow in the non-volatile semiconductor memory device for each codeword offset is determined by multiplying the overflow of each codeword by the codeword offset; and The overflow offset is determined by dividing the total overflow by the first data length.

14. The method of claim 5, wherein the plurality of codewords are stored on one or more word lines in the non-volatile semiconductor memory device.

15. The method of claim 14, wherein each of the word lines has a different code rate.

16. The method of claim 15, wherein the controller generates a payload overflow boundary lookup table for each bit rate.

17. The method of claim 16, wherein the read data continues across a plurality of word lines, the method further comprising: Determine the word line associated with each codeword, and Select the payload overflow boundary lookup table based on the associated word line.

18. The method of claim 1, further comprising: The code rate mapping table of the non-volatile semiconductor memory device is stored in the configuration file in the read-only memory within the controller. The code rate mapping table stores the code rates associated with multiple word lines in the non-volatile semiconductor memory device.

19. The method of claim 18, further comprising: Determine the bit error rate associated with each of the plurality of nonvolatile semiconductor memory devices; The bit rate of at least one of the non-volatile semiconductor memory devices is adjusted based on the bit error rate. and Update the bitrate in the configuration file.

20. The method of claim 1, wherein combining the read data includes combining the first and second portions of the read data with a header, an error correction code (ECC), and a parity check code before transmitting the read data to the host.

21. The method of claim 1, wherein each of the plurality of non-volatile semiconductor memory devices comprises NAND memory.

Images