Universal flash storage device with partial buffer refresh and refresh recovery function

Abstract

Methods executable by a universal flash storage (UFS) system of a computing device provide a write accelerator buffer portion flush procedure and a flush recovery / retry procedure in a flash storage device. A method for managing operations of a write accelerator buffer of a flash memory device includes notifying a host controller that a flush of the write accelerator buffer has terminated, sending context information to the host controller that describes one or more data structures that have been successfully flushed. The method can include receiving a partial unmap command from the host controller to unmap the one or more data structures that have been successfully flushed, and can include resuming the flush of the write accelerator buffer.

Description

[0001] Related applications

[0002] This application claims the benefit of priority to U.S. nonprovisional application No. 18 / 519,031, filed November 26, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0003] Developers and users of computing devices are always seeking improved operational performance and durability. In some computing devices, such as buffers and cache memory elements, flushing buffers or caches to longer-term storage can be a frequent process of freeing them up to receive further data. Errors or faults encountered during flushing can cause the memory tables of the device and controller to become out of sync, and the state of one or more data structures in memory to become uncertain. Therefore, resynchronization and restarting are both time-consuming and error-prone. Summary of the Invention

[0004] Various aspects may also include a method performed by a universal flash storage (UFS) system of a computing device for writing data to a flash storage device having a write accelerator buffer that records refresh progress positions. Various aspects may include: notifying a host controller that the refresh of the write accelerator buffer has been terminated; sending context information to the host controller describing one or more data structures that have been successfully refreshed; and resuming the refresh of the write accelerator buffer. In some aspects, the one or more data structures may be multiple levels, addresses, or blocks in the write accelerator buffer memory, indicated as refreshed or not refreshed by multiple refresh points corresponding to the multiple levels, addresses, or blocks.

[0005] In some aspects, sending the context information may include sending a refresh completion position indicating the last successful refresh point in the refresh of the write accelerator buffer, and resuming the refresh may include resuming the refresh from the refresh completion position provided in the context information.

[0006] Some aspects may also include: receiving a context read command from the host controller; and sending the context information to the host controller in response to receiving the context read command. Some aspects may also include: receiving a refresh recovery command from the host controller; and resuming the refresh of the write to the accelerometer buffer in response to receiving the refresh recovery command. Some aspects may also include: the one or more data structures being one or more levels, addresses, or blocks of the write to the accelerometer buffer memory. Some aspects may also include: receiving a partial unmapping command from the host controller to unmapping the one or more data structures that have been successfully refreshed; and resuming the refresh from the refresh completion position in the context information.

[0007] A further aspect includes a flash memory storage device including a device controller configured to perform operations of any of the methods outlined above. A further aspect includes a computing device including a flash memory storage device controller and a host controller configured to perform operations of any of the methods outlined above. A further aspect includes a flash memory storage device including components for performing functions of any of the methods outlined above. Attached Figure Description

[0008] The accompanying drawings, which are incorporated herein and form part of this specification, illustrate exemplary embodiments of the claims and, together with the general description and detailed description given, serve to explain the features of this document.

[0009] Figure 1 This is a system block diagram illustrating an example flash memory system suitable for implementing any of the various implementation schemes.

[0010] Figure 2 This is a system block diagram illustrating an example flash memory system suitable for implementing any of the various implementation schemes.

[0011] Figure 3 This is a component block diagram of an example computing device applicable to any implementation of various implementation schemes.

[0012] Figure 4 This is a component block diagram illustrating an example system configured to perform partial flush and recovery capabilities of a write accelerator buffer according to some implementation schemes.

[0013] Figure 5 This is a signaling diagram illustrating an example of the write accelerator buffer partial refresh and recovery process according to some implementation schemes.

[0014] Figure 6 This is a flowchart illustrating an example method for partially refreshing and restoring the write accelerator buffer according to some implementation schemes.

[0015] Figure 7A This is a flowchart illustrating an example method for partially refreshing and restoring the write accelerator buffer according to some implementation schemes.

[0016] Figure 7B This is a flowchart illustrating an example method for partially refreshing and restoring the write accelerator buffer according to some implementation schemes.

[0017] Figure 8 This is a block diagram illustrating the components of an example personal computer suitable for use with various implementation schemes.

[0018] Figure 9 This is a component block diagram illustrating an example server suitable for use with various implementation schemes.

[0019] Figure 10 This is a component block diagram illustrating an example wireless communication device suitable for use with various implementation schemes. Detailed Implementation

[0020] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and embodiments are for illustrative purposes and are not intended to limit the scope of the claims.

[0021] Various implementations include methods and computing devices for implementing a partial refresh and recovery process for a write accelerator buffer in a flash storage device. Various implementations may include methods performed by a universal flash storage (UFS) system of the computing device, the method comprising: notifying a host controller that the refresh of the write accelerator buffer has been terminated; receiving a context read command from the host controller; and sending context information to the host controller describing one or more data structures that have been successfully refreshed.

[0022] Various implementations may include a method performed by a universal flash storage (UFS) system of a computing device, the method including: receiving a partial unmapping command from a host controller to unmapping one or more data structures that have been successfully refreshed; receiving a refresh recovery command from the host controller; and resuming the refresh of the write accelerator buffer. The universal flash storage (UFS) system of the computing device may resume the refresh from the refresh completion position provided in the context information.

[0023] More generally, a UFS device can operate as a storage module having multiple logical units (LUs) and may include a write accelerator buffer to increase the speed at which data is written to the device (e.g., before being placed in a conventional storage device). Most storage volumes may be three-level cell (TLC) NAND memory elements, while some memory (including write accelerator buffers) may be single-level cell (SLC) NAND memory elements.

[0024] In SLC NAND memory elements, each memory cell stores only one bit of data representing either "0" or "1". Due to the simplicity of storing a single bit per cell, SLC memory has several advantages, including faster write and read speeds, greater durability, and a lower error rate.

[0025] In TLC NAND memory elements, each memory cell stores three bits of data, resulting in eight possible voltage levels. While this increases storage density, it also introduces some trade-offs compared to SLC memory, including slower write and read speeds, lower endurance, and a higher error rate.

[0026] The conventional storage device in a flash memory device can be TLC NAND, and flash memory devices (e.g., UFS devices) can include write buffers for SLC NAND memory elements that temporarily store received data before transferring it to the conventional storage device within the TLC NAND memory. This process of transferring the temporarily stored data to the conventional storage device is called a refresh. A refresh typically transfers all data from the write accelerator buffer to the conventional storage device as a single refresh process. Errors, faults, and terminations that occur during a refresh are difficult to recover from and can result in extensive error checking and correction by both the host controller and the flash memory device.

[0027] When system anomalies occur (such as device driver errors, device controller pauses, insufficient TLC memory, hardware component failures, accelerated write buffer (TWB) issues, or synchronization problems or security limitations at the device controller), refresh operations may fail under certain operating conditions supporting many applications. For example, the TWB and the memory tables in the device controller may become out of sync with each other or with the memory tables at the host controller. Furthermore, hardware failures (such as cable faults, short circuits, static electricity, loose connections, or compatibility issues) can introduce errors and faults into the refresh process or SLC-to-TLC conversion.

