Data storage device and method for inferring read thresholds using time tag determination

Abstract

A data storage device has an inference engine that may infer a read threshold based on a non-linear function reflecting an input to a current memory and a data condition. The read threshold may be used in reading word lines in the memory. Using a machine learning-based approach to infer read thresholds may provide significant improvements in read threshold accuracy, which may reduce bit error rates and also improve latency, throughput, power consumption, and quality of service.

Description

Background Art

[0001] One of the main challenges brought about by NAND process shrinkage and three-dimensional stacking is maintaining process uniformity. In addition, memory products need to support a wide range of operating conditions, such as different program / erase cycles, retention time, and temperature, which leads to increased variability between memory dies, blocks, and pages across different operating conditions. Due to these changes, the read threshold used to read the memory page is not fixed and changes significantly with physical location and operating conditions, especially for less mature new memory nodes. Reads with inaccurate read thresholds will result in higher bit error rates, which will reduce performance and service quality due to decoding failures, and decoding failures require the invocation of high-latency recovery flows, causing delays and performance issues. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1A is a block diagram of a nonvolatile storage system of an embodiment.

[0003] Figure 1B is a block diagram illustrating a storage module of an embodiment.

[0004] Figure 1C is a block diagram illustrating a hierarchical storage system according to an embodiment.

[0005] Figure 2A is a diagram showing the Figure 1A A block diagram of components of a controller of a nonvolatile storage system is shown.

[0006] Figure 2B is a diagram showing the Figure 1A A block diagram of components of a non-volatile storage system is shown in FIG.

[0007] Figure 3 is a block diagram of a host and a storage system of an embodiment.

[0008] Figure 4 is a diagram of an inference engine for an embodiment of machine learning based read threshold calibration.

[0009] Figure 5 is a diagram of an inference engine for an embodiment in which target page features are not used for machine learning based read threshold calibration.

[0010] Figure 6 is a diagram of an inference engine using an embodiment of a background-foreground approach.

[0011] Figure 7 is a flow chart of a method of an embodiment for time label optimization through a light machine learning application.

[0012] Figure 8is a Σ plot of average failing bit count (FBC) for different example test conditions of an embodiment. DETAILED DESCRIPTION

[0013] The following embodiments generally relate to a data storage device and method for inferring a read threshold using time tag determination (e.g., time tag optimization by a light machine learning application). In one embodiment, a method is provided for execution in a data storage device including a memory. The method includes: inferring a read threshold based on a nonlinear function reflecting a plurality of input and data conditions of the current memory; and using the read threshold when reading a word line in the memory.

[0014] In another embodiment, a data storage device is provided, comprising a memory and a controller. The controller is configured to use an inference engine to infer a read threshold for reading a word line in the memory based on data available during a time tag update rather than based on data currently associated with the word line; and to read the word line using the read threshold.

[0015] In yet another embodiment, a data storage device is provided, comprising: a memory; a component for inferring a read threshold based on a nonlinear function reflecting a plurality of input and data conditions of the current memory; and a component for using the read threshold when reading a word line in the memory.

[0016] Other embodiments are provided and may be used alone or in combination.

[0017] Turning now to the drawings, a storage system suitable for implementing aspects of these embodiments is shown in FIG. Figures 1A-1C Displayed in. Figure 1A 1 is a block diagram illustrating a non-volatile storage system 100 (sometimes referred to herein as a storage device or just a device) according to an embodiment of the subject matter described herein. Figure 1A , a nonvolatile memory system 100 includes a controller 102 and a nonvolatile memory, which may be composed of one or more nonvolatile memory dies 104. As used herein, the term die refers to a collection of nonvolatile memory cells formed on a single semiconductor substrate and associated circuits for managing the physical operations of those nonvolatile memory cells. The controller 102 interfaces with a host system and transmits command sequences for read, program, and erase operations to the nonvolatile memory dies 104.

