Ecc parity biasing for key-value pair data storage devices

Abstract

Error Correction Code (ECC) encoding is used for key-value data storage devices. In one embodiment, the controller includes a memory interface configured to connect to the memory; an ECC engine configured to perform ECC encoding on data stored in the memory; a controller memory including a flash translation layer and a namespace database; and an electronic processor. The electronic processor is configured to receive data to be stored, divide the data into multiple sub-code blocks, and assign parity bits to each of the multiple sub-code blocks.

Description

Background Technology

[0001] This application generally relates to data storage devices, and more specifically, to error correction codes (ECCs) encoded in data storage devices.

[0002] Key-value (KV) databases store a fixed amount of user data associated with a key that is addressable as a complete entity. For example, user data can be photos, records, or files. From the host's perspective, photos or files can be retrieved using a single key / read address instead of multiple read addresses containing the data that makes up the photo. Using a single key / read address simplifies database management for some applications, thereby improving the performance of those applications. Summary of the Invention

[0003] The technology disclosed herein improves the operation of the aforementioned key-value (KV) database. Specifically, the KV data storage device of this disclosure utilizes the unique structure of a KV database, where each value is written sequentially and completely, and each value must be read completely, or up to a certain point, but cannot be read from the index. As described in more detail below, the KV data storage device of this disclosure utilizes this unique structure to provide better performance, reduced latency, lower power consumption, and better correction capability, reliability, and durability of the KV data storage device.

[0004] The first advantage of supporting KV databases at the storage device level is the improved performance in terms of transfers per second. This advantage arises from two reasons: 1) the translation layer from key / value to block storage in the host can be removed or becomes unnecessary, and 2) the removal of the translation layer eliminates two layers of mapping and transaction information, which increases the number of transactions per second, reduces write amplification, and reduces latency because commands on the bus are reduced to a single transfer of the entire key-value pair.

[0005] A second advantage of the KV data storage device disclosed herein is the simplification and enablement of computational storage (near-storage computation). User data on the KV data storage device can now be identified as complete units, rather than as various fragments that may be contiguous or discontinuous in normal storage operations.

[0006] This disclosure provides a data storage controller. In one embodiment, the data storage controller includes a memory interface, an error correction code (ECC) engine, a controller memory, and an electronic processor communicatively connected to the ECC engine and the controller memory. The memory interface is configured to connect to a memory. The error correction code (ECC) engine is configured to perform ECC encoding on data stored in the memory. The controller memory includes a flash translation layer (FTL) and a namespace database. When the FTL is executed, the electronic processor is configured to receive data to be stored, divide the data into multiple sub-code blocks, and assign parity bits generated by the ECC engine to each sub-code block.

[0007] This disclosure also provides a method. In one embodiment, the method includes receiving data to be stored in a key-value (KV) database using an electronic processor of a data storage controller, dividing the data into a plurality of sub-code blocks, and assigning parity bits to each of the plurality of sub-code blocks.

[0008] This disclosure also provides a memory device that supports storing data in a key-value namespace. The memory device includes a memory and a controller. The memory includes a key-value (KV) database. The controller is configured to perform a first ECC encoding process that assigns parity checks to the user data when writing user data to the KV database.

[0009] Thus, various aspects of this disclosure provide improvements, at least in the technical field of data storage devices and their design and architecture. This disclosure can be embodied in various forms, including hardware or circuitry controlled by firmware (i.e., code executed on a processor), computer systems and networks; and hardware implementation methods, signal processing circuits, memory arrays, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), etc. The foregoing summary is intended only to give a general idea of ​​various aspects of this disclosure and does not limit the scope of this disclosure in any way. Attached Figure Description

[0010] Figure 1 This is a block diagram of a system including a data storage device with ECC encoding / decoding, according to some embodiments of this disclosure.

[0011] Figure 2 This is a graph illustrating the correction capability of exemplary LDPC codes of different lengths according to some embodiments of this disclosure.

[0012] Figure 3 This is a diagram illustrating codewords with asymmetric parity allocation according to some embodiments of this disclosure.

[0013] Figure 4This is a flowchart illustrating an asymmetric parity check allocation process according to some embodiments of the present disclosure.