[0028] When a flash memory device failure is detected, the flash memory device controller may generate an error code or set a refresh status (e.g., bWriteBoosterBufferFlushStatus=04h). In current designs, this error may not be easily repaired or easily retried, leading to widespread error remapping or complete buffer failure. For example, in the event of an error during refresh, the SLC buffer may be occupied by existing data (e.g., unrefreshed data). Because refresh is an internal operation of the flash memory device, the host controller may not be aware of the refresh failure. The host controller may not retry the refresh because it is unaware of the failure. The host controller may also fail to write data to the SLC buffer because the buffer may be full due to incomplete unmapping. When a refresh operation fails due to a general failure, only the successfully refreshed data may be unmapped or synchronized, which could be the entire SLC buffer. This could mean that the entire SLC buffer becomes unusable. The host controller may then be forced to write directly to the TLC, which reduces write speed.

[0029] Various implementations address and overcome the aforementioned problems of the inability to remap the memory table after a partial refresh and the inability to resume refresh from a specific point in the SLC buffer based on a previous partial refresh. These implementations enable the flash device to: notify the host controller that the refresh of the write accelerator buffer has been terminated; receive a context read command from the host controller; and send context information to the host controller describing one or more data structures that have been successfully refreshed. This allows the host controller to be informed of errors during the refresh process, preventing it from assuming the refresh was successful, and enables the host controller to receive context information about faults, including points of failure in the process.

[0030] The host controller can unmap or remap its memory table based on context information and can send a partial unmap command to the flash device to unmap one or more data structures successfully refreshed at the flash device. The host controller can then send a refresh recovery command, which the flash device can receive, and the flash device can resume refreshing the write accelerator buffer. In some embodiments, the write accelerator buffer includes several refresh points or checkpoints corresponding to segments of the write accelerator buffer that were triggered or recorded as successful or unsuccessful during a refresh. The UFS device controller can then access the recorded refresh checkpoint data to provide the last successful checkpoint as context information to the host controller, enabling the host controller to update its memory table. In some embodiments, the flash device can use checkpoint data to identify (or be provided by the host controller) the point in the write accelerator buffer from which it resumed refreshing (e.g., a memory address). The flash device can then resume refreshing and notify the host controller of the result; if an error occurs, the host controller can restart the process.

[0031] The term "System-on-a-Chip" (SoC) is used herein to refer to a single integrated circuit (IC) chip containing multiple resources and / or processors integrated on a single substrate. A single SoC may contain circuitry for digital, analog, mixed-signal, and radio frequency functions. A single SoC may also include any number of general-purpose and / or specialized processors (digital signal processors, modem processors, video processors, etc.), blocks of memory (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). An SoC may also include software for controlling the integrated resources and processors, as well as software for controlling peripheral devices. A host controller may be part of an SoC, and a UFS device may be part of an SoC.

[0032] The term "System-in-Package" (SIP) may be used herein to refer to a single module or package containing multiple resources, computing units, cores and / or processors on two or more IC chips, a substrate, or a System-on-a-Chip (SoC). For example, an SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, an SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. An SIP may also include multiple independent SoCs coupled together via high-speed communication circuitry and packaged in close proximity, such as on a single motherboard or within a single computing device. This proximity of the SoCs facilitates high-speed communication and the sharing of memory and resources.

[0033] As used herein, the term "processing system" refers to one or more processors, including multi-core processors, that are organized and configured to perform various computational functions. Various implementation methods can be implemented in one or more of the multiple processors within a vehicle processing system as described herein.

[0034] Figure 1This is a system block diagram illustrating an example flash memory storage system suitable for implementing any of the various implementation schemes. System 100 may include one or more computing devices or processors connected to a UFS device 106 for storage. For example, system 100 may include a SoC 102 including a host controller 104, dynamic random access memory (DRAM) 108 communicatively connected to the host controller 104, and a UFS device 106 communicatively connected to the host controller 104 via link 114. The host controller 104 may include a processor (not shown separately) configured to perform the operations of the host controller described herein. The host controller 104 may maintain and access data stored in DRAM 108 or SRAM (not shown) integrated with the SoC 102 and / or the host controller 104. The UFS device 106 may include a device controller 116, static random access memory (SRAM) 110, a write accelerator buffer (e.g., SLC NAND memory) 118, and a conventional storage device (e.g., TLC NAND memory) 112. Device controller 116 may include one or more processors configured as a processing system to implement various embodiments. Device controller 116 may be coupled to SRAM 110 and conventional storage device 112 such that device controller 116 may store a memory table for conventional storage device 112 in SRAM 110. Write accelerator buffer 118 may be coupled to device controller 116 and conventional storage device 112 such that write accelerator buffer buffers data written from host controller 104 to conventional storage device 112 via device controller 116. When device controller 116 has been instructed to bypass write accelerator buffer 118, conventional storage device 112 may be coupled to device controller 116 to store data written from host controller 104.

[0035] Host controller 104 can implement write transactions to UFS device 106. Write transactions may include host controller 104 issuing write commands to device controller 116 from other components of SoC 102 and / or from components communicatively connected to SoC 102 (e.g., via SoC I / O). Host controller 104 can implement one or more memory management commands to UFS device 106, including refresh commands, unmapping commands, and remapping commands. Host controller 104 may store one or more memory tables on DRAM 108, which may be synchronized with data tables on SRAM 110 describing the location of data in conventional storage device 112 and write accelerator buffer 118. In addition to commands and data from host controller 104, device controller 116 may also respond via link 114 with information (e.g., status variables, device status) and data (e.g., data previously received and stored in flash storage device (UFS device 106)).

[0036] Device controller 116, receiving write commands and data from host controller 104, can write data to write accelerator buffer 118. Device controller 116 can manage write accelerator buffer 118, which stores data, including controlling the flushing of data from write accelerator buffer 118 to conventional storage device 112. Device controller 116 can periodically, irregularly, or at the command of host controller 104 to flush data from write accelerator buffer 118 to conventional storage device 112. Device controller 116 can maintain a memory mapping table at UFS device 106 using addresses at conventional storage device 112 and write accelerator buffer 118. The memory table can include parameters and controls for different parts of conventional storage device 112, such as the logical unit number (LUN) for each of the multiple memory logical units in conventional storage device 112.

[0037] In some implementations, device controller 116 may be configured to update the memory table after a refresh of write accelerator buffer 118. Device controller 116 may define one or more checkpoints at specific addresses within write accelerator buffer 118 and may record the refresh progress through these checkpoints. Furthermore, after a refresh, device controller 116 may unmap refreshed addresses in write accelerator buffer 118 to free these addresses for further writing (rewriting) by host controller 104, and may notify write accelerator buffer 118 of refreshed addresses or successful addresses, allowing host controller to write data to unmapped memory portions within write accelerator buffer 118. In some implementations, device controller 116 may be configured to manage the refresh process, including recording refresh progress, sharing refresh status and context with host controller, and resuming refresh after premature termination. In this way, device controller provides advantageous refresh capabilities and advantageous refresh status communication with host controller.

