Methods for copying and moving data on memory devices including write acceleration buffers

Abstract

Various aspects include methods related to moving and copying data on a UFS device. These aspects may include the storage device: receiving a move or copy command from a host device for data stored in a write acceleration buffer on the storage device; updating an address table stored on the storage device with an indicator of the destination address in the main memory of the storage device in response to the move or copy command; and flushing the data from the write acceleration buffer to the main memory based on the updated address table.

Description

Background Technology

[0001] Developers and users of computing devices constantly seek improved operational performance and durability. The lifespan of NAND flash memory can be physically limited by the maximum number of write cycles. In some applications, such as buffer and cache memory elements, rapid cycling of data temporarily stored in these memory elements can quickly shorten the overall lifespan of the device. In host-managed memory devices, the bandwidth between the host and the memory device is limited, and sending data back to the host device for copy or move operations on the memory device can waste bandwidth and reduce the lifespan of the NAND storage device. Summary of the Invention

[0002] Various aspects may include methods performed by a memory device, such as a general-purpose flash memory (UFS) device, for copying and moving data on a UFS memory device including a write acceleration buffer without sending the data back to a host device. Various aspects may include the memory device: receiving from a host device a move command or a copy command for data stored in the write acceleration buffer; updating an address table stored on the memory device in response to the move command or the copy command with an indicator of the destination address in the memory device's main memory; and flushing the data from the write acceleration buffer to the main memory based on the updated address table. In some aspects, the address table and a logical-to-physical (L2P) mapping table stored on the memory device may be stored separately. In some aspects, the operations performed in response to the copy command or the move command are performed without sending the data to the host device.

[0003] In some respects, updating the address table in response to receiving a copy command may also include setting an indicator of the duplicate block of the physical address in main memory as the destination of the data.

[0004] In some aspects, updating the address table in response to receiving a move command may further include: setting an indicator of a duplicate block of physical address in main memory as the destination of the data; and resetting an indicator of the original block of physical address.

[0005] In some respects, the address table may include a byte indicator corresponding to each physical address, wherein the byte indicator may indicate one or more logical units as the destination of the data at each physical address in the main memory.

[0006] Some aspects may also include providing the host device with copy and move flag indicators to instruct the memory device to bypass the host device when implementing copy and move commands.

[0007] Another aspect includes a memory device system (such as a UFS) including a memory device controller configured to perform operations of any of the methods outlined above. Another aspect includes a memory device (such as a UFS) including components for performing functions of any of the methods outlined above. Another aspect includes a memory device controller for use in a computing device, the memory device controller including a processor configured to perform operations 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 memory system suitable for implementing any of the various implementation schemes.

[0010] Figure 2 This is a system block diagram illustrating an example 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 suitable for implementing any of the various implementation schemes.

[0012] Figure 4 This is a system block diagram of an example memory system applicable to any implementation of various implementation schemes.

[0013] Figure 5 This is a time flow diagram of example methods for copy and move operations based on some implementation schemes.

[0014] Figure 6 This is a process diagram of an example method for copy and move operations based on some implementation schemes.

[0015] Figure 7A It is a message format table for copying commands based on some implementation schemes.

[0016] Figure 7B It is a message format table for example mobile commands based on 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 embodiments include methods for copying and moving data on a memory device including a write acceleration buffer, and memory devices implementing such methods. Various embodiments may include: a memory device controller within the memory device receiving from a host device a move command or a copy command for data stored in the write acceleration buffer; the memory device controller, in response to the move command or the copy command, updating an address table stored on the memory device with an indicator of a destination address in the memory device's main memory; and the memory device controller flushing the data from the write acceleration buffer to the main memory based on the updated address table.

[0022] Some implementations may include the memory device controller providing copy and move flag indicators to the host device to instruct the memory device to bypass the host device when implementing copy and move commands. Some implementations may include the memory device controller, in response to receiving a move command, performing the following actions: updating the address table by setting an indicator of a duplicate block of physical addresses in main memory as the destination of the data and resetting an indicator of the original block of physical addresses. Some implementations may include the memory device controller, in response to receiving a copy command, performing the following actions: updating the address table by setting an indicator of a duplicate block of physical addresses in main memory as the destination of the data. In various implementations, the operations performed in response to the copy command or the move command are performed without sending the data to the host device.

