ML-assisted dynamic decoding gear selection

Abstract

To provide a multi-gear error correction code (ECC) decoder using a fast low power decoder and a slow high power decoder.SOLUTION: A multi-gear ECC decoder includes a high power decoder and a low power decoder. In order to significantly reduce the decoding time for high-BER codewords using a slow high power decoder, rather than decoding codewords in either slow high power or fast low power, a controller switches between slow high power decoding and fast low power decoding during the decoding process. The controller first will determine, based on a predetermined factor, whether to start decoding in slow high power or fast low power. Once a decoding power is determined, then the decoding will begin. During the decoding process the decoding transitions from a first power lever decoder to a second power level decoder. The decoding will continue in the second decoding power level after the transition, until the decoding is completed or if another switch needs to occur for insufficient decoding.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 481,056, filed January 23, 2023, which is incorporated herein by reference.

[0002] Embodiments of the present invention generally relate to a multi-gear error correction code (ECC) decoder that uses a high-speed, low-power decoder and a low-speed, high-power decoder. [Background technology]

[0003] The multi-gear ECC decoder approach is a proven decoding technique used in many flash-stored ECC solutions. Compared to a single-gear decoder, it offers significant cost and power efficiency advantages. However, a drawback of this approach is that the more infrequent high-bit-error-rate (BER) decoding operations are decoded by a more powerful but slower decoding gear. A high-speed, low-power decoder can process more messages per clock (the parallelism of a slower, high-power decoder can be engineered to maintain the same effective power and overall low-cost solution across the decoding gears). The lower parallelism of the more powerful decoding gears can reduce average throughput and cause read performance issues. In a multi-gear ECC decoder, multiple gears or modes with different algorithms, precision, clock frequencies, and parallelism, or separate cores, are used to process the decoding operations.

[0004] Typically, a low-cost / low-power decoder is fast and used to decode codewords with a lower BER, while a high-cost / high-power decoder is used to decode codewords with a high BER. A high-speed low-power decoder and a slow high-power decoder can also be used in cascade: the first decoder decodes everything, and the second decoder decodes codewords that failed the first decoding attempt. It is important to note that typically, a high-speed low-power decoder has high parallelism (it can compute many messages per clock), while a slow high-power decoder has low parallelism due to its higher cost and power consumption.

[0005] In typical operation, the initial decoder is used for the entire decoding operation and is selected based on the syndrome weight (SW), since the syndrome weight (SW) is calculated at the beginning of the decoding operation, but it is costly to recalculate and track. The decoder used changes when the low-power decoder is not sufficient to decode the data, and therefore a higher-power decoder is needed. In such cases, the decoder is switched from a lower-power decoder to a higher-power decoder, but this only increases the decoding delay.

[0006] Therefore, there is a need in the art to reduce the decoding delay for slow high power decoding. Summary of the Invention [Problem to be solved by the invention]

[0007] The present invention generally relates to significantly reducing the decoding time of codewords using a slow, high-power decoder. Rather than decoding codewords at either a slow, high-power or a fast, low-power speed, the present invention proposes switching between slow, high-power and fast, low-power decoding during the decoding process, or performing slow, high-power decoding followed by fast, low-power decoding to reduce decoding delay. A controller first determines whether to start decoding at a slow, high-power speed or a fast, low-power speed based on predetermined factors. Once the decoding power is determined, decoding begins. During the decoding process, decoding reaches a transition from a first power lever decoder that switches to a second power level decoder. Decoding continues at the second decoding power level after the transition until decoding is complete or until another switch needs to occur due to insufficient decoding. [Means for solving the problem]

[0008] In one embodiment, the controller includes a first decoder operating at a first power efficiency level and a second decoder operating at a power efficiency level lower than the first power efficiency level. expensive a second decoder operating at a second power efficiency level; and a decoder manager coupled to the first decoder and the second decoder, the decoder manager configured to direct encoded data to the first decoder for decoding, detect a point in the decoding where the data has been sufficiently decoded to be decodable by the second decoder, and direct the sufficiently decoded data to the second decoder.

[0009] In another embodiment, the controller comprises a first decoder operating at a first decoding level, a second decoder operating at a second decoding level lower than the first level, and a decoder manager coupled to the first and second decoders, the decoder manager configured to direct encoded data to the first decoder for partial decoding and direct the partially decoded data to the second decoder. Exemplary factors that may distinguish the two decoders include power, decoding algorithm, speed (parallelism), clock frequency, silicon area, and / or combinations thereof.