[0038] Host controller 104 can implement read transactions at UFS device 106. A read transaction may include host controller 104 issuing a read request to device controller 116 from other components of SoC 102 and / or from components communicatively connected to SoC 102 (e.g., via SoC I / O). A read transaction may include passing the address to be read from host controller 104 to device controller 116. The read address may be a physical address corresponding to a logical address received by host controller 104 from other components of SoC 102 and / or from components communicatively connected to SoC 102. Read transactions may occur after write transactions, and the written data may be read from conventional storage device 112. As illustrated, host controller 104 may send commands and data to UFS device 106 via link 114, and UFS device 106 may send a response acknowledging receipt and / or requesting the next transmission.

[0039] Figure 2 This is a system block diagram illustrating an example flash memory system 200 suitable for implementing any of the various implementation schemes. Reference Figure 1 and Figure 2The illustrated example UFS device 106 includes a device controller 116, which may include a processing system, a write accelerator buffer 118, and a conventional storage device 112. The conventional storage device 112 may include a plurality of logical unit numbers (LUNs) that may correspond to logical address blocks of TLC NAND memory. The device controller 116 may be connected to the write accelerator buffer 118 and may include one or more processors in the processing system configured to transmit commands and requests to the write accelerator buffer 118. For example, the device controller 116 may command the write accelerator buffer 118 to flush data to the conventional storage device 112, or may process read commands to read data from the write accelerator buffer 118 to the host controller 104, or may process other control commands as described in the UFS 4.0 specification or its updates.

[0040] As illustrated, the data stream from host controller 104 can first be directed to write accelerator buffer 118 to achieve faster throughput to UFS device 106. Finally, some or all of the data in write accelerator buffer 118 is flushed by device controller 116. After completing the writing of data to write accelerator buffer 118 or conventional storage device 112, device controller 116 can send a response to host controller 104. (As opposed to...) Figure 1 As described, host controller 104 can send data for writing to one or more data structures (e.g., L1, L2, L3, L4) in write accelerator buffer 118. Data structures L1 through L4 may include one or more addresses associated with checkpoints (e.g., illustrated by lines 1 through 4 between data structures in 118), such that when the address corresponding to the checkpoint is refreshed, device controller 116 can record the refresh of the data structure (e.g., L2) as complete. The number and organization of the illustrated data structures L1 through L4 are non-limiting examples and can be any non-zero integer. The entire write accelerator buffer 118 may be divided into data structures (e.g., multiple data structures) with corresponding refresh points indicating whether each data structure in the write accelerator buffer has been successfully refreshed.

[0041] The host controller 104 can command data sent to the write accelerator buffer 118 to be stored in any data structure within the data structure, and the device controller 116 can individually address and map one or more addresses and one or more data structures that may contain one or more addresses. For example, the device controller 116 can be operated to refresh individual data structures (e.g., L3) or write data to individual data structures (e.g., L4), or can fill data structure L3 before filling data structure L1. Data structures L1 through L4 can be filled sequentially, randomly, or through other organization schemes using the locations of stored data reflected in one or more memory tables on the UFS device 106.

[0042] Figure 3 This is a component block diagram illustrating an example computing device 300 suitable for implementing any of the various implementation schemes. Various implementation schemes may be implemented on several single-processor and multi-processor computer systems, including system-on-a-chip (SoC) or system-in-package (SIP) systems.

[0043] refer to Figures 1 to 3 The illustrated example computing device 300 (which may be a system-in-package in some embodiments) includes two SoCs 302 (e.g., SoC 102) and 304 coupled to a clock 306, a voltage regulator 308, at least one subscriber identity module (SIM) 368 and / or SIM interface, DRAM 370 (e.g., DRAM 108), a UFS device 372 for storage (e.g., UFS device 106), and a wireless transceiver 366 configured to transmit and receive wireless communications to / from wireless computing devices (such as base stations, wireless devices, and / or computing devices (e.g., system 100)) via an antenna (not shown). In some embodiments, the first SoC 302 may operate as a central processing unit (CPU) of the computing device 300, which executes instructions by performing arithmetic, logic, control, and input / output (I / O) operations specified by instructions from a software application. In some embodiments, the second SoC 304 may operate as a dedicated processing unit. For example, the second SoC 304 can operate as a dedicated 5G processing unit responsible for managing high-capacity, high-speed (e.g., 5Gbps) and / or very high frequency shortwave length (e.g., 28GHz millimeter wave spectrum) communications.

[0044] The first SoC 302 may include a digital signal processor (DSP) 310, a modem processor 312, a graphics processor 314, an application processor (AP) 316, one or more coprocessors 318 (e.g., vector coprocessors) connected to one or more of these processors, memory 320 (e.g., DRAM 108), custom circuitry 322, system components and resources 324, a host controller 362 (e.g., host controller 104), an interconnect / bus module 326, one or more sensors 330 (e.g., accelerometers, temperature sensors, pressure sensors, optical sensors, infrared sensors, analog sound sensors, etc.), a thermal management unit 332, and a thermal power envelope (TPE) component 334. The second SoC 304 may include a low-power processor 352, a power management unit 354, an interconnect / bus module 364, a BT controller 356, memory 358, and various additional processors 360, such as application processors, packet processors, etc.

[0045] Each processor 310, 312, 314, 316, 318, 352, 360 may include one or more cores, and each processor / core may perform operations independently of other processors / cores. For example, the first SoC 302 may include a processor executing a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor executing a second type of operating system (e.g., MICROSOFT WINDOWS 10). Furthermore, any or all of processors 310, 312, 314, 316, 318, 352, 360 may be included as part of a processor cluster architecture (e.g., synchronous processor cluster architecture, asynchronous or heterogeneous processor cluster architecture, etc.).

[0046] The first SoC 302 and the second SoC 304 may include various system components, resources, and custom circuitry for managing sensor data, analog-to-digital conversion, wireless data transmission, and performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for presentation in web browsers or audio / video applications. For example, the system components and resources 324 of the first SoC 302 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components for supporting processors and software clients running on computing devices. The system components and resources 324 and / or custom circuitry 322 may also include circuitry for engaging peripheral devices such as cameras, electronic displays, wireless communication devices, external memory chips, etc.

[0047] The first SoC 302 and the second SoC 304 may communicate via an interconnect / bus module 350. In some embodiments, the interconnect / bus module may be a connection established through transceiver (i.e., receiving and transmitting) components within both SoC 302 and SoC 304. For example, the low-power processor 352 may include a universal asynchronous receiver-transmitter (UART), and the application processor 316 may include a multi-signal message (MSM) UART driver communicatively connected to the UART of the low-power processor 352.

[0048] Various processors 310, 312, 314, 316, and 318 can be interconnected via interconnect / bus module 326 to one or more memory elements 320, system components and resources 324, custom circuitry 322, and thermal management unit 332. Similarly, low-power processor 352 can be interconnected via interconnect / bus module 364 to power management unit 354, BT controller 356, memory 358, and various additional processors 360. Interconnect / bus modules 326, 350, and 364 may include arrays of reconfigurable logic gates and / or implement bus architectures (e.g., CoreConnect, AMBA, etc.). Communication may be provided by advanced interconnects such as high-performance on-chip networks (NoC).

