Command optimization through intelligent threshold detection

Aspects of a storage device including a memory and a controller are provided which prevent retransmissions of set features commands with identical read voltage threshold offsets for the same die. When the controller receives a first read command for data stored in the memory, the controller identifies a first parameter to modify a first read threshold, and executes a first set features command for modifying the read threshold based on the first parameter. Subsequently, when the controller receives a second read command from the host device for data stored in the memory, the controller identifies a second parameter to modify a second read threshold, and determines whether the first and second parameters are the same. If the parameters are the same, the controller refrains from executing a second set features command for modifying the second read threshold. Thus, the read latency of the storage device may be reduced.

BACKGROUND

Field

This disclosure is generally related to electronic devices and more particularly to storage devices.

Background

Storage devices enable users to store and retrieve data. Examples of storage devices include non-volatile memory devices. A non-volatile memory generally retains data after a power cycle. An example of a non-volatile memory is a flash memory, which may include array(s) of NAND cells on one or more dies. Flash memory may be found in solid-state devices (SSDs), Secure Digital (SD) cards, and the like.

A flash storage device may store control information associated with data. For example, a flash storage device may maintain control tables that include a mapping of logical addresses to physical addresses. This control tables are used to track the physical location of logical sectors, or blocks, in the flash memory. The control tables are stored in the non-volatile memory to enable access to the stored data after a power cycle.

When the flash storage device reads data from a cell of the flash memory, e.g. from a memory location such as a block, a read voltage of the cell is compared against one or more read voltage thresholds, and the data stored in the cell (e.g. a logic 0 or 1) is identified based on the comparison. In some cases, the flash storage device may perform dynamic reads, during which the read voltage threshold(s) may be offset using a set features command prior to each read in order to clearly identify the stored data in the cell. However, sending a set features command before each read may take significant time relative to the read sense command (e.g. approximately 2 μs compared to less than 1 μs for a read), thus increasing read latency and impacting the performance of the flash storage device.

SUMMARY

One aspect of a storage device is disclosed herein. The storage device includes a memory and a controller. The memory includes a first memory location and a second memory location. The controller is configured to receive a first read command from a host device for data stored in the first memory location, to identify a first parameter to modify a first read threshold associated with the first memory location, and to execute a first set features command for modifying the first read threshold based on the first parameter. The controller is further configured to receive a second read command from the host device for data stored in the second memory location, to identify a second parameter to modify a second read threshold associated with the second memory location, and to refrain from executing a second set features command for modifying the second read threshold when the second parameter is the same as the first parameter.

One aspect of a method is disclosed herein. The method includes receiving a first read command from a host device for data stored in a first memory location of a memory of a storage device, identifying a first parameter to modify a first read threshold associated with the first memory location, and executing a first set features command for modifying the first read threshold based on the first parameter. The method further includes receiving a second read command from the host device for data stored in a second memory location of the memory of the storage device, identifying a second parameter to modify a second read threshold associated with the second memory location, and refraining from executing a second set features command for modifying the second read threshold when the second parameter is the same as the first parameter.

A further aspect of a storage device is disclosed herein. The storage device includes a memory and a controller. The memory includes a first memory location and a second memory location. The controller is configured to receive a first read command from a host device for data stored in the first memory location, to identify a first parameter to modify a first read threshold associated with the first memory location, to execute a first set features command for modifying the first read threshold based on the first parameter, to receive a second read command from the host device for data stored in the second memory location, and to identify a second parameter to modify a second read threshold associated with the second memory location. The storage device also includes means for comparing the first parameter with the second parameter. The controller is further configured to determine when the second parameter is the same as the first parameter based on the means for comparing, and to refrain from executing a second set features command for modifying the second read threshold when the second parameter is the same as the first parameter.

It is understood that other aspects of the storage device and method will become readily apparent to those skilled in the art from the following detailed description, wherein various aspects of apparatuses and methods are shown and described by way of illustration. As will be realized, these aspects may be implemented in other and different forms and its several details are capable of modification in various other respects. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.

DETAILED DESCRIPTION

The detailed description set forth below in connection with the appended drawings is intended as a description of various exemplary embodiments of the present invention and is not intended to represent the only embodiments in which the present invention may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring the concepts of the present invention. Acronyms and other descriptive terminology may be used merely for convenience and clarity and are not intended to limit the scope of the invention.