[0010] In another embodiment, the controller includes a first means for decoding data at a first power efficiency level and a second means for decoding data at a power efficiency level lower than the first power efficiency level. expensive The data decoding system includes a second means for decoding data at a second power efficiency level, and a decoding manager coupled to the first means for decoding data and the second means for decoding data, wherein the decoding manager obtains first decoding information by simulating decoded data with the first means for decoding data, obtains second decoding information by simulating decoded data with the second means for decoding data, delivers the first decoding information and the second decoding information to a classifier, and creates weights and biases for the classifier based on the delivery. [Brief explanation of the drawings]

[0011] So that the above features of the present invention can be understood in detail, the present invention, briefly summarized above, may be more particularly described by reference to embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical embodiments of the invention and are therefore not to be considered as limiting its scope, since the invention may admit of other equally effective embodiments.

[0012] [Figure 1] 1 is a schematic block diagram illustrating a storage system in which a data storage device can function as a storage device for a host device, according to an embodiment.

[0013] [Figure 2] FIG. 1 is a schematic block diagram illustrating a storage system according to an embodiment.

[0014] [Figure 3] 1 is a schematic block diagram illustrating a multi-gear low-density parity-check (LDPC) coder according to an embodiment.

[0015] [Figure 4] 1 is a flowchart illustrating a method for initial decoding gear selection, according to an embodiment.

[0016] [Figure 5] 1 is a flowchart illustrating a method for switching decoding gears, according to an embodiment.

[0017] [Figure 6] 1 is a schematic graph of gear transition decoding according to an embodiment;

[0018] [Figure 7] 1 is a schematic graph of an opportunistic transition according to an embodiment;

[0019] [Figure 8] 1 is a flowchart illustrating a method for decoding a transition, according to an embodiment.

[0020] [Figure 9] 1 is a schematic graph of syndrome weight (SW) based transition according to an embodiment;

[0021] [Figure 10] 1 is a flowchart illustrating a method for SW-based transition according to an embodiment.

[0022] [Figure 11] 1 is a schematic graph of a machine learning (ML) based transition according to an embodiment.

[0023] [Figure 12] 1 is a flowchart illustrating a method for ML-based transition according to one embodiment.

[0024] [Figure 13] 1 is a flowchart illustrating a method for classification training and interference according to an embodiment.

[0025] For ease of understanding, like reference numerals have been used, where possible, to designate like elements common to the figures, and it is intended that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation. DETAILED DESCRIPTION OF THE INVENTION

[0026] Reference will now be made to embodiments of the present invention. However, it should be understood that the present invention is not limited to the specifically described embodiments. Instead, any combination of the following features and elements, whether associated with different embodiments or not, is contemplated to implement and practice the present invention. Furthermore, embodiments of the present invention may achieve other possible solutions and / or advantages over the prior art, but whether or not a particular advantage is achieved by a given embodiment does not limit the present invention. Accordingly, the following aspects, features, embodiments, and advantages are merely exemplary and should not be considered elements or limitations of the appended claims unless expressly recited in the claims. Similarly, references to "the present invention" should not be construed as a generalization of any inventive subject matter disclosed herein, nor should they be considered elements or limitations of the appended claims unless expressly recited in the claims.

[0027] The present invention generally relates to significantly reducing the decoding time of high-BER codewords using a slow, high-power decoder. Rather than decoding codewords at either a slow, high-power or a fast, low-power speed, the present invention proposes switching between slow, high-power and fast, low-power decoding during the decoding process. A controller first determines whether to begin decoding at a slow, high-power speed or a fast, low-power speed based on predetermined factors. Once the decoding power is determined, decoding begins. During the decoding process, decoding transitions from a first power level decoder switching to a second power level decoder. Decoding continues at the second decoding power level after the transition until decoding is complete or until another switch needs to occur due to insufficient decoding.

[0028] 1 is a schematic block diagram illustrating a storage system 100 having a data storage device 106 that can function as a storage device for a host device 104, according to one embodiment. For example, the host device 104 may store and retrieve data utilizing non-volatile memory (NVM) 110 included in the data storage device 106. The host device 104 includes host dynamic random access memory (DRAM) 138. In some examples, the storage system 100 may include multiple storage devices, such as the data storage device 106, that may operate as a storage array. For example, the storage system 100 may include multiple data storage devices 106 configured as a redundant array of inexpensive / independent disks (RAID) that collectively function as a mass storage device for the host device 104.