[0049] In various implementations, any or all of the processors 310, 312, 314, 316, and 318 in the system can operate as the main processor, central processing unit (CPU), microprocessor unit (MPU), arithmetic logic unit (ALU), etc., of the SoC. One or more coprocessors in coprocessor 318 can operate as the CPU. In addition to the example SIP100 discussed above, various implementations can be implemented in a wide variety of computing systems, which may include a single processor, multiple processors, multi-core processors, or any combination thereof.

[0050] The first SoC 302 and / or the second SoC 304 may also include input / output modules (not illustrated) for communicating with external SoC resources such as clock 306, voltage regulator 308, one or more wireless transceivers 366, and at least one SIM 368 and / or SIM interface (i.e., an interface for receiving one or more SIM cards)). External SoC resources (e.g., clock 306, voltage regulator 308) may be shared by two or more internal SoC processors / cores.

[0051] In addition to the example computing device 300 discussed above, various implementations can be implemented in a wide variety of computing systems, which may include a single processor, multiple processors, multi-core processors, or any combination thereof. In some implementations, the various processors of SoC 302 and SoC 304 may reside within the same SoC. For example, application processor 316 and low-power processor 352 may reside within the same SoC (such as in a single SoC of a wearable device) to execute optimized storage routines using UFS device 372.

[0052] Figure 4 This is a component block diagram illustrating an example system 400 configured for partial flushing and flush recovery of the accelerometer buffer according to some implementation schemes. Reference Figures 1 to 4 System 400 may include a flash memory device 402 and a host device 418 that can communicate via a communication link 424 (e.g., link 114). Host device 418 may be a processing system of a computing device that can send read and write requests to flash memory device 402. System 400 may include multiple hardware, software, and / or firmware components that operate together to provide functionality attributed herein to processor 422 (e.g., UFS device controller 116). Flash memory device 402 may include a write accelerator buffer 118 (e.g., write accelerator buffer 118, SLCNAND memory) that receives and temporarily stores (i.e., buffers) data to be written to and stored in electronic storage device 420, as described herein.

[0053] Flash memory device 402 may include electronic storage device 420 (e.g., conventional storage device 112), which, together with write accelerator buffer 118, may be configured to store information as instructed by processor 422 via machine-readable instructions 406. Electronic storage device 420 may include flash-type non-transitory storage medium (e.g., read-only memory) that electronically stores information. Processor 422 may form a processor system of executable modules 430 to 438. Electronic storage device 420 may store software algorithms, information determined by processor 422 of the processing system, and / or other information that enables flash memory device 402 to operate as described herein.

[0054] The flash memory device processor 422 can be configured by machine-readable instructions 406. The machine-readable instructions 406 may include one or more instruction modules. Instruction modules may include computer program modules. Instruction modules may include one or more of a write accelerator buffer module 430, a write accelerator communication module 432, a progress tracking module 436, a refresh management module 438, and other instruction modules (not illustrated). The flash memory device 402 may include one or more processors 422 configured to implement the machine-readable instructions 406 and corresponding modules.

[0055] In some implementations, the processor 422 executing the write accelerator buffer module 430 may be configured to manage the refresh of the write accelerator buffer 118 and may be configured to resume the refresh of the write accelerator buffer 118 after premature termination. For example, the write accelerator buffer module 430 may be configured to control the implementation of refreshing the contents of the write accelerator buffer 118 of the UFS device 402 to conventional storage devices (e.g., conventional storage device 112, TLC NAND memory) in the electronic storage device 420 of the UFS device. The refresh may be implemented periodically, irregularly, etc. For example, it may be implemented once or multiple times per read transaction (such as each data read command received at the flash memory device 402). As another example, a refresh may be implemented when a capacity threshold of the write accelerator buffer 118 is reached.

[0056] In some implementations, the processor 422 executing the write accelerator buffer module 430 may be configured to store one or more memory tables to manage the electronic storage device 420 (e.g., conventional storage device 112). These memory tables may map addresses in the shared write accelerator memory and conventional storage device 112 (e.g., to manage refresh operations). The memory tables may also record the progress of memory refreshes of the write accelerator buffer 118 or the progress of refreshes of one or more data structures (e.g., L1 to L4) of the write accelerator buffer 118 via one or more segments of the write accelerator buffer 118. The processor 422 executing the write accelerator buffer module 430 may be configured to independently evaluate the need for refreshing the write accelerator buffer 118 (or a portion thereof), or may be configured to refresh the write accelerator buffer 118 (or a portion thereof) upon receiving a command from the host device 418. The processor 422 executing the write accelerator buffer module 430 can be configured to send a response to the host device 418 (e.g., host controller 104) when data is sent or a portion thereof has been received and stored on the write accelerator buffer 118.

[0057] In some implementations, the processor 422 executing the write accelerator communication module 432 can manage and schedule incoming commands and data received at the flash memory device 402 from the host controller 418 for processing at the write accelerator buffer 118 or the electronic storage device 420. For example, the write accelerator communication module 432 can provide confirmation to the device controller 116 or the host device 418 that data has been fully written and can report its physical or logical address. Similarly, the write accelerator communication module 432 can confirm the delivery of data that has been refreshed from the write accelerator buffer 118, so that the device controller 116 or the host device 418 can correctly record the updated data location (e.g., physical or logical address). Confirmation may include a response command for writing a transaction from the host device 418 via link 424.

[0058] In some implementations, the processor 422 executing the progress tracking module 436 may be configured to record the progress of refreshing the SLC buffer (e.g., write accelerator buffer 118) to TLC memory via one or more checkpoints (e.g., 1 to 4) or via one or more memory addresses. The progress tracking module 436 may include a memory table having one or more rows corresponding to checkpoints at addresses of the write accelerator buffer 118, such that when an address or checkpoint is reached, the progress tracking module 436 may set a flag or bit in the corresponding row of that checkpoint. The progress tracking module 436 may communicate the refresh status or refresh completion point to the write accelerator communication module 432, device controller 116, or host device 418 (e.g., host controller 104).

[0059] In some implementations, the processor 322 executing the refresh management module 438 may be configured to perform a refresh based on one or more parameters (e.g., fill level) or on commands from the host device 418. The refresh management module 438 may detect refresh termination or receive error or fault codes indicating unsuccessful refresh from the write accelerator buffer 118 or other components of the flash memory device 402. The refresh management module 438 may set a status flag to success or failure (e.g., 1 / 0) based on the refresh result and may communicate the status flag to the write accelerator module 432 to include the information in a notification from the host device 418. When the refresh is successful, the refresh management module 438 may unmap the refreshed address or data structure (e.g., L2) in the write accelerator buffer 118, making the refreshed address available for further data writing. When the refresh is unsuccessful and terminates prematurely, the refresh management module 438 may set a status and communicate the result to the device controller 116 or modules 430 to 436, and may determine the last data structure (e.g., L2) that was successfully refreshed based on a memory table in the progress tracking module 436.