[0014] Figure 5 This is a diagram illustrating an exemplary parity check matrix with a spatially coupled LDPC structure according to some embodiments of the present disclosure.

[0015] Figure 6 This is a flowchart illustrating another asymmetric parity allocation process according to some embodiments of the present disclosure.

[0016] Figure 7 This is a diagram illustrating alternative exemplary spatially coupled LDPC structures according to some embodiments of the present disclosure.

[0017] Figure 8 This is a flowchart illustrating another asymmetric parity check allocation process according to some embodiments of this disclosure. Detailed Implementation

[0018] In the following description, numerous details, such as data storage device configuration and controller operation, are set forth in order to provide an understanding of one or more aspects of this disclosure. It will be apparent to those skilled in the art that these specific details are merely exemplary and are not intended to limit the scope of this application. Specifically, the functions associated with the memory device may be performed by hardware (e.g., analog or digital circuitry), a combination of hardware and software (e.g., program code or firmware stored in a non-transitory computer-readable medium and executed by processing or control circuitry), or any other suitable means. The following description is intended only to give a general idea of ​​the various aspects of this disclosure and does not limit the scope of this disclosure in any way.

[0019] Figure 1 This is a block diagram of a system 100 including a data storage device 102 with ECC encoding / decoding, according to some embodiments of this disclosure. Figure 1 In this example, system 100 includes a data storage device 102 and a host device 150 (also referred to as an "external electronic device"). The data storage device 102 includes a controller 120 and a memory 104 (e.g., non-volatile memory) coupled to the controller 120.

[0020] exist Figure 1 An example of the structural and functional features provided by controller 120 is shown. However, controller 120 is not limited to those provided by controller 120. Figure 1 The controller 120 provides structural and functional features. The controller 120 may include... Figure 1 Fewer or additional structural and functional features not shown in the diagram.

[0021] Data storage device 102 and host device 150 may be operatively coupled via a connector (e.g., communication path 110) such as a bus or wireless connector. In some examples, data storage device 102 may be embedded within host device 150. Alternatively, in other examples, data storage device 102 may be removed from host device 150 (i.e., "removably" coupled to host device 150). For example, data storage device 102 may be removably coupled to host device 150 according to a removable universal serial bus (USB) configuration. In some implementations, data storage device 102 may include or correspond to a solid-state drive (SSD) that can be used as an embedded storage drive (e.g., a mobile embedded storage drive), an enterprise storage drive (ESD), a client storage device, or a cloud storage drive, or other suitable storage drive.

[0022] Data storage device 102 may be configured to be coupled to host device 150 via communication path 110 (such as a wired communication path and / or a wireless communication path). For example, data storage device 102 may include interface 108 (e.g., a host interface) that enables communication via communication path 110 between data storage device 102 and host device 150, such as when interface 108 is communicatively coupled to host device 150.

[0023] Host device 150 may include an electronic processor and memory. The memory may be configured to store data and / or instructions executable by the electronic processor. The memory may be a single memory, or may include one or more memories, such as one or more non-volatile memories, one or more volatile memories, or combinations thereof. Host device 150 may issue one or more commands to data storage device 102, such as one or more requests 134 to erase data at memory 104 of data storage device 102, read data from the memory, or write data to the memory. For example, one or more requests 134 may include a key-value pair (KV) or read address associated with user data 132, where user data 132 is an entire photograph, an entire record, or an entire file. Furthermore, host device 150 may be configured to provide data to be stored at memory 104 (such as user data 132) or request data to be read from memory 104. Host device 150 may include a mobile smartphone, music player, video player, game console, e-book reader, personal digital assistant (PDA), computer (such as a laptop or notebook computer), any combination thereof, or other suitable electronic device.

[0024] Host device 150 communicates via a memory interface that enables reading from and writing to memory 104. In some examples, host device 150 may operate according to industry specifications such as the Universal Flash Storage (UFS) Host Controller Interface Specification. In other examples, host device 150 may operate according to one or more other specifications such as the Secure Digital (SD) Host Controller Specification or other suitable industry specifications. Host device 150 may also communicate with memory 104 according to any other suitable communication protocol.

