Data storage device and method for increasing random input-output-per-second (IOPS) operations

Abstract

Data storage devices with an open protocol may be limited in terms of input / output operations per second (IOPS) due to the time taken to stop the transmission cleanup activity. A data storage device is disclosed that may increase IOPS by using command length estimation logic that stores / memorizes a command length of a previous write / read command and limits a next open read / write command to a predicted / memorized length. This increases IOPS by eliminating the need to perform a stop transmission cleaning activity.

Description

BACKGROUND

[0001] In some data storage devices, such as Secure Digital (SD) and microSD memory cards, an "application performance class" indicates a minimum random read and write performance of the data storage device. A data storage device with an "A1" rating has a minimum random read speed of 1500 input / output operations per second (IOPS) and a write speed of 500 IOPS. BRIEF DESCRIPTION OF DRAWINGS

[0002] Figure 1A is a block diagram of a data storage device of an embodiment.

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

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

[0005] Figure 2A is a block diagram illustrating a data storage device according to an embodiment. Figure 1A is a block diagram of components of a controller of a data storage device shown.

[0006] Figure 2B is a block diagram illustrating a data storage device according to an embodiment. Figure 1A is a block diagram of components of a data storage device shown.

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

[0008] Figure 4 is a table illustrating an improvement of an embodiment for random read commands.

[0009] Figure 5 is a table illustrating an improvement of an embodiment for random write commands.

[0010] Figure 6 is a flowchart of a method of an embodiment for increasing random input / output operations per second (IOPS). DETAILED DESCRIPTION

[0011] The following embodiments generally relate to data storage devices and methods for increasing random input / output operations per second (IOPS). In one embodiment, a data storage device including a memory and one or more processors is provided. The one or more processors, individually or in combination, are configured to: store a length of a previously received read or write command; receive an open-ended read or write command from a host; and limit the open-ended read or write command to the length of the previously received read or write command, wherein limiting the open-ended read or write command to the length of the previously received read or write command increases input / output operations per second (IOPS) by eliminating a need to perform a stop transmission cleanup activity.

[0012] In another embodiment, a method performed in a data storage device including a memory and a controller is provided. The method includes: determining whether a length of an open-ended read / write command is predicted; in response to determining that the length of the open-ended read / write command is predicted: sending a portion of the read / write command having a predicted length to low level firmware in the controller; determining whether a stop transmission (ST) command is received; and in response to determining that the stop transmission (ST) command is received: calculating an actual length of the read / write command; and updating a prediction data structure for an upcoming command.

[0013] In another embodiment, a data storage device is provided that includes: a memory; and means for limiting an open-ended read / write command to a length of a previously received read / write command to increase input / output operations per second (IOPS) by eliminating a need to perform a stop transmission cleanup activity.

[0014] Other embodiments are possible, and each of the embodiments can be used alone or in combination. Accordingly, various embodiments will now be described with reference to the drawings.

[0015] Embodiments

[0016] The following embodiments relate to a data storage device (DSD). As used herein, “data storage device” refers to a non-volatile device that stores data. Examples of CSDs include, but are not limited to, a hard disk drive (HDD), a solid state drive (SSD), a tape drive, a hybrid drive, etc. Details of an example DSD are provided below.

[0017] In Figures 1A to 1C An example of a data storage device suitable for implementing aspects of these embodiments is shown in FIG. 1. It should be noted that these are merely examples, and other implementations can be used. Figure 1A is a block diagram illustrating a data storage device 100 according to one embodiment. Reference is made to FIG. 1.Figure 1A The data storage device 100 includes, in this example, a controller 102 coupled with non-volatile memory that can be composed of one or more non-volatile memory dies 104. As described herein, the term die refers to a collection of non-volatile memory cells formed on a single semiconductor substrate, as well as associated circuitry for managing the physical operations of those non-volatile memory cells. The controller 102 interacts with a host system and transmits command sequences for read, program, and erase operations to the non-volatile memory dies 104. Further, as used herein, the phrase “in communication with” or “coupled with” can mean either a direct communication / coupling with or an indirect communication / coupling with via one or more components, which can or can not be illustrated or described herein. The communication / coupling can be wired or wireless.