[0023] The proposed method for handling data storage and movement on a memory device with a shared write acceleration buffer may include: receiving commands from a host device; updating an address table with destination information; and flushing data to main memory based on the updated address table. The address table and a logical-to-physical mapping table may be stored separately, and the address table may include byte indicators for each physical address, indicating one or more logical units as destinations. The address table may include byte indicators corresponding to each physical address, indicating one or more logical units as destinations for data at each physical address in main memory. Additionally, a copy and move flag may be provided to the host device by the memory device controller to instruct the memory device to bypass the host device when executing copy and move commands (i.e., not to transfer data to or receive data from the host device).

[0024] The memory device controller can use an address table to manage data storage and movement on the memory device, enabling bypassing the host device during move and copy operations. The address table provides local placeholders for updating destination information of data being transferred within the memory device (e.g., between a write acceleration buffer and regular storage). Moving and copying data within the memory device without exporting data to the host device saves bandwidth on the host-to-device interface. Similarly, moving and copying data within the memory device reduces the total number of writes to the write acceleration buffer, extending the component's lifespan.

[0025] Conventional storage devices for flash memory can be three-level cell (TLC) NAND, and memory devices (e.g., UFS devices) can include write acceleration buffers composed of single-level cell (SLC) NAND memory elements that temporarily store received data before transferring it to conventional storage within the TLC NAND memory. If internal move and copy commands are not enabled, repeated cycles of all incoming data through the write acceleration buffer can cause NAND cells to age faster than required. This can occur when copying or moving data already stored on a UFS device, or when the UFS device must transfer data out to a host device. With increased cycles, the write acceleration buffer may have a much shorter lifespan than the conventional storage device that ultimately receives the data written to the flash memory.

[0026] In some systems, an example of data copying via an additional loop in the write accelerator buffer involves copying data already stored in the write accelerator buffer and intended for storage at logical unit number (LUN) #1 in the regular memory device, to an additional destination on LUN #2 of the regular memory device. Typically, this type of memory copying operation might require a read command and response from the host device, followed by a write command with the data and response to place the data in the additional LUN #2. This process is clearly inefficient, but necessary because current memory systems only have read and write commands available for moving data from one memory address or LUN to another.

[0027] Various implementations address and overcome the problem of inefficient use of write acceleration buffers when copying or moving data within memory devices such as flash memory and UFS devices by reducing write cycles through direct data copying and move operations. This is achieved by the memory device controller performing the following operations: receiving a move or copy command from the host device for data stored in the write acceleration buffer; updating an address table stored on the memory device with an indicator of the destination address in the memory device's main memory in response to the move or copy command; and flushing the data from the write acceleration buffer to main memory based on the updated address table. Various implementations enable UFS devices to execute the move and copy commands as described herein. This allows the UFS device controller device to internally rearrange data without transferring the data back to the host device.

[0028] The move command updates the address table using LUN destination indicators for data that will be written to main memory upon refresh, while simultaneously resetting the original LUN destination indicator for the same data. The address table maps the physical address of data to LUN destination indicators. This allows the memory device to efficiently handle multiple requests to move data from one location to another without redundant reads or writes. By setting the LUN destination indicator and resetting the original LUN destination indicator, this method ensures that data is transferred to its intended destination only once, reducing unnecessary I / O operations and improving overall performance. This approach also helps reduce power consumption by avoiding redundant data transfers and minimizing the use of write acceleration buffers.

[0029] The copy command updates the address table using an additional LUN destination indicator for the data to be written to main memory during the flush write accelerator buffer. This allows the memory device to efficiently handle multiple requests to copy data from one location to another without redundant reads or writes of data or passing the data through the host device. By setting a repeating LUN destination indicator, this method ensures that data is transferred in a single fast process during flushing. This method also helps reduce power consumption by avoiding redundant data transfers and minimizing the use of the write accelerator buffer. To implement this copy command, the memory device's device controller and / or write accelerator buffer can be configured to flush data to multiple locations in conventional TLC NAND memory.