[0025] The memory 104 of the data storage device 102 may include non-volatile memory (e.g., NAND, BiCS series memory, or other suitable memory). In some examples, memory 104 may be any type of flash memory. For example, memory 104 may be a two-dimensional (2D) memory or a three-dimensional (3D) flash memory. Memory 104 may include one or more memory dies 103. Each of the one or more memory dies 103 may include one or more blocks (e.g., one or more erase blocks). Each block may include one or more sets of memory elements, such as a set of representative memory elements 107A-107N. The set of memory elements 107A-107N may be configured as word lines. The set of memory elements 107A-107N may include multiple memory elements (e.g., memory cells referred to herein as a “string”), such as representative memory elements 109A and 109N, respectively.

[0026] Memory 104 may include support circuitry (such as read / write circuitry 140) to support the operation of one or more memory dies 103. Although depicted as a single component, read / write circuitry 140 may be divided into separate components of memory 104, such as read circuitry and write circuitry. Read / write circuitry 140 may be external to one or more memory dies 103 of memory 104. Alternatively, one or more individual memory dies may include corresponding read / write circuitry operable to read from and / or write to storage elements within the individual memory die, independent of any other read and / or write operations at any other memory die.

[0027] Data storage device 102 includes a controller 120 coupled to memory 104 (e.g., one or more memory dies 103) via bus 106, memory interface 122 (e.g., interface circuitry), another structure, or a combination thereof. For example, bus 106 may include multiple different channels enabling controller 120 to communicate with each of the one or more memory dies 103, in parallel with and independently of communication with the other memory dies 103. In some implementations, memory 104 may be flash memory.

[0028] The controller 120 is configured to receive data and instructions from the host device 150 and send data to the host device 150 via the memory interface 122. For example, the controller 120 can send data to the host device 150 via interface 108, and the controller 120 can receive data from the host device 150 via interface 108.

[0029] Controller 120 is configured to send data and commands (e.g., memory operation 136) to memory 104 via memory interface 122. For example, controller 120 is configured to send data and write commands via memory interface 122 to cause memory 104 to store data at a specified address. The write command may specify the physical address of memory 104 to be used to store a portion of the data (e.g., the physical address of a word line of memory 104).

[0030] Controller 120 is configured to send read commands to memory 104 via memory interface 122 to access data from a specified address in memory 104. The read command may specify the physical address of a region of memory 104 (e.g., the physical address of a word line in memory 104). Controller 120 may also be configured to send data and commands to memory 104 via memory interface 122, which may be associated with background scan operations, garbage collection operations and / or wear leveling operations, or other suitable memory operations.

[0031] Controller 120 may include memory 124, error correction code (ECC) engine 126, and processor 128. Memory 124 may be configured to store data and / or instructions executable by processor 128. Memory 124 may include flash translation layer 160 and namespace database 162. Flash translation layer 160 may be hardware circuitry or instructions executable by processor 128. Flash translation layer 160 may enable processor 128 to set namespaces (i.e., key-value pair (KV) namespaces and block I / O namespaces) associated with different physical regions of memory 104 in namespace database 162. In some examples, host device 150 includes a command in request 134 to cause processor 128 to set namespaces (including KV namespaces and block I / O namespaces). In other examples, flash translation layer 160 may enable processor 128 to set namespaces (including KV namespaces and block I / O namespaces) in response to receiving a key from host device 150 in request 134.

[0032] KV namespaces represent KV databases in data storage device 102, and each KV namespace includes a key associated with a volume of data across multiple addresses, and the data is indexed based on that key. In some examples, each KV namespace may also include multiple key-value pairs. Each block I / O namespace includes a logical address range, and host device 150 can access any address within that logical address range.

[0033] The flash translation layer 160 can also select or generate one of the KV namespaces or block I / O namespaces based on one of the requests in 134 and the size of the user data 132. For example, when request 134 includes a key and the size of user data 132 is equal to or greater than a threshold (e.g., 4KB), the flash translation layer 160 generates (when the key is new) or selects (when the key has been seen) one of the KV namespaces associated with that key. Alternatively, when request 134 includes a key and the size of user data 132 is less than a threshold (e.g., 4KB), the flash translation layer 160 generates (when the key is new) or selects (when the key has been seen) one of the block I / O namespaces associated with that key and a single address. Furthermore, when request 134 includes a single address, the flash translation layer 160 generates (when the address is new) or selects (when the address has been seen) one of the block I / O namespaces associated with that address. In other examples, request 134 also requests that user data 132 be saved to a block I / O namespace or a KV namespace.