The words “exemplary” and “example” are used herein to mean serving as an example, instance, or illustration. Any exemplary embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other exemplary embodiments. Likewise, the term “exemplary embodiment” of an apparatus, method or article of manufacture does not require that all exemplary embodiments of the invention include the described components, structure, features, functionality, processes, advantages, benefits, or modes of operation.

In the following detailed description, various aspects of a storage device in communication with a host device will be presented. These aspects are well suited for flash storage devices, such as SSDs and SD cards. However, those skilled in the art will realize that these aspects may be extended to all types of storage devices capable of storing data. Accordingly, any reference to a specific apparatus or method is intended only to illustrate the various aspects of the present invention, with the understanding that such aspects may have a wide range of applications without departing from the spirit and scope of the present disclosure.

When a storage device performs multiple dynamic reads of a single die, the storage device generally sends a set features command prior to each read. Each set features command may include one or more read voltage threshold offsets, which modify the default, programmed read voltage threshold(s) of cells to assist the storage device in clearly identifying the data stored in the cells (e.g. as a logic 0 or 1). However, in certain cases such as dynamic reads of the same die, multiple set features commands may be provided that indicate the same read voltage threshold offsets. Such duplicative set features commands may be inefficient, increasing the read latency and affecting the performance of the storage device.

To improve storage device performance, the present disclosure allows a controller of the storage device to refrain from sending multiple set features commands with identical read voltage threshold offsets based on a threshold history buffer for each die or page, and a comparator such as an XOR engine. When the controller performs an initial dynamic read, the controller identifies a parameter, e.g., a threshold vector, indicating a read voltage threshold offset for the cells of a memory location (such as a block of a die). The controller then stores the parameter in the threshold history buffer for that die (or page), e.g., as a last threshold vector. The controller executes an initial set features command including this parameter to modify the read voltage threshold, and then the controller performs the dynamic read accordingly. Afterwards, when the controller performs another dynamic read for that die, the controller identifies a new parameter, e.g. a target threshold vector, indicating another read voltage threshold offset.

However, before executing another set features command including this new parameter, the controller uses the comparator to determine whether the new parameter (the target threshold vector) is the same as the stored parameter (the last threshold vector). If the parameters are the same (e.g. an XOR result is 0 or an XNOR result is non-zero), the controller determines that the read voltage threshold offset has not changed, and the controller refrains from sending another set features command prior to performing the subsequent dynamic read. Otherwise, if the parameters are different (e.g. an XOR result is non-zero or an XNOR result is 0), the controller executes another set features command with the new offset prior to performing the subsequent dynamic read, and the threshold history buffer for that die or page is overwritten with the new parameter indicating the offset. In this way, the storage device may refrain from retransmitting set features commands with the same read voltage threshold offset when dynamically reading the same die, thereby reducing overall read latency and improving storage device performance.

FIG. 1shows an exemplary block diagram100of a storage device102which communicates with a host device104(also “host”) according to an exemplary embodiment. The host104and the storage device102may form a system, such as a computer system (e.g., server, desktop, mobile/laptop, tablet, smartphone, etc.). The components ofFIG. 1may or may not be physically co-located. In this regard, the host104may be located remotely from storage device102. AlthoughFIG. 1illustrates that the host104is shown separate from the storage device102, the host104in other embodiments may be integrated into the storage device102, in whole or in part. Alternatively, the host104may be distributed across multiple remote entities, in its entirety, or alternatively with some functionality in the storage device102.

Those of ordinary skill in the art will appreciate that other exemplary embodiments can include more or less than those elements shown inFIG. 1and that the disclosed processes can be implemented in other environments. For example, other exemplary embodiments can include a different number of hosts communicating with the storage device102, or multiple storage devices102communicating with the host(s).