[0030] 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.

[0031] 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.

[0032] 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 computing functions.

[0033] Various implementation methods may be implemented in a memory device controller (also referred to herein as a “device controller”), which may include one or more processors within a memory device, such as a UFS memory device. The terms “UFS,” “universal flash memory device,” and “flash memory” are used interchangeably herein to refer to a memory device configured to store data in NAND memory.

[0034] Figure 1 This is a system block diagram illustrating an example system suitable for implementing any of the various implementation schemes. System 100 may include one or more computing devices or processors connected to UFS device 106 for storage. For example, system 100 may include a SoC 102 containing 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. Streams of commands, data, and responses illustrated between SoC 102 and UFS device 106 may be carried or transmitted via data / command link 114. Host controller 104 may include a processor (not shown separately) configured to perform the operations of a host controller as described herein. Host controller 104 may maintain and access DRAM 108 or SRAM (not shown) and / or data stored in host controller 104. The SRAM of host controller 104 may be part of SoC 102.

[0035] UFS device 106 may include device controller 116, static random access memory (SRAM) 110, write acceleration buffer (e.g., SLC NAND memory) 118, and 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 implementation schemes. Device controller 116 may be connected to SRAM 110 and conventional storage device 112, allowing device controller 116 to select different memory locations for storage and control the flow of information to the memories (e.g., 110, 112, 118). Write acceleration buffer 118 may be connected to device controller 116 and conventional storage device 112, allowing write acceleration buffer to buffer data written from host controller 104 to conventional storage device 112 via device controller 116. Alternatively, conventional storage device 112 can be connected to device controller 116 independently of write acceleration buffer 118 to directly store data written from host controller 104 when device controller 116 has been instructed (or configured) to bypass write acceleration buffer 118.

[0036] Host controller 104 enables write transactions to UFS device 106. These 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). Write transactions may also include transferring write data from host controller 104 to device controller 116 via data output UFS Protocol Information Units (UPIUs). Data from write transactions may initially be stored in write acceleration buffer 118 and then flushed to conventional storage device 112 according to commands. Conventional storage device 112 may be divided into multiple Logical Unit Numbers (LUNs), which may be two, five, seven, eight, or more.

[0037] Device controller 116, receiving write commands and data output UPIUs from host controller 104, can write data from the data output UPIUs to write acceleration buffer 118. Device controller 116 can manage write acceleration buffer 118, including controlling the flushing of data from write acceleration buffer 118 to conventional storage device 112. Device controller 116 can periodically, occasionally, or in response to commands from host controller 104 to flush data from write acceleration buffer 118 to conventional storage device 112. Device controller 116 can maintain a memory mapping table at UFS device 106, which records addresses at conventional storage device 112 and write acceleration buffer 118. The memory table can include parameters and controls for different portions of conventional storage device 112, such as LUNs for each of the multiple logical cells in the memory. UFS device 106 can maintain destination tables for data stored at physical addresses in write acceleration buffer 118, which map the physical addresses of data to one or more destination LUNs. These destination tables can control data flow when flushing data to conventional storage device 112. The memory table and destination table can be stored on SRAM 110.