[0018] The controller 102 (which may be a non-volatile memory controller (e.g., a flash, resistive random access memory (ReRAM), phase change memory (PCM), or magnetoresistive random access memory (MRAM) controller)) may take the form of a processing circuit, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., firmware), which may be executed by, for example, a (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. The controller 102 may be configured with hardware and / or firmware to perform the various functions described below and shown in the flow charts. Furthermore, some components shown as being internal to the controller may also be stored external to the controller, and other components may be used. In addition, the phrase "operably communicating with..." may mean directly communicating with..., or indirectly (wired or wirelessly) communicating with... through one or more components that may or may not be shown or described herein.

[0019] As used herein, a nonvolatile memory controller is a device that manages data stored on a nonvolatile memory and communicates with a host such as a computer or electronic device. A nonvolatile memory controller may have various functionalities in addition to the specific functionality described herein. For example, a nonvolatile memory controller may format a nonvolatile memory to ensure that the memory operates properly, map out bad nonvolatile memory cells, and allocate spare cells to replace future failed cells. A portion of the spare cells may be used to store firmware to operate the nonvolatile memory controller and implement other features. In operation, when a host needs to read data from a nonvolatile memory or write data to a nonvolatile memory, the host may communicate with the nonvolatile memory controller. If the host provides a logical address to read / write data, the nonvolatile memory controller may convert the logical address received from the host into a physical address in the nonvolatile memory. (Alternatively, the host may provide the physical address.) The nonvolatile memory controller may also perform various memory management functions, such as, but not limited to, wear leveling (distributing writes to avoid wearing out a particular block of memory cells that would otherwise be written to repeatedly) and garbage collection (moving only valid data pages to a new block after a block has filled up so that the filled block can be erased and reused). Also, the structure of "means" recited in the claims may include, for example, some or all of the structure of the controller described herein, programmed or manufactured as needed to cause the controller to operate to perform the recited functions.

[0020] The non-volatile memory die 104 may include any suitable non-volatile storage medium, including ReRAM, MRAM, PCM, NAND flash memory cells, and / or NOR flash memory cells. The memory cells may take the form of solid-state (e.g., flash) memory cells, and may be programmable once, programmable a few times, or programmable many times. The memory cells may also be single-level (one bit per cell) cells (SLC) or multi-level cells (MLC), such as dual-level cells, triple-level cells (TLC), quad-level cells (QLC), or using other memory cell level technologies now known or later developed. Also, the memory cells may be fabricated in two or three dimensions.

[0021] The interface between the controller 102 and the non-volatile memory die 104 may be any suitable flash interface, such as Toggle Mode 200, 400, or 800. In one embodiment, the storage system 100 may be a card-based system, such as a Secure Digital (SD) or Micro Secure Digital (microSD) card (or USB, SSD, etc.). In an alternative embodiment, the storage system 100 may be part of an embedded storage system.

[0022] Although in Figure 1A In the example shown in FIG. 1 , the nonvolatile memory system 100 (sometimes referred to herein as a memory module) includes a single channel between the controller 102 and the nonvolatile memory die 104, but the subject matter described herein is not limited to having a single memory channel. For example, in some memory system architectures (such as Figure 1B and 1C In the storage system architecture shown in ), depending on the controller capabilities, there may be 2, 4, 8 or more memory channels between the controller and the memory devices. In any embodiments described herein, there may be more than a single channel between the controller and the memory die, even if a single channel is shown in the drawings.

[0023] Figure 1B A storage module 200 including a plurality of non-volatile storage systems 100 is shown. Thus, the storage module 200 may include a storage controller 202 that interfaces with a host and with a storage system 204, the storage system including a plurality of non-volatile storage systems 100. The interface between the storage controller 202 and the non-volatile storage system 100 may be a bus interface, such as a Serial Advanced Technology Attachment (SATA), a Peripheral Component Interconnect Express (PCIe) interface, or a Double Data Rate (DDR) interface. In one embodiment, the storage module 200 may be a solid state drive (SSD) or a non-volatile dual in-line memory module (NVDIMM), such as found in a server PC or a portable computing device (e.g., a laptop computer and a tablet computer).

[0024] Figure 1C 2 is a block diagram illustrating a hierarchical storage system. Hierarchical storage system 250 includes a plurality of storage controllers 202, each of which controls a corresponding storage system 204. A host system 252 can access memory within the storage system via a bus interface. In one embodiment, the bus interface can be a non-volatile memory express (NVMe) interface or a Fibre Channel over Ethernet (FCoE) interface. In one embodiment, Figure 1C The system shown in may be a rack-mountable mass storage system accessible by multiple host computers, such as found in a data center or other location where mass storage is needed.

[0025] Figure 2A 1 is a block diagram showing the components of controller 102 in more detail. Controller 102 includes a front-end module 108 that interfaces with a host, a back-end module 110 that interfaces with one or more non-volatile memory dies 104, and various other modules that perform functions that will now be described in detail. A module may be, for example, in the form of a packaged functional hardware unit designed to be used with other components, a portion of a program code (e.g., software or firmware) that can be executed by a specific function (micro)processor or processing circuit that generally performs related functions, or a self-contained hardware or software component that interfaces with a larger system. Controller 102 may sometimes be referred to herein as a NAND controller or a flash controller, but it should be understood that controller 102 can be used with any suitable memory technology, some examples of which are provided below.

[0026] Referring again to the modules of controller 102, buffer manager / bus controller 114 manages the buffers in random access memory (RAM) 116 and controls the internal bus arbitration of controller 102. Read only memory (ROM) 118 stores system startup code. Figure 2A 102, but in other embodiments, one or both of RAM 116 and ROM 118 may be located within the controller. In still other embodiments, portions of RAM and ROM may be located within the controller 102 or may be located outside the controller.

[0027] The front-end module 108 includes a host interface 120 and a physical layer interface (PHY) 122 that provide an electrical interface with a host or next-level storage controller. The selection of the type of host interface 120 may depend on the type of memory being used. Examples of host interface 120 include, but are not limited to, SATA, SATA Express, Serial Attached Small Computer System Interface (SAS), Fibre Channel, Universal Serial Bus (USB), PCIe, and NVMe. The host interface 120 generally facilitates the transfer of data, control signals, and timing signals.

[0028] The back-end module 110 includes an error correction code (ECC) engine 124 that encodes data bytes received from the host and decodes and error corrects data bytes read from the non-volatile memory. A command sequencer 126 generates a command sequence to be transmitted to the non-volatile memory die 104, such as a program and erase command sequence. A redundant array of independent drives (RAID) module 128 manages the generation of RAID parity and the recovery of failed data. RAID parity can be used as an additional level of integrity protection for data written to the memory device 104. In some cases, the RAID module 128 can be part of the ECC engine 124. The memory interface 130 provides the command sequence to the non-volatile memory die 104 and receives status information from the non-volatile memory die 104. In one embodiment, the memory interface 130 can be a double data rate (DDR) interface, such as a switching mode 200, 400 or 800 interface. The flash control layer 132 controls the overall operation of the back-end module 110.

[0029] The storage system 100 also includes other discrete components 140, such as external electrical interfaces, external RAM, resistors, capacitors, or other components that may interface with the controller 102. In alternative embodiments, one or more of the physical layer interface 122, the RAID module 128, the media management layer 138, and the buffer management / bus controller 114 are optional components that are not necessarily in the controller 102.

[0030] Figure 2B 1 is a block diagram showing components of the nonvolatile memory die 104 in more detail. The nonvolatile memory die 104 includes peripheral circuits 141 and a nonvolatile memory array 142. The nonvolatile memory array 142 includes nonvolatile memory cells for storing data. The nonvolatile memory cells may be any suitable nonvolatile memory cells, including ReRAM, MRAM, PCM, NAND flash memory cells, and / or NOR flash memory cells in a two-dimensional and / or three-dimensional configuration. The nonvolatile memory die 104 further includes a data cache 156 for caching data. The peripheral circuits 141 include a state machine 152 that provides state information to the controller 102.

[0031] Return to Figure 2A, a flash control layer 132 (which will be referred to herein as a flash translation layer (FTL), or more generally as a "media management layer" because the memory may not be flash) handles flash errors and interfaces with the host. Specifically, the FTL, which may be an algorithm in firmware, is responsible for memory internal management and translates writes from the host into writes to the memory 104. The FTL may be needed because the memory 104 may have limited endurance, may only be written to in multiple pages, and / or may not be written to unless it is erased as a block of memory cells. The FTL is aware of these potential limitations of the memory 104, which may not be visible to the host. Therefore, the FTL attempts to translate writes from the host into writes in the memory 104.

[0032] The FTL may include a logical to physical address (L2P) mapping (sometimes referred to herein as a table or data structure) and an allocated cache memory. In this way, the FTL translates logical block addresses ("LBAs") from the host into physical addresses in memory 104. The FTL may include other features, such as, but not limited to, power failure recovery (so that the FTL's data structures can be restored in the event of a sudden power failure) and wear leveling (so that the wear on the memory blocks is more even to prevent some blocks from being over-worn, which will result in a greater chance of failure).

[0033] Turning to the schema again, Figure 3 1 is a block diagram of a host 300 and a storage system (sometimes referred to herein as a device) 100 of an embodiment. The host 300 may take any suitable form, including but not limited to a computer, a mobile phone, a digital camera, a tablet computer, a wearable device, a digital video recorder, a surveillance system, etc. The host 300 includes a processor 330 configured to send data (e.g., initially stored in a memory 340 (e.g., DRAM) of the host) to the storage system 100 for storage in a memory 104 (e.g., a non-volatile memory die) of the storage system. Although the host 300 and the storage system 100 are in Figure 3 300, but it should be noted that the storage system 100 may be integrated in the host 300, the storage system 100 may be removably connected to the host 300, and the storage system 100 and the host 300 may communicate via a network. It should also be noted that the memory 104 may be integrated in the storage system 100 or removably connected to the storage system 100.

[0034] As mentioned above, one of the main challenges brought about by NAND process shrinkage and three-dimensional stacking is maintaining process uniformity. In addition, data storage devices are generally required to support a wide range of operating conditions (e.g., different program / erase (P / E) cycles, retention time and temperature), which may lead to increased variability between memory dies, blocks, and pages across different operating conditions. Due to these variations, the read threshold (RT) for reading a memory page is not fixed and varies significantly with physical location and operating conditions, especially for new and less mature memory nodes.

[0035] Reads with inaccurate read thresholds result in high bit error rates (BER), which degrade memory performance and quality of service (QoS) due to decode failures that require invoking high-latency recovery flows, causing latency and performance issues. The challenge of maintaining optimal read thresholds is particularly important for enterprise memory systems with extremely stringent QoS requirements, as well as for mobile, Internet of Things (IoT), and automotive memory systems where a wide range of required operating conditions are possible and the frequency of condition changes (e.g., temperature) may be high. This problem is exacerbated during the transition to new, less mature memory nodes.

[0036] Current solutions for read threshold calibration, such as BER estimation scan (BES) and valley search (VS), are high latency operations designed to optimize the read threshold for a particular word line, which is suitable for rare read recovery flows where data cannot be decoded, but may not be suitable for frequent operations where read thresholds change frequently. To address this issue, data storage devices may implement a read threshold management scheme that attempts to track read threshold changes in the background via a maintenance process to help ensure that the appropriate read threshold is used when a host issues a read command.

[0037] A read threshold management method is to track read thresholds for each group of blocks in a memory that share the same conditions. More specifically, blocks and temperatures that are written at approximately the same time are grouped into time and temperature (TT) groups ("TT" is sometimes also referred to herein as time tags). Read thresholds are tracked for each TT group, and are typically acquired (e.g., via BES or VS) on some representative word lines from blocks within the group. When a host performs a read operation, the read threshold associated with the TT group corresponding to the read block is used. Adjustment of the read threshold according to a specific read word line can be performed based on a pre-calibrated word line partition table (i.e., a predefined correction can be applied to the read threshold of a representative word line based on the word line number being read).

[0038] In the event that a certain word line shows a BER increase or data decoding of the word line fails (e.g., a corrected error (CECC)), BES or VS can be applied in the foreground to calibrate the read threshold of the word line as part of the read error handling (REH) flow. The indicator word line can usually be selected on the edge of the block so that the BER increase is captured quickly.

[0039] One problem with this approach is that data is not matched to a specific set of parameters, but rather is grouped under similar conditions to obtain suboptimal but reasonable results (e.g., because it does not perfectly track the read threshold under frequently changing conditions and high variance between memory pages). In theory, a direct calculation of the read threshold could be run for each read flash management unit (FMU) to obtain near-optimal results. However, due to the very long duration of performing a read threshold calibration on a physical storage device, such an approach may not achieve satisfactory performance and may therefore be infeasible.

[0040] Other table-based approaches may also be used. However, due to practical table size limitations, such approaches may only consider a limited, small number of parameters, or alternatively, employ a simplified model where each factor (word line number, PEC, temperature, data retention, RD, die dependencies, etc.) affects the read threshold independently and additively, whereas in reality, the interactions may be more complex and may be more complex, non-linear functions of the various factors. Covering all condition sets in a straightforward manner of storing a data table of information for all relevant cases may result in an infeasible data table size, which would be very expensive to maintain and manage.

[0041] Other methods are described in U.S. Patent Application Nos. 17 / 838,481 and 17 / 899,073, which are incorporated herein by reference. Some of those methods apply machine learning-based methods in a controller of a data storage device for inferring an optimal read threshold based on the use of various memory parameters and data sources (e.g., data about the current target page).

[0042] Figure 4 is a diagram of an inference engine for an embodiment of machine learning based read threshold calibration. Figure 4As shown in , the interference engine 400 takes as inputs the target page features 410 and the time and temperature (TT) group features, and infers the optimal read threshold level 430 from those inputs. Thus, in this approach, all available data sources are fused to provide an inference of the optimal read level for each page or flash management unit (FMU) in the data storage device. (It should be understood that the inferred read threshold level may not be optimal, but close to optimal, or even better to some extent than the read threshold level available without using this approach.) One possible disadvantage of this approach may be that it is computationally intensive and may call upon dedicated computing resources during the reading of the target page. In another embodiment, a simpler firmware implementation may be used. However, this implementation may be associated with longer processing delays, which may cause temporary delays in the firmware process or require the addition of dedicated hardware.

[0043] The following embodiments present low complexity systems and methods for inferring near-optimal read thresholds based only on data available during a TT update, the available data including TT group information, temperature information, BER information, and program erase count (PEC) information. These embodiments can be used to infer near-optimal read thresholds with low interference to data storage devices, thereby allowing the use of firmware-based solutions, wherein the inference is driven by the firmware in a manner that does not interrupt the firmware flow but obtains excellent results. This "lightweight" solution may be important for implementing machine learning-based read threshold setting methods without supporting dedicated hardware. Therefore, these embodiments can be used to infer near-optimal read thresholds with a small firmware footprint and minimal system resource usage. This can be accomplished by calling the action only once in a TT update, thereby avoiding long background runs. Moreover, these embodiments do not require direct access to the memory in order to generate the threshold calibration, and are faster than BES. Therefore, the use of these embodiments is negligible in supplementing the existing TT calibration scheme.

[0044] In general, these embodiments can infer the optimal read threshold based on a nonlinear function that reflects multiple input and data conditions of the current memory. This solution can be uniquely adapted to provide improved results without being frequently called, thereby reducing the BER level of read data, improving performance and QoS, and reducing power consumption and CECC rates. The following paragraphs provide several example ways to perform read threshold inference (e.g., considering the basic TT update process and optimizing the acquired read threshold). It should be noted that these are only examples, and other implementations can be used. Therefore, unless explicitly stated in the claims, the details of these examples should not be read into the claims.

[0045] One example involves periodic inference. The features used by the inference model may have different update periods. While some features change constantly, other features rarely change. Typically, data related to a particular target page changes from page to page, while TT features are fairly static and may only change during a time tag update process, which may be done once in a long period of time (e.g., once every 15 minutes, once an hour, once a day, etc., depending on the product and usage conditions). Figure 5 As shown in , if the inference engine 400 (which may be in the controller 102 of the data storage device 100) only uses the TT-related features 420 and ignores the target features, the inference itself can be completed during the TT update interval. This will sacrifice some accuracy in exchange for a more relaxed system and reduce its complexity overhead. This also allows the read threshold to be inferred in the background (e.g., when the TT update is performed or some time thereafter). If the inference is not completed at the time of the TT update, the TT read threshold can be used (with some performance degradation) until it is optimized by the model at a time more convenient for the data storage device 100. In this way, the inference can be separated from the TT update process itself to obtain a finer granularity of operation.

[0046] Another example involves periodic inference using wordline partitioning. One of the features of this example is the abandonment of wordline numbering. Due to the physical differences in the memory portions, wordline numbering has a unique effect on the read threshold. Therefore, it would be advantageous to add wordline numbering to the read threshold inference. To do this, a foreground step can be used. Wordline numbering may already be part of the read stream in a data storage device using a wordline partition table that holds correction terms for each wordline group added to the TT read threshold. Therefore, if during training time, the data is changed to reflect the effect of wordline partitioning, the model can take this into account and avoid any bias that would offset this effect after addition.

[0047] This example is in Figure 6 As shown in Figure 6 As shown in , the inference engine 400 uses the TT group features as input and outputs a TT table 600. This operation can be performed in the background. The read threshold information in this table is then modified by information from the wordline partition table with the reference wordline number, where the result of the modification is the optimal read level 430. This operation can be performed in the foreground. Since the background part will usually be performed infrequently and the foreground part can be represented by a mere lookup in the table (and is already part of the read flow), this example has the advantage of not incurring a latency penalty.

[0048] The inference model can be viewed as an approximation of a multiple input function in a compact manner, where the alternative would be to save a large lookup table that would contain the values ​​of all combinations of all input variables. Since the alternative may not be feasible, the machine learning model in this example is attractive. However, the data storage device 100 may still save some lookup tables that describe a portion of this multi-dimensional function and avoid using these lookup tables for inference, thereby achieving a looser inference schedule and accurate results. In the case of consistent differences between planes / strings in word line offsets, one such example may be to use one word line partition table per plane / string. Another option is to use multiple word line partition tables based on the read temperature.

[0049] In one example embodiment, wordline numbering is a powerful, constantly changing feature and therefore worth transferring from the background to the foreground. However, in general, the explicit values ​​can be separated from the inference as long as the number of explicit values ​​is small enough to save the lookup in memory and there is sufficient benefit and as long as the explicit values ​​are taken into account when training the model. The lookup values ​​themselves can be obtained with the same large data used for model training, thereby obtaining both the background and foreground portions of the data storage device 100 with the same data collection process.

[0050] Turning now to yet another example embodiment, the read threshold may be inferred only when the TT threshold changes. In some data storage devices, inferring once for each TT update may be too challenging, and a more relaxed solution may be sought. However, most TT updates do not change the TT read threshold, but only verify the TT read threshold to ensure that it is still preserved, in which case the only features that will change are the TT BER value, which indicates the BER level generated by the current TT value and any time counters since the TT update. These inputs can help model the impact of data retention and track BER increases so that additional countermeasures can be taken if the BER increases above a certain threshold. If the impact of data retention can be ignored, assuming that increasing BER will trigger the acquisition of a new read threshold, the remaining inputs to the model can be changed only once every several TT updates, when the read threshold is considered to be mismatched by a certain threshold.

[0051] Figure 7 700 is a flow chart of a method of an embodiment in which read threshold inference is triggered only if the TT threshold changes. Figure 7As shown in , in this method, the controller 102 of the data storage device 100 determines whether a change in the TT threshold is detected (action 710). If no change is detected, no further action is taken (action 720). However, if a change is detected, the controller 102 determines whether a TT inference operation should be scheduled (action 730). If the controller 102 determines not to schedule a TT inference operation, the method loops back to action 710. However, if the controller 102 determines to schedule a TT inference operation, the controller 102 performs a read threshold inference after a period of time has passed (action 740).

[0052] In another example embodiment, the read threshold is inferred after the temperature and program erase count (PEC) change. Some data storage systems may have fewer constraints. Although these data storage systems may not be able to infer the read threshold for every incoming read command, they may be able to infer the read threshold once per second or minute. In this case, the model can add other features that change faster than the TT group but do not change with the FMU (e.g., PEC, current temperature, or even BER statistics).

[0053] Figure 8 Σ is a graph of mean failed bit count (FBC) for different example test conditions of the embodiment. These results are based on experiments comparing several read threshold acquisition schemes, and the tests were performed with sequential / random write / read workloads and continuous chamber temperature sweeps to induce all temperature / X temperature conditions. It is carried out under field conditions with a temperature range of 10°C to 90°C. Figure 8 As shown in , the read thresholds obtained by TT achieve a higher FBC than the read threshold FBCs obtained by all ARTs. Also, the periodic inference method shows better FBC than TT, but still shows a significant gap with the full hardware mainstream ART implementation cyan. However, adding wordline partitioning in the foreground to the periodic inference closes most of the gap with the full hardware version. This provides an attractive alternative for data storage devices that cannot implement the hardware version.

[0054] There are several advantages associated with these embodiments. For example, these embodiments can be used to generate improved read thresholds, resulting in reduced BER, which can improve memory latency and throughput, reduce power consumption, reduce CECC rates, and improve QoS. These embodiments can be implemented in firmware, so that this solution can be used in low-cost / existing controllers.

[0055] Finally, as mentioned above, any suitable type of memory may be used. Semiconductor memory devices include: volatile memory devices, such as dynamic random access memory ("DRAM") or static random access memory ("SRAM") devices; non-volatile memory devices, such as ReRAM, electrically erasable programmable read-only memory ("EEPROM"), flash memory (which may also be considered a subset of EEPROM), ferroelectric random access memory ("FRAM"), and MRAM; as well as other semiconductor elements capable of storing information. Each type of memory device may have a different configuration. For example, a flash memory device may be configured in a NAND or NOR configuration.

[0056] Memory devices may be formed of passive and / or active elements in any combination. By way of non-limiting example, passive semiconductor memory elements include ReRAM device elements, which in some embodiments include resistivity switching storage elements, such as antifuses, phase change materials, etc., and optionally include steering elements, such as diodes, etc. Further by way of non-limiting example, active semiconductor memory elements include EEPROM and flash memory device elements, which in some embodiments include elements containing charge storage regions, such as floating gates, conductive nanoparticles, or charge storage dielectric materials.

[0057] Multiple memory elements may be configured so that they are connected in series or so that each element is individually accessible. By way of non-limiting example, a flash memory device in a NAND configuration (NAND memory) typically contains memory elements connected in series. A NAND memory array may be configured so that the array consists of multiple memory strings, where a string consists of multiple memory elements that share a single bit line and are accessed as a group. Alternatively, the memory elements may be configured so that each element is individually accessible, such as a NOR memory array. NAND and NOR memory configurations are examples, and memory elements may be configured in other ways.

[0058] Semiconductor memory elements located within and / or above the substrate may be arranged in two or three dimensions, such as a two-dimensional (2D) memory structure or a three-dimensional (3D) memory structure.

[0059] In a 2D memory structure, semiconductor memory elements are arranged in a single plane or a single memory device level. Typically, in a 2D memory structure, the memory elements are arranged in a plane extending substantially parallel to the major surface of a substrate supporting the memory elements (e.g., in an xz-direction plane). The substrate may be a wafer on which or in which a layer of memory elements is formed, or may be a carrier substrate attached to the memory elements after the memory elements are formed. As a non-limiting example, the substrate may include a semiconductor such as silicon.

[0060] The memory elements may be arranged in a single memory device level in an ordered array, such as a plurality of rows and / or columns. However, the memory elements may be arranged in an irregular or non-orthogonal configuration. The memory elements may each have two or more electrodes or contact lines, such as a bit line and a word line.

[0061] A 3D memory array is arranged so that the memory elements occupy multiple planes or multiple memory device levels, thereby forming a structure in three dimensions (i.e., in x, y and z directions, where the y direction is substantially perpendicular to the major surface of the substrate, and the x and z directions are substantially parallel to the major surface of the substrate).

[0062] As a non-limiting example, a 3D memory structure may be arranged vertically as a stack of multiple 2D memory device levels. As another non-limiting example, a 3D memory array may be arranged as a plurality of vertical columns (e.g., columns extending substantially perpendicular to a major surface of a substrate (i.e., in the y-direction)), wherein each column has a plurality of memory elements in each column. The columns may be arranged, for example, in a 2D configuration in the xz plane, thereby producing a 3D arrangement of memory elements, wherein the elements are on multiple vertically stacked memory planes. Other configurations of memory elements in three dimensions may also constitute a 3D memory array.

[0063] By way of non-limiting example, in a 3D NAND memory array, memory elements may be coupled together to form NAND strings within a single horizontal (e.g., xz) memory device level. Alternatively, memory elements may be coupled together to form vertical NAND strings that traverse multiple horizontal memory device levels. Other 3D configurations are contemplated in which some NAND strings contain memory elements in a single memory level, while other strings contain memory elements that span multiple memory levels. 3D memory arrays may also be designed in NOR configurations and ReRAM configurations.

[0064] Typically, in a monolithic 3D memory array, one or more memory device levels are formed over a single substrate. Optionally, a monolithic 3D memory array may also have one or more memory layers at least partially within a single substrate. As a non-limiting example, the substrate may include a semiconductor such as silicon. In a monolithic 3D array, the layers that make up each memory device level of the array are typically formed on the layers of the underlying memory device level of the array. However, the layers of adjacent memory device levels of a monolithic 3D memory array may be shared between memory device levels, or have intervening layers between memory device levels.

[0065] Also, two-dimensional arrays may be formed separately and then packaged together to form a non-monolithic memory device having multiple memory layers. For example, a non-monolithic stacked memory may be constructed by forming memory levels on separate substrates and then stacking the memory levels on top of each other. The substrate may be thinned or removed from the memory device levels prior to stacking, but since the memory device levels are initially formed over separate substrates, the resulting memory array is not a monolithic 3D memory array. Furthermore, multiple 2D memory arrays or 3D memory arrays (monolithic or non-monolithic) may be formed on separate chips and then packaged together to form a stacked chip memory device.

[0066] Typically, associated circuitry is required to operate and communicate with the memory element. As a non-limiting example, a memory device may have circuitry for controlling and driving the memory element to implement functions such as programming and reading. This associated circuitry may be on the same substrate as the memory element and / or on a separate substrate. For example, a controller for memory read and write operations may be located on a separate controller chip and / or on the same substrate as the memory element.

[0067] Those skilled in the art will recognize that the present invention is not limited to the described 2D and 3D structures, but encompasses all related memory structures within the spirit and scope of the invention as described herein and as understood by those skilled in the art.

[0068] It is intended that the foregoing detailed description be understood as an illustration of selected forms that the invention may take, rather than as a limitation of the invention. Only the appended claims (including all equivalents) are intended to define the scope of the invention as claimed. Finally, it should be noted that any aspect of any embodiment described herein may be used alone or in combination with each other.

Claims

1. A method, in a data storage device including a memory, the method comprising: inferring a read threshold based on a nonlinear function reflecting a plurality of input and data conditions of the current memory; as well as The read threshold is used when reading a word line in the memory.

2. The method of claim 1, wherein the read threshold is inferred by using machine learning in the background and a static table in the foreground.

3. The method of claim 2, wherein the machine learning is trained to consider future static tables in the foreground. The method of claim 1 , wherein the plurality of inputs comprises a programming temperature. The method of claim 1 , wherein the plurality of inputs includes temperature during time tag updates. The method of claim 1 , wherein the plurality of inputs includes a time elapsed since a previous time stamp update.

7. The method of claim 1, wherein the plurality of inputs includes time tag bit error rate (BER) information. The method of claim 1 , further comprising periodically updating the read threshold.

9. The method of claim 1, further comprising modifying the read threshold based on a value in an entry in a wordline partition table associated with the wordline.

10. A data storage device, comprising: Memory; as well as a controller coupled to the memory and configured to: inferring, using an inference engine, a read threshold for reading the word line based on data available during a time tag update rather than based on data currently associated with the word line in the memory; as well as The word line is read using the read threshold.

11. The data storage device of claim 10, wherein the data available during the time stamp update includes a programming temperature.

12. The data storage device of claim 10, wherein the data available during the time stamp update includes a temperature during the time stamp update.

13. The data storage device of claim 10, wherein the data available during the time stamp update includes the time that has elapsed since a previous time stamp update.

14. The data storage device of claim 10, wherein the data available during the time tag update includes time tag bit error rate (BER) information.

15. The data storage device of claim 10, wherein the controller is further configured to use the inference engine to periodically infer a read threshold.

16. The data storage device of claim 10, wherein the controller is further configured to use the inference engine to periodically infer a read threshold when a time tag threshold has changed.

17. The data storage device of claim 10, wherein the controller is further configured to use the inference engine to periodically infer a read threshold when temperature and / or a program erase cycle (PEC) count has changed.

18. The data storage device of claim 10, wherein the controller is further configured to use the inference engine to periodically infer a read threshold during a time tag update.

19. The data storage device of claim 10, wherein the controller is further configured to modify the read threshold based on a value in an entry in a wordline partition table associated with the wordline, wherein the read threshold is inferred as a background operation and modified as a foreground operation.

20. The data storage device of claim 10, wherein the inference engine is implemented as firmware in the controller.

21. The data storage device of claim 10, wherein the memory comprises a three-dimensional memory.

22. A data storage device comprising: Memory; means for inferring a read threshold based on a non-linear function reflecting a plurality of input and data conditions of the current memory; as well as Means for using the read threshold when reading a word line in the memory.

Images