The host device104may store data to, and/or retrieve data from, the storage device102. The host device104may include any computing device, including, for example, a computer server, a network attached storage (NAS) unit, a desktop computer, a notebook (e.g., laptop) computer, a tablet computer, a mobile computing device such as a smartphone, a television, a camera, a display device, a digital media player, a video gaming console, a video streaming device, or the like. The host device104may include at least one processor101and a host memory103. The at least one processor101may include any form of hardware capable of processing data and may include a general purpose processing unit (such as a central processing unit (CPU)), dedicated hardware (such as an application specific integrated circuit (ASIC)), digital signal processor (DSP), configurable hardware (such as a field programmable gate array (FPGA)), or any other form of processing unit configured by way of software instructions, firmware, or the like. The host memory103may be used by the host device104to store data or instructions processed by the host or data received from the storage device102. In some examples, the host memory103may include non-volatile memory, such as magnetic memory devices, optical memory devices, holographic memory devices, flash memory devices (e.g., NAND or NOR), phase-change memory (PCM) devices, resistive random-access memory (ReRAM) devices, magnetoresistive random-access memory (MRAM) devices, ferroelectric random-access memory (F-RAM), and any other type of non-volatile memory devices. In other examples, the host memory103may include volatile memory, such as 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, and the like). The host memory103may also include both non-volatile memory and volatile memory, whether integrated together or as discrete units.

The host interface106is configured to interface the storage device102with the host104via a bus/network108, and may interface using, for example, Ethernet or WiFi, or a bus standard such as Serial Advanced Technology Attachment (SATA), PCI express (PCIe), Small Computer System Interface (SCSI), or Serial Attached SCSI (SAS), among other possible candidates. Alternatively, the host interface106may be wireless, and may interface the storage device102with the host104using, for example, cellular communication (e.g. 5G NR, 4G LTE, 3G, 2G, GSM/UMTS, CDMA One/CDMA2000, etc.), wireless distribution methods through access points (e.g. IEEE 802.11, WiFi, HiperLAN, etc.), Infra Red (IR), Bluetooth, Zigbee, or other Wireless Wide Area Network (WWAN), Wireless Local Area Network (WLAN), Wireless Personal Area Network (WPAN) technology, or comparable wide area, local area, and personal area technologies.

As shown in the exemplary embodiment ofFIG. 1, the storage device102includes non-volatile memory (NVM)110for non-volatilely storing data received from the host104. The NVM110can include, for example, flash integrated circuits, NAND memory (e.g., single-level cell (SLC) memory, multi-level cell (MLC) memory, triple-level cell (TLC) memory, quad-level cell (QLC) memory, penta-level cell (PLC) memory, or any combination thereof), or NOR memory. The NVM110may include a plurality of memory locations112which may store system data for operating the storage device102or user data received from the host for storage in the storage device102. For example, the NVM may have a cross-point architecture including a 2-D NAND array of memory locations112having n rows and m columns, where m and n are predefined according to the size of the NVM. In the illustrated exemplary embodiment ofFIG. 1, each memory location112may be a block114including multiple cells116. The cells116may be single-level cells, multi-level cells, triple-level cells, quad-level cells, and/or penta-level cells, for example. Other examples of memory locations112are possible; for instance, each memory location may be a die containing multiple blocks. Moreover, each memory location may include one or more blocks in a 3-D NAND array. Moreover, the illustrated memory locations112may be logical blocks which are mapped to one or more physical blocks.

The storage device102also includes a volatile memory118that can, for example, include a Dynamic Random Access Memory (DRAM) or a Static Random Access Memory (SRAM). Data stored in volatile memory118can include data read from the NVM110or data to be written to the NVM110. In this regard, the volatile memory118can include a write buffer or a read buffer for temporarily storing data. WhileFIG. 1illustrates the volatile memory118as being remote from a controller123of the storage device102, the volatile memory118may be integrated into the controller123.

The memory (e.g. NVM110) is configured to store data119received from the host device104. The data119may be stored in the cells116of any of the memory locations112. As an example,FIG. 1illustrates data119being stored in different memory locations112, although the data may be stored in the same memory location. In another example, the memory locations112may be different dies, and the data may be stored in one or more of the different dies.

Each of the data119may be associated with a logical address. For example, the NVM110may store a logical-to-physical (L2P) mapping table120for the storage device102associating each data119with a logical address. The L2P mapping table120stores the mapping of logical addresses specified for data written from the host104to physical addresses in the NVM110indicating the location(s) where each of the data is stored. This mapping may be performed by the controller123of the storage device. The L2P mapping table may be a table or other data structure which includes an identifier such as a logical block address (LBA) associated with each memory location112in the NVM where data is stored. WhileFIG. 1illustrates a single L2P mapping table120stored in one of the memory locations112of NVM to avoid unduly obscuring the concepts ofFIG. 1, the L2P mapping table120in fact may include multiple tables stored in one or more memory locations of NVM.