[0029] Host device 104 may store and / or retrieve data from one or more storage devices, such as data storage device 106. As shown in Figure 1, host device 104 may communicate with data storage device 106 via interface 114. Host device 104 may include any of a wide range of devices, including a computer server, a network-attached storage (NAS) unit, a desktop computer, a notebook (i.e., laptop) computer, a tablet computer, a set-top box, a telephone handset such as a so-called "smart" phone, a so-called "smart" pad, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, or any other device capable of sending and receiving data from a data storage device.

[0030] The host DRAM 138 may optionally include a host memory buffer (HMB) 150. The HMB 150 is a portion of the host DRAM 138 allocated to the data storage device 106 for exclusive use by the controller 108 of the data storage device 106. For example, the controller 108 may store mapping data, buffered commands, logical-to-physical (L2P) tables, metadata, etc. in the HMB 150. In other words, the HMB 150 may be used by the controller 108 to store data that would normally be stored in the controller 108's internal memory, such as the volatile memory 112, the buffer 116, or static random access memory (SRAM). In examples where the data storage device 106 does not include DRAM (i.e., the optional DRAM 118), the controller 108 may utilize the HMB 150 as the DRAM of the data storage device 106.

[0031] Data storage device 106 includes controller 108, NVM 110, power supply 111, volatile memory 112, interface 114, write buffer 116, and optional DRAM 118. In some examples, data storage device 106 may include additional components not shown in FIG. 1 for clarity. For example, data storage device 106 may include a printed circuit board (PCB) to which components of data storage device 106 are mechanically attached and which includes conductive traces that electrically interconnect components of data storage device 106, etc. In some examples, the physical dimensions and connector configuration of data storage device 106 may conform to one or more standard form factors. Some exemplary standard form factors include, but are not limited to, a 3.5-inch data storage device (e.g., HDD or SSD), a 2.5-inch data storage device, a 1.8-inch data storage device, Peripheral Component Interconnect (PCI), PCI Expansion (PCI-X), PCI Express (PCIe) (e.g., PCIex1, x4, x8, x16, PCIe Mini Card, Mini PCI, etc.). In some examples, the data storage device 106 may be directly coupled to the motherboard of the host device 104 (e.g., soldered or plugged directly into a connector).

[0032] The interface 114 may include one or both of a data bus for exchanging data with the host device 104 and a control bus for exchanging commands with the host device 104. The interface 114 may operate according to any suitable protocol. For example, the interface 114 may operate according to one or more of the following protocols: Advanced Technology Attachment (ATA) (e.g., Serial ATA (SATA) and Parallel ATA (PATA)), Fibre Channel Protocol (FCP), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), PCI and PCIe, Non-Volatile Memory Express (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Open Channel Single Sign-On (SSSD) (OCSSD), etc. The interface 114 (e.g., a data bus, a control bus, or both) is electrically connected to the controller 108 and provides an electrical connection between the host device 104 and the controller 108, enabling data to be exchanged between the host device 104 and the controller 108. In some examples, the electrical connections of interface 114 may also allow data storage device 106 to receive power from host device 104. For example, as shown in FIG. 1, power supply 111 may receive power from host device 104 via interface 114.

[0033] The NVM 110 may include multiple memory devices or memory units. The NVM 110 may be configured to store and / or retrieve data. For example, a memory unit of the NVM 110 may receive data and messages from the controller 108 instructing the memory unit to store the data. Similarly, a memory unit may receive messages from the controller 108 instructing the memory unit to retrieve data. In some examples, each of the memory units may be referred to as a die. In some examples, the NVM 110 may include multiple dies (i.e., multiple memory units). In some examples, each memory unit may be configured to store a relatively large amount of data (e.g., 128 MB, 256 MB, 512 MB, 1 GB, 2 GB, 4 GB, 8 GB, 16 GB, 32 GB, 64 GB, 128 GB, 256 GB, 512 GB, 1 TB, etc.).

[0034] In some examples, each memory unit may include any type of non-volatile memory device, such as a flash memory device, a phase change memory (PCM) device, a resistive random access memory (ReRAM) device, a magnetoresistive random access memory (MRAM) device, a ferroelectric random access memory (F-RAM), a holographic memory device, and any other type of non-volatile memory device.

[0035] The NVM 110 may include multiple flash memory devices or memory units. The NVM flash memory devices may include NAND- or NOR-based flash memory devices and may store data based on the charge contained in the floating gate of a transistor for each flash memory cell. In an NVM flash memory device, the flash memory device may be divided into multiple dies, and each die of the multiple dies includes multiple physical or logical blocks that may be further divided into multiple pages. Each of the multiple blocks within a particular memory device may include multiple NVM cells. Rows of NVM cells may be electrically connected using word lines to define one of multiple pages. Each cell in each of the multiple pages may be electrically connected to a respective bit line. Furthermore, the NVM flash memory device may be a 2D or 3D device and may be a single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), or quad-level cell (QLC) device. The controller 108 may write data to the NVM flash memory device at the page level, read data from the NVM flash memory device, and erase data from the NVM flash memory device at the block level.