[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 also include transferring data from host controller 104 to the UPIU of device controller 116 with a read address. 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 data may be read from conventional storage device 112. As illustrated, host controller 104 may send commands (including read 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. As described above, immediate implementations of UFS device 106 may include copy commands and move commands in addition to read and write commands. Copy and move commands can also be issued by host controller 104 and executed within UFS device 106 without looping data through link 114.

[0039] Figure 2 This is a system block diagram illustrating an example memory system 200 suitable for implementing any of the various implementation schemes. Reference Figure 1 and Figure 2 The illustrated example UFS device 106 includes a device controller 116, which may include a processing system, a write acceleration buffer 118, and a conventional storage device 112. The conventional storage device 112 may include multiple logical unit numbers (LUNs), which may correspond to logical address blocks of NAND memory. Logical unit numbers are typically used to identify logical storage partitions within a UFS device or system. LUNs may be individually addressable by the host controller 104. The device controller 116 may be connected to the write acceleration buffer 118 and may include one or more processors in the processing system configured to transmit commands and requests to the write acceleration buffer 118. Figure 2 The arrows illustrated show the data flow between host controller 104 and LUN and device controller 116 during the execution of an example copy or move command. Generally, device controller 116 may, according to commands and as defined by the copy destination table and move destination table, command write to acceleration buffer 118 to flush data to regular memory 112, or execute other control commands as described in the UFS 4.0 specification or its updates.

[0040] As illustrated, a data stream from host controller 104 can be directed to device controller 116 and then further directed to the shared write acceleration buffer 118 of UFS device 106, or these data streams can be directed to bypass write acceleration buffer 118 and directly store the data in conventional storage device 112. Finally, the data in write acceleration buffer 118 is flushed to the appropriate LUN by device controller 116, as shown. After completing the writing of data to write acceleration buffer 118 or conventional storage device 112, device controller 116 can send a response to host controller 104. (As shown relative to...) Figure 1 As described, host controller 104 can send data to one or more LUNs and can designate one or more LUNs (e.g., 202, 204, 206, 214) as the destination for data transmission. The LUN address can be an 8-bit variable, allowing individual addressing of up to thirty-two LUNs. Destination LUNs can be stored in a destination table, two examples of which are provided below. Figure 2 Examples of copying and moving tables are shown in the text.

[0041] In some implementations, device controller 116 may store a memory table containing parameters and configurations corresponding to each LUN (e.g., LU0, LU1, etc.). Device controller 116 may signal via a move / copy support flag that it can bypass host controller 104 when moving or copying data within the UFS device. Host controller 104 may read the move / copy support flag to determine how to configure UFS Protocol Information Unit (UPIU) commands and ensure that move / copy commands are supported. The move / copy support flag may be an 8-bit persistent flag (register) read by host controller 104 at startup. Host controller 104 may command device controller 116 to modify one or more destination tables as part of a move or copy command, as illustrated by the shaded arrows from the device controller to the copy table.

[0042] As illustrated, for a copy command, the copy table is modified such that, in addition to the original destination of LU0 in the illustrated copy table, LU1 is also designated as the destination for data at a physical block address (PBA). Then, when host controller 104 refreshes data from the shared write acceleration buffer (WBB) 118, the data at the logical block address (LBA) in the table is refreshed to the logical unit (LU) specified in the destination table (e.g., the COPY table). Similarly, for a move command, device controller 116 may receive a move command from host controller 104 with a new destination for the data to be stored (e.g., where the LUN is individually addressable). The new destination for the data (e.g., a new LUN) may be stored in the destination table (e.g., the move table) as a change to the target LU (e.g., LU0 is set to "No" and LU1 is set to "Yes"). Therefore, when the shared WBB 118 is refreshed, the data stored in the listed PBAs is refreshed to the logical unit (LU) assigned "Yes" (i.e., LU1).

[0043] The use of "yes / no" in this document is merely an example notation and could also be a binary flag, where (1) designates a LUN as a destination. Accordingly, the destination table (such as a move table or a copy table) can be implemented in a single column with one or more bytes used as a Logical Unit Access Register (LAR), where each LU is assigned a single bit. In this way, eight logical units (LUs) indexed from 0 to 7 can be represented by a single byte (00000011) as whether they are destinations. When refreshed by the host controller 104, the data in each physical block address (PBA) is refreshed to the general memory 112 based on the LAR bit sequence.

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

[0045] refer to Figures 1 to 3The illustrated example computing device 300 (which may be a system-in-package in some embodiments) includes two SoCs 302 and 304 (e.g., SoC 102) 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 via an antenna (not shown) to and from a wireless computing device (such as a base station, wireless device, and / or computing device (e.g., system 100)). 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.

[0046] 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 processors (e.g., 312, 314, 316), memory 320, 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 Bluetooth controller 356, memory 358, and various additional processors 360, such as application processors, packet processors, etc.

[0047] 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 running a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor running a second type of operating system (e.g., MICROSOFT WINDOWS 10). Furthermore, any one or all of the 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.).

[0048] 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.

[0049] The first SoC 302 and the second SoC 304 may communicate via an interconnect / bus module 350. In some embodiments, the interconnect / bus module 350 may be a connection established through transceiver (i.e., receive and transmit) 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.

[0050] 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, Bluetooth 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).