FIG. 2is a conceptual diagram200of an example of an L2P mapping table205illustrating the mapping of data202received from a host device to logical addresses and physical addresses in the NVM110ofFIG. 1. The data202may correspond to the data119inFIG. 1, while the L2P mapping table205may correspond to the L2P mapping table120inFIG. 1. In one exemplary embodiment, the data202may be stored in one or more pages204, e.g., pages 1 to x, where x is the total number of pages of data being written to the NVM110. Each page204may be associated with one or more entries206of the L2P mapping table205identifying a logical block address (LBA)208, a physical address210associated with the data written to the NVM, and a length212of the data. LBA208may be a logical address specified in a write command for the data received from the host device. Physical address210may indicate the block and the offset at which the data associated with LBA208is physically written. Length212may indicate a size of the written data (e.g. 4 KB or some other size).

Referring back toFIG. 1, the volatile memory118also stores a cache122for the storage device102. The cache122includes entries showing the mapping of logical addresses specified for data requested by the host104to physical addresses in NVM110indicating the location(s) where the data is stored. This mapping may be performed by the controller123. When the controller123receives a read command or a write command for data119, the controller checks the cache122for the logical-to-physical mapping of each data. If a mapping is not present (e.g. it is the first request for the data), the controller accesses the L2P mapping table120and stores the mapping in the cache122. When the controller123executes the read command or write command, the controller accesses the mapping from the cache and reads the data from or writes the data to the NVM110at the specified physical address. The cache may be stored in the form of a table or other data structure which includes a logical address associated with each memory location112in NVM where data is being read.

The NVM110includes sense amplifiers124and data latches126connected to each memory location112. For example, the memory location112may be a block including cells116on multiple bit lines, and the NVM110may include a sense amplifier124on each bit line. Moreover, one or more data latches126may be connected to the bit lines and/or sense amplifiers. The data latches may be, for example, shift registers. When data is read from the cells116of the memory location112, the sense amplifiers124sense the data by amplifying the voltages on the bit lines to a logic level (e.g. readable as a ‘0’ or a ‘1’), and the sensed data is stored in the data latches126. The data is then transferred from the data latches126to the controller123, after which the data is stored in the volatile memory118until it is transferred to the host device104. When data is written to the cells116of the memory location112, the controller123stores the programmed data in the data latches126, and the data is subsequently transferred from the data latches126to the cells116.

The storage device102includes a controller123which includes circuitry such as one or more processors for executing instructions and can include a microcontroller, a Digital Signal Processor (DSP), an Application-Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), hard-wired logic, analog circuitry and/or a combination thereof.

The controller123is configured to receive data transferred from one or more of the cells116of the various memory locations112in response to a read command. For example, the controller123may read the data119by activating the sense amplifiers124to sense the data from cells116into data latches126, and the controller123may receive the data from the data latches126. The controller123is also configured to program data into one or more of the cells116in response to a write command. For example, the controller123may write the data119by sending data to the data latches126to be programmed into the cells116. The controller123is further configured to access the L2P mapping table120in the NVM110when reading or writing data to the cells116. For example, the controller123may receive logical-to-physical address mappings from the NVM110in response to read or write commands from the host device104, identify the physical addresses mapped to the logical addresses identified in the commands (e.g. translate the logical addresses into physical addresses), and access or store data in the cells116located at the mapped physical addresses.

The controller123and its components may be implemented with embedded software that performs the various functions of the controller described throughout this disclosure. Alternatively, software for implementing each of the aforementioned functions and components may be stored in the NVM110or in a memory external to the storage device102or host device104, and may be accessed by the controller123for execution by the one or more processors of the controller123. Alternatively, the functions and components of the controller may be implemented with hardware in the controller123, or may be implemented using a combination of the aforementioned hardware and software.

In operation, the host device104stores data in the storage device102by sending a write command to the storage device102specifying one or more logical addresses (e.g., LBAs) as well as a length of the data to be written. The interface element106receives the write command, and the controller allocates a memory location112in the NVM110of storage device102for storing the data. The controller123stores the L2P mapping in the NVM (and the cache122) to map a logical address associated with the data to the physical address of the memory location112allocated for the data. The controller also stores the length of the L2P mapped data. The controller123then stores the data in the memory location112by sending it to one or more data latches126connected to the allocated memory location, from which the data is programmed to the cells116.