[0036] The power supply 111 may provide power to one or more components of the data storage device 106. When operating in a standard mode, the power supply 111 may power one or more components using power provided by an external device, such as the host device 104. For example, the power supply 111 may provide power to one or more components using power received from the host device 104 via the interface 114. In some examples, the power supply 111 may include one or more power storage components configured to provide power to one or more components when the power supply operates in a shutdown mode, such as when it no longer receives power from an external device. In this manner, the power supply 111 may function as an on-board backup power source. Some examples of the one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, etc. In some examples, the amount of power that can be stored by the one or more power storage components may be a function of the cost and / or size (e.g., area / volume) of the one or more power storage components. In other words, as the amount of power that can be stored by the one or more power storage components increases, the cost and / or size of the one or more power storage components also increase.

[0037] The volatile memory 112 may be used by the controller 108 to store information. The volatile memory 112 may include one or more volatile memory devices. In some examples, the controller 108 may use the volatile memory 112 as a cache. For example, the controller 108 may store cached information in the volatile memory 112 until the cached information is written to the NVM 110. As shown in FIG. 1 , the volatile memory 112 may consume power received from the power supply 111. Examples of the volatile memory 112 include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static RAM (SRAM), and synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, etc.)). Similarly, the optional DRAM 118 may be utilized to store mapping data, buffered commands, logical-to-physical (L2P) tables, metadata, cached data, and the like. In some examples, the data storage device 106 does not include the optional DRAM 118, such that the data storage device 106 is DRAM-less. In other examples, the data storage device 106 includes the optional DRAM 118.

[0038] The controller 108 may manage one or more operations of the data storage device 106. For example, the controller 108 may manage reading data from and / or writing data to the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 may initiate the data storage command to store the data in the NVM 110 and monitor the progress of the data storage command. The controller 108 may determine at least one operating characteristic of the storage system 100 and store the at least one operating characteristic in the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 temporarily stores data associated with the write command in an internal memory or write buffer 116 before sending the data to the NVM 110.

[0039] The controller 108 may include an optional second volatile memory 120. The optional second volatile memory 120 may be similar to the volatile memory 112. For example, the optional second volatile memory 120 may be an SRAM. The controller 108 may allocate a portion of the optional second volatile memory to the host device 104 as a controller memory buffer (CMB) 122. The CMB 122 may be directly accessed by the host device 104. For example, instead of maintaining one or more submission queues in the host device 104, the host device 104 may utilize the CMB 122 to store one or more submission queues that are typically maintained within the host device 104. In other words, the host device 104 may generate commands and store the generated commands, with or without associated data, in the CMB 122, and the controller 108 accesses the CMB 122 to retrieve the stored generated commands and / or associated data.

[0040] 2 is a schematic block diagram illustrating a storage system 200 according to one embodiment. The storage system 200 includes a controller 202 that includes a decoder module 204. The decoder module 204 includes a first decoder 206, a second decoder 208, and a decoder manager / classifier 210. The first decoder 206, the second decoder 208, and the decoder manager / classifier 210 are all connected. While only the first decoder 206 and the second decoder 208 are shown, it should be understood that there may be more than one decoder.

[0041] FIG. 3 is a schematic block 300 illustrating a multi-gear low-density parity check (LDPC) decoder 302 according to one embodiment. The multi-gear LDPC decoder 302 includes a high-speed low-power decoder 304 and a low-speed high-power decoder 306. The LDPC decoder 302, the high-speed low-power decoder 304, and the low-speed high-power decoder 306 are exemplary and may be used for other decoding algorithms. The high-speed low-power decoder 304 uses a simple bit-flipping algorithm and can process simple calculations. The high-speed low-power decoder 304 has a low memory size and low bandwidth (BW). The high-speed low-power decoder 304 has high parallelism (GB / sec) and is very power-efficient (mW / GB / sec). The high-speed low-power decoder is very cost-efficient (mm 2 / GB / sec), and correction capability is degraded.

