Ufs out-of-order hint generation
By introducing a controller to generate OOO hints in the UFS interface protocol and switching the working mode according to BER conditions, the increased complexity of ordered data transmission is solved, the throughput and system performance of the UFS interface are improved, and the reliability and efficiency of data storage devices are enhanced.
Patent Information
- Application Number
- CN202210575649.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2021-08-06
- Filing Date
- 2022-05-24
- Publication Date
- 2026-01-23
- Estimated Expiration
- 2042-05-24
AI Technical Summary
The existing UFS interface protocol adds extra complexity and size requirements to ordered data transmission, limiting throughput and system performance. Therefore, a method that supports out-of-order (OOO) data transmission is needed.
By introducing a controller into the data storage device, interacting with the host device using the UFS interface protocol, generating out-of-order (OOO) hints, and switching between the first mode and the second mode, the data transmission requirements under different bit error rate (BER) conditions are adapted to achieve data reordering and transmission.
It improves the throughput and system performance of the UFS interface, reduces the complexity and latency of data transmission, and enhances the reliability and efficiency of data storage devices.
Smart Images

Figure CN115904217B_ABST
Abstract
Description
BACKGROUND TECHNICAL FIELD
[0001] Embodiments of the present disclosure generally relate to out-of-order hint generation for Universal Flash Storage (UFS).
[0002] Description of the Related Art
[0003] UFS is an advanced high-performance interface designed for computing and mobile systems that need to minimize power consumption, such as smartphones and tablets. The latest UFS interface protocol is optimized for efficient throughput, system performance, and reliability. With UFS, power consumption is reduced due to near-zero idle power levels. When combined with Mobile Industry Processor Interface (MIPI) power saving specifications, power consumption of data storage devices is significantly reduced.
[0004] The UFS standard also adopts the well-known Small Computer System Interface (SCSI) architectural model. The command protocol, which supports multiple simultaneous commands and command queuing functionality, enables efficient multi-threaded programming. This is a significant difference compared to traditional flash-based memory cards and embedded flash solutions, which can only handle a single command, thereby limiting random read / write access performance.
[0005] The UFS protocol generally supports in-order data transfer per command. However, to perform in-order data transfer, in-order data transfer can add additional complexity and size requirements to the data storage device. To achieve greater throughput, system performance, and reliability of the UFS interface protocol, a different method of data transfer than in-order data transfer can be needed. For example, UFS out-of-order (OOO) data transfer support can allow for greater throughput, system performance, and reliability because the additional complexity and size requirements to support in-order data transfer can no longer be needed.
[0006] Accordingly, there is a need for a data storage device that supports OOO hint generation and data transfer. SUMMARY
[0007] The present disclosure generally relates to out-of-order (OOO) hint generation for Universal Flash Storage (UFS). A data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to interact with a host device using a Universal Flash Storage (UFS) interface protocol, provide a hint to the host device, switch between a first mode and a second mode, retrieve data from the memory device, and transfer the data to the host device. The hint includes an indication of what order data is to be received from the data storage device. After the hint is provided, the order of the data will be a different order than the requested order.
[0008] In one embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to interact with a host device using a UFS interface protocol and to operate in a first mode corresponding to a first bit error rate (BER) and a second mode corresponding to a second BER that is greater than the first BER. The controller is configured to operate in the first mode and to provide a hint to the host device. The hint includes an indication of what order of data is to be received from the data storage device. The order of the data is to be a different order than a requested order. After providing the hint, the controller is configured to retrieve data from the memory device. The controller detects a hint conflict caused by the BER, reorders the data to match the order provided in the hint, and transfers the data to the host device. The controller then determines that the BER is greater than a predetermined threshold and switches to operating in the second mode.
[0009] In another embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to interact with a host device using a UFS interface protocol and to operate in a first mode corresponding to a first bit error rate (BER) and a second mode corresponding to a second BER that is greater than the first BER. The controller is configured to operate in the second mode and to retrieve data from the memory device. After retrieving the data, the controller is configured to provide a hint to the host device. The hint includes an indication of what order of data is to be received from the data storage device. The order of the data is to be a different order than a requested order. The controller is configured to transfer the data to the host device. The controller is further configured to compare a BER of the transferred data to a threshold, determine that the BER is less than the threshold, and switch to operating in the first mode.
[0010] In another embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to interact with a host device using a UFS interface protocol. The controller is configured to provide a hint to the host device, switch between a first mode and a second mode, and transfer data to the host device. The hint includes an indication of what order of data is to be received from the data storage device. The order of the data is to be a different order than a requested order. The first mode includes providing the hint before retrieving data from the memory device. The second mode includes providing the hint after retrieving data from the memory device. BRIEF DESCRIPTION OF DRAWINGS
[0011] So that the manner in which the above recited features of the present disclosure can be understood in detail, a more particular description of the disclosure, briefly summarized above, can be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this disclosure and are therefore not to be considered limiting of its scope, for the disclosure can admit to other equally effective embodiments.
[0012] Figure 1 is a schematic block diagram illustrating a storage system having a data storage device that can be used as a data storage device of a host device, in accordance with certain embodiments.
[0013] Figure 2 is an illustration of UFS packets, in accordance with certain embodiments.
[0014] Figure 3 is a schematic diagram of an example of out-of-order (OOO) transmission using generated hints, in accordance with certain embodiments.
[0015] Figure 4 is a schematic diagram of OOO data transmission, in accordance with certain embodiments.
[0016] Figure 5 is a schematic diagram of a read data path of a controller, in accordance with certain embodiments.
[0017] Figure 6 is a flowchart illustrating a method of switching a controller between supported OOO hint generation modes, in accordance with certain embodiments.
[0018] Figure 7 is a flowchart illustrating a method of switching a controller between supported OOO hint generation modes with respect to quality of service (QoS), in accordance with certain embodiments.
[0019] To facilitate the understanding of this description, like reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment can be advantageously used in other embodiments without specific recitation. DETAILED DESCRIPTION
[0020] In the following, reference is made to embodiments of the present disclosure. However, it should be understood that the present disclosure is not limited to the particularly described embodiments. Rather, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the present disclosure. Additionally, although the embodiments of the present disclosure can achieve advantages over other possible solutions and / or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not a limitation of the present disclosure. Thus, the following aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims, unless specifically recited therein. Likewise, reference to "the present disclosure" shall not be construed as being a summary of any inventive subject matter disclosed herein and shall not be considered as an element or limitation of the appended claims, unless specifically recited in the claims.
[0021] The present disclosure generally relates to out-of-order (OOO) hint generation for universal flash storage (UFS). A data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to interact with a host device using a universal flash storage (UFS) interface protocol, provide a hint to the host device, switch between a first mode and a second mode, retrieve data from the memory device, and transfer the data to the host device. The hint includes an indication of what order data is to be received from the data storage device. After the hint is provided, the order of the data will be a different order than the requested order.
[0022] Figure 1 is a schematic block diagram of a storage system 100 in accordance with certain embodiments, in which a host device 104 communicates with a data storage device 106. For example, the host device 104 can utilize a non-volatile memory (NVM) 110 included in the data storage device 106 to store and retrieve data. The host device 104 includes a host DRAM 138. In some examples, the storage system 100 can include multiple storage devices, such as the data storage device 106, that can work as a storage array. For example, the storage system 100 can include multiple data storage devices 106 that are configured to collectively work as a redundant array of inexpensive / independent disks (RAID) for the host device 104.
[0023] The host device 104 can store data to and / or retrieve data from one or more storage devices, such as the data storage device 106. As Figure 1As shown, the host device 104 can communicate with the data storage device 106 via the interface 114. The host device 104 can comprise any of a variety of devices, including a computer server, a network-attached storage (NAS) unit, a desktop computer, a notebook (i.e., laptop) computer, a tablet computer, a set-top box, a telephone handset such as a so-called “smart” phone, a so-called “smart” tablet, a television, a camera, a display device, a digital media player, a video gaming console, a video streaming device, or other device capable of sending or receiving data from the data storage device.
[0024] The data storage device 106 includes a controller 108, NVM 110, a power source 111, volatile memory 112, an interface 114, and a write buffer 116. In some examples, for the sake of clarity, the data storage device 106 can include additional components not shown in FIG. 1. For example, the data storage device 106 can include a printed circuit board (PCB) to which the components of the data storage device 106 are mechanically attached, and which includes conductive traces to electrically interconnect the components of the data storage device 106, etc. In some examples, the physical size and connector configuration of the data storage device 106 can conform to one or more standard form factors. Some example standard form factors include, but are not limited to, 3.5” data storage devices (e.g., HDDs or SSDs), 2.5” data storage devices, 1.8” data storage devices, peripheral component interconnect (PCI), PCI extended (PCI-X), PCI Express (PCIe) (e.g., PCIe xl, x4, x8, x16, PCIe Mini card, MiniPCI, etc.). In some examples, the data storage device 106 can be directly coupled (e.g., directly soldered or plugged into a connector) to a motherboard of the host device 104. Figure 1
[0025] The interface 114 can include one or both of a data bus for exchanging data with the host device 104 and a control bus for exchanging commands with the host device 104. The interface 114 can operate according to any suitable protocol. For example, the interface 114 can operate according to one or more of the following protocols: Advanced Technology Attachment (ATA) (e.g., Serial ATA (SATA) and Parallel ATA (PATA)), Fibre Channel Protocol (FCP), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), PCI and PCIe, Non-Volatile Memory express (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Open Channel SSD (OCSSD), etc. The interface 114 (e.g., the data bus, the control bus, or both) is electrically connected to the controller 108, providing an electrical connection between the host device 104 and the controller 108, allowing data to be exchanged between the host device 104 and the controller 108. In some examples, the electrical connection of the interface 114 can also allow the data storage device 106 to receive power from the host device 104. For example, as shown in FIG. 1, the power supply 111 can receive power from the host device 104 via the interface 114. Figure 1
[0026] The NVM 110 can include a plurality of storage devices or storage units. The NVM 110 can be configured to store and / or retrieve data. For example, a storage unit of the NVM 110 can receive data and receive a message from the controller 108 instructing the storage unit to store the data. Similarly, the storage unit can receive a message from the controller 108 instructing the storage unit to retrieve data. In some examples, each of the storage units can be referred to as a die. In some examples, the NVM 110 can include a plurality of dies (e.g., a plurality of storage units). In some examples, each storage unit can be configured to store a relatively large amount of data (e.g., 128 MB, 256 MB, 512 MB, 1 GB, 2 GB, 4 GB, 8 GB, 16 GB, 32 GB, 64 GB, 128 GB, 256 GB, 512 GB, 1 TB, etc.).
[0027] In some examples, each storage unit can include any type of non-volatile memory device, such as a flash memory device, a phase change memory (PCM) device, a resistive random access memory (ReRAM) device, a magnetoresistive random access memory (MRAM) device, a ferroelectric random access memory (F-RAM), a holographic memory device, and any other type of non-volatile memory device.
[0028] The NVM 110 can include a plurality of flash memory devices or storage units. The NVM flash memory devices can include NAND or NOR based flash memory devices and can store data based on charge contained in a floating gate of a transistor for each flash memory unit. In NVM flash memory devices, a flash memory device can be divided into a plurality of dies, where each die of the plurality of dies includes a plurality of physical or logical blocks, which can be further divided into a plurality of pages. Each block of the plurality of blocks within a particular memory device can include a plurality of NVM cells. Rows of NVM cells can be electrically connected using word lines to define a page of the plurality of pages. Respective cells in each page of the plurality of pages can be electrically connected to a respective bit line. Further, the NVM flash memory devices can be 2D or 3D devices and can be single level cell (SLC), multi-level cell (MLC), triple level cell (TLC), or quad level cell (QLC). The controller 108 can write data to and read data from the NVM flash memory devices at a page level and erase data from the NVM flash memory devices at a block level.
[0029] The power supply 111 can provide power to one or more components of the data storage device 106. When operating in a standard mode, the power supply 111 can use power provided by an external device, such as the host device 104, to power the one or more components. For example, the power supply 111 can use power received from the host device 104 via the interface 114 to power the one or more components. In some examples, the power supply 111 can include one or more power storage components configured to power the one or more components when operating in an off mode, such as in the event that power is stopped being received from the external device. In this way, the power supply 111 can act as an on-board backup power supply. Some examples of the one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, and the like. In some examples, the amount of power that can be stored by the one or more power storage components can be a function of the cost and / or size (e.g., area / volume) of the one or more power storage components. In other words, as the amount of power stored by the one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.
[0030] The volatile memory 112 can be used by the controller 108 to store information. The volatile memory 112 can include one or more volatile memory devices. In some examples, the controller 108 can use the volatile memory 112 as a cache. For example, the controller 108 can store cached information in the volatile memory 112 until the cached information is written to the NVM 110. As Figure 1As shown, volatile memory 112 can consume power received from power supply 111. Examples of volatile memory 112 include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static RAM (SRAM), and synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, etc.).
[0031] Controller 108 can manage one or more operations of data storage device 106. For example, controller 108 can manage reading data from NVM 110 and / or writing data to the NVM. In some embodiments, when data storage device 106 receives a write command from host device 104, controller 108 can initiate a data storage command to store data to NVM 110 and monitor the progress of the data storage command. Controller 108 can determine at least one operational characteristic of storage system 100 and store the at least one operational characteristic to NVM 110. In some embodiments, when data storage device 106 receives a write command from host device 104, controller 108 temporarily stores data associated with the write command in an internal memory or write buffer 116 prior to sending the data to NVM 110.
[0032] Figure 2 is an illustration of a UFS packet 200 according to certain embodiments. UFS packet 200 includes a plurality of fields 220, which includes a hint field 230. Each of the plurality of fields 220 is associated with one or more bit values. Hint field 230 adds support for out-of-order (OOO) data transfer functionality. Hint field 230 includes HintControl 201 located in field 20, HintIID (hint independent and identically distributed random variable) 202 located in field 21, HintLUN (hint linear unit number) 203 located in field 22, HintTaskTag 204 located in field 23, Hint Data Buffer Offset 205 located in fields 24-27, and In Order Hint Count 206 located in fields 28-31.
[0033] HintControl 201 indicates the validity of hint field 230. When HintControl 201 is set to “0b”, hint field 230 is invalid and is expected to be ignored by a controller of a host device, such as Figure 1Host device 104. However, when HintControl 201 is set to "1b", the Hint field 230 is valid. When the Hint field 230 is invalid, disabled (e.g. bDataOrdering = 00h or bOutOfOrderDataEn = 00h) or when the Hint field 230 (e.g. HintTaskTag 204, etc.) does not reference a READ (6), READ (10), READ (16) or HPB Read command that requests to read a specific logical block and transfer data to a buffer, the HintControl 201 is set to 0x0 and no hint information is provided.
[0034] HintIID 202 can include a notation that indicates the location of the field. In addition, HintIID 202 indicates the IID of the data that will be transferred by the controller (such as Figure 1 controller 108) to the host device 104 in a UFS protocol information unit (UPIU). When HintControl 201 is set to "1b", the HintIID 202 field is valid. The HintIID 202 field can be different from the IID field.
[0035] HintLUN 203 is a field that indicates the LUN of the data in the UPIU that will be transferred by the controller (such as Figure 1 controller 108). When HintControl 201 is set to "1b", the HintLUN 203 field is valid. The HintLUN 203 field can be different from the LUN field.
[0036] HintTaskTag 204 is a field that indicates the task tag of the data in the UPIU. The HintTaskTag 204 field can be different from the TaskTag 250 field located in bit3. Hint Data Buffer Offset 205 is a field that indicates the data buffer offset in the data in the UPIU that will be transferred by the data storage device 106. When HintControl 201 is set to "1b", the HintTaskTag 204 field is valid.
[0037] In Order Hint Count 206 is a field that indicates the number of 4KBs that the host device 104 expects to be transferred in order to the initiator starting from the Hint Data Buffer Offset 205. The data storage device 106 can interleave the data in the UPIU related to all hints provided by the data storage device 106. When HintControl 201 is set to "1b", the In Order Hint Count 206 is valid.
[0038] Figure 3 is a schematic diagram of an example 300 of out-of-order (OOO) data transfer using generated hints according to certain embodiments. In this example, the transfer size of command hints 340 is 32 KB. For simplicity purposes, command hints 340 can be referred to as commands 340. A data storage device, such as data storage device 106 of Figure 1 provides hints to a host device, such as host device 104 of Figure 1 In this example, there are four hints (i.e., 310A, 310B, 310C, and 310D). Each hint (i.e., 310A, 310B, 310C, and 310D) defines an order of data within a data block. Commands 340 include the hints issued to host device 104.
[0039] Each of these issued hints includes two components. The two components include a hint offset 330A, 330B, 330C, 330D, such as Hint Data Buffer Offset 205 of Figure 2 and a hint count 311A, 311B, 311C, 311D, such as In Order Hint Count 206 of Figure 2 The hint count represents the size of the data transfer. For example, a hint count of 1 in units of size can be substantially equal to about 4 KB. In the presently depicted embodiment, first hint 310A includes a hint offset 330A of zero and a hint count 311A of 1 (4 KB). Second hint 310B includes a hint offset 330B of 4 and a hint count 311B of 1 (4 KB). Third hint 310C includes a hint offset 330C of 8 and a hint count 311C of 2 (8 KB). Fourth hint 310D includes a hint offset 330D of 16 and a hint count 311D of 8 (16 KB). Commands 340 are capable of providing the issued 310 hints to a controller, such as controller 108 of Figure 1
[0040] Data transfers 350 can include data transferred in any order based on the issued hints 310. One embodiment of data transfers 350 is shown. Each transfer data includes two components. The two components include an offset 331A, 331B, 331C, and 331D, and a count 321A, 321B, 321C, and 321D. In the embodiment shown, it can be seen that the first transfer data 320A includes a count 321A of 8KB and an offset 331A of zero. The first transfer data 320A combines the first two hints 310A and 310B from the command 340 together. The second transfer data 320B includes a count 321B of 16KB and an offset 331B of 16KB, which represents the fourth hint 310D of the command 340. The last transfer data 320C includes a count 321C and an offset 331C of 8KB, which represents the third hint 310C of the command 340. The order of the transfer data listed previously is not intended to be limiting, but rather to provide an example of a possible embodiment. Thus, the described embodiments are not intended to be limiting in any order.
[0041] Figure 4 is a schematic diagram 400 of OOO data transfers according to certain embodiments. A controller 404 receives a read command 402. The controller 404 can be Figure 1 controller 108. The controller 404 includes a buffer 406, which can be a volatile memory such as SRAM or DRAM. The buffer 406 can be used to store the read command as well as data read from a memory device such as Figure 1 NVM 110 or multiple dies 412A-412I in the current embodiment. The read command 402 can be a set of sequential read commands. For example, the read command 402 includes read commands in the order of A-G, which correspond to respective data A-G located on one or more of the multiple dies 412A-412I.
[0042] The controller 404 is coupled to the multiple dies 412A-412I. It should be understood that the arrangement and number of the multiple dies 412A-412I is not intended to be limiting, but rather to provide an example of a possible embodiment. Further, the multiple dies 412A-412I can be arranged into multiple parallel die groups 410A-410C. For example, a first parallel die group includes dies 412A-412C, a second parallel die group includes dies 412D-412F, and a third parallel die group 410C includes dies 412G-412I. Each of the multiple die groups 410A-410C can work in parallel with each other. For example, when a read command is received to read data from a first die 412A and a fourth die 412D, the data of the first die 412A and the fourth die 412D can be read in parallel. Likewise, when the controller 404 receives a read command from a host device (such as a host device 106) to read data from a first die 412A and a fourth die 412D, the data of the first die 412A and the fourth die 412D can be read in parallel. Figure 1The dies of the parallel die groups of the plurality of parallel die groups 410A-410C can be activated (i.e., read) to efficiently receive the read data when the sequential read commands are received by the host device 104.
[0043] Since each die in the plurality of die groups 412A-412I can have its own timing (i.e., its own efficiency due to die characteristics), the data can be transmitted or read back to the controller 404 out of order according to the read commands. The timing of each die can be based on the current process of the relevant die. For example, a die can be in an idle state. For example, to read data from a die in an idle state, the die needs to be moved (i.e., additional power is provided) to “wake up” the die to an active state. In another example, a die can be busy (i.e., currently performing) an erase operation, a write operation, or in an exception handling state. It should be understood that the previously listed examples are not intended to be limiting and other examples are contemplated.
[0044] For example, the dies 412A-412D, 412F, 412G, and 412I can be in an idle state, the fifth die 412E can be processing an erase operation, and the eighth die 412H can be in an exception handling state. When the controller 404 receives the read commands 402 in the order of A to G, the controller 404 resolves the read commands and schedules them to the relevant dies in the plurality of dies. Rather than waiting for an ordered data transmission, the controller 404 can utilize the OOO hint generator 408 to schedule the data transmission in a more efficient manner.
[0045] For example, the OOO hint generator 408 can utilize a logical to physical (L2P) table to convert a logical block address (LBA) associated with a relevant read command to a physical block address (PBA) to generate a hint, such as Figure 3 the issued hints 310 from the controller 404. The generated hints are provided to the host device 104 so that the host device 104 can process the hints before receiving the data from the controller 404. Thus, when the host device 104 receives the data (i.e., the returned data 414), the host device 104 knows of the out-of-order data transmission. For example, even though the data was requested in the order of A, B, C, D, E, F, and G, the returned data 414 is in the order of G, A, F, E, B, D, and C.
[0046] Figure 5 is a controller according to certain embodiments, such as from Figure 1FIG. 5 is a schematic diagram of a read data path 500 of the controller 108. The read data path 500 includes a low-density parity-check (LDPC) engine 530. In one embodiment, the LDPC engine 530 is located in the controller 108. In another embodiment, the LDPC engine 530 is coupled to the controller 108. The LDPC engine 530 is coupled to a host interface module (HIM) 502 and a plurality of flash interface modules (FIMs) 521A-521N.
[0047] The HIM 502 can be configured to transfer data to a host device, such as the host device 104, and receive write commands and write data from the host device 104. The plurality of FIMs 521A-521N are configured to interact with a memory device, such as the NVM 110 of the memory device 100. The plurality of FIMs 521A-521N can be arranged as parallel components of the controller 108, such that each FIM is coupled to a respective parallel group of dies, such as the plurality of die groups 410A-410C. Figure 1
[0048] The LDPC engine 530 includes a control path 522, a write direct memory access (DMA) 560, a decoder pool 570, a decoder pool scheduler 523, and a read DMA 550. The control path 522 can be responsible for generating and scheduling commands to receive data, decode data, and transfer data to the HIM 502. The decoder pool scheduler 523 can be configured to determine which layer decoder of the decoder pool 570 decodes raw data 540 retrieved by the read DMA 550.
[0049] The raw data 540 can include a bit error rate (BER). Depending on the rate of bit errors, the BER can be characterized as a low BER, a medium BER, or a high BER. The decoder pool 570 can include one or more decoders, each associated with a decoding layer. For example, the decoder pool 570 includes a layer 1 decoder 511, a layer 2 decoder 512, and a layer 3 decoder 513. The examples of different layers of decoders are not intended to be limiting, but rather to provide examples of possible embodiments. Further, the decoder pool 570 can include one or more decoders per layer. Additionally, the use of the term “layer” can be used as a placeholder for different decoders specialized for different cases. Further, more or less than the illustrated layers of decoders are contemplated.
[0050] Layer 1 decoder 511 can be used for low intensity decoding tasks, such as for low BER data. Layer 2 decoder 512 can be used for medium intensity decoding tasks, such as for medium low BER data. Layer 3 decoder 513 can be used for more intensive decoding tasks, such as for high BER data. In other embodiments, the selected decoder can be based on whether the received data exceeds a syndrome weight threshold of layer 1 decoder 511, layer 2 decoder 512, or layer 3 decoder 513. The decoder utilized can depend on the decoding operation as well as the current resources utilized, such as the current power consumption of other components of the data storage device. The various decoders can use a tradeoff between latency and power versus correction capability, such that the tradeoff is a gear shifting scheme. For example, layer 1 decoder 511 can be a bit flipping decoder, while layer 2 decoder 512 and layer 3 decoder 513 can be message passing decoders. In this context, layer 2 decoder 512 would be a faster message passing decoder, while layer 3 decoder 513 would be a stronger message passing decoder.
[0051] For example, when first requested data 510A has a low BER, first requested data 510A is provided to layer 1 decoder 511. Likewise, when second requested data 510B has a medium BER and third requested data 510C has a high BER, second requested data 510B is provided to layer 2 decoder 512 and third requested data 510C is provided to layer 3 decoder 513. Because the number of bit errors can be different for each data for each layer decoder, the decoding time can vary from data to data and decoder to decoder.
[0052] The processing time of LDPC engine 530 depends on the current BER. The higher the BER of the requested data, the higher the processing latency of LDPC engine 530. Due to the implementation of several parallel engines in LDPC engine 530, there is no guarantee that in-order data transfer is performed. Data can be decoded in-order or out-of-order as the raw data 540 is decoded in decoder pool 570. Write DMA 560 transfers the corrected / decoded data to HIM 502, where HIM 502 transfers the data to a host device, such as Figure 1 host device 104. The data transferred to host device 104 can be out-of-order (e.g., in the order of third requested data 510C, second requested data 510B, first requested data 510A) from the order of the read commands received (e.g., in the order of first requested data 510A, second requested data 510B, third requested data 510C).
[0053] Figure 6 is a diagram illustrating a switching controller between support modes of OOO hint generation, such as from Figure 1The flowchart of method 600 for controller 108. At block 602, NVM (such as Figure 1 The BER of an NVM 110 memory device can be relatively low at the beginning of its lifecycle (i.e., a new memory device). When the BER distribution of a memory device is low, OOO data transfers may be rare. More specifically, OOO data transfers due to BER distribution are rare, and this should not be confused with OOO data transfers due to die mapping, as OOO data transfers due to die mapping are not rare. This is because OOO data transfers occur in data storage devices (such as...) Figure 1 The data storage device 106 is relatively infrequent at the start of its lifecycle, so controller 108 begins operating in mode A at box 604. Mode A, which may be more accurately described as the mode when the storage device or NVM 110 has a low BER, is the mode in which controller 108 generates hints based on L2P die scheduling or die mapping due to a fixed order of dies or die quality (e.g., BER, usage, etc.). Controller 108 logic generates a data flow through the dies after determining the die mapping and before requests are queued. After interpreting the data flow, relevant hints are generated and provided to the host device, such as... Figure 4 The advantage of Mode A is that it provides prompts to the host device 104 early in the read command execution operation.
[0054] At box 606, controller 108 checks for cue collisions caused by data paths. For example, a cue collision might include determining that received data has a high BER (Bit Error Rate). In another example, a cue collision occurs when the order of the decoded data differs from the order of the cue data provided according to mode A. If no data path collision is detected at box 606, the retrieved data is transmitted to host device 104, and controller 108 continues operating in mode A. If a data path collision is detected at box 606, the retrieved data must be reordered before transmitting the data to host device 104 to avoid collisions with previously sent cue data at box 608. Detection of a collision might include determining that data was sent out of order from a previously sent cue to host device 104. During reordering, controller 108 stores the out-of-order data in a buffer, such as... Figure 7 The buffer 406. The controller 108 then waits for the next data corresponding to the issued prompt command to complete its decoding process. When the next data completes the decoding process and is transmitted to the host device, the relevant data in the buffer is then transmitted in the order of the previously sent prompts.
[0055] After the data is reordered and sent to the host device 104, the controller 108 checks the BER of the dies. If the BER of the dies (or each of the dies) does not equal or exceed a first threshold (e.g., Thresholdl), the controller 108 continues to work in Mode A. If at block 610, the BER equals or exceeds the first threshold, at block 612, the controller 108 begins to work in Mode B. In Mode B, the controller 108 generates hints based on the BER of the data in the data path. Mode B is based on the LDPC corrected data readiness. The hints can be generated after the error correction processing, i.e., when the data transfer order has been determined. Mode B is characterized by accurate hints. However, the hints are provided later and can provide less hint processing time for the host device 104. In Mode B, the hints are generated after the original data is decoded and the data order is known. At block 614, the controller determines whether the BER of the dies is below a second threshold (e.g., Threshold2). If at block 614, the BER is below the second threshold, the controller 108 returns to working in Mode A at block 604. However, if at block 614, the BER equals or is above the second threshold, the controller continues to work in Mode B at block 612.
[0056] Figure 1 is a flowchart illustrating a method 700 of switching a controller (such as the controller 108 of Figure 1 ) between support modes of OOO hint generation with respect to Quality of Service (QoS) in accordance with certain embodiments. At block 702, the controller 108 receives a BER threshold from a host device (such as the host device 104 of Figure 1 ). At block 704, the controller 108 receives a read command to fetch data from one or more dies. At block 706, the controller 108 determines whether QoS is to be considered or important. For example, if the read command has a high priority indicator, QoS will be considered or determined to be important.
[0057] If at block 706, QoS is not important, the controller 108 begins to work in Mode A at block 710. At block 712, the controller 108 determines the order of data expected from the relevant memory device (i.e., one or more dies) by utilizing L2P die scheduling and die mapping, which can be the NVM 110 of Figure 5 ). At block 714, one or more hints including the order of data are provided to the host device 104. Each hint includes a hint data buffer offset and a hint count, where the hint data buffer offset indicates where the data starts and the hint count indicates to the host device 104 the size of the data transfer.
[0058] At block 716, the controller 108 receives data from the one or more memory devices, which can be the raw data 540 of Figure 4 When the controller 108 receives data from the one or more memory devices, the order of the received data is evaluated. At block 718, the controller 108 determines whether the order of the received data matches the order of the data provided to the host device 104 through the hint. If the order of the received data does match the order of the data provided to the host device 104 at block 718, then the data is transferred to the host device 104 at block 720. However, if the order of the received data does not match the order of the data provided to the host device 104, then the data must be reordered at block 722 to match the hint. A buffer, such as the buffer 406 of Figure 5 The first data page can be released from the buffer after the different data page is decoded and provided to the host device 104 (if the next data page corresponds to the hint order), and the data can be provided to the host device 104 in an order that matches the order provided by the hint.
[0059] When the data is reordered to match the hint, the controller 108 determines whether a different mode of providing the hint to the host device 104 is more advantageous to use. At block 724, the controller 108 evaluates whether the BER exceeds the BER threshold received at block 702. The BER is evaluated in order to maintain optimal system performance. For example, when the BER reaches the threshold BER, the processing time for data transfer can not be optimal in Mode A. Thus, the controller 108 can switch to working in Mode B. If the BER does not exceed the BER threshold at block 724, then at block 720, the data will be transferred to the host device, and the data transfer will be complete. If, on the other hand, the BER does exceed the received BER threshold at block 724, then at block 726, the data will be transferred to the host device.
[0060] If QoS is important at block 706, or if the data is transferred to the host device at block 726, then at block 708, the controller 108 switches to working in Mode B. At block 728, the controller 108 receives data from the one or more memory devices. At block 730, the received data, such as the raw data 540 of decoded at block 732. At block 734, one or more hints of the order of data received from the one or more memory devices are provided to the host device 104. After the one or more hints are provided to the host device at block 734, the data is transferred to the host device 104 at block 720. When there is a high BER, the act of sending hints after the data is decoded benefits the performance of the system. When the relevant data includes a high BER, the performance of the data storage device is reduced, and the delay in providing hints can not impact the overall performance of the data storage device.
[0061] The OOO hints generator works in several modes depending on the state of the NVM 110 or memory device. When the NVM 110 or memory device is new, the BER is very low, and thus, the valid assumption is that data transfers rarely incur OOO. When the NVM 110 or memory device is near the end of its life cycle, the assumption is invalid because the processing time of the LDPC engine can depend on the current BER of the NVM 110 or memory device. Thus, data transfers of low BER tasks can bypass data transfers of high BER tasks. When there is a low BER, the OOO hints are generated in Mode A, which can be more accurate than generating hints in Mode B. In Mode A, the hints are generated and provided to the host device 104 early enough so that the host device 104 can have enough time to process the hints. When a high BER is detected in the NVM or memory device, the controller 108 switches to Mode B. Mode B generates hints after the raw data is decoded and the order is known. When working in Mode B, the hints are transferred late in the read command execution operation, and the host device 104 can receive less time to process the received hints. However, Mode B can be more accurate than Mode A.
[0062] Two main factors drive OOO in NAND-based devices. The first reason involves the number of dies implemented in a single memory device. In eSSDs, the number of dies can be 512 or even 1024. These values are not meant to limit the present disclosure. Even in single-die systems, the data storage device 106 can prefer to transfer data OOO due to a high BER in a particular page or a particular memory device. Other pages can be transferred to the host before the pages with high BER.
[0063] By generating accurate OOO hints and sending the OOO hints to the host device, the performance of the data storage device can be improved.
[0064] In one embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to interact with a host device using a UFS interface protocol and to operate in a first mode corresponding to a first bit error rate (BER) and a second mode corresponding to a second BER that is greater than the first BER. The controller is configured to operate in the first mode and to provide a hint to the host device. The hint includes an indication of what order data is to be received from the data storage device. The order of the data is to be a different order than a requested order. After providing the hint, the controller is configured to retrieve data from the memory device. The controller detects a hint conflict caused by the BER, reorders the data to match the order provided in the hint, and transfers the data to the host device. The controller then determines that the BER is greater than a predetermined threshold and switches to operating in the second mode.
[0065] The controller is further configured to determine availability of memory dies of the memory device prior to providing the hint. The hint is based on the determined availability of the memory dies. The controller is further configured to switch back to operating in the first mode after determining that the BER is below the threshold. The controller stores the out-of-order data in the hint in a buffer prior to reordering. The data is decoded prior to sending to the host device. The hint accounts for logical-to-physical (L2P) address translation and memory die mapping.
[0066] In another embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to interact with a host device using a UFS interface protocol and to operate in a first mode corresponding to a first bit error rate (BER) and a second mode corresponding to a second BER that is greater than the first BER. The controller is configured to operate in the second mode and to retrieve data from the memory device. After retrieving the data, the controller is configured to provide a hint to the host device. The hint includes an indication of what order data is to be received from the data storage device. The order of the data is to be a different order than a requested order. The controller is configured to transfer the data to the host device. The controller is further configured to compare a BER of the transferred data to a threshold, determine that the BER is less than the threshold, and switch to operating in the first mode.
[0067] The controller is configured to determine a bit error rate of data retrieved from each die of the memory device. The first mode includes transferring a hint to the host device prior to retrieving the data. During operation in the second mode, data retrieved from the memory device is sent to a decoder, where the data is decoded, and where any data that needs correction is corrected prior to providing the hint. The data emerges from the decoder in an order that is different than an order in which the data was transferred to the decoder. The hint is embedded in a UFS packet sent to the host device.
[0068] In another embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to interact with a host device using a UFS interface protocol. The controller is configured to provide a hint to the host device, switch between a first mode and a second mode, and transfer data to the host device. The hint includes an indication of what order data is to be received from the data storage device. The order of the data is to be a different order than a requested order. The first mode includes providing the hint prior to retrieving data from the memory device. The second mode includes providing the hint after retrieving data from the memory device.
[0069] The controller is configured to operate in the first mode and switch to the second mode upon determining that data has exceeded a bit error rate threshold. The controller is configured to switch back to the first mode upon determining that data is below the bit error rate threshold. The controller is configured to reorder data received from the memory device to match an order of the hint transferred to the host device. Switching to the second mode after transferring requested data to the host device. The hint is based on a logical block array range. The hint is based on attaining a predetermined quality of service (QoS) threshold.
[0070] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the disclosure can be devised without departing from the basic scope thereof, and the scope of the present disclosure is determined by the claims that follow.
Claims
1. A data storage device, the data storage device comprising: Memory devices; and A controller coupled to the memory device, wherein the controller is configured to interact with the host device using a Universal Flash Storage (UFS) interface protocol and to operate in a first mode corresponding to a first bit error rate (BER) and a second mode corresponding to a second BER greater than the first BER, wherein the controller is further configured to: Operates in the first mode; Provide a prompt to the host device, wherein the prompt includes an indication of what order of data will be received from the data storage device, wherein the order of the data will be different from the requested order; After the prompt is provided, the data is retrieved from the memory device; The conflicting prompts were caused by BER detection; The data is reordered to match the order provided in the prompt; The data is transmitted to the host device; Determine that the BER is greater than a predetermined threshold; as well as Switch to working in the second mode.
2. The data storage device of claim 1, wherein the controller is further configured to determine the availability of the memory die of the memory device before providing the prompt.
3. The data storage device of claim 2, wherein the notification is based on the determined availability of the memory die.
4. The data storage device of claim 1, wherein the controller is configured to switch back to operating in the first mode after determining that the BER is below the threshold.
5. The data storage device of claim 4, wherein the controller stores the out-of-order data in the prompt in a buffer before the reordering.
6. The data storage device of claim 1, wherein the data is decoded before being sent to the host device.
7. The data storage device of claim 1, wherein the hints take into account logical-to-physical address translation and memory die mapping.
8. A data storage device, the data storage device comprising: Memory devices; and A controller coupled to the memory device, wherein the controller is configured to interact with the host device using a Universal Flash Storage (UFS) interface protocol and to operate in a first mode corresponding to a first bit error rate (BER) and a second mode corresponding to a second BER greater than the first BER, wherein the controller is configured to: Operates in the second mode; Retrieve data from the memory device; After retrieving the data, a prompt is provided to the host device, wherein the prompt includes an indication of the order in which the data will be received from the data storage device. The order of the data will be different from the order requested. The data is transmitted to the host device; Compare the BER of the transmitted data with the threshold; Determine that the BER is less than the threshold; as well as Switch to working in the first mode.
9. The data storage device of claim 8, wherein the controller is configured to determine the bit error rate of the data retrieved from each die of the memory device.
10. The data storage device of claim 9, wherein the first mode includes transmitting a prompt to the host device before retrieving the data.
11. The data storage device of claim 8, wherein during operation in the second mode, the data retrieved from the memory device is sent to a decoder, wherein the data is decoded, and wherein any data requiring correction is corrected before the prompt is provided.
12. The data storage device of claim 11, wherein the data appears from the decoder in an order different from the order in which the data is transmitted to the decoder.
13. The data storage device of claim 8, wherein the notification is embedded in a UFS packet sent to the host device.
14. A data storage device, the data storage device comprising: Memory devices; and A controller, coupled to the memory device, is configured to interact with the host device using a Universal Flash Storage (UFS) interface protocol, wherein the controller is configured to: Provide a prompt to the host device, wherein the prompt includes an indication of what order of data will be received from the data storage device, wherein the order of the data will be different from the requested order; Switching between a first mode and a second mode, wherein the first mode includes providing the prompt before retrieving the data from the memory device, and wherein the second mode includes providing the prompt after retrieving the data from the memory device; as well as The data is transmitted to the host device; and The controller is configured to operate in the first mode and switch to the second mode when it is determined that the data has exceeded a bit error rate threshold; and The controller is configured to switch back to the first mode after determining that the data is below a bit error rate threshold.
15. The data storage device of claim 14, wherein the controller is configured to reorder data received from the memory device to match the order of the prompts transmitted to the host device.
16. The data storage device of claim 14, wherein the controller switches to the second mode after transmitting the requested data to the host device.
17. The data storage device of claim 14, wherein the prompt is based on a logical block array range.
18. The data storage device of claim 14, wherein the prompt is based on obtaining a predetermined quality of service (QoS) threshold.
Citation Information
Patent Citations
Data processing device and data processing method
CN105210299A
Adaptive multi-rate partial decode
US20160204908A1