The host104may retrieve data from the storage device102by sending a read command specifying one or more logical addresses associated with the data to be retrieved from the storage device102, as well as a length of the data to be read. The interface106receives the read command, and the controller123accesses the L2P mapping in the cache122or otherwise the NVM to translate the logical addresses specified in the read command to the physical addresses indicating the location of the data. The controller123then reads the requested data from the memory location112specified by the physical addresses by sensing the data using the sense amplifiers124and storing them in data latches126until the read data is returned to the host104via the host interface106.

When the controller123reads data119from the NVM110as described above, the controller compares the voltage in the cells116with one or more read voltage thresholds to determine the logical value of the data.FIG. 3illustrates an example of a voltage distribution chart300for multi-level cells storing two bits of data (e.g. a logic 00, 01, 10, or 11). The logical value of each multi-level cell may be determined based on a comparison of a voltage in the cell with read threshold voltages302,304,306. For example, the controller may determine that a particular cell stores data corresponding to logic ‘11’ when the voltage of the cell is below read threshold voltage302, logic ‘10’ when the voltage is between read threshold voltage302and read threshold voltage304, logic ‘01’ when the voltage is between read threshold voltage304and read threshold voltage306, or logic ‘00’ when the voltage is above read threshold voltage306. WhileFIG. 3illustrates three read threshold voltages for multi-level cells, the number of read threshold voltages may change depending on the amount of data that is stored in each cell (e.g. one threshold voltage for single-level cells, seven threshold voltages for triple-level cells, etc.).

Although the controller123may read data119from cells116using default read voltages (e.g. read threshold voltages302,304,306), in some cases the read threshold voltages may not clearly differentiate the stored data in the cells (e.g. as a logic 00, 01, etc.). For example, in some cases the read threshold voltages302,304,306may overlap with one or more of the respective curves ofFIG. 3, resulting in possible data read errors. In such cases, the controller may reduce read errors by performing a dynamic read operation, e.g. dynamically applying read threshold voltage offsets to modify the default read thresholds when reading the data. To modify the read thresholds, the controller123may send a set features command.

FIG. 4illustrates an example400of multiple dynamic read commands preceded by individual set features commands. When the controller123receives a first read command from host device104, the controller may execute a first set features command402to modify the read voltage threshold(s)302,304,306prior to executing a first dynamic read command404for data requested by the host device. Similarly, when the controller receives a second read command from the host device, the controller may execute a second set features command406to modify the read voltage threshold(s) prior to executing a second dynamic read command408for data requested by the host device. Each dynamic read command may request data in a single plane of a particular die (e.g. a single plane dynamic read).

In one example, when the controller123executes a set features command402,406, the controller may send to a sequencer in the NVM110a value indicating the command (e.g. D5h for set features), a die address indicating the target die for the command, a feature address indicating a feature register for storing the voltage threshold offsets, and one or more parameter(s)403,407(e.g. a sequence of four bytes) indicating the voltage threshold offsets to be stored in the feature register. In some cases, the controller may subsequently track an internal busy status of the die (e.g. through status queries) before proceeding to send the dynamic read command404,408. Alternatively, the controller may refrain from tracking the internal busy status and wait a period of time (e.g. tFeat_NO_BUSY or approximately 700 ns or another number) prior to sending the dynamic read command, which may optimally save more time (e.g. at least 300-400 ns) than tracking the internal busy status.

After executing the set features command402,406, when the controller123executes the dynamic read command404,408, the controller may send to the sequencer values indicating the command (e.g. 5Dh for dynamic read, followed by00hand30hfor the read operation), a physical address to read the data (e.g. physical address210), and status commands (e.g. F1h) which may repeat until the controller receives an indication that the die is ready. The parameters403,407stored in the feature register may be used to offset the read voltage thresholds when reading the data from the cells. Once the data is dynamically read, the data is subsequently transferred to the controller, e.g. to volatile memory118for transfer to the host device.