[0018] The controller 102, which can 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), can include one or more components configured individually or in combination to perform certain functions, including but not limited to the functions described herein and illustrated in the flowcharts. For example, as shown in FIG. 1, the controller 102 can include one or more processors 138 configured individually or in combination to perform functions, such as but not limited to the functions described herein and illustrated in the flowcharts, by executing computer-readable program code stored in one or more non-transitory memories 139 within and / or outside of the controller 102 (e.g., in random access memory (RAM) 116 or read-only memory (ROM) 118). As another example, the one or more components can include circuitry, such as but not limited to logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Figure 2A The controller 102, which can 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), can include one or more components configured individually or in combination to perform certain functions, including but not limited to the functions described herein and illustrated in the flowcharts. For example, as shown in FIG. 1, the controller 102 can include one or more processors 138 configured individually or in combination to perform functions, such as but not limited to the functions described herein and illustrated in the flowcharts, by executing computer-readable program code stored in one or more non-transitory memories 139 within and / or outside of the controller 102 (e.g., in random access memory (RAM) 116 or read-only memory (ROM) 118). As another example, the one or more components can include circuitry, such as but not limited to logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers.

[0019] In one example embodiment, the non-volatile memory controller 102 is a device that manages data stored on non-volatile memory and communicates with a host, such as a computer or electronic device, having any suitable operating system. In addition to the specific functionality described herein, the non-volatile memory controller 102 can have various functionality. For example, the non-volatile memory controller can format the non-volatile memory to ensure that the memory is operating correctly, flag bad non-volatile memory cells, and allocate spare cells to replace future failed cells. Some portion of the spare cells can be used to house firmware (and / or other metadata used for housekeeping and tracking) to operate the non-volatile memory controller and implement other features. In operation, when a host needs to read data from or write data to the non-volatile memory, it can communicate with the non-volatile memory controller. If the host provides a logical address at which to read / write data, the non-volatile memory controller can convert the logical address received from the host to a physical address in the non-volatile memory. The non-volatile memory controller can also perform various memory management functions, such as, but not limited to, wear leveling (allocating writes to avoid wearing out particular blocks of memory that would otherwise be repeatedly written to) and garbage collection (after a block is full, only valid pages of data are moved to a new block so the full block can be erased and reused).

[0020] The non-volatile memory die 104 can include any suitable non-volatile storage medium, including resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), phase change memory (PCM), NAND flash memory cells, and / or NOR flash memory cells. The memory cells can be in the form of solid state (e.g., flash) memory cells and can be single programmable, multi-programmable, or multi-time programmable. The memory cells can also be single level cells (SLC), multi-level cells (MLC) (e.g., dual level cells, triple level cells (TLC), quad level cells (QLC)), or use other memory cell level technology now known or later developed. Additionally, the memory cells can be fabricated in two-dimensional or three-dimensional fashion.

[0021] The interface between the controller 102 and the non-volatile memory die 104 can be any suitable flash interface, such as Toggle Mode 200, 400, or 800. In one embodiment, the data storage device 100 can be a card-based system, such as a secure digital (SD) card or a micro secure digital (microSD) card. In alternative embodiments, the data storage device 100 can be part of an embedded data storage device.