[0042] The low-speed, high-power decoder 306 uses a belief propagation algorithm (an optimal iterative algorithm) and can handle complex calculations. The low-speed, high-power decoder 306 has a high memory size and a high BW. The low-speed, high-power decoder 306 has low parallelism of about 100 MB / sec and lower power efficiency (mW / GB / sec) than the high-speed, low-power decoder 304. The low-speed, high-power decoder 306 is less cost-effective (mm 2 / GB / sec) and has increased correction capabilities. It should be understood that the algorithm is merely an example and other decoding algorithms are contemplated.

[0043] 4 is a flowchart illustrating a method 400 for initial decoding gear selection according to one embodiment. In conventional systems, initial gear selection is performed according to syndrome weights (SW). Because SW is calculated at the start of decoding, recalculating or tracking SW is costly. In conventional systems, the decoding gear transition is always from a weaker / faster gear to a stronger / slower gear.

[0044] Method 400 begins at block 402. In block 402, a controller, such as controller 202 of FIG. 2, calculates SW. SW is the value if the parity check equation in the codeword is not satisfied. Based on the SW calculated in block 402, method 400 proceeds to either block 404 or block 406. Method 400 proceeds from block 402 to block 404 if the controller calculates SW to be low. Method 400 proceeds from block 402 to block 406 if the controller calculates SW to be high. In block 404, the controller uses a high-speed, low-power decoder. If a failure occurs, the controller retries using the high-speed, low-power decoder. If there is a failure, method 400 proceeds to block 406. In block 406, the system uses a low-speed, high-power decoder.

[0045] 5 is a flowchart illustrating a method 500 for switching decoding gears, according to one embodiment. The method 500 dynamically switches decoding gears according to the decoding state. Primarily, for codewords decoded by a slow, high-power decoder (second decoder), the codewords are fully decoded and forwarded (potentially back) to a (much) faster, more efficient decoder (high-speed, low-power).

[0046] Method 500 begins at block 502. In block 502, a controller, such as controller 202 of FIG. 2, selects a high BER codeword. In block 504, the system decodes using a high BER decoder (slow speed, high power). In block 506, the controller determines whether the codeword is fully decoded. If the controller determines that the codeword is not fully decoded, method 500 returns to block 504 and continues the decoding process. The point at which the codeword is fully decoded is an inflection point where a low-power decoder has a high probability of success. If the controller determines that the codeword is fully decoded, method 500 proceeds to block 508. In block 508, the controller decodes with a high-speed / low BER decoder (fast speed, low power).

[0047] FIG. 6 is a schematic graph 600 of gear transition decoding according to one embodiment. In graph 600, the x-axis indicates decoding time and the y-axis indicates decoding gear. During slow-speed, high-power decoding, there is a transition point detected for a gear transition. At the transition point, the codeword is corrected sufficiently to allow the fast, low-power decoder to succeed. The fast, low-power decoder is much more power-efficient than the slow-speed, high-power decoder. The fast, low-power decoder operates faster than the slow, high-power decoder in terms of decoding time. Thus, at the inflection / transition point, the controller can switch from the slow, high-power decoder to the fast, low-power decoder and still successfully decode, but at a much faster speed and with lower power usage. The dashed line indicates the time it may take for the slow, high-power decoder to complete the decoding operation.

[0048] For successful decoding, inflection / transition point identification is important to avoid false transitions from slow high-power to fast low-power, a transition that would cause fast low-power decoding to fail. If fast low-power fails, decoding must be run again with a slow high-power decoder (potentially from scratch) or a recovery flow must be initiated. Either option adds a significant latency penalty. Therefore, it is advantageous to avoid false transitions.

[0049] FIG. 7 is a schematic graph 700 of opportunistic transitioning according to one embodiment. In graph 700, the x-axis indicates decoding time and the y-axis indicates decoding gear. During opportunistic transitioning, a codeword is decoded after a fixed time interval while continuing decoding (or pausing decoding) in FP. If fast, low-power decoding is successful, slow, high-power decoding may be stopped. While opportunistic transitioning reduces delay to some extent, it may be wasted due to multiple attempts using more power. Thus, FIG. 7 illustrates an approach that has some gain without switching but may not be as power-efficient as possible due to additional failed decoding operations performed along the path.