However, when the storage device102heavily relies on dynamic read commands404,408to read data based on voltage threshold offsets, sending a set features command402,406prior to each dynamic read command may increase the read latency of the storage device.FIG. 5illustrates a timing diagram500showing an example of the timing difference between a set features command and a dynamic read command. As shown in the diagram, a timing502for executing a set features command may be significantly longer than a timing504for executing a dynamic read command. For instance, while the timing504to complete a read sense command may be less than 1 μs, the timing502to construct and send a set features command (even when optimized to not use busy status tracking as described above) may be approximately 2 μs. Thus, when a set features command is re-transmitted prior to each read sense command, the overall impact to the read latency of the storage device may be significant, especially for random reads where more dynamic read commands may be executed than for sequential reads.

To address this issue,FIG. 6illustrates an example600of a threshold history buffer602and comparator604which may be used for minimizing re-transmission of set features commands (e.g. second set features command406) to reduce the aforementioned read latency. The threshold history buffer602may be a buffer in volatile memory118(e.g. cache122) that stores a most recent or last threshold vector for a die. The last threshold vector may be the parameter403,407identified in the set features command402,406, which indicates the read threshold voltage offset(s) for a particular die. For instance, referring toFIG. 4, the last threshold vector may correspond to parameter403(e.g. the sequence of four bytes) in set features command402when dynamic read command404is the most recently executed read command. The threshold history buffer602may be implemented in firmware/software, or in hardware (e.g. an ASIC) as illustrated inFIG. 6. For instance, the threshold history buffer may include one or more data latches that are wired to the feature register which stores the voltage threshold offsets as described above.

In one example, the threshold history buffer602may be associated with an individual die601. For instance, multiple threshold history buffers602may be present in hardware, with each buffer associated with a respective die. Thus, each threshold history buffer may store the last threshold vector for a different die. For instance, if set features commands402and406include different die addresses, parameter403may be stored in one threshold history buffer associated with the first die address, and parameter407may be stored in another threshold history buffer associated with the second die address.

In another example, the threshold history buffer602may be associated with an individual page603of a memory location605. Memory location605may correspond to memory location112, e.g. block114. For example, multiple threshold history buffers602may be present in hardware, with each buffer associated with a respective page of a block of a die. Thus, each threshold history buffer may store the last threshold vector for a different page. For instance, if dynamic read commands404,408include different physical addresses (associated with different pages), parameter403may be stored in one threshold history buffer associated with the first page, and parameter407may be stored in another threshold history buffer associated with the second page.

Each threshold history buffer602may include one or more indicators606or variables (e.g. A, C, E, G) that represent individual components or voltage settings of the last threshold vector. For instance, the first indicator A may represent the first byte of parameter403, the second indicator C may represent the second byte of parameter403, the third indicator E may represent the third byte of parameter403, and the fourth indicator G may represent the fourth byte of parameter403. While the threshold history buffer602illustrated inFIG. 6spans four bytes (32 bits) with four indicators (A, C, E, G), the threshold history buffer602may alternatively span other lengths or include other numbers of indicators606based on a length or composition of parameter403. For instance, if parameter403is a single byte, threshold history buffer602may include four indicators each representing 2 bits of parameter403, one indicator representing the entire 8 bits of parameter403, or other examples.

The comparator604may receive, as an input, data from the threshold history buffer602. The comparator604may be implemented in firmware/software (e.g. as an XOR or XNOR operand), or in hardware as illustrated inFIG. 6. For instance, the comparator604may include XOR gates or XNOR gates that are wired to the threshold history buffer602. The length of comparator604may correspond to the length of the threshold history buffer602. For example, if threshold history buffer602spans 32 bits in length as described above, comparator604may include 32 XOR or XNOR gates which respectively receive individual bits from the threshold history buffer. Additionally, whileFIG. 6illustrates one comparator604and threshold history buffer602, multiple comparators and threshold history buffers may be present. For instance, where multiple threshold history buffers are respectively associated with different dies (or pages) as described above, multiple comparators604may be included in hardware which are individually wired to respective threshold history buffers.

When the controller123receives a read command from the host device104, the controller may identify a target threshold vector608indicating a read voltage threshold offset for reading the data from the NVM110. For example, when the read command is the first read command associated with a particular die, the target threshold vector may correspond to parameter403ofFIG. 4, which may be a sequence of bytes that indicate the read threshold voltage offset(s) for the die associated with the first read command (e.g. dynamic read command404). Alternatively, when the read command is the second or later read command associated with the same die, the target threshold vector may correspond to parameter407ofFIG. 4, which may be a sequence of bytes that indicate the read threshold voltage offset(s) for the die associated with the second or later read command (e.g. dynamic read command408). The target threshold vector608may also have the same length as the last threshold vector in the threshold history buffer602. For example, the target threshold vector608may similarly be represented by four indicators (A, C, E, and G), with each indicator representing a corresponding one of the four bytes of parameter403or407illustrated inFIG. 4.