[0051] In various implementations, any one 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 SIP 100 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.

[0052] 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 accepting 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. In addition to the example computing device 300 discussed above, various embodiments may 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 embodiments, 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.

[0053] Figure 4 This is a component block diagram illustrating an example system 400 configured for enhanced move and copy operations according to some implementation schemes. References Figures 1 to 4System 400 may include a flash memory device 402 and a host device 418, which 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 components, software components, and / or firmware components that operate together to provide the functionality attributed herein to processor 422 (e.g., UFS device controller 116). Flash memory device 402 may include a write acceleration buffer 118 (e.g., SLC NAND memory) that receives and temporarily stores (i.e., buffers) data to be written to and stored in electronic storage device 420, as described herein.

[0054] Flash memory device 402 may include electronic storage device 420 (e.g., conventional storage device 112) 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 media (e.g., read-only memory) that electronically stores information. 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.

[0055] The flash memory device processor 422 may 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 acceleration buffer module 430, a LUN manager module 432, a write acceleration refresh module 436, a memory table module 438, and other instruction modules (not illustrated). The flash memory device 402 may include one or more processors 422 of a processing system configured to implement the machine-readable instructions 406 and corresponding modules.

[0056] In some implementations, the processor 422 executing the write acceleration buffer module 430 may be configured to manage and optimize the use of the write acceleration buffer 118. For example, the write acceleration buffer module 430 may be configured to control the organization of the contents of the write acceleration buffer 118 (e.g., SLC NAND memory) of the UFS device 402. In some implementations, the processor 422 executing the write acceleration buffer module 430 may be configured to store one or more memory tables to manage the electronic storage device 420. These memory tables may map addresses between shared memory (WBB 118) and conventional storage device 112. The processor 422 executing the write acceleration buffer module 430 may be configured to evaluate the priority of incoming information based on priority information associated with the incoming data. The processor 422 executing the write acceleration buffer module 430 may be configured to send a response to the host device 418 (e.g., host controller 104) when data is transmitted or a portion thereof has been received and stored on the write acceleration buffer 118.

[0057] In some implementations, the processor 422 executing the LUN manager module 432 can monitor and manage data storage on the LUN of the general memory 112. In other words, the LUN manager module 432 can provide the device controller 116 with confirmation that data has been fully written and can report its physical or logical address on the LUN. Similarly, the LUN manager module 432 can confirm the transfer of data that has been flushed from the write acceleration buffer 118, enabling the device controller to correctly record the updated data location (e.g., physical or logical address). Confirmation may include a response UPIU transmitted to the host device 418 in response to a write transaction from the host device 418.

[0058] In some implementations, the processor 422 executing the write-accelerated refresh module 436 may be configured to refresh data stored in the write-accelerated buffer 118. The write-accelerated refresh module 436 may be configured to execute a refresh command received from the host device 418 and read the destination table of the data on the write-accelerated buffer 118 to refresh the data to the appropriate LUN. The write-accelerated refresh module 436 may include one or more conditional paths (per physical address) configured based on a Logical Cell Access Register (LAR) (e.g., 01101001) such that appropriate data transmissions are directed to the appropriate LUNs of the conventional storage devices 112, 420. The write-accelerated refresh module 436 may update the destination table and other memory tables (e.g., L2P tables) after refreshing data from the write-accelerated buffer 118. Refreshing may be implemented periodically, occasionally, etc. For example, refreshing may be implemented once or more for each read transaction, such as each data output UPIU received at a UFS device. As another example, refreshing may be implemented when a capacity threshold of the write-accelerated buffer 118 is reached.