[0050] FIG. 8 is a flow chart illustrating a method 800 of decoding transitions according to one embodiment. Method 800 may also be used in opportunistic methods such as method 700. Method 800 begins at block 802. In block 802, a controller, such as controller 202 of FIG. 2, directs data to be decoded to a first decoder, such as first decoder 206 of FIG. 2. In block 804, the first decoder decodes the data. In block 806, the controller determines whether a timer has expired. If the controller determines that the timer has not expired, method 800 returns to block 804. If the controller determines that the timer has expired, method 800 proceeds to block 808. In block 808, the controller determines whether decoding is complete. If the controller determines that decoding is complete, method 800 proceeds to block 820, where it ends. If the controller determines that decoding is not complete, method 800 proceeds to block 810. At block 810, the controller moves the partially decoded data and the remaining encoded data to a second decoder, such as second decoder 208 of FIG. 2. At block 812, the controller decodes the data to the second decoder. At block 814, the controller determines whether the second decoder was successful. If the controller determines that the second decoder was successful, method 800 proceeds to block 818. If the controller determines that the second decoder was not successful, method 800 proceeds to block 816. At block 816, the controller sends the partially decoded data and the remaining encoded data to the first decoder at block 804. At block 818, the controller determines whether decoding is complete. If the controller determines that decoding is complete, method 800 proceeds to block 820, where it ends. If the controller determines that decoding is not complete, method 800 returns to block 812.

[0051] FIG. 9 is a schematic graph 900 of SW-based transitioning according to one embodiment. In graph 900, the x-axis represents decoding time and the y-axis represents decoding gear. SW-based transitioning identifies transition points by comparing SW to a threshold. SW is periodically checked during slow, high-power decoding. SW is a proxy for BER. When SW falls below the threshold, decoding transitions from slow, high-power decoding to fast, low-power decoding. The threshold can be adjusted offline to ensure best performance while avoiding false transitions. Offline threshold adjustment can set the threshold to avoid transitions to fast, low-power decoding that may fail. When SW falls below a handoff threshold, slow, high-power decoding transitions from slow, high-power decoding to fast, low-power decoding. SW transitioning provides increased delay reduction compared to the delay reduction of opportunistic transitions seen in graph 700. A drawback is that SW-based transitioning requires circuitry to track SW during decoding. The cost and power of SW tracking may still be low compared to the delay reduction achieved using current methods.

[0052] 10 is a flow chart illustrating a method 1000 of SW-based transition according to one embodiment. The method 1000 identifies a transition point by comparing SW to a threshold. When the BER becomes low enough, decoding transitions from slow high-power decoding to fast low-power decoding.

[0053] Method 1000 begins at block 1002. In block 1002, a controller, such as controller 202 of FIG. 2, directs data to be decoded to a first decoder, such as first decoder 206 of FIG. 2. In block 1004, the first decoder decodes the data. In block 1006, the controller calculates SW. Calculation of SW may also occur in parallel with decoding. In block 1008, the controller determines whether SW is below a threshold. If the controller determines that SW is not below the threshold, method 1000 returns to block 1004. If the controller determines that SW is above the threshold, method 1000 proceeds to block 1010. In block 1010, the controller moves the partially decoded data and the remaining encoded data to a second decoder, such as second decoder 208 of FIG. 2. In block 1012, the controller decodes the data to the second decoder. In block 1014, the controller determines whether decoding is complete. If the controller determines that decoding is not complete, the method 1000 returns to block 1012. If the controller determines that decoding is complete, the method 1000 proceeds to block 1016, where it ends.

[0054] FIG. 11 is a schematic diagram of a machine learning (ML)-based transition 1100 according to one embodiment. The graph 1100, with its x-axis representing decoding time and its y-axis representing decoding gear, illustrates the use of an ML classifier trained to detect the point within the slow, high-power decoding when a codeword is sufficiently decoded to transition from slow, high-power decoding to fast, low-power decoding. A sufficiently decoded decoding is defined by the likelihood that fast, low-power decoding will be successful from this point. The classifier is trained using readily available features (generated as a by-product of the decoding process) and can be implemented via a low-complexity inference function. The ML-based transition 1100 is preferable to SW-based transition approaches because it does not require SW tracking, which may result in a lower-cost and lower-power solution.

[0055] The implemented classifiers can be low-complexity inference functions (such as linear support vector machines (SVMs) and simple tree-based models) to ensure low ASIC gate count and good power performance. Furthermore, simple features that are available during the decoding operation (as a by-product of the decoding) or are easy to extract (low complexity and power) are used in the ML transition.