In one example of operation, the controller may receive a first read command for reading data from memory location605,607of die601. In such case, the controller may identify an initial target threshold vector (e.g. parameter403) to modify the read voltage threshold(s) for the cells or page603in that memory location, and the controller may send a set features command (e.g. set features command402) prior to performing the read operation (e.g. dynamic read command404). The threshold history buffer602for die601or page603may then be updated with the initial target threshold vector, thereby becoming the last threshold vector for the die or page. For example, when the threshold history buffer is implemented in firmware/software, the controller123may update the buffer with the most recently identified threshold vector. In another example, when the threshold history buffer is implemented in hardware, the threshold history buffer may be automatically updated with the read voltage threshold offsets from the feature register (e.g. in response to the set features command402).

Subsequently, the controller may receive a second read command for reading data from memory location605,607of die601. In such case, the controller may identify a target threshold vector608(e.g. parameter407) to modify the read voltage threshold(s) for the cells or page603in that memory location. However, the controller may refrain from sending another set features command (e.g. set features command406) prior to performing the read operation (e.g. dynamic read command408) if the threshold vector or offset(s) has not changed since the previous set features command.

To determine whether the offsets have changed, the controller uses comparator604to compare the target threshold vector608with the last threshold vector in threshold history buffer602corresponding to the die601or page603. If a result610of the comparison indicates the parameters are the same, the controller refrains from re-transmitting the set features command, and the dynamic read command (e.g. dynamic read command408) may be performed based on the previously stored voltage threshold offsets. Alternatively, if the result610of the comparison indicates the parameters are different, the controller re-transmits the set features command (e.g. set features command406) and performs the dynamic read command based on the updated voltage threshold offsets. For example, if the comparator604includes XOR gates, the controller may refrain from re-transmitting the set features command when the result610is zero, and the controller may re-transmit the set features command when the result610is non-zero. Similarly, if the comparator604includes XNOR gates, the controller may refrain from re-transmitting the set features command when the result610is non-zero, and the controller may re-transmit the set features command when the result610is zero. The threshold history buffer602may then be updated with the target threshold vector, thereby becoming the last threshold vector for the die601or page603. For instance, when the threshold history buffer is implemented in hardware, the threshold history buffer may be automatically updated with the modified read voltage threshold offsets from the updated feature register (e.g. in response to the set features command406).

As a result, since the storage device may refrain from sending duplicate set features commands when the read voltage threshold offset is unchanged, the read latency of the storage device may be reduced. For instance,FIG. 7illustrates an example700of a modified command sequence with respect toFIG. 4in which the controller may refrain from re-transmitting set features commands for the same die based on the result610of the comparison of threshold vectors inFIG. 6. For instance, while the controller may send an initial set features command702in response to a read command from a host device prior to sending an initial dynamic read command704for a particular die, the controller may refrain from sending another set features command in response to a subsequent read command prior to sending another dynamic read command706based on the threshold vector comparison described above.

FIG. 8illustrates an example flow chart800of a method for preventing retransmission of multiple set feature commands with identical read voltage threshold offsets. For example, the method can be carried out in a storage device102such as the one illustrated inFIG. 1. Each of the steps in the flow chart can be controlled using the controller as described below (e.g. controller123), or by some other suitable means. Optional aspects are illustrated in dashed lines.

As represented by block802, the controller receives a first read command from a host device for data stored in a first memory location of a memory. For example, referring toFIGS. 1 and 6, the controller123may receive a first read command from the host device104for data119stored in a memory location112(e.g. memory location605) of the NVM110.

As represented by block804, the controller identifies a first parameter to modify a first read threshold associated with the first memory location. The first parameter may comprise a first voltage setting. The first parameter may also indicate a die having the first memory location. Moreover, the first parameter may indicate a first page of the first memory location. For example, referring toFIGS. 1, 3, 4 and 6, the controller123may identify parameter403, e.g. a threshold vector including one or more indicators606(e.g. voltage settings or read voltage threshold offsets) to modify a read voltage threshold302,304,306of cells116in the memory location605of a die601. The threshold vector may be stored in a threshold history buffer602that is associated with die601or with a page603of the memory location605in die601corresponding to the read command. Thus, the parameter403may indicate the die601or page603(e.g. based on the threshold history buffer association).