[0060] When the last successfully refreshed data structure (e.g., L2) is determined, the refresh management module 438 can communicate the refresh location corresponding to that data structure and can communicate the refresh failure point (e.g., address) as context information to the write accelerator communication module 432 for transmission to the host device 418. The refresh management module 438 can be configured to unmap successfully refreshed data structures and not unmap unsuccessfully refreshed data structures. The refresh management module 438 can be configured to resume the refresh from SLC memory (e.g., write accelerator buffer 118) to TLC memory (e.g., conventional storage device 112) at a point after the last successfully refreshed data structure (e.g., an address after L2).

[0061] The description of the functionality provided by the different modules 430 to 438 is for illustrative purposes and is not intended to be limiting, as any of modules 430 to 438 may provide more or fewer functionalities than described. For example, one or more of modules 430 to 438 may be eliminated, and some or all of their functionality may be provided by the others in modules 430 to 438. As another example, processor 422 may execute one or more additional modules that may perform some or all of the functionality attributable to one of modules 430 to 438.

[0062] In some implementations, the write accelerator buffer module 430, the write accelerator communication module 432, the progress tracking module 436, and the refresh management module 438 may be implemented by a UFS device controller (e.g., device controller 116) that executes in the processor 422 of the flash memory device 402 (which may be and / or may include the processor 422).

[0063] Figure 5 This is a signal flow and operation diagram illustrating an example of write accelerator buffer optimization according to some implementation schemes. Reference Figures 1 to 5 The host controller 104 (e.g., 104, 418) of the SoC (e.g., SoC 102, 302) may be communicatively connected via a link (e.g., link 114) to the device controller 116 of the UFS device (e.g., UFS device 106, 402, 372, processor 422). The host controller 104 and device controller 116 may each include one or more processors in a processing system configured to execute computer program code to perform computational operations. The host controller 104 and UFS device controller 116 may each be configured to transmit and receive signals, including computational data and / or computational instructions, between components of the computing device (including between each other) via links.

[0064] In operation 501, host controller 104 may send a command to device controller 116 to refresh the write accelerator buffer. In operation 502, device controller 116 may notify host controller 104 that the refresh was unsuccessful. In operation 504, host controller 104 may respond to the received notification with a refresh context read command. The refresh context read command may read one or more values ​​and variables from device controller 116 (e.g., progress tracking module 436) describing context information (e.g., error code, error location, last checkpoint) associated with the refresh failure. Then, in operation 506, device controller 116 may execute the read request received from host controller 104. Then, in operation 508, device controller 116 may send context information about the refresh (e.g., last refreshed address) to host controller 104. Host controller 104 may update one or more memory tables in DRAM 108 describing the locations of data stored on flash memory devices (e.g., 402). Then, in operation 510, host controller 104 may generate a demapping command (or partial demapping) and send it to device controller 116 to release successfully refreshed memory (if any). Device controller 116 may then demapping these memory addresses in one or more memory tables. Then, in operation 512, host controller 104 may generate a refresh recovery command and send it to device controller 116. Then, in operation 514, device controller 116 may recover the refresh from SLC memory to TLC memory, starting from the position indicated by the checkpoint of the last successfully refreshed data structure.

[0065] Figure 6 This is a process flowchart of example method 600 according to various implementation schemes, which can be executed by the UFS device controller of the flash storage device (e.g., by a processor or processing system within the UFS device controller) for writing accelerator buffer refresh failure notifications and refresh recovery. Reference Figures 1 to 6 Method 600 can be executed by a UFS device controller (e.g., device controller 116) of a flash storage device (e.g., 106, 402). The UFS device controller may include one or more processors (e.g., processors 322, 422) in a processing system, wherein the one or more processors can be configured by processor-executable instructions stored in a non-transitory processor-readable medium (e.g., memory 110) to perform the operations of method 600. Components used to perform the operations of method 600 may be as described in the reference... Figures 1 to 6 The UFS device controller and / or processor or processing system described herein. To cover alternative configurations implemented in various implementations, the hardware implementing method 600 is referred to herein as the "processing system".

[0066] In box 602, the UFS device controller of the flash storage device may notify the host controller that the refresh of the write accelerator buffer has been terminated. In some implementations, a refresh failure notification may cause the host controller 104 to delay one or more queued or scheduled commands (e.g., read / write commands) so that the remaining process 600 can be executed. The notification may include an error code or cause of failure, which may be analyzed by the host controller 104 to determine whether the error or failure is recoverable (e.g., the storage device is full) or permanent (e.g., disconnection). The notification in box 602 may be an interruption in the wExceptionEventControl property (e.g., wExceptionEventControl[7]), which may notify the host that the context for the failure is available.

[0067] In block 604, the UFS device controller of the flash storage device may send context information to the host controller describing one or more data structures that have been successfully refreshed. In some embodiments, the context information may include a checkpoint corresponding to the last successfully refreshed data structure or address. In some embodiments, the one or more data structures may be multiple levels, addresses, or blocks written to the accelerator buffer memory, indicated as refreshed or unrefreshed by multiple refresh points corresponding to the multiple levels, addresses, or blocks. In some embodiments, the context information sent in block 604 may include a refresh completion position indicating the last successful refresh point in the refresh of the accelerator buffer. In some embodiments, block 604 may be combined with the operation of block 602 such that the context information is provided along with a failure notification. In some embodiments, the address of the remaining unrefreshed blocks may be provided as context information. The sending of context information may be part of a response to a context information read request.

[0068] In box 606, the UFS device controller of the flash storage device can resume refreshing the write accelerator buffer. In some implementations, the UFS device controller can resume refreshing from the refresh completion position (e.g., checkpoint address) provided in the context information sent in box 604. Remaining checkpoints can also be used to track the resumed refresh. Furthermore, if an error is expected to occur again, the UFS device controller can resume refreshing at a point later than the last successful checkpoint (e.g., sequentially later). In other words, the UFS device controller of the flash storage device can resume refreshing after premature termination (unexpected termination) at any given point in the write accelerator buffer 118.

[0069] Figure 7AThis is a process flowchart of example method 700 according to various implementation schemes, which can be executed by device controller 116 of a computing device (e.g., by a processor within the device controller) for writing accelerator buffer refresh failure notifications and refresh recovery. Reference Figures 1 to 7A Method 700 may be executed by a device controller 116 of a computing device (e.g., system 100, computing device 300) or a flash memory device (e.g., 106, 402). In some embodiments, the flash memory device may include one or more processors (e.g., processor 422) of a processing system, which are configured to perform operations by processor-executable instructions stored in a non-transitory processor-readable medium (e.g., memory 320, electronic storage device 420). Components for performing the operations of method 700 may be as described in the references. Figures 1 to 7A The described device controller and / or processor, etc. (Reference) Figures 1 to 7A Method 700 may be executed in a computing device by a processing system encompassing one or more processors (e.g., 310, 312, 314, 316, 318, 321, 322, 321, 322, 352, 360, etc.), components, or subsystems discussed herein. Components for performing the operations in method 700 may include the processing system, which includes one or more of processors 310, 312, 314, 316, 318, 321, 322, 321, 322, 352, 360 and other components described herein.