[0056] An example of a simple feature that may be used is the number of unsatisfied parity checks occurring in different backward windows, e.g., repeating backward (1 / 8, 2 / 8, . . . , 1). An additional feature is the number of bit flips inverted by the decoder in the same backward window. Also, the number of log-likelihood ratios (LLRs) whose magnitude exceeds a threshold. Other LLR statistics include, but are not limited to, the number of bits whose LLR magnitude is below / above a certain value, the average LLR magnitude, the LLR magnitude STD, etc. It should be noted that the above bit-related features can be separated and counted according to bit degree. Bit degree refers to the number of parity check equations in which the bit participates. For example, according to bit degree, such as separate statistics for bits participating in three parity checks (= degree -3 bits) or bits participating in four parity checks (= degree -4 bits). It should be understood that the simple features are exemplary and other simple features may be used.

[0057] FIG. 12 is a flowchart illustrating a method 1200 of ML-based transitioning according to one embodiment. Method 1200 begins at block 1202. In block 1202, a controller, such as controller 202 of FIG. 2, directs data to be decoded to a first decoder, such as first decoder 206 of FIG. 2. In block 1204v, the first decoder decodes the data. In block 1206, the controller calculates a point at which the data is sufficiently decoded to be moved to a second decoder, such as second decoder 208 of FIG. 2. In block 1208, the controller determines whether the point at which the data is sufficiently decoded has been reached. If the controller determines that the point has not been reached, method 1200 returns to block 1204. If the controller determines that the point has been reached, method 1200 proceeds to block 1210. In block 1210, the controller moves the partially decoded data and the remaining encoded data to the second decoder. In block 1212, the controller decodes the data to the second decoder. At block 1214, the controller determines whether decoding is complete. If the controller determines that decoding is not complete, method 1200 returns to block 1212. If the controller determines that decoding is complete, method 1200 proceeds to block 1216, where it ends.

[0058] FIG. 13 is a flowchart illustrating a method 1300 for classification training and interference according to one embodiment. The label used for training is whether fast low-power decoding can successfully decode a noisy codeword. In a use case, it is beneficial to minimize the false positive rate (at the expense of the true positive rate). As mentioned above, if a controller, such as controller 202 in FIG. 2, forwards a codeword to fast low-power decoding and the fast low-power decoding fails, a recovery flow is triggered. The training cost function is then biased to select a conservative working point where the observable false positives are minimized.

[0059] Method 1300 begins at block 1302 during ML training. At block 1302, data is extracted. At block 1304, the data is encoded. At block 1306, a flash channel model is created. At block 1308, a slow-speed, high-power decoder simulation is performed. Method 1300 can proceed to either block 1310 or block 1312. At block 1310, a fast-speed, low-power decoder simulation is performed. At block 1314, the data is decoded with a second decoder. Method 1300 continues at block 1316 during inference. At block 1316, the data is decoded using a slow-speed, high-power decoder. At block 1318, the data is decoded using a high-speed, low-power decoder. At block 1320, the inference circuitry can receive data from the slow-speed, high-power decoder through the use of features such as the simple features described above, or can forward data to the slow-speed, high-power decoder at block 1316.

[0060] To improve the performance of a decoding system, a basic approach is to take hard decisions from the second decoder and use soft information to initialize the first decoder when making transitions.

[0061] In one embodiment, the controller includes a first decoder operating at a first power efficiency level and a second decoder operating at a power efficiency level lower than the first power efficiency level. expensiveThe decoder includes a second decoder operating at a second power efficiency level and a decoder manager coupled to the first decoder and the second decoder, the decoder manager configured to direct encoded data to the first decoder for decoding, detect a point in the decoding where the data is sufficiently decoded to be decoded by the second decoder, and direct the sufficiently decoded data to the second decoder. The detecting includes performing a low-complexity inference function using an inference circuit. The inference circuit includes a multiplier and an adder coupled to the multiplier. The inference circuit further includes an accumulator coupled to the adder. The decoder manager further includes a machine learning (ML) classifier. The ML classifier is trained to perform the detection. The training is performed offline. The ML classifier is configured to determine a number of bit flips inverted by the first decoder in a backward look-back window. The ML classifier is configured to determine a number of unsatisfied parity checks of the first decoder in the backward look-back window.

[0062] In another embodiment, the controller includes a first decoder operating at a first decoding level, a second decoder operating at a second decoding level lower than the first level, and a decoder manager coupled to the first and second decoders, the decoder manager configured to direct encoded data to the first decoder for partial decoding and direct the partially decoded data to the second decoder. The decoder manager is further configured to calculate a syndrome weight (SW) for the encoded data. The decoder manager is further configured to compare the calculated SW with a threshold. The decoder manager is further configured to direct the partially decoded data to the second decoder after a predetermined period of time. The decoder manager is further configured to determine that the second decoder has failed to decode the partially decoded data. The decoder manager is further configured to return the partially decoded data to the first decoder. The decoder manager is further configured to detect a point in decoding the encoded data at the first decoder at which the partially decoded data can be directed to the second decoder.