[0059] In some implementations, the processor 422 executing the memory table module 438 may be configured to manage and edit memory tables corresponding to memory on a UFS device (e.g., flash memory device 402). For example, in response to a move command from the host device 418, the memory table module 438 may be configured to record different LUNs as destinations for data written to the acceleration buffer 118 via changes to indicators in the destination table. The memory table module 438 may manage separate tables for move and copy commands (such as move tables and copy tables), or the memory table module 438 may manage a single destination table for data stored on the write acceleration buffer 118 (e.g., mapping physical addresses to LARs). The memory table module 438 may be configured to manage and edit other memory tables, including logical-to-physical (L2P) tables for translating logical memory addresses from the host device 418.

[0060] 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 the modules 430 to 438 may provide more or less functionality than described. For example, one or more of the modules 430 to 438 may be eliminated, and some or all of their functionality may be provided by other 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 attributed to one of the modules 430 to 438. In some embodiments, write acceleration buffer module 430, LUN manager module 432, write acceleration refresh module 436, and memory table module 438 may be implemented by a UFS device controller that executes in a processor 422 (e.g., device controller 116) of a flash memory device 402, which may be and / or may include processor 422.

[0061] Figure 5 This is a time flow diagram of example methods for copy and move operations based on some implementation schemes. (Reference) Figures 1 to 5 ,exist Figure 5 The various operations are illustrated sequentially, while... Figure 2 These operations are illustrated as a system flow. In operation 502, host controller 104 may transmit a move command or copy command to device controller 116 of UFS device 106, wherein the move command or copy command is associated with specific data (e.g., a file) or a specific address range. In operation 504, device controller 116 may update the corresponding portion of the destination table for the data stored in write acceleration buffer 118. Then, host controller 104 may issue a refresh command, and in operation 506, the refresh command continues to be sent from device controller 116 to write acceleration buffer 118. After write acceleration buffer 118 has been refreshed according to the destination table with data allocated to destination LUNs, device controller 116 may send a response message to host controller 104 in operation 508 to update its status and changes.

[0062] In operation 512, host controller 104 may transmit a copy command or a move command to device controller 116. In this case, the data adjusted by the move command or copy command from host controller 104 has been flushed to conventional storage device 112 and thus recorded in the L2P table or other memory table on device controller 116. The move command or copy command may include a source address and a destination address. In this case, in operation 514, device controller 116 adjusts the mapping of the source physical address and logical address and updates the L2P table on UFS device 106 accordingly. Once the move or copy operation is complete, device controller 116 may respond to host controller in operation 516 with acknowledgments and information related to any changes made.

[0063] Figure 6 This is a process diagram illustrating example methods for copy and move operations based on some implementation schemes. (Reference) Figures 1 to 6 Method 600 may be implemented in a device controller (e.g., 116) of a UFS device (e.g., 106), in hardware (e.g., device controller 116, flash memory device 402), in software executing in a processor (e.g., device controller 116, processor 422), or in a combination of a software-configured processor and dedicated hardware including other separate components. Components for performing the functions of method 600 may include a processor (e.g., device controller 116, processor 422) coupled to a memory (e.g., write acceleration buffer 118, electronic storage device 420, memory 320, conventional memory 112, SRAM 110). To cover alternative configurations implemented in various embodiments, the hardware implementing method 600 is referred to herein as a "processor".

[0064] In block 602, the processor can perform operations including receiving move commands or copy commands from a host controller (e.g., 104, 418) for data stored on a write acceleration buffer. The nature of these move commands and copy commands is... Figure 7A and Figure 7B The following example illustrates this. For instance, the host controller can move a file from one logical unit number (LUN) to another by sending the corresponding source and destination addresses. Similarly, the host controller can copy a file from one logical unit number (LUN) to another by sending the corresponding source and destination addresses. If the file being moved or copied is stored on the write acceleration buffer 118, the move or copy can be recorded in the destination table so that the move or copy can be performed as part of the next flush operation.