[0034] When generating or selecting either a key-value (KV) namespace or a block I / O namespace, the flash translation layer 160 can control the ECC engine 126 to perform ECC encoding / decoding via memory operations 136 and memory interface 122, based on the selected namespace and user data 132. In some examples, the ECC engine 126 can perform asymmetric ECC encoding / decoding via memory operations 136 based on the selection of a key-value (KV) namespace. This process is referred to herein as "asymmetric ECC encoding / decoding" and will be referenced below. Figures 3-8 A more detailed description follows. Additionally, in these examples, the ECC engine 126 can also perform ECC encoding / decoding using spatially coupled low-density parity-check (SC-LDPC) codes via memory operation 136, based on the selection of the KV namespace. This process is referred to herein as "SC-LDPC asymmetric ECC encoding / decoding" and will be referenced below. Figures 5-8 A more detailed description follows. Furthermore, in some examples, a separate and distinct application or circuitry, independent of any application stored in memory 124, can control the ECC engine 126 to perform asymmetric ECC encoding / decoding or SC-LDPC asymmetric ECC encoding / decoding as described herein.

[0035] The retrieval commands for the KV database in data storage device 102 require reading values ​​from the beginning and fully up to a specific point, rather than reading based on an index. The method described in this paper uses the unique structure of KV database retrieval commands to provide better performance, latency, power consumption, and correction capabilities for data storage device 102.

[0036] Longer ECC values ​​perform better and result in fewer decoding failures than shorter ECC values. For example, Figure 2 Figure 200 shows examples of various ECC lengths for the X4 memory die. The y-axis 202 of Figure 200 provides the block error rate (BLER) for each code length as defined by legend 206. The x-axis 204 of Figure 200 provides the bit error rate (BER) for each code length as defined by legend 206. As shown, longer ECCs have greater correction capability than shorter ECCs.

[0037] Figure 3An example of asymmetric code parity allocation among subcodes of code block 300 is provided. For example, a subcode structure is one in which a smaller portion of the data has local parity bits available for local decoding (e.g., data from no other subcodes). Alternatively, joint parity bits can be used to concatenate several subcodes, allowing the subcodes to be jointly decoded as longer codes for better correction capabilities. Code block 300 includes multiple subcodes 302 (e.g., first subcode 302A, second subcode 302B, up to final subcode 302N). Code block 300 can have any number of subcodes 302. Each subcode includes a data block 304 and a parity block 306. For example, first subcode 302A has a first data block 304A and a first parity block 306A, second subcode 302B has a second data block 304B and a second parity block 306B, and final subcode 302N has a final data block 304N and a final parity block 306N. In addition, code block 300 includes a global parity block 308 following the final parity block 306N.

[0038] In some examples, parity is evenly distributed across each subcode. For instance, the first subcode 302A, the second subcode 302B, and the final subcode 302N are each assigned an equal amount of parity. In other examples, more parity is assigned to the earlier subcodes (e.g., the first subcode 302A) compared to the later subcodes (e.g., the second subcode 302B and the final subcode 302N). As parity is assigned to each subcode 302, the parity allocation can decrease linearly. In other examples, the reduction in parity can be non-linear, such that the first parity block 306A and the second parity block 306B have the same number of parity bits (e.g., N parity bits), and the subsequent parity block 306 has fewer parity bits (e.g., 0.75N parity bits). Therefore, the first parity block 306A is greater than (i.e., includes more parity bits) or equal to (i.e., includes the same number of parity bits) the second parity block 306B, and the second parity block 306B is greater than the final parity block 306N. Since the codes in the KV database are read sequentially, the initial subcode 302 (such as the first subcode 302A) can be read by itself, and thus can be decoded without subsequent subcodes 302, resulting in a shorter length. Furthermore, subsequent subcodes are always read after the preceding code, so the preceding subcode can be used and has a longer code length. Therefore, for the same amount of correction, subsequent subcodes require less parity. Thus, since the total parity to be allocated is finite, more parity is allocated to the earlier subcode 302 to increase its correctability.