[0063] In another embodiment, the controller includes a first means for decoding data at a first power efficiency level and a second means for decoding data at a power efficiency level lower than the first power efficiency level. expensive The system includes a second means for decoding data at a second power efficiency level, and a decoding manager coupled to the first means for decoding data and the second means for decoding data, wherein the decoding manager obtains first decoding information by simulating decoded data with the first means for decoding data, obtains second decoding information by simulating decoded data with the second means for decoding data, distributes the first decoding information and the second decoding information to a classifier, and creates weights and biases for the classifier based on the distribution. The obtaining of the first decoding information, the obtaining, distribution, and creation of the second decoding information are performed offline. The decoding manager is configured to determine the number of unsatisfied parity checks for the first means for decoding data and the second means for decoding data. The decoding manager is configured to distribute the classified weights and biases to an inference circuit.

[0064] While the forgoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, which scope is determined by the following claims.

Claims

1. a first decoder operating at a first power efficiency level; a second decoder operating at a second power efficiency level higher than the first power efficiency level; a decoder manager coupled to the first decoder and the second decoder, the decoder manager comprising: directing the encoded data to the first decoder for decoding; detecting a point in the decoding where the data has been sufficiently decoded so that it can be decoded by the second decoder; configured to direct the fully decoded data to the second decoder; the decoder manager further includes a machine learning (ML) classifier. controller.

2. The controller of claim 1 , wherein the detecting includes using inference circuitry to perform low-complexity inference functions including linear support vector machines and tree-based models.

3. The controller of claim 2 , wherein the inference circuitry includes a multiplier and an adder coupled to the multiplier.

4. The controller of claim 3 , wherein the inference circuitry further comprises an accumulator coupled to the adder.

5. The controller of claim 1 , wherein the ML classifier is trained to perform the detection.

6. The controller of claim 5 , wherein the training is performed offline.

7. The controller of claim 1 , wherein the ML classifier is configured to determine a number of bit flips inverted by the first decoder in a backward window.

8. The controller of claim 1 , wherein the ML classifier is configured to determine a number of unsatisfied parity checks of the first decoder in a backward window.

9. a first decoder operating at a first decoding level; a second decoder operating at a second decoding level lower than the first decoding level; a decoder manager coupled to the first decoder and the second decoder, the decoder manager comprising: directing the encoded data to a first decoder for partial decoding; configured to direct the partially decoded data to the second decoder; the decoder manager further includes a machine learning (ML) classifier. controller.

10. The controller of claim 9 , wherein the decoder manager is further configured to calculate syndrome weights (SW) for the encoded data.

11. The controller of claim 10 , wherein the decoder manager is further configured to compare the calculated SW to a threshold value.

12. 10. The controller of claim 9, wherein the decoder manager is further configured to direct the partially decoded data to the second decoder after a predetermined period of time.

13. The controller of claim 9 , wherein the decoder manager is further configured to determine that the second decoder failed to decode the partially decoded data.

14. The controller of claim 13 , wherein the decoder manager is further configured to send the partially decoded data back to the first decoder.

15. 10. The controller of claim 9, wherein the decoder manager is further configured to detect a transition point during decoding of the encoded data at the first decoder at which the partially decoded data can be sent to the second decoder.

16. first means for decoding data at a first power efficiency level; second means for decoding data at a second power efficiency level higher than the first power efficiency level; a decryption manager coupled to the first means for decrypting data and the second means for decrypting data, the decryption manager comprising: obtaining first decoding information by simulating decoded data with the first means for decoding data; obtaining second decoding information by simulating the decoded data with the second means for decoding data; delivering the first decoded information and the second decoded information to a classifier; configured to generate weights and biases for a classifier based on the distribution. controller.

17. The controller of claim 16 , wherein the obtaining of the first decryption information, the obtaining, distributing, and creating of the second decryption information occurs offline.

18. 17. The controller of claim 16, wherein the decoding manager is configured to determine a number of unsatisfied parity checks for the first means for decoding data and the second means for decoding data.

19. The controller of claim 16 , wherein the decoding manager is configured to deliver the classified weights and biases to an inference circuit.

Images