[0065] In block 604, the processor may perform operations including updating an address table stored on the memory device with an indicator of the destination address in the main memory of the memory device in response to a move command or copy command. For example, as Figure 2 As shown, copying data stored on WBB 118 from LU0 to LU1 is recorded as updating the bit flags of each row in the destination table corresponding to the physical address of the data to be copied. In some embodiments, the address table and the logic-to-physical (L2P) mapping table are stored separately. In some embodiments, updating the address table in response to receiving a copy command further includes setting the indicator of the duplicate block of the physical address in main memory as the destination of the data. In some embodiments, updating the address table in response to receiving a move command may further include: setting the indicator of the duplicate block of the physical address in main memory as the destination of the data; and then resetting the indicator of the original block of the physical address. In some embodiments, the address table may include a byte indicator corresponding to each physical address. In some embodiments, the byte indicator may indicate one or more logical units as the destination of the data at each physical address (e.g., the byte indicator is associated with each LUN in the LUN).

[0066] In block 606, the processor may perform operations including flushing data from the write acceleration buffer to main memory based on an updated address table. For example, based on a previous copy command, the address table may have been updated to record two LUNs or two address blocks as destination addresses, and then a flush of the write acceleration buffer to the destination addresses (e.g., LU1 and LU2) is performed. In some embodiments, the processor may perform operations in response to a copy or move command without sending data to the host device. In other words, by implementing copy and move commands, the device controller may be configured to bypass the host controller 104 when performing data movement or copying and perform data adjustments entirely internally.

[0067] Figure 7A This is a sample copy command message format table 700 based on some implementation schemes. As illustrated, a copy command can be formatted to cover ten bytes with various fields. Importantly, the copy command can include source and destination addresses, which can be logical block addresses or physical block addresses. Other fields included in the copy command may include the least significant bit (LSB), the most significant bit (MSB), the transfer length corresponding to the data to be transferred, and control and operation codes. Copy commands can be implemented as UPIU commands in the UFS specification along with write and read commands.

[0068] Figure 7BThis is a sample move command message format table 710 based on some implementation schemes. As illustrated, a move command can be formatted to cover ten bytes with various fields. Importantly, the move command can include source and destination addresses, which can be logical block addresses or physical block addresses. Other fields included in the move command may include the least significant bit (LSB), the most significant bit (MSB), the transfer length corresponding to the data to be transferred, and control and operation codes. Move commands can be implemented as UPIU commands in the UFS specification along with write and read commands.

[0069] 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 8 The 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.

[0070] 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).

[0071] 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.

[0072] 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.

[0073] Figure 10 This is a component block diagram of a computing device 1000 suitable for use with various implementation schemes. (Reference) Figures 1 to 10 Various 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.

[0074] 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.

[0075] 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).

[0076] 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.

[0077] 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.

[0078] Example 1. A method for copying and moving data on a memory device including a write acceleration buffer, the method comprising: receiving from a host device a move command or a copy command for data stored in the write acceleration buffer; updating an address table stored on the memory device in response to the move command or the copy command with an indicator of a destination address in the main memory of the memory device; and flushing the data from the write acceleration buffer to the main memory based on the updated address table.

[0079] Example 2. The method according to claim 1, wherein the address table and the logical-to-physical (L2P) mapping table stored on the memory device are stored separately.

[0080] Example 3. The method of claim 1, wherein updating the address table in response to receiving a copy command further includes setting an indicator of a duplicate block of physical address in the main memory as the destination of the data.

[0081] Example 4. The method according to claim 1, wherein updating the address table in response to receiving a move command further includes: setting an indicator of a duplicate block of physical address in the main memory as the destination of the data; and resetting an indicator of the original block of physical address.

[0082] Example 5. The method of claim 1, wherein the address table includes a byte indicator corresponding to each physical address, wherein the byte indicator indicates one or more logical units as the destination of the data at each physical address in the main memory.

[0083] Example 6. The method of claim 1, further comprising providing the host device with copy and move flag indicators to instruct the memory device to bypass the host device when implementing copy and move commands.

[0084] Example 7. The method of claim 1, wherein the operation performed in response to the copy command or the move command is performed without sending the data to the host device.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] The hardware used to implement the various exemplary logic units, logic blocks, modules, and circuits described in conjunction with these embodiments 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 a given function.

[0090] In one or more embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, such functionality 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, 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 magnetically reproduce data, while optical discs optically reproduce data 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.