[0070] In some implementations, method 700 may be consistent with reference to Figure 6 The described method 600 is implemented in parallel (or together). For example, the UFS device controller implementing method 700 may be the same as a portion of the UFS device controller and / or UFS device described in method 600, and the host controller implementing method 700 may be the same as a portion of the host controller and / or host device described for method 600.

[0071] In box 602, the UFS device controller (e.g., 116) may notify the host controller that the refresh of the write accelerator buffer has been terminated. The operation of box 602 of method 700 may be performed as described for box 602 of method 600.

[0072] In box 704, the UFS device controller of the flash storage device can receive a context read command from the host controller. That is, the host controller can respond to a refresh failure notification by requesting more information via a read request with context information. In other words, the host controller can be configured to request this context information or be notified of its existence via a notification in box 602.

[0073] In block 604 of method 700, the UFS device controller of the flash storage device may send context information to the host controller describing one or more data structures that have been successfully refreshed from the write accelerator buffer (e.g., 118). The operation of block 604 of method 700 may be performed as described for block 604 of method 600.

[0074] In box 708, the UFS device controller of the flash storage device may receive a partial unmapping command from the host controller to unmapping one or more data structures that have been successfully refreshed. The host controller may specify one or more portions of the write accelerator buffer (e.g., data structures, addresses) not to be mapped (i.e., such that no data is mapped to that portion) to free up memory portions for further writing and access. These specified portions of memory in the write accelerator buffer may then be indicated in the (partial) unmapping command, or the device controller may interpret the unmapping command to apply only to the successfully refreshed portions of the write accelerator buffer (e.g., 118). The UFS device controller may initiate its own unmapping based on stored checkpoints after sending context information that provides the host controller with the information needed to unmapping its own memory table entries.

[0075] In block 710, the UFS device controller of the flash storage device may receive a "refresh recovery" command from the host controller. The refresh recovery command may include a start point for refresh recovery in the write accelerator buffer (e.g., 118). If the host controller determines that error correction needs to be performed, or if more data needs to be written to the unmapped memory (e.g., for correction or replacement of data), the reception of the refresh recovery command may be delayed after the unmapping of block 708 is completed.

[0076] In block 606 of method 700, the UFS device controller of the flash storage device can resume the refresh of the write accelerator buffer. The operation of block 606 can be performed automatically after the unmapping or partial unmapping of a successfully refreshed portion of the memory. In other words, block 710 can be optional. The operation of block 606 of method 700 can be performed as described for block 606 of method 600.

[0077] Figure 7B This is a process flowchart of example method 750 according to various implementation schemes, which can be executed by the host controller of a computing device (e.g., by a processor within the host controller) for writing accelerator buffer refresh failure notifications and memory refresh recovery. Reference Figures 1 to 7BMethod 750 may be executed by a host controller (e.g., host controller 104, 362, 418) of a computing device (e.g., system 100, computing device 300). In some embodiments, the host controller may include a processor (e.g., processor 422) configured to perform operations by processor-executable instructions stored in a non-transitory processor-readable medium (e.g., memory 320, electronic storage device 420). Components for performing the operations of method 750 may be as described in the references. Figures 1 to 7B The described host controller and / or processor, etc. (Reference) Figures 1 to 7B Method 750 may be executed by a processing system in a computing device, the processing system including one or more processors (e.g., 310, 312, 314, 316, 318, 321, 322, 321, 322, 352, 360, etc.), components, or subsystems discussed herein. Components for performing the operations in method 750 may include the processing system, which includes one or more of processors 310, 312, 314, 316, 318, 321, 322, 321, 322, 352, 360 and other components described herein.

[0078] In some implementations, method 750 may be compatible with reference to Figure 6 and Figure 7A The methods 600 / 700 described are implemented in parallel (or together). For example, the UFS device controller implementing method 750 may be the same as a portion of the UFS device controller and / or UFS device described in method 600, and the host controller implementing method 750 may be the same as a portion of the host controller and / or host device described for methods 600 / 700.

[0079] In box 752, the host controller of the SoC (e.g., 102, 302) may receive a notification from the flash memory device that a refresh of the write accelerator buffer has been terminated. As noted above, this notification may include the status of the write accelerator buffer and one or more error codes defining the error that terminated the memory refresh. Box 752 may be the counterpart of box 602 of method 600 / 700 at the host controller and the UFS device controller.

[0080] In block 754, the SoC's host controller may (e.g., via link 114) send a context read command to the flash device. Block 754 may be the counterpart of block 704 of method 700 at the host controller and the UFS device controller.

[0081] In box 756, the SoC's host controller may receive context information from the flash memory device describing one or more data structures that have been successfully refreshed. This context information enables the host controller to update one or more memory tables stored on the SoC that map data stored on the flash memory device (e.g., 402). Box 756 may be the counterpart of box 604 of method 600 / 700 at the host controller and the UFS device controller.

[0082] In box 758, the SoC's host controller may send a partial unmapping command to the flash device to unmapping one or more data structures that have been successfully refreshed. The partial unmapping command and its corresponding instructions are operable to synchronize the device controller's memory table with updates already performed at the host controller, where these updates may be based on context information. Box 758 may be the counterpart to box 708 of method 700 at the host controller and the UFS device controller.

[0083] In box 760, the SoC's host controller can send a refresh recovery command to the flash memory device. When the host controller's command queue is empty, the host controller can initiate a refresh recovery request (e.g., a TWB_FLUSH_RESUME_REQ command) to refresh the remaining data stored in the SLC memory. Box 760 can be the counterpart of box 606 of method 600 / 700 at the host controller and the UFS device controller.

[0084] Various implementation plans (including but not limited to references) Figures 1 to 7B The described implementation scheme can be implemented in a wide variety of computing systems, including laptop computers 800 (e.g., computing devices 100, 300, 402), examples of which are shown in Figure 8 Example in. refer to Figures 1 to 8The laptop computer may include a touchpad touch surface 817 that serves as a pointing device for the computer and is therefore capable of receiving drag, scroll, and tap gestures similar to those implemented on computing devices equipped with touchscreen displays and as described above. The laptop computer 800 will generally include a processor 802 coupled to volatile memory 812 and a disk drive 813 containing mass non-volatile memory such as flash memory. Additionally, the computer 800 may have one or more antennas 808 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless data link and / or to a cellular transceiver 816 coupled to the processor 802. The computer 800 may also include a floppy disk drive 814 and a compact disc (CD) drive 815 coupled to the processor 802. The laptop computer 800 may include a touchpad 817, a keyboard 818, and a display 819, all coupled to the processor 802. Other configurations of the computing device may include a computer mouse or trackball, which is well known to be coupled to the processor (e.g., via a Universal Serial Bus (USB) input), and this can also be used in combination with various implementation schemes.