[0039] Figure 4 This is a flowchart illustrating an asymmetric parity check allocation process 400 (i.e., asymmetric ECC encoding / decoding) according to various aspects of this disclosure. Figure 4 Compared to Figure 1 The controller 120 is described.

[0040] like Figure 4 As shown, the asymmetric parity allocation process 400 includes a controller 120 receiving data to be stored in memory 104 (in block 402). The data may be, for example, user data 132. The asymmetric parity allocation process 400 includes the controller 120 dividing the data into sub-code blocks (such as sub-code 302) (in block 404).

[0041] The asymmetric parity allocation process 400 includes the controller 120 asymmetrically inserting parity bits between sub-code blocks. For example, a first parity block 306A is added to (i.e., assigned to) a first sub-code 302A, a second parity block 306B is added to a second sub-code 302B, and a final parity block 306N is added to a final sub-code 302N. In some examples, a global parity block 308 is added to the data.

[0042] The asymmetric parity allocation process 400 includes the controller 120 writing sub-code blocks to memory 104. In some examples, the controller 120 writes sub-code blocks to memory 124. In other examples, the controller 120 writes sub-code blocks to the memory of the host device 150. The asymmetric parity allocation process 400 includes the controller 120 decoding sub-code blocks sequentially (e.g., serial order, first / last order, or other order). In some examples, only the first sub-code 302A, which includes the first data block 304A and the first parity block 306A, is decoded by the controller 120. In other examples, the first sub-code 302A and the second sub-code 302B, which include the second data block 304B and the second parity block 306B, are decoded. In some examples, the entire code block 300 is decoded.

[0043] SC-LDPC codes can also be used to implement asymmetric parity allocation. SC-LDPC codes consist of blocks. Figure 5Exemplary SC-LDPC parity matrix structure 500 is provided according to various aspects of this disclosure. The SC-LDPC parity matrix structure 500 includes multiple blocks 502, such as a first block 502A, a second block 502B, a third block 502C, a fourth block 502D, and a fifth block 502E. Parity checks are unevenly distributed among each block 502. Specifically, more parity checks (e.g., more rows in the parity matrix) are assigned to the beginning blocks, and fewer parity checks are assigned to blocks towards the ends of the SC-LDPC parity matrix structure 500. For example, the first block 502A receives the most parity checks, and the fifth block 502E receives the fewest parity checks.

[0044] Figure 6 This is a flowchart illustrating an asymmetric parity check allocation process 600 (i.e., SC-LDPC asymmetric ECC encoding / decoding) according to various aspects of this disclosure. Figure 6 Compared to Figure 1 The controller 120 is described.

[0045] like Figure 6 As shown, the asymmetric parity allocation process 600 includes a controller 120 receiving data to be stored in memory 104 (in block 602). The data may be, for example, user data 132. The asymmetric parity allocation process includes the controller 120 dividing the data into spatial blocks (such as multiple blocks 502) (in block 604).

[0046] The asymmetric parity allocation process 600 includes the controller 120 asymmetrically allocating parity bits to each of a plurality of spatial blocks 502 (in block 606). The asymmetric parity allocation process 600 includes the controller 120 writing the plurality of spatial blocks 502 to memory 104 (in block 608). In some examples, each of the plurality of spatial blocks 502 is written to memory 104 in a sequential order (e.g., serial order, first / last order, or other sequential order). For example, first block 502A is written to memory 104 first, then second block 502B, and so on. In some examples, the controller 120 writes the plurality of spatial blocks 502 to memory 124. In other examples, the controller 120 writes the plurality of spatial blocks 502 to the memory of host device 150. The asymmetric parity allocation process 600 includes the controller 120 decoding the plurality of spatial blocks 502 in a sequential order (in block 610). In some examples, the data is decoded during the sliding window process.

[0047] Figure 7Another exemplary SC-LDPC parity check matrix structure 700 according to various aspects of this disclosure is shown. The SC-LDPC parity check matrix structure 700 includes multiple blocks 702, such as a first block 702A, a second block 702B, a third block 702C, and a fourth block 702D. Parity checks are unevenly distributed among each block 702. The first and last blocks in the SC-LDPC code inherently have more parity checks and can be stored first in memory 104. Figure 7 In the example, the first block 702A and the fourth block 702D contain more parity checks than the second block 702B and the third block 702C. Because the first block 702A and the fourth block 702D contain more parity checks, they are written to memory 104 first.