[0022] While in Figure 1AIn the illustrated example, the data storage device 100 (sometimes referred to herein as a storage module) includes a single channel between the controller 102 and the non-volatile memory die 104, although the subject matter described herein is not limited to having a single memory channel. For example, in some storage system architectures (such as the architecture shown in Figure 1B and Figure 1C there can be 2, 4, 8, or more memory channels between the controller and the memory device depending on the capabilities of the controller. In any of the embodiments described herein, there can be more than one single channel between the controller and the memory die, even if a single channel is shown in the figures.

[0023] Figure 1B A storage module 200 is illustrated that includes multiple non-volatile data storage devices 100. As such, the storage module 200 can include a storage controller 202 that interacts with a host and with data storage devices 204 that include multiple data storage devices 100. The interface between the storage controller 202 and the data storage devices 100 can be a bus interface such as a Serial Advanced Technology Attachment (SATA), Peripheral Component Interconnect Express (PCIe) interface, Double Data Rate (DDR) interface, or Serial Attached Small Computer Interface (SAS / SCSI). In one embodiment, the storage module 200 can 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 such as a laptop computer and a tablet.

[0024] Figure 1C is a block diagram illustrating a hierarchical storage system. The hierarchical storage system 250 includes multiple storage controllers 202, each of which controls a respective data storage device 204. A host system 252 can access the memory within the storage system 250 via a bus interface. In one embodiment, the bus interface can be a Non-Volatile Memory Express (NVMe) or an Ethernet Fibre Channel (FCoE) interface. In one embodiment, Figure 1C The illustrated system can be a rack-mountable mass storage system that is accessible by multiple host computers, such as can be found in a data center or in other locations where mass storage is needed.

[0025] Referring again to Figure 2AThe controller 102 also includes, in this example, a front-end module 108 that interfaces with the host, a back-end module 110 that interfaces with the one or more non-volatile memory dies 104, and various other components or modules such as, but not limited to, a buffer manager / bus controller module that manages buffers in a RAM 116 and controls internal bus arbitration of the controller 102. As described above, the modules can include one or more processors or components. A ROM 118 can store system boot code. While Figure 2A The RAM 116 and ROM 118 are shown positioned apart from the controller 102, but in other embodiments, one or both of the RAM 116 and ROM 118 can be located within the controller 102. In still other embodiments, portions of the RAM 116 and ROM 118 can be located within and outside of the controller 102.

[0026] The front-end module 108 includes a host interface 120 and a physical layer interface (PHY) 122 that provide an electrical interface to the host or to a next level storage controller. The type of host interface 120 can be selected depending on the type of memory used. Examples of host interfaces 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.

[0027] 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 command sequences, such as program command sequences and erase command sequences, for transmission to the non-volatile memory dies 104. A RAID (Redundant Array of Independent Drives) module 128 manages the generation of RAID parity and the recovery of failed data. The RAID parity can be used as an additional level of integrity protection for data written into the memory devices 104. In some cases, the RAID module 128 can be part of the ECC engine 124. A memory interface 130 provides command sequences to the non-volatile memory dies 104 and receives status information from the non-volatile memory dies 104. In one embodiment, the memory interface 130 can be a double data rate (DDR) interface, such as a Toggle Mode 200, 400, or 800 interface. The controller 102 also includes, in this example, a media management layer 137 and a flash control layer 132 that controls the overall operation of the back-end module 110.

[0028] The data storage device 100 also includes other discrete components 140, such as external electrical interfaces, external RAM, resistors, capacitors, or other components that can interact 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 are optional components that are not necessary in the controller 102.

[0029] Figure 2B is a block diagram illustrating components of the non-volatile memory die 104 in more detail. The non-volatile memory die 104 includes a peripheral circuit 141 and a non-volatile memory array 142. The non-volatile memory array 142 includes non-volatile memory cells for storing data. The non-volatile memory cells can be any suitable non-volatile memory cells, including ReRAM, MRAM, PCM, NAND flash memory cells, and / or NOR flash memory cells in two-dimensional and / or three-dimensional configurations. The non-volatile memory die 104 also includes a data cache 156 that caches data and address decoders 148, 150. The peripheral circuit 141 includes a state machine 152 in this example that provides state information to the controller 102. The peripheral circuit 141 can also include one or more components that are individually or collectively configured to perform certain functions, including but not limited to the functions described herein and illustrated in the flowcharts. For example, as shown in Figure 2B one or more processors 168 that are individually or collectively configured to execute computer-readable program code stored in one or more non-transitory memories 169, stored in the memory array 142, or stored external to the memory die 104. As another example, the one or more components can include circuitry, such as but not limited to logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers.

[0030] In addition to or instead of the one or more processors 138 (or more generally, components) in the controller 102 and the one or more processors 168 (or more generally, components) in the memory die 104, the data storage device 100 can include another set of one or more processors (or more generally, components). In general, regardless of where they are located and how many there are, the one or more processors (or more generally, components) in the data storage device 100 can be individually or in combination configured to perform various functions, including but not limited to the functions described herein and illustrated in the flowcharts. For example, the one or more processors (or components) can be in the controller 102, the memory device 104, and / or other locations in the data storage device 100. Moreover, different processors (or components) or combinations of processors (or components) can be utilized to perform different functions. Furthermore, the means for performing a function can be implemented with a controller that includes one or more components (e.g., processors or other components described above).

[0031] Returning again to the figures, Figure 2A The flash control layer 132 (which will be referred to herein as the flash translation layer (FTL)) handles flash errors and interfaces with the host. In particular, the FTL (which can be an algorithm in firmware) is responsible for the internal management of memory and translating writes from the host to writes to the memory 104. The FTL can be needed because the memory 104 can have limited durability, can only be written to a number of pages, and / or can not be written to (unless it is erased as a block). The FTL understands these potential limitations of the memory 104, which can not be visible to the host. Thus, the FTL attempts to translate writes from the host to writes in the memory 104.

[0032] The FTL can 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 to physical addresses in the memory 104. The FTL can include other features, such as but not limited to power fail recovery (so that the data structures of the FTL can be recovered in the event of a sudden loss of power) and wear leveling (so that wear is evenly distributed across memory blocks to prevent certain blocks from wearing out too much, which would lead to a greater chance of failure).

[0033] Returning again to the figures, Figure 3is a block diagram of a host 300 and data storage device 100 of an embodiment. The host 300 can take any suitable form, including but not limited to a computer, a mobile phone, a tablet, a wearable device, a digital video recorder, a monitoring system, etc. In this embodiment, the host 300 (here, a computing device) includes one or more processors 330 and one or more memories 340. In one embodiment, computer-readable program code stored in the one or more memories 340 configures the one or more processors 330 to perform the actions described herein as being performed by the host 300. Thus, the actions performed by the host 300 are sometimes referred to herein as being performed by an application (computer-readable program code) running on the host 300. For example, the host 300 can be configured to send data (e.g., initially stored in the host's memory 340) to the data storage device 100 for storage in the data storage device's memory 104.

[0034] As noted above, in some data storage devices such as Secure Digital (SD) and microSD memory cards, the "Application Performance Class" indicates the minimum random read / write performance of the data storage device. A data storage device with an "A1" rating has a minimum random read speed of 1500 Input / Output Operations Per Second (IOPS) and a write speed of 500 IOPS. Further, in data storage devices with an open protocol (e.g., SD memory cards), the controller of the data storage device can pre-provision additional Low Density Parity Check (LDPC) codes and Flash Interface Module (FIM) descriptors. Once the host sends a Stop Transmission (ST) signal, the controller of the data storage device can perform clean-up activities to prepare the LDPC engine / FIM / memory for the next command. In one example, this clean-up can add about 100 microseconds of overhead on each open read / write command, which in turn affects the A1 random read / write performance.

[0035] To address this issue, in the following embodiments, the controller 102 (e.g., one or more processors) of the data storage device 100 is configured with command length estimation logic that stores / remembers the command length of previous write / read commands and limits the next open read / write command to the predicted / remembered length. In this way, the controller 102 does not have to deal with the clean-up activities related to stop transmission (e.g., FIM, LDPC, NAND reset), which in turn increases the A1 random IOPS. Figure 4 and Figure 5 are tables that illustrate examples of this improvement for random read and write commands, respectively. As illustrated in these tables, using the command length estimation logic can provide a significant improvement in A1 read / write IOPS. It should be noted that the data storage device 100 can be used in any suitable application (e.g., a camera, an Internet of Things (IoT) device, etc.).

[0036] Any suitable method can be used to calculate the host read length. One example algorithm is described below. It is important to note that this is merely one example, and other implementations can be used. The example will be illustrated in connection with an open read command (e.g., 0x100 start, length - open -). In this example, the controller 102 does not know the incoming read length, and the controller 102 prepares additional read descriptors until it receives a stop transfer (ST) signal from the host 300. Thus, to start, the host 300 sends an open read command (0x100, - length not given -). The controller 102 prepares FIM and LDPC descriptors for a length of 0x400 sectors, with all of these sectors being written sequentially. Then, the host 300 sends a stop transfer (ST) signal after reading 0x80 sectors. By the time the stop transfer (ST) signal is received by the controller 102, the controller 102 has decoded 0x100 sectors and stored them in volatile memory in the data storage device 100 (e.g., in a buffer RAM (BRAM)) for the host 300 to read. The host 300 reads out 0x80 sectors from the BRAM, and 0x80 sectors remain in the BRAM. Thus, the total read length equals the total decoded host sectors (0x100) - the sectors in the BRAM that are pending to be read.

[0037] Regarding the calculation of the total decoded host sectors, the controller 102 prepares FIM and LDPC descriptors for 0x400 sectors, but needs to know how many are decoded. To do this, the controller 102 can parse the LDPC decode header buffer and obtain the last decoded segment (e.g., four kilobytes of data), and use this information to find how many segments are decoded, which can be used to find the total length read by the host 300.

[0038] Regarding the host read length estimation, the controller 102 can track the incoming read command lengths. If the last X (e.g., three) command lengths are the same, then on the X+1 (e.g., fourth) command, the controller 102 can enable the estimation logic and treat the open command as a closed command with the predicted / remembered length. In this way, the controller 102 does not need to prepare undesirable FIM / LDPC descriptors that will need to be cleaned up after a stop transfer (ST), which adds firmware overhead (e.g., about 100 microseconds in one example). As can be seen by this example, using the command length estimation logic can reduce the firmware overhead associated with the stop transfer cleanup activity. If the estimation fails, the controller 102 can continue reading with the estimation disabled.

[0039] Again, turning back to the figures, Figure 6is a flowchart 600 of a method for an implementation to improve random input / output operations per second (IOPS). As shown, a controller 102 in a data storage device 100 determines whether the length of an open read / write command is predicted (act 610). If the length is not predicted, a flash translation layer (FTL) / flash control layer 132 in the controller 102 sends the read / write command block to the low level firmware (LL FW) in the controller 102 as an open command (act 520). The controller 102 then determines whether a stop transfer (ST) command is received (act 520). If the stop transfer command is received, logic in the controller 102 calculates the actual length of the received command and updates a prediction data structure (e.g., a database) for upcoming commands (act 660). However, if the stop transfer command is not received, the method loops back to act 620. Figure 6 As shown, a controller 102 in a data storage device 100 determines whether the length of an open read / write command is predicted (act 610). If the length is not predicted, a flash translation layer (FTL) / flash control layer 132 in the controller 102 sends the read / write command block to the low level firmware (LL FW) in the controller 102 as an open command (act 520). The controller 102 then determines whether a stop transfer (ST) command is received (act 520). If the stop transfer command is received, logic in the controller 102 calculates the actual length of the received command and updates a prediction data structure (e.g., a database) for upcoming commands (act 660). However, if the stop transfer command is not received, the method loops back to act 620.

[0040] Referring again to act 610, if the length is predicted, the flash translation layer (FTL) / flash control layer 132 in the controller 102 sends the read / write command block to the low level firmware (LL FW) with the predicted length (act 640). The controller 102 then determines whether a stop transfer (ST) command is received (act 520). If the stop transfer command is received, the method proceeds to act 660, as described above. However, if the stop transfer command is not received, the controller 102 determines whether the predicted length is crossed (act 670). If the predicted length is crossed, the method proceeds to act 620; otherwise, the method proceeds to act 640, both of which are described above.

[0041] With respect to host write length estimation logic, for open write commands, the controller 102 can already have logic to detect a stop transfer (ST) signal and write all received data to the memory 104, in which case the length calculation should not be an issue. The controller 102 can only enable the command length estimation logic (similar to that described above with respect to the read path) to reduce firmware overhead after stop transfer. Once the command length estimation logic is enabled, the FIM / LDPC will not prepare additional descriptors, as the firmware does not need post-stop transfer FIM / LDPC / NAND cleanup.

[0042] These embodiments have several advantages. For example, these embodiments can be used to increase Al random 4K IOPS. In one example, read performance is improved by 80-90% and write performance is improved by 10%. Also, these embodiments can boost Al performance without any additional hardware cost to identify accurate read length for length estimation to get better user experience. In one example, these embodiments can provide an improvement from 1600-1700 4k read IOPS to 2900-3000 4k read IOPS.

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

[0044] The memory devices can be formed from 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 resistive-switching fuses, phase change materials, and the like, and optionally include steering elements such as diodes and the like. Further by way of non-limiting example, active semiconductor memory elements include EEPROM and flash memory device elements, which in some embodiments include elements having charge storage regions such as floating gates, conductive nano-particles, or charge storage dielectric material.

[0045] The plurality of memory elements can be configured such that they are connected in series or such that each element can be individually accessed. By way of non-limiting example, flash memory devices in a NAND configuration (NAND memory) typically contain memory elements connected in series. A NAND memory array can be configured such that the array is made up of a plurality of strings of memory, where a string is made up of a plurality of memory elements that share a single bit line and are accessed as a group. Alternatively, the memory elements can be configured such that each element can be individually accessed, such as a NOR memory array. NAND and NOR memory configurations are examples, and the memory elements can be configured in other ways.

[0046] Semiconductor memory elements located within and / or above a substrate can be arranged in two or three dimensions, such as two-dimensional memory structures or three-dimensional memory structures.

[0047] In two-dimensional memory structures, semiconductor memory elements are arranged in a single plane or a single memory device level. Typically, in two-dimensional memory structures, memory elements are arranged in a plane (e.g., in an x-z direction plane) that extends substantially parallel to a major surface of a substrate that supports the memory elements. The substrate can be a wafer over or in which layers of memory elements are formed, or it can be a carrier substrate that is attached to the memory elements after they are formed. As non-limiting examples, the substrate can comprise a semiconductor, such as silicon.

[0048] Memory elements can be arranged in a single memory device level in an ordered array, such as in multiple rows and / or columns. However, memory elements can be arranged in irregular or non-orthogonal configurations. Memory elements can each have two or more electrodes or contact lines, such as bit lines and word lines.

[0049] Three-dimensional memory arrays are arranged so that memory elements occupy multiple planes or multiple memory device levels, forming a structure in three dimensions (i.e., in an x direction, a y direction, and a z direction, where the y direction is substantially perpendicular to a major surface of the substrate, and the x direction and z direction are substantially parallel to the major surface of the substrate).

[0050] As a non-limiting example, three-dimensional memory structures can be arranged vertically as a stack of multiple two-dimensional memory device levels. As another non-limiting example, three-dimensional memory arrays can be arranged as multiple vertical columns (e.g., columns that extend substantially perpendicular to a major surface of the substrate, i.e., in the y direction), with multiple memory elements in each column in each level. The columns can be arranged in a two-dimensional configuration, e.g., in an x-z plane, resulting in a three-dimensional arrangement of memory elements, with elements on multiple vertically stacked memory planes. Other configurations of three-dimensional memory elements can also constitute a three-dimensional memory array.

[0051] As a non-limiting example, in a three-dimensional NAND memory array, memory elements can be coupled together to form NAND strings within a single horizontal (e.g., x-z) memory device level. Alternatively, memory elements can be coupled together to form vertical NAND strings that traverse multiple horizontal memory device levels. Other three-dimensional configurations are contemplated, in which some NAND strings contain memory elements in a single memory level, while other strings contain memory elements across multiple memory levels. Three-dimensional memory arrays can also be designed in NOR configurations, as well as ReRAM configurations.

[0052] Typically, in a monolithic three-dimensional memory array, one or more memory device levels are formed over a single substrate. Optionally, a monolithic three-dimensional memory array can also have one or more memory levels at least partially within the single substrate. As a non-limiting example, the substrate can comprise a semiconductor, such as silicon. In a monolithic three-dimensional 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 three-dimensional memory array can be shared or have intervening layers between the memory device levels.

[0053] A two-dimensional array can then be formed individually and then packaged together to form a non-monolithic memory device having multiple memory levels. For example, a non-monolithic stacked memory can be constructed by forming memory levels on separate substrates and then stacking the memory levels on top of one another. The substrates can be thinned or removed from the memory device levels prior to stacking, but because the memory device levels are initially formed over separate substrates, the resulting memory array is not a monolithic three-dimensional memory array. Further, multiple two-dimensional memory arrays or three-dimensional memory arrays (monolithic or non-monolithic) can be formed on separate chips and then packaged together to form a stacked chip memory device.

[0054] Associated circuitry is typically needed to operate and communicate with the memory elements. As a non-limiting example, a memory device can have circuitry for controlling and driving the memory elements to implement functions such as programming and reading. This associated circuitry can be on the same substrate as the memory elements and / or on a separate substrate. For example, a controller for memory read-write operations can be positioned on a separate controller chip and / or on the same substrate as the memory elements.

[0055] Those skilled in the art will recognize that the application is not limited to the two-dimensional and three-dimensional structures described, but encompasses all related memory structures within the spirit and scope of the application as described herein and as understood by those skilled in the art.

[0056] It is expected that the foregoing detailed description of the application is illustrative only and not limiting of the application as claimed. It is expected that only the claims (including all equivalents) define the scope of the application. Finally, it should be noted that any of the embodiments described herein can be used individually or in combination with one another.

Claims

1. A data storage device, the data storage device comprising: a memory; and one or more processors, individually or in combination, configured to: store a length of a previously received read or write command; receive an open-ended read or write command from a host; and limit the open-ended read or write command to the length of the previously received read or write command, wherein limiting the open-ended read or write command to the length of the previously received read or write command increases input / output operations per second (IOPS) by eliminating a need to perform a stop transfer cleanup activity.

2. The data storage device of claim 1, wherein: the previously received read or write command comprises a previously received read command; and the one or more processors, individually or in combination, are further configured to calculate the length of the previously received read command by: parsing a low density parity check (LDPC) decode header buffer to obtain a last decoded segment; and identifying a number of decoded segments.

3. The data storage device of claim 1, wherein the one or more processors, individually or in combination, are further configured to estimate a length of the open-ended read or write command by: determining whether a threshold number of previously received read or write commands have a same length; and in response to determining that the threshold number of previously received read or write commands have the same length, treating the open-ended read or write command as a closed-ended read or write command having the same length.

4. The data storage device of claim 1, wherein: the previously received read or write command comprises a previously received write command; and the one or more processors, individually or in combination, are further configured to: receive a stop transfer (ST) signal from the host; and estimate a length of the previously received write command.

5. The data storage device of claim 1, wherein the stop transfer cleanup activity comprises removing extraneous low density parity check (LDPC) code descriptors.

6. The data storage device of claim 1, wherein the stop transfer cleanup activity comprises removing extraneous flash interface module (FIM) descriptors.

7. The data storage device of claim 1, wherein the stop transfer cleanup activity comprises a memory cleanup operation.

8. The data storage device of claim 1, wherein the data storage device comprises a secure digital (SD) memory card.

9. The data storage device of claim 1, wherein the data storage device comprises a microSD memory card.

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

11. A method in a data storage device comprising a memory and a controller, the method comprising: determining whether a length of an open-ended read / write command is predicted; in response to determining that the length of the open-ended read / write command is predicted: sending a portion of the read / write command having the predicted length to a low level firmware in the controller; determining whether a stop transfer (ST) command is received; and in response to determining that the stop transfer (ST) command is received: calculating an actual length of the read / write command; and updating a prediction data structure for upcoming commands.

12. The method of claim 11, further comprising: in response to determining that the stop transfer (ST) command is not received: determining whether a predicted length is crossed; and in response to determining that the predicted length is crossed, sending a portion of the read / write command block as an open command to the low level firmware in the controller; and determining whether a stop transfer (ST) command is received.

13. The method of claim 11, further comprising: in response to determining that the predicted length is not crossed: sending a portion of the read / write command block with the predicted length to the low level firmware in the controller; and determining whether a stop transfer (ST) command is received.

14. The method of claim 11, further comprising: in response to determining that the length of the open read / write command is not predicted: sending a portion of the read / write command block as an open command to the low level firmware in the controller; determining whether a stop transfer (ST) command is received; and in response to determining that the stop transfer (ST) command is received: calculating an actual length of the read / write command; and updating a prediction data structure for upcoming commands.

15. The method of claim 14, further comprising: in response to determining that the stop transfer (ST) command is not received: sending another portion of the read / write command block as an open command to the low level firmware in the controller; and determining whether a stop transfer (ST) command is received.

16. The method of claim 11, further comprising: in response to determining that the length of the open read / write command is predicted, forgoing performing a stop transfer clean up activity, wherein forgoing performing the stop transfer clean up activity increases input / output operations per second (IOPS).

17. The method of claim 16, wherein the stop transfer clean up activity comprises removing extraneous low density parity check (LDPC) code descriptors.

18. The method of claim 16, wherein the stop transfer clean up activity comprises removing extraneous flash interface module (FIM) descriptors.

19. The method of claim 16, wherein the stop transfer clean up activity comprises a memory clean operation.

20. A data storage device, comprising: a memory; and means for limiting an open read / write command to a length of a previously received read / write command to increase input / output operations per second (IOPS) by eliminating a need to perform a stop transfer clean up activity.

Images