[0091] 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 copying and moving data on a memory device including a write acceleration buffer, the method comprising: Receive move or copy commands for data stored in the write acceleration buffer from the host device; In response to the move command or the copy command, the address table stored on the memory device is updated with an indicator of the destination address in the main memory of the memory device; as well as Based on the updated address table, the data is flushed from the write acceleration buffer to the main memory.

2. The method of claim 1, wherein the address table and the logical-to-physical (L2P) mapping table stored on the memory device are stored separately.

3. The method of claim 1, wherein updating the address table in response to receiving a copy command further comprises setting an indicator of a repeating block of physical addresses in the main memory as the destination of the data.

4. The method of claim 1, wherein updating the address table in response to receiving a move command further comprises: Set the indicator of the repeating block of the physical address in the main memory as the destination of the data; as well as Indicator for resetting the original block at the physical address.

5. The method of claim 1, wherein the address table includes a byte indicator corresponding to each physical address, wherein the byte indicator indicates one or more logical units as the destination of the data at each physical address in the main memory.

6. The method of claim 1, further comprising providing the host device with copy and move flag indicators to instruct the memory device to bypass the host device when executing copy and move commands.

7. The method of claim 1, wherein the operation performed in response to the copy command or the move command is performed without sending the data to the host device.

8. A memory device, the memory device comprising: Main memory; Static random access memory; Write to the acceleration buffer; and A device controller, coupled to the main memory, the static random access memory, and the write acceleration buffer, and configured to receive move commands and copy commands from the host device, wherein the device controller is configured to: Receive from the host device a move command or copy command for the data stored in the write acceleration buffer; In response to the move command or the copy command, the address table stored on the memory device is updated with an indicator of the destination address in the main memory; as well as Based on the updated address table, the data is flushed from the write acceleration buffer to the main memory.

9. The memory device of claim 8, wherein the device controller is further configured to store the address table separately from a logical-to-physical (L2P) mapping table stored on the memory device.

10. The memory device of claim 8, wherein the device controller is configured to update the address table in response to receiving a copy command by setting an indicator of a duplicate block of physical address in the main memory as the destination of the data.

11. The memory device of claim 8, wherein the device controller is configured to update the address table in response to receiving a move command by: Set the indicator of the repeating block of physical address in the main memory as the destination of the data; and Indicator for resetting the original block at the physical address.

12. The memory device of claim 8, wherein the address table includes a byte indicator corresponding to each physical address, wherein the byte indicator indicates one or more logical units as the destination of the data at each physical address in the main memory.

13. The memory device of claim 8, wherein the device controller is further configured to provide the host device with copy and move flag indicators to instruct the memory device to bypass the host device when executing copy and move commands.

14. The memory device of claim 8, wherein the device controller is further configured to perform an operation in response to the copy command or the move command without sending the data to the host device.

15. A memory device, the memory device comprising: Main memory; Write to the acceleration buffer; A component for receiving from the host device a move command or copy command for data stored in the write acceleration buffer; A component for updating an address table stored on the memory device with an indicator of the destination address in the main memory in response to the move command or the copy command; and A component for flushing data from the write acceleration buffer to the main memory based on the updated address table without sending the data to the host device.

16. The memory device of claim 15, wherein the address table and the logical-to-physical (L2P) mapping table stored on the memory device are stored separately.

17. The memory device of claim 15, wherein the component for updating the address table in response to receiving a copy command further includes a component for setting an indicator of a repeating block of physical addresses in the main memory as the destination of the data.

18. The memory device of claim 15, wherein the component for updating the address table in response to receiving a move command further comprises: A component for setting an indicator of a repeating block of physical address in the main memory as the destination of the data; and A component used to reset the original block of physical address.

19. The memory device of claim 15, wherein the address table includes a byte indicator corresponding to each physical address, wherein the byte indicator indicates one or more logical units as the destination of the data at each physical address in the main memory.

20. The memory device of claim 15, further comprising means for providing copy and move flag indicators to the host device to instruct the memory device to bypass the host device when executing copy and move commands.

Images