Patent Application
20240411481
Developers and users of computing devices are always seeking improved operation performance and endurance. The lifetime of NAND flash memories may be physically limited to a certain number of write cycles. In some applications, such as buffers and cache memory elements, quick cycling of data temporarily stored in such memory elements can quickly deteriorate the lifetime of the entire device.
Various aspects may further include methods performed by a universal flash storage (UFS) system of a computing device for writing data to a flash storage device including a plurality of logical units of memory. Various aspects may include receiving, by the flash storage device, a command identifying a logical unit among the plurality of logical units to store data and data for storage in the identified logical unit, obtaining information indicating a memory write type for the identified logical unit, and writing the data to either a shared write booster buffer before writing to the identified logical unit of device storage of the identified logical unit or directly to the identified logical unit of device storage of based on the obtained memory write type.
Some aspects may further include storing in a memory table of the flash storage device a value indicating the memory write type for each of the plurality of logical units, in which obtaining information indicating the memory write type for the identified logical unit may include obtaining, from the memory table, the value indicating the memory write type corresponding to the identified logical unit. In some aspects, storing in the memory table of the flash storage device a value indicating the memory write type for each of the plurality of logical units may include provisioning the memory table at boot of the flash storage device. Some aspects may further include receiving by the flash storage device a command that changes the value indicating the memory write type corresponding to one or more of the plurality of logical units.
In some aspects, obtaining information indicating the memory write type for the identified logical unit may include obtaining the information indicating the memory write type from the command identifying the logical unit to store the data. In some aspects, the information in the command indicating the memory write type may include a bit in a command Universal Flash Storage (UFS) Protocol Information Unit (UPIU) in which the bit indicates that subsequent data should be written to the shared write booster buffer before writing to the identified logical unit of device storage identified in the command UPIU or written directly to the identified logical unit of device storage identified in the command UPIU.
Further aspects include a UFS system including a UFS device controller and a host controller configured to perform operations of any of the methods summarized above. Further aspects include a computing device including means for performing functions of any of the methods summarized above. Further aspects include a UFS device controller and a host controller for use in a computing device, the UFS device controller and the host controller each including a processor configured to perform operations of any of the methods summarized above.
The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary embodiments of the claims, and together with the general description given and the detailed description, serve to explain the features herein.
Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.
Various embodiments include methods and computing devices for implementing the methods for optimizing the usage and write cycles of a write boost buffer of a flash storage device. Various embodiments may include methods performed by a universal flash storage (UFS) system of a computing device including receiving, by the flash storage device, a command identifying a logical unit among the plurality of logical units to store data and data for storage in the identified logical unit, obtaining information indicating a memory write type for the identified logical unit, and then writing the data to either a shared boost buffer before writing to the identified logical unit of device storage or directly to the identified logical unit of device storage based on the obtained memory write type.
Some embodiments may include storing in a memory table of the flash storage device a value indicating the memory write type for each of the plurality of logical units, in which embodiments the memory write type may be obtained from the memory table. Some embodiments may include receiving by the flash storage device a command that changes the value indicating the memory write type corresponding to one or more of the plurality of logical units.
Some embodiments may include obtaining the memory write type from a command, which is received from a host controller of the computing device, identifying the logical unit in which to store data. In some embodiments the command may be a Universal Flash Storage (UFS) Protocol Information Unit (UPIU), and the information in the UPIU indicating the memory write type may be in the form of a bit or similar value.
More generally, a UFS device may operate as a storage module with a plurality of logical units (LU) and may include a write buffer to increase the speed of data writes to the device (e.g., before placement in normal storage). A majority of the storage volumes may be triple level cell (TLC) NAND memory elements, while some memory, including the write buffer, may be single layer cell (SLC) NAND memory elements.
In SLC NAND memory elements, each memory cell stores only one bit of data, representing either a ‘0’ or a ‘1’. Due to the simplicity of storing a single bit per cell, SLC memory has several advantages, including faster write and read speeds, higher endurance, and lower error rates.
In TLC NAND memory elements, each memory cell stores three bits of data, resulting in eight possible voltage levels. While this increases the storage density, it also introduces a few trade-offs compared to SLC memory, including slower write and read speeds, lower endurance, and higher error rates.
The normal storage of the flash device may be TLC NAND and the flash device (e.g., UFS device) may include a write buffer of SLC NAND memory elements that temporarily stores received data before transferring the data to normal storage in the TLC NAND memory. Repeated cycling of all incoming data through the write boost buffer may deteriorate the endurance of the NAND cells faster than is necessary. This may occur when the UFS device is configured to always write all data to the write booster buffer (e.g., flag fWriteBoosterEn is enabled) with all logical units sharing the write boost buffer, which may occur when the bWriteBoosterBufferType is configured as 01h-shared type. If all data received at the flash storage device is first stored in the write booster buffer, then the write booster buffer may have a much shorter lifetime than the normal storage which ultimately receives the data written to the flash storage.
However, in many operating conditions supporting many applications, not all data from a host device needs to be written so quickly as to require the use of the write booster buffer. For example, longer-term storage (e.g., digital photographs from a camera) may not operationally place much value in quickly storing the data (e.g., low latency). In contrast, video applications, for example, may need data write operations to be accelerated via the write booster buffer so that local storage or cache does not fill up from the sequence of image frame data.
Depending on the application running on the computing device, the host controller may have information identifying a latency requirement or a priority of data associated with a write operation of the application. Without control over what data uses the write booster buffer, the write booster buffer may not be optimized to focus on this priority data. As a result, lower priority data and data with no urgency or latency requirements may fill up the write booster buffer, thus interfering with or delaying storage of higher priority data with stringent latency requirements.
Various embodiments address and overcome the foregoing problems of inefficiently using the write booster buffer in a FLASH memory device and wasting the limited write cycles of its lifetime on low priority write commands by enabling the UFS device to obtain and act on commands from the host that manage use of the write booster buffer in order to more effectively use the write cycles of the write booster buffer. Various embodiments enable a UFS device to obtain information or receive commands from a host controller that indicate whether the write booster buffer should be used for one or more subsequent data transmissions. This enables a host controller to control a UFS device to write data to memory via a write booster buffer or directly to one or more logical units of memory in normal storage.
The host controller may transmit a command containing instructions that indicate one or more logical units of memory to be allowed to use the write booster buffer. In some embodiments, the host controller may configure a memory table stored on the UFS device that indicates the logical units that use the write booster buffer. A UFS device controller may then access the memory table to obtain information containing a write type for incoming data directed to each logical unit. In some embodiments, the host controller may transmit a command (e.g., a UPIU) containing instructions that indicate one or more subsequent data transmissions to write to the write booster buffer or to normal memory based on one or more set values. Based on this information, the device controller of the UFS device may send certain data to the write booster buffer and may direct other data to bypass the write booster buffer and be written directly in normal memory (e.g., TLC NAND) storage of the identified logical unit.
The term “system-on-a-chip” (SoC) is used herein to refer to a single integrated circuit (IC) chip that contains 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.), memory blocks (e.g., ROM, RAM, Flash, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). SoCs may also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices. The host controller may form a portion of the SoC and the UFS device may form a portion of the SoC.
The term “system-in-a-package” (SIP) may be used herein to refer to a single module or package that contains multiple resources, computational units, cores and/or processors on two or more IC chips, substrates, or SoCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, the SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unifying substrate. A 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 in a single computing device. The proximity of the SoCs facilitates high speed communications and the sharing of memory and resources.
As used herein, the term “processing system” is used herein to refer to one or more processors, including multi-core processors, that are organized and configured to perform various computing functions. Various embodiment methods may be implemented in one or more of multiple processors within a UFS memory device or host memory controller as described herein. The term “UFS” or Universal Flash Storage and the term “flash storage device” are interchangeable herein.
The UFS device 106 may include a device controller 116, a static random access memory (SRAM) 110, a write booster buffer (e.g., SLC NAND memory) 118, and a normal storage (e.g., TLC NAND memory) 112. The device controller 116 may include one or more processors, which may be configured as a processing system configured to implement operations of various embodiments. The device controller 116 may be connected to the SRAM 110 and the normal storage 112, such that the device controller 116 may select different memory locations for storage and control flows of information to memory (e.g., 110, 112, 118). The write booster buffer 118 may be connected to the device controller 116 and the normal storage 112, such that the write booster buffer buffers data written from the host controller 104 via the device controller 116 to the normal storage 112. In addition, the normal storage 112 may be connected to the device controller 116 independent from the write booster buffer 118 to directly store data written from the host controller 104 when the device controller 116 has been instructed (or is configured) to bypass the write booster buffer 118.
The host controller 104 may implement write transactions to the UFS device 106. The write transactions may include the host controller 104 issuing write commands from other components of the SoC 102 and/or from components communicably connected to the SoC 102 (e.g., via I/O of the SoC) to the device controller 116. The write transactions may also include data out UFS protocol information units (UPIUs) transferring the write data from the host controller 104 to the device controller 116.
The device controller 116 receiving the write commands and data out UPIUs from the host controller 104 may write the data of the data out UPIUs to the write booster buffer 118. The device controller 116 may manage the write booster buffer 118 storing the data, including controlling flushing the data from the write booster buffer 118 to the normal storage 112. The device controller 116 may implement flushing the data from the write booster buffer 118 to the normal storage 112 periodically, episodically, etc. The device controller 116 may maintain a memory mapping table at the UFS device 106 with addresses at the normal storage 112 and write booster buffer 118. The memory table may include parameters and controls for different portions of normal storage 112, such as a logical unit number (LUN) for each of a plurality of logical units of memory.
In some embodiments, the device controller 116 may be configured to update a write type register that corresponds to each LUN of the normal storage 112. The write type register may operate as an enable flag for each of the LUNs via an 8-bit value sequence that identifies the write type status of each LUN. The write type may be to enable shared memory (e.g., write to the write booster buffer 118) or to disable shared memory and write directly to normal storage 112. This write type register may be set during provisioning to a default setting (e.g., LUNs 1-8 are enabled for shared write booster). This write type register may be updated in the memory table by a UPIU command that designates one or more LUNs and one or more write type statuses for each of them (or collectively).
In some embodiments, the device controller 116 may be configured to update a write type register that corresponds to a series of incoming data packets directed to a LUN. The device controller 116 may receive a UPIU command that includes an expected length of the subsequent transfer to which the write type update applies. After the expected transfer corresponding to that command is complete, the device controller may revert back to a default write type (e.g., disabled shared write to write booster) for that LUN. The device controller 116 may record that data directed to a LUN is set at a specific write type (e.g., shared enabled/disabled) until another UPIU command updates the write type for that LUN. Based on these commands and defaults, the device controller 116 may decide to write the received data from the host controller 104 to respective memory elements, such as SLC or TLC memory elements.
The host controller 104 may implement read transactions at the UFS device 106. Read transactions may include the host controller 104 issuing read requests from other components of the SoC 102 and/or from components communicably connected to the SoC 102 (e.g., via I/O of the SoC) to the device controller 116. Read transactions may also include data in UPIUs transferring the read addresses from the host controller 104 to the device controller 116. The read addresses may be physical addresses corresponding to logical addresses received by the host controller 104 from the other components of the SoC 102 and/or from components communicably connected to the SoC 102. Read transactions may be subsequent to write transactions and may read the data out of the normal storage 112. As illustrated, the host controller 104 may transmit commands (including read commands) and data to the UFS device 106 over link 114 and the UFS device 106 may transmit a response which acknowledges receipt and/or requests the next transmission.
As illustrated, data flows from the host controller 104 may be directed to the write booster buffer 118 first for quicker throughput to the UFS device 106 or these data flows may be directed to bypass the write booster buffer 118 and directly save the data in the normal storage 112. Eventually data in the write booster buffer 118 is flushed by the device controller 116 to the appropriate LUN as shown. After a write of data is completed to the write booster buffer 118 or normal storage 112, the device controller 116 may transmit a response to the host controller 104. As described with respect to
In some embodiments, the device controller 116 may store a memory table that contains parameters and configurations corresponding to each of the LUNs (e.g., 202, 204, 206, 208, 210, 212, 214). The device controller 116 may signal via a write booster buffer support flag that it is capable of bypassing the write booster buffer 118 on a per LUN basis. The host controller 104 may read this write booster buffer support flag to determine how to configure the UPIU commands and ensure that the write commands are supported. The host controller 104 may command the device controller 116 to configure a memory table to enable shared write booster buffer access for LUNs 202, 204, 206, 208, and 210 (e.g., set a write type variable in the memory table for one or more LUNs). Subsequent write commands and data transmissions to these LUNs of the UFS device 106 may then be written to the write booster buffer 118. A data transmission to LUN 212 or LUN 214 may be written to normal storage 112 and may bypass the write booster buffer 118.
In some embodiments, the device controller 116 may manage usage of the write booster buffer 118 based on a flag or value provided in the UPIU write command. Based on the UPIU write command and a write type provided therein, the device controller 116 may store subsequent data in the write booster buffer 118 or directly in normal storage 112. The subsequent data may be designated by the write command and/or may be data destined for a particular LUN which was assigned a particular write type based on the command. In other words, the write type indicated in the UPIU command beginning a data transfer may enable or disable write booster buffer usage on a per write command basis or on a per LUN basis, or a combination.
With reference to
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 co-processor) connected to one or more of the 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 interconnection/bus module 326, one or more sensors 330 (e.g., accelerometer, temperature sensor, pressure sensor, optical sensor, infrared sensor, analog sound sensor, 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 interconnection/bus module 364, a BT controller 356, memory 358, and various additional processors 360, such as an applications processor, packet processor, etc.
Each processor 310, 312, 314, 316, 318, 352, 360 may include one or more cores, and each processor/core may perform operations independent of the other processors/cores. For example, the first SoC 302 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., MICROSOFT WINDOWS 10). In addition, any or all of the processors 310, 312, 314, 316, 318, 352, 360 may be included as part of a processor cluster architecture (e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).
The first and second SoC 302, 304 may include various system components, resources, and custom circuitry for managing sensor data, analog-to-digital conversions, wireless data transmissions, and for performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for rendering in a web browser or audio/video application. 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 used to support the processors and software clients running on a computing device. The system components and resources 324 and/or custom circuitry 322 may also include circuitry to interface with peripheral devices, such as cameras, electronic displays, wireless communication devices, external memory chips, etc.
The first and second SoC 302, 304 may communicate via interconnection/bus module 350. In some embodiments, the interconnection/bus module 350 may be a connection established by transceiving (i.e., receiving and transmitting) components within both the 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 multiple signal messages (MSM) UART driver that is communicatively connected to the UART of the low power processor 352.
The various processors 310, 312, 314, 316, and 318, may be interconnected to one or more memory elements 320, system components and resources 324, and custom circuitry 322, and a thermal management unit 332 via an interconnection/bus module 326. Similarly, the low power processor 352 may be interconnected to the power management unit 354, the BT controller 356, memory 358, and various additional processors 360 via the interconnection/bus module 364. The interconnection/bus module 326, 350, 364 may include an array of reconfigurable logic gates and/or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications may be provided by advanced interconnects, such as high-performance networks-on chip (NoCs).
In various embodiments, any or all of the processors 310, 312, 314, 316, and 318 in the system may operate as the SoC's main processor, central processing unit (CPU), microprocessor unit (MPU), arithmetic logic unit (ALU), etc. One or more of the coprocessors 318 may operate as the CPU. In addition to the example SIP 100 discussed above, various embodiments may be implemented in a wide variety of computing systems, including a single processor, multiple processors, multicore processors, or any combination thereof.
The first and/or second SoCs 302, 304 may further include an input/output module (not illustrated) for communicating with resources external to the SoC, such as a clock 306, a 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). Resources external to the SoC (e.g., clock 306, voltage regulator 308) may be shared by two or more of the internal SoC processors/cores. The at least one SIM 368 (or one or more SIM cards coupled to one or more SIM interfaces) may store information supporting multiple subscriptions, including a first 5GNR subscription and a second 5GNR subscription, etc.
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, multicore processors, or any combination thereof.
In some embodiments, the various processors of the SoC 302 and SoC 304 may be located within the same SoC. For example, the application processor 316 and low power processor 352 may be located within a same SoC, such as in a single SoC of a wearable device, to perform optimized storage routines with the UFS device 372.
The FLASH memory device 402 may include electronic storage 420 (e.g., normal storage 112) that may be configured to store information as instructed by the processors 422 via machine-readable instructions 406. The electronic storage 420 may include FLASH-type non-transitory storage media (e.g., read-only memory) that electronically stores information.
The electronic storage 420 may store software algorithms, information determined by processor(s) 422 of a processing system, and/or other information that enables the FLASH memory device 402 to function as described herein.
The FLASH memory device processor(s) 422 may be configured by machine-readable instructions 406. Machine-readable instructions 406 may include one or more instruction modules. The instruction modules may include computer program modules. The instruction modules may include one or more of a write booster buffer module 430, a LUN manager module 432, a write booster enable module 436, a memory table provisioning module 438, and other instruction modules (not illustrated). The FLASH memory device 402 may include one or more processor(s) 422 of a processing system configured to implement the machine-readable instructions 406 and corresponding modules.
In some embodiments, the processor(s) 422 executing the write booster buffer module 430 may be configured to manage and optimize usage of the write booster buffer 118. For example, the write booster buffer module 430 may be configured to control implementing a flush of contents of a write booster buffer 118 (e.g., SLC NAND memory) of the UFS device 402 to a normal storage in the electronic storage 420 (e.g., normal storage 112, TLC NAND memory) of the UFS device. The flush may be implemented periodically, episodically, etc. For example, the flush may be implemented one or more times per read transaction, such as per data out UPIU received at the UFS device. As another example, the flush may be implemented at reaching a capacity threshold for the write booster buffer.
In some embodiments, the processor(s) 422 executing the write booster buffer module 430 may be configured to store one or more memory tables to manage the electronic storage 420 (e.g., write booster buffer 118). These memory tables may map addresses between shared memory and normal storage 112 (e.g., to manage flushing operations). The memory tables may also configure data directed to one or more normal storage addresses (e.g., LUNs) to be directed directly to the normal storage 112, 420 and may bypass the write booster buffer 118. The processor(s) 422 executing the write booster buffer module 430 may be configured to assess on its own based on priority information associated with the incoming data to be written whether to store the data in shared memory (e.g., the buffer) or bypass the shared memory and store in normal storage 112 (e.g., for low priority). The processor(s) 422 executing the write booster buffer module 430 may be configured to transmit a response to a host device 418 (e.g., host controller 104) when a data transmission or portion thereof has been received and stored on the write booster buffer 118.
In some embodiments, the processor(s) 422 executing the LUN manager module 432 may record and monitor storage on LUNs which have been designated as direct write such that data bypasses the write booster buffer 118. In other words, the LUN manager module 432 may provide an acknowledgement to the device controller 116 that data has been fully written and may report its physical or logical address. Likewise, the LUN manager module 432 may acknowledge transfer of data that has been flushed from the write booster buffer 118 so that the device controller can properly record the updated data location (e.g., physical or logical address). The acknowledgements may include response UPIUs to write transactions from the host device 418.
In some embodiments, the processor(s) 422 executing the write booster enable module 436 may be configured to monitor for changes to the write type of one or more LUNs. The write booster enable module 436 may include one or more conditional paths that are configured based on the write type status of the LUNs so that the appropriate data transmissions are directed to the write booster buffer 118 and normal storage 112, 420. The write booster enable module 436 may adjust the routing of data based on a write type or a shared memory enable flag that has been received at the FLASH memory device 402 from the host device 418.
In some embodiments, the processor(s) 422 executing the memory table provisioning module 438 may be configured to execute upon a start-up signal or at power ON of the FLASH memory device 402. Upon boot the processors 422 may execute instructions to assign default values to a memory table that is used to manage the write processes of the write booster buffer 118 as described with respect to the write booster buffer module 430 and the LUN manager 432. For example, the default values assigned may set a write booster buffer type as a shared type or other type and may set a write booster enable flag to enabled or disabled. The provisioning of the memory table may be determined by extensible markup up language (XML) information that is stored for this purpose (e.g., in electronic storage 420).
The description of the functionality provided by the different modules 430-438 is for illustrative purposes, and is not intended to be limiting, as any of modules 430-438 may provide more or less functionality than is described. For example, one or more of modules 430-438 may be eliminated, and some or all of its functionality may be provided by other ones of modules 430-438. As another example, processor(s) 422 may execute one or more additional modules that may perform some or all of the functionality attributed below to one of modules 430-438.
In some embodiments, the write booster buffer module 430, the LUN manager module 432, the write booster enable module 436, and the memory table provisioning module 438 may be implemented by a UFS device controller executing in the processor(s) 422 (e.g., device controller 116) of the FLASH memory device 402, which may be and/or may include processor 422.
The host controller 104 may send a write UPIU command to be implemented at the UFS device in operation 502. The device controller 116 may respond to receiving the write command with a ready to transfer signal in operation 504. The host controller 104 may send one or more data-out UPIUs, including data and/or addresses at a write booster buffer (e.g., write booster buffer 118, SLC NAND memory) in operation 506 or data and addresses at one or more LUNs (e.g., normal storage 120). In some examples, the host controller 104 may update an address mapping table at the host device to associate logical addresses for the data of the write command with physical addresses of the write booster buffer or one or more LUNs at which to store the data.
The device controller 116 may set one or more shared memory enable flags for one or more LUNs in operation 508 based on the received UPIU write command from operation 502. In some examples, the UPIU write command from operation 502 may include a change to a memory table of the device controller 116 that provides routing for data received at the device controller 116 (e.g., data out 506). The write command may designate one or more LUNs for the subsequent data-out operations and may command the device controller 116 to enable or disable shared memory (e.g., write booster buffer 118) for one or more LUNs. This write command may be processed by the device controller 116 by updating a memory table as described with respect to
In some embodiments, the host controller 104 may send a write command UPIU to be implemented at the UFS device in operation 512. The device controller 116 may respond to receiving the write command with a ready to transfer signal in operation 516. The host controller 104 may send one or more data-out UPIUs in operation 518, including data and/or addresses at a write booster buffer (e.g., write booster buffer 118, SLC NAND memory) or data and addresses at one or more LUNs (e.g., normal storage 120). In some examples, the device controller 116 may set one or more write type variables or fields corresponding to one or more LUNs in operation 514 based on information in the write command 512. Subsequent write command UPIUs may similarly change this write type variable based on the priority or latency requirement of the data associated with the write command. The write type of a LUN may thereby be adapted to the incoming data so as to optimize usage of the write booster buffer 118.
When the host device needs to access the data stored by these write commands, the host controller 104 may send the read command UPIUs with physical addresses or logical addresses for data at the normal storage 112. The device controller 116 may retrieve the read data using the physical addresses or logical addresses at the normal storage 112 from the read request and return the read data to the host controller 104.
In block 602, a UFS device controller of a flash storage device may receive a command identifying a logical unit among the plurality of logical units in which to store data and the data for storage in the identified logical unit (e.g., LUN). The write command may be received by the UFS device controller from a host device (e.g., SoC 102, 302, host controller 104, 418). In some embodiments, receiving the command may include receiving the information in the command indicating the memory write type. For example, the command may comprise a bit in a command Universal Flash Storage (UFS) Protocol Information Unit (UPIU) in which the bit of one value indicates that subsequent data should be written to a shared write booster buffer before writing to device storage of the logical unit identified in the command UPIU or written directly to device storage of the identified logical unit identified in the command UPIU. In some embodiments, receiving the command may include changing a shared memory enable flag in a memory table for one or more LUNs identified in the command.
In block 604, the UFS device controller of the flash storage device may obtain information indicating a memory write type for the identified logical unit. In some embodiments, obtaining the information indicating the memory write type may involve or include obtaining the changed shared memory enable flag in a memory table for one or more LUNs identified in the command. In some embodiments, obtaining the information may include obtaining information indicating the memory write type for the identified logical unit comprises obtaining, from the memory table, the value indicating the memory write type corresponding to the identified logical unit. In some embodiments, obtaining the information indicating the memory write type may include obtaining the information from the command identifying the logical unit to store the data.
In block 606, the UFS device controller of the flash storage device may write the data to either a shared write booster buffer before writing to device storage of the identified logical unit or directly to device storage of the identified logical unit based on the obtained memory write type to which the data is written to process write commands. For example, if a command (or a value obtained from the memory table) indicates that the shared write booster buffer is enabled for a LUN, then data destined for the LUN may be written to the shared write booster buffer before being flushed to the device storage of the LUN (e.g., LUN 202 of
In some embodiments, the method 700 may be implemented in parallel (or together) with the method 600 described with reference to
In block 702, the method 700 may continue from block 602 of
In some embodiments, the method 710 may be implemented in parallel (or together) with the method 600 described with reference to
In block 712, the method 710 may continue from block 602 of
Various embodiments (including, but not limited to, embodiments described with reference to
The computing device 900 may also include a peripheral memory access device such as a floppy disc drive, compact disc (CD) or digital video disc (DVD) drive 906 coupled to the processor 901. The computing device 800 may also include network access ports 904 (or interfaces) coupled to the processor 901 for establishing data connections with a network, such as the Internet and/or a local area network coupled to other system computers and servers.
The computing device 900 may include one or more antennas 907 for sending and receiving electromagnetic radiation that may be connected to a wireless communication link. The computing device 900 may include additional access ports, such as USB, Firewire, Thunderbolt, and the like for coupling to peripherals, external memory, or other devices.
The computing device 1000 may include an antenna 1004 for sending and receiving electromagnetic radiation that may be connected to a wireless transceiver 366 coupled to one or more processors in the first and/or second SoCs 302, 304. The computing device 1000 may also include menu selection buttons or rocker switches 1020 for receiving user inputs.
The computing device 1000 also includes a sound encoding/decoding (CODEC) circuit 1010, which digitizes sound received from a microphone into data packets suitable for wireless transmission and decodes received sound data packets to generate analog signals that are provided to the speaker to generate sound. Also, one or more of the processors in the first and second SoCs 302, 304, wireless transceiver 366 and CODEC 1010 may include a digital signal processor (DSP) circuit (not shown separately).
The processors of the computer 800, the computing device 900, and the computing device 1000 may be any programmable microprocessor, microcomputer or multiple-processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described below. In some mobile devices, multiple processors may be provided, such as one processor within an SoC 304 dedicated to wireless communication functions and one processor within an SoC 302 dedicated to running other applications. Software applications may be stored in memory 320, 1016 before they are accessed and loaded into the processor. The processors may include internal memory sufficient to store the application software instructions.
Implementation examples are described in the following paragraphs. While some of the following implementation examples are described in terms of example methods that may be performed in a computing device by a host controller, further example implementations may include: a computing device including a UFS device controller and a host controller configured to perform the methods of the following implementation examples; a computing device including means for performing functions of the following implementation examples, a UFS device controller and a host controller suitable for use in a computing device, in which the UFS device controller and the host controller each includes a processor configured to perform the methods of the following implementation examples; and a non-transitory, processor-readable memory having stored thereon processor-executable instructions configured to cause a UFS device controller and a host controller in a computing device configured to perform the methods of the following implementation examples.
Example 1. A method for writing data to a flash storage device including a plurality of logical units of memory, including: receiving, by the flash storage device, a command identifying a logical unit among the plurality of logical units to store data and data for storage in the identified logical unit; obtaining information indicating a memory write type for the identified logical unit; and writing the data to either a shared write booster buffer before writing to the identified logical unit of device storage or directly to the identified logical unit of device storage based on the obtained memory write type.
Example 2. The method of example 1, wherein writing the data either to a shared write booster buffer before writing to the identified logical unit of device storage or directly to the identified logical unit of device storage based on the obtained memory write type includes: writing the data to the shared write booster buffer before writing to the identified logical unit of device storage, if the obtained memory write type indicates write booster buffer usage is enabled for the identified logical unit; and writing the data to the identified logical unit of device storage by bypassing the shared write booster buffer, if the obtained memory write type indicates write booster buffer usage is disabled for the identified logical unit.
Example 3. The method of any of the examples 1-2, further including: storing in a memory table of the flash storage device a value indicating the memory write type for each of the plurality of logical units, wherein obtaining information indicating the memory write type for the identified logical unit comprises obtaining, from the memory table, the value indicating the memory write type corresponding to the identified logical unit.
Example 4. The method of any of the examples 1-3, further including: wherein storing in the memory table of the flash storage device a value indicating the memory write type for each of the plurality of logical units comprises provisioning the memory table at boot of the flash storage device.
Example 5. The method of any of the examples 1-4, further including receiving by the flash storage device a command that changes the value indicating the memory write type corresponding to one or more of the plurality of logical units.
Example 6. The method of any of the examples 1-5, wherein obtaining information indicating the memory write type for the identified logical unit includes obtaining the information indicating the memory write type from the command identifying the logical unit to store the data.
Example 7. The method of any of the examples 1-6, wherein the information in the command indicating the memory write type includes a bit in a command Universal Flash Storage (UFS) Protocol Information Unit (UPIU) in which the bit indicates that subsequent data should be written to the shared write booster buffer before writing to the identified logical unit of device storage or written directly to the identified logical unit of device storage.
As used in this application, the terms “component,” “module,” “system,” and the like are intended to include a computer-related entity, such as, but not limited to, hardware, firmware, a combination of hardware and software, software, or software in execution, which are configured to perform particular operations or functions. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, 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 may be referred to as a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one processor or core and/or distributed between two or more processors or cores. In addition, these components may execute from various non-transitory computer readable media having various instructions and/or data structures stored thereon. Components may communicate by way of local and/or remote processes, function or procedure calls, electronic signals, data packets, memory read/writes, and other known network, computer, processor, and/or process related communication methodologies.
Various embodiments illustrated and described are provided merely as examples to illustrate various features of the claims. However, 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 that are shown and described. Further, the claims are not intended to be limited by any one example embodiment. For example, one or more of the operations of the methods may be substituted for or combined with one or more operations of the methods.
The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of operations in the foregoing embodiments may be performed in any order. Words such as “thereafter,” “then,” “next,” etc. are not intended to limit the order of the operations; these words are simply used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles “a,” “an” or “the” is not to be construed as limiting the element to the singular.
The various illustrative logical blocks, modules, circuits, and algorithm operations described in connection with the embodiments may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.
The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.
In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable medium or non-transitory processor-readable medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module, which may reside on a non-transitory computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor. By way of example but not limitation, such non-transitory computer-readable or processor-readable media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage 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 that may be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product.
The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.
The present application claims the benefit of priority to U.S. Provisional Application No. 63/506,372, entitled “Universal Flash Storage Write Boost Buffer Enhancements” filed Jun. 6, 2023, the entire contents of which are hereby incorporated by reference for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 63506372 | Jun 2023 | US |