[0048] Figure 8 This is a flowchart illustrating an asymmetric parity check allocation process 800 according to various aspects of this disclosure. Figure 8 Compared to Figure 1 The controller 120 is described.

[0049] like Figure 8 As shown, the asymmetric parity allocation process 800 includes a controller 120 receiving data to be stored in memory 104 (in block 802). The data may be, for example, user data 132. The asymmetric parity allocation process includes the controller 120 dividing the data into spatial blocks (such as multiple blocks 702) (in block 804).

[0050] The asymmetric parity allocation process 800 includes the controller 120 asymmetricly allocating parity bits to each of a plurality of spatial blocks 702 (in block 806). The asymmetric parity allocation process 800 includes the controller 120 writing the first spatial block (i.e., first block 702A) to memory 104 (in block 808). The asymmetric parity allocation process 800 includes the controller 120 writing the last spatial block (i.e., fourth block 702D) to memory 104 (in block 810). As described above, the first and last spatial blocks in the SC-LDPC parity matrix structures 500 and 700 inherently have more parity bits. By storing the last spatial block immediately after the first spatial block, more parity bits are allocated at the beginning of the stored memory block.

[0051] The asymmetric parity allocation process 800 includes controller 120 writing remaining space blocks 702 to memory 104 (in block 812). In some examples, controller 120 writes multiple space blocks 702 to memory 124. In other examples, controller 120 writes multiple space blocks 702 to the memory of host device 150. In some examples, each of the remaining space blocks 702 is written to memory 104 in a sequential order (e.g., serial order, first / last order, or other sequential order). For example, after the fourth block 702D, controller 120 writes the second block 702B to memory 104, and then writes the third block 702C. The asymmetric parity allocation process 800 includes controller 120 decoding multiple space blocks 702 in a sequential order as they are written to memory 104 (in block 814). In some examples, decoding is performed during a sliding window process.

[0052] Regarding the processes, systems, methods, heuristics, etc., described herein, it should be understood that although the steps of such processes are described as being performed according to an ordered sequence, such processes can be practiced with the steps performed in a sequence other than that described herein. It should also be understood that some steps may be performed simultaneously, other steps may be added, or some steps described herein may be omitted. In other words, the description of processes herein is provided for the purpose of illustrating certain embodiments and should in no way be construed as limiting the claims.

[0053] Therefore, it should be understood that the above description is intended to be exemplary and not restrictive. Many embodiments and applications beyond the examples provided will be apparent upon reading the above description. The scope should not be determined by reference to the above description, but rather by reference to the full scope of the appended claims together with the equivalents to which such claims are entitled. It is anticipated and intended that the technology discussed herein will be further developed in the future, and the disclosed systems and methods will be incorporated into such future embodiments. In conclusion, it should be understood that modifications and variations are possible with this application.

[0054] All terms used in the claims are intended to be given their broadest reasonable construction and their common meaning as understood by one skilled in the art described herein, unless expressly indicated otherwise herein. Specifically, the use of singular articles such as “a,” “the,” “the,” etc., should be understood to mean one or more of the elements indicated in the statement, unless expressly limited to the contrary by the statement of the claims.

[0055] A summary of the specification is provided to allow readers to quickly determine the nature of the technical disclosure. It should be understood that the submitted content is not intended to interpret or limit the scope or meaning of the claims. Furthermore, in the foregoing detailed description, it can be seen that various features are grouped together in various embodiments for the purpose of simplifying this disclosure. This approach of the disclosure should not be construed as reflecting an intention that the claimed embodiments require more features than expressly recited in each claim. Rather, as reflected in the appended claims, the subject matter of the invention lies in fewer than all features of a single disclosed embodiment. Therefore, the appended claims are hereby incorporated into the detailed description, wherein each claim is independently claimed as a separate subject matter.

Claims