[0085] Figure 9 This is a component block diagram of a computing device 900 (such as a server) suitable for use with various implementation schemes. Such a computing device may include at least... Figure 9 The components are shown. (See reference.) Figures 1 to 9 The computing device 900 (e.g., computing devices 100, 300, 402) may include a processor 901 coupled to volatile memory 902 and mass non-volatile memory (such as disk drive 903).

[0086] The computing device 900 may also include peripheral memory access devices coupled to the processor 901, such as floppy disk drives, compact disc (CD) or digital video disc (DVD) drives 906. The computing device 900 may also include a network access port 904 (or interface) coupled to the processor 901 for establishing data connections to networks, such as the Internet and / or local area networks coupled to other system computers and servers.

[0087] The computing device 900 may include one or more antennas 907 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless communication link. The computing device 900 may include additional access ports for coupling to peripheral devices, external memory, or other devices, such as USB, FireWire, Thunderbolt, etc.

[0088] Figure 10 This is a component block diagram of a computing device 1000 suitable for use with various implementation schemes. (Reference) Figures 1 to 10Various implementation schemes can be implemented on various computing devices 1000 (e.g., computing devices 100, 300, 402), examples of which are shown in […]. Figure 10 The example is illustrated in the form of a smartphone. The computing device 1000 may include a first SoC 302 (e.g., SoC-CPU) coupled to a second SoC 304 (e.g., a 5G-enabled SoC). The first SoC 302 and the second SoC 304 may be coupled to internal memory 1016, a display 1012, and a speaker 1014. The first SoC 302 and the second SoC 304 may also be coupled to at least one SIM 368 and / or a SIM interface, which may store information supporting a first 5G NR subscription and a second 5G NR subscription, which support services on a 5G non-autonomous (NSA) network.

[0089] The computing device 1000 may include an antenna 1004 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless transceiver 366 coupled to one or more processors in a first SoC 302 and / or a second SoC 304. The computing device 1000 may also include a menu selection button or rocker switch 1020 for receiving user input.

[0090] The computing device 1000 also includes a sound codec (CODEC) circuit 1010 that digitizes sound received from a microphone into data packets suitable for wireless transmission and decodes the received sound data packets to generate an analog signal provided to a speaker to produce sound. Additionally, one or more processors in the first SoC 302 and the second SoC 304, as well as the wireless transceiver 366 and CODEC 1010, may include digital signal processor (DSP) circuitry (not shown separately).

[0091] The processors of computer 800, computing device 900, and computing device 1000 can be any programmable microprocessor, microcomputer, or one or more multiprocessor chips that can be configured via software instructions (applications) to perform a variety of functions, including those described in the various embodiments below. In some mobile devices, multiple processors may be provided, such as one processor within SoC 304 dedicated to wireless communication functions and another within SoC 302 dedicated to running other applications. Software applications may be stored in memories 320 and 1016 before being accessed and loaded into the processor. The processor may include internal memory sufficient to store application software instructions.

[0092] Specific implementation embodiments are described in the following paragraphs. While some of the specific implementation examples below are described according to example methods that can be executed by a host controller in a computing device, other example implementations may include: a computing device including a UFS device controller and a host controller configured to perform the methods of the following specific implementation examples; a computing device including components for performing the functions of the following specific implementation examples, a UFS device controller and a host controller suitable for use in the computing device, wherein the UFS device controller and the host controller each include a processor configured to perform the methods of the following specific implementation examples; and a non-transitory processor-readable memory storing processor-executable instructions configured to cause the UFS device controller and the host controller in the computing device to perform the methods of the following specific implementation examples.

[0093] Example 1. A method for managing the operation of a write accelerator buffer in a flash memory device, the method comprising: notifying a host controller that a refresh of the write accelerator buffer has been terminated; sending context information to the host controller describing one or more data structures that have been successfully refreshed; and resuming the refresh of the write accelerator buffer.

[0094] Example 2. According to the method of Example 1, the one or more data structures are multiple levels, addresses or blocks written into the accelerator buffer memory, and are indicated as refreshed or not refreshed by multiple refresh points corresponding to the multiple levels, addresses or blocks.

[0095] Example 3. The method according to Example 1 or 2, wherein: sending the context information includes sending a refresh completion position indicating the last successful refresh point in the refresh of the write accelerator buffer; and resuming the refresh includes resuming the refresh from the refresh completion position provided in the context information.

[0096] Example 4. The method according to any one of Examples 1 to 3, the method further comprising: receiving a context read command from the host controller; and sending the context information to the host controller in response to receiving the context read command.

[0097] Example 5. The method according to any one of Examples 1 to 4, the method further comprising: receiving a refresh recovery command from the host controller; and resuming the refresh of the write accelerator buffer in response to receiving the refresh recovery command.

[0098] Example 6. The method according to any one of Examples 1 to 5, the method further comprising: receiving a partial unmapping command from the host controller to unmap one or more data structures that have been successfully refreshed.

[0099] Example 7. The method according to Example 6. According to the method of Example 6, wherein the partial unmapping command allocates the one or more data structures that have been successfully refreshed to free memory.

[0100] As used in this application, the terms "component," "module," "system," etc., are intended to include computer-related entities such as, but not limited to, hardware, firmware, combinations of hardware and software, software, or software being executed, configured to perform specific operations or functions. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a computing device and the computing device itself can be referred to as a component. One or more components may reside within a process and / or a thread of execution, and components may reside on a processor or core and / or be distributed across two or more processors or cores. Furthermore, these components may execute on various non-transitory computer-readable media on which various instructions and / or data structures are stored. Components may communicate via local and / or remote processes, function or procedure calls, electronic signals, data packets, memory read / write, and other known network, computer, processor, and / or process-related communication methods.

[0101] The various embodiments illustrated and described are provided merely as examples illustrating the various features of the claims. However, the features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment and may be used or combined with other embodiments shown and described. Furthermore, the claims are not intended to be limited to any one of the exemplary embodiments. For example, one or more operations in the operation of the method may substitute for or combine with one or more operations of the method.

[0102] The foregoing method descriptions and process flowcharts are provided as illustrative examples only and are not intended to require or imply that the operations of the various embodiments must be performed in the given order. As those skilled in the art will recognize, the operations in the foregoing embodiments can be performed in any order. Words such as “afterward,” “then,” “next,” etc., are not intended to restrict the order of operations; these words are only used to guide the reader through the description of the method. Furthermore, any reference to singular claim elements (e.g., references using the articles “a,” “an,” or “the”) should not be construed as limiting that element to the singular.

[0103] The various exemplary logic blocks, modules, circuits, and algorithmic operations described in conjunction with the implementation scheme can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various exemplary components, blocks, modules, circuits, and operations have been generally described above according to their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. While those skilled in the art may implement the described functionality in different ways for each specific application, such implementation decisions should not be construed as departing from the scope of the claims.

[0104] Hardware for implementing the various exemplary logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed by a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic unit, discrete hardware component, or any combination thereof, designed to perform the functions described herein. While the general-purpose processor may be a microprocessor, in alternative embodiments, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry specific to (i.e., configured to perform) a given function.