As represented by block806, the controller executes a first set features command for modifying the first read threshold based on the first parameter. For example, referring toFIGS. 1 and 4, the controller123may execute set features command402for modifying the read threshold voltage(s)302,304,306based on parameter403.

As represented by block808, the controller may store the first parameter in a cache of the memory. For example, referring toFIGS. 1, 4, and 6, the controller123may store the parameter403in the threshold history buffer602as the last threshold vector for the page603or die601. The threshold history buffer602may be stored in the volatile memory118(e.g. in cache122).

As represented by block810, the controller receives a second read command from the host device for data stored in the second memory location of the memory. For example, referring toFIGS. 1 and 6, the controller123may receive a second read command from the host device104for data119stored in a memory location112(e.g. memory location607) of the NVM110.

As represented by block812, the controller identifies a second parameter to modify a second read threshold associated with the second memory location. The second parameter may comprise a second voltage setting. The second parameter may also indicate the die having the second memory location. Moreover, the second parameter may indicate a second page of the second memory location. For example, referring toFIGS. 1, 3, 4 and 6, the controller123may identify parameter407, e.g. a target threshold vector608including one or more indicators606(e.g. voltage settings or read voltage threshold offsets) to modify a read voltage threshold302,304,306of cells116in the memory location607of die601. The target threshold vector608may subsequently overwrite the data in the threshold history buffer602associated with die601or with a page603of the memory location607in die601corresponding to the read command. Thus, the parameter407may indicate the die601or page603(e.g. based on the threshold history buffer association).

As represented by block814, the controller determines when the second parameter is the same as the first parameter using a comparator. For example, the comparator may comprise one or more exclusive-or (XOR) gates or exclusive-nor (XNOR) gates. For instance, referring toFIGS. 1, 4, and 6, the controller123may determine whether parameter403(the last threshold vector in threshold history buffer602) is the same as parameter407(the target threshold vector608) using the comparator604. The comparator604may include XOR gates or XNOR gates, for example.

The comparator604may provide a means for comparing the last threshold vector in threshold history buffer602(a first parameter) with the target threshold vector608(a second parameter). In one example, the comparator604may be implemented using the one or more processors of controller123. For instance, the comparator604may be implemented in firmware/software (e.g. as an XOR or XNOR operand). In another example, the comparator604may be implemented in hardware as illustrated inFIG. 6. For instance, the comparator604may include XOR gates or XNOR gates that are wired to the threshold history buffer602. The length of comparator604may correspond to the length of the threshold history buffer602. For example, if threshold history buffer602spans 32 bits in length, comparator604may include 32 XOR or XNOR gates which respectively receive individual bits from the threshold history buffer. Additionally, whileFIG. 6illustrates one comparator604and threshold history buffer602, multiple comparators and threshold history buffers may be present. For instance, where multiple threshold history buffers are respectively associated with different dies (or pages) as described above, multiple comparators604may be included in hardware which are individually wired to respective threshold history buffers.

Finally, as represented by block816, the controller may refrain from executing a second set features command for modifying the second read threshold when the second parameter is the same as the first parameter. For example, referring toFIGS. 1, 4, 6, and 7, the controller123may refrain from executing set features command406for modifying read voltage thresholds302,304,306when the parameters403,407are the same as determined by comparator604. Thus, as illustrated inFIG. 7, the controller123may send dynamic read command706without an immediately preceding set features command. Alternatively, if the second parameter is not the same as the first parameter, the controller123may execute the set features command406. The threshold history buffer602may correspondingly be updated with the last threshold vector (parameter407).

Accordingly, the present disclosure reduces the read latency caused by multiple set features commands with the same voltage threshold offsets for the same die. Dynamic reads performed on the same die may be minimized to a single set feature command, thereby reducing inefficient bus utilization caused by multiple set features commands with identical read voltage threshold offsets. Moreover, random read performance may be improved by saving significant time (e.g. 700 ns) for preparing subsequent dynamic read operations, thereby allowing more read operations to be performed in the saved time.