1. A data storage controller, the data storage controller comprising: A memory interface configured to connect to a memory; An error correction code (ECC) engine, which is configured to perform ECC encoding on data stored in memory; A controller memory, comprising a flash translation layer (FTL) and a key-value (KV) database; and An electronic processor, communicatively connected to the ECC engine and the controller memory, is configured to perform the FTL as follows: Receive data to be stored in the KV database; The data is divided into multiple sub-code blocks, and The parity bit generated by the ECC engine is assigned to each of the plurality of sub-code blocks; and The multiple sub-code blocks mentioned above are multiple blocks that are part of a Spatial Coupled Low-Density Parity-Check (SC-LDPC) structure.

2. The data storage controller of claim 1, wherein the parity bit is asymmetrically assigned to each of the plurality of sub-code blocks.

3. The data storage controller according to claim 2, wherein the first sub-code block among the plurality of sub-code blocks receives more parity bits compared to the last sub-code block among the plurality of sub-code blocks.

4. The data storage controller of claim 1, wherein the electronic processor is further configured to: After the parity bit is assigned to each of the plurality of sub-code blocks, the plurality of sub-code blocks are written to the memory, wherein the plurality of sub-code blocks are written sequentially.

5. The data storage controller of claim 1, wherein the electronic processor is further configured to: After assigning the parity bit to each of the plurality of blocks, the first block of the plurality of blocks is written to the memory, and After the first block of the plurality of blocks is written to the memory, the last block of the plurality of blocks is written to the memory.

6. The data storage controller of claim 1, wherein the electronic processor is further configured to: After the parity bit is assigned to each of the plurality of blocks, the plurality of blocks are written to the memory, wherein the plurality of blocks are written to the memory sequentially.

7. The data storage controller of claim 6, wherein the electronic processor is further configured to: Using a sliding window procedure, the plurality of blocks from the memory are decoded in the order in which they were written to the memory.

8. A method for operating a data storage controller, the method comprising: The electronic processor of the data storage controller receives data to be stored in the key-value (KV) database. The data is divided into multiple sub-code blocks, and The parity bit is assigned to each of the plurality of sub-code blocks; and The multiple sub-code blocks mentioned above are multiple blocks that are part of a Spatial Coupled Low-Density Parity-Check (SC-LDPC) structure.

9. The method of claim 8, wherein the parity bit is asymmetrically assigned to each of the plurality of sub-code blocks.

10. The method of claim 9, wherein the first sub-code block among the plurality of sub-code blocks receives more parity bits compared to the last sub-code block among the plurality of sub-code blocks.

11. The method of claim 8, further comprising: After assigning the parity bit to each of the plurality of sub-code blocks, the plurality of sub-code blocks are written to the key-value (KV) database.

12. The method of claim 11, wherein writing the sub-code block into the KV database comprises: Write the first block of the plurality of blocks into the KV database, and After writing the first block of the plurality of blocks into the KV database, the last block of the plurality of blocks is written into the KV database.

13. The method of claim 12, further comprising: The plurality of blocks from the KV database are decoded in the order in which they are written into the KV database, wherein a sliding window procedure is used to decode the plurality of blocks.

14. A memory device that supports storing data in a key-value pair namespace, the memory device comprising: The memory includes a key-value (KV) database; and The controller is configured to: A first error correction code (ECC) encoding process is performed, wherein parity is allocated to the first user data when the first user data is written to the KV database; as well as The second ECC encoding process is performed when the second user data is written to the second KV database located in the external electronic device. The second ECC encoding process assigns parity checks to the second user data. and In order to perform the first ECC encoding process of allocating the parity check to the user data when writing the user data to the KV database, the controller is also configured to divide the user data into multiple blocks of a spatially coupled low-density parity check (SC-LDPC) structure.

15. The memory device of claim 14, wherein the first ECC encoding process asymmetrically distributes the parity bit in the user data, and wherein the first ECC encoding process distributes more parity bits at the beginning of the user data than at the end of the user data.

16. The memory device of claim 14, wherein, in order to perform the first ECC encoding process of allocating the parity check to the user data when writing the user data into the KV database, the controller is further configured to: Parity checks are asymmetrically assigned to the multiple blocks.

17. The memory device of claim 16, wherein, in order to perform the first ECC encoding process of allocating the parity check to the user data when writing the user data to the KV database, the controller is further configured to: Write the first block of the plurality of blocks into the KV database, and After the first block is written to the KV database, the last block among the plurality of blocks is written to the KV database.

Images