[0105] In one or more embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, these functions may be stored as one or more instructions or code on a non-transitory computer-readable medium or a non-transitory processor-readable medium. The operation of the methods or algorithms disclosed herein may be embodied in a processor-executable software module that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. By way of example and not limitation, such non-transitory computer-readable or processor-readable media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and is accessible by a computer. As used herein, disks and optical discs include compact optical discs (CDs), laser discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operation of a method or algorithm may reside as a single line of code and / or instruction, or any combination or set of code and / or instructions, on a non-transitory processor-readable medium and / or computer-readable medium that may be incorporated into a computer program product.

[0106] The above description of the disclosed embodiments is provided to enable any person skilled in the art to implement or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments without departing from the scope of the claims. Therefore, this disclosure is not intended to be limited to the embodiments shown herein, but should be granted the broadest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. A method for managing the operation of a write accelerator buffer in a flash memory device, the method comprising: The host controller is notified that the flushing of the write accelerator buffer has been terminated; Send context information to the host controller describing one or more data structures that have been successfully refreshed; as well as Restore the refresh of the write accelerator buffer.

2. The method of claim 1, wherein the one or more data structures are multiple levels, addresses or blocks written into an accelerator buffer memory, and are indicated as refreshed or not refreshed by multiple refresh points corresponding to the multiple levels, addresses or blocks.

3. The method according to claim 1, wherein: Sending the context information includes sending the refresh completion position indicating the last successful refresh point in the refresh of the write accelerator buffer; as well as Resuming the refresh includes resuming the refresh from the refresh completion position provided in the context information.

4. The method according to claim 1, further comprising: Receive a context read command from the host controller; as well as In response to receiving the context read command, the context information is sent to the host controller.

5. The method according to claim 1, further comprising: Receive refresh recovery command from the host controller; as well as The refresh of the write accelerator buffer is resumed in response to receiving the refresh recovery command.

6. The method according to claim 1, further comprising: Receive partial unmapping commands from the host controller to unmap one or more data structures that have been successfully refreshed.

7. The method of claim 6, wherein the partial unmapping command allocates the one or more data structures that have been successfully refreshed to free memory.

8. A flash memory storage device, the flash memory storage device comprising: Multiple logical units of memory; Write to the accelerator buffer; and A device controller, coupled to the plurality of logic cells of the memory and the write accelerator buffer, wherein the device controller is configured to: The host controller is notified that the flushing of the write accelerator buffer has been terminated; Send context information to the host controller describing one or more data structures that have been successfully refreshed; and Restore the refresh of the write accelerator buffer.

9. The flash memory storage device of claim 8, wherein the one or more data structures are multiple levels, addresses, or blocks written into an accelerator buffer memory, and are indicated as refreshed or not refreshed by multiple refresh points corresponding to the multiple levels, addresses, or blocks.

10. The flash memory storage device of claim 8, wherein the device controller is further configured to: Sending context information, the context information including the refresh completion position indicating the last successful refresh point in the refresh of the write accelerator buffer; and The refresh of the write accelerator buffer is resumed from the refresh completion position provided in the context information.

11. The flash memory storage device of claim 8, wherein the device controller is further configured to: Receive a context read command from the host controller; and In response to receiving the context read command, the context information is sent to the host controller.

12. The flash memory storage device of claim 8, wherein the device controller is further configured to: Receive refresh recovery command from the host controller; and The refresh of the write accelerator buffer is resumed in response to receiving the refresh recovery command.

13. The flash memory storage device of claim 8, wherein the device controller is further configured to: Receive partial unmapping commands from the host controller to unmap one or more data structures that have been successfully refreshed.

14. The flash memory storage device of claim 13, wherein the partial unmapping command allocates the one or more data structures that have been successfully refreshed to free memory.

15. A flash memory storage device, the flash memory storage device comprising the following components: A component used to notify the host controller that the flushing of the accelerator buffer has been terminated; A component for sending context information to the host controller describing one or more data structures that have been successfully refreshed; and A component used to restore the refresh of the write accelerator buffer.

16. The flash memory storage device of claim 15, wherein the one or more data structures are multiple levels, addresses, or blocks written into an accelerator buffer memory, and are indicated as refreshed or not refreshed by multiple refresh points corresponding to the multiple levels, addresses, or blocks.

17. The flash memory storage device of claim 15, wherein the component for transmitting the context information includes a component for transmitting a refresh completion position indicating the last successful refresh point in the refresh of the write accelerator buffer, and The component used to resume the refresh starts from the refresh completion position provided in the context information.

18. The flash memory storage device of claim 15, further comprising: Components used to receive context read commands from the host controller; and A component for sending the context information to the host controller in response to receiving the context read command.

19. The flash memory storage device of claim 15, further comprising: Components for receiving refresh recovery commands from the host controller; and A component for resuming the refresh of the write accelerator buffer in response to receiving the refresh recovery command.

20. The flash memory storage device of claim 15, further comprising: A component for receiving partial unmapping commands from the host controller to unmap one or more data structures that have been successfully refreshed.

21. The flash memory storage device of claim 20, wherein the partial unmapping command allocates the one or more data structures that have been successfully refreshed to free memory.

22. A non-transitory processor-readable medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a device controller of a flash memory storage device to perform an operation, the operation comprising: The host controller is notified that the flushing of the write accelerator buffer has been terminated; Send context information to the host controller describing one or more data structures that have been successfully refreshed; as well as Restore the refresh of the write accelerator buffer.

23. The non-transitory processor-readable medium of claim 22, wherein the one or more data structures are multiple levels, addresses, or blocks written into an accelerator buffer memory, and are indicated as refreshed or not refreshed by multiple refresh points corresponding to the multiple levels, addresses, or blocks.

24. The non-transitory processor-readable medium of claim 22, wherein the stored processor-executable instructions are further configured to cause the device controller of the flash memory storage device to perform an operation such that: Sending the context information includes sending the refresh completion position indicating the last successful refresh point in the refresh of the write accelerator buffer; and Resuming the refresh includes resuming the refresh from the refresh completion position provided in the context information.

25. The non-transitory processor-readable medium of claim 22, wherein the stored processor-executable instructions are configured to cause the device controller to perform an operation, the operation further comprising: Receive a context read command from the host controller; as well as In response to receiving the context read command, the context information is sent to the host controller.

26. The non-transitory processor-readable medium of claim 22, wherein the stored processor-executable instructions are configured to cause the device controller to perform an operation, the operation further comprising: Receive refresh recovery command from the host controller; as well as The refresh of the write accelerator buffer is resumed in response to receiving the refresh recovery command.

27. The non-transitory processor-readable medium of claim 22, wherein the stored processor-executable instructions are configured to cause the device controller to perform an operation, the operation further comprising: Receive partial unmapping commands from the host controller to unmap one or more data structures that have been successfully refreshed.

28. The non-transitory processor-readable medium of claim 22, wherein the partial unmapping command allocates the one or more data structures that have been successfully refreshed to free memory.

Images