Buffer management in flash memory

Abstract

The invention relates to a buffer management control device for a flash memory controller. The buffer management control device comprises a flag table and a flag management engine. The flag table is used for tracking availability states of a plurality of configuration units in a shared memory of the flash memory controller. The flag management engine is configured to allocate one or more configuration units from the plurality of configuration units to cache read data associated with a host read command, and update the flag table according to the allocated one or more configuration units to indicate that the allocated one or more configuration units are occupied.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to flash memory, and more particularly, to a hardware-based buffer management control device and related methods, memory controllers, and data storage devices. BACKGROUND

[0002] Flash memory has become an indispensable element in modern computer systems, offering numerous advantages over traditional storage solutions. Its non-volatility, high-speed data access, low power consumption, and compact form factor make it the preferred choice for a wide range of applications, from consumer electronics to enterprise-level storage systems. The performance and efficiency of a flash memory system are greatly influenced by the architecture of the flash memory controller and the algorithms it executes. As an intermediary between the host device and the flash memory chip, the flash memory controller manages complex operations such as data read / write, wear-leveling, garbage collection, and error correction. The effectiveness of these operations directly impacts overall system performance, reliability, and the lifespan of the flash memory.

[0003] Traditionally, flash memory controllers rely on firmware-based algorithms executed by a single-core or multi-core central processor to manage the allocation and release of internal storage space. This approach requires the flash memory controller to maintain complex data structures and perform time-consuming searches to determine the availability of storage units.

[0004] This approach has several drawbacks: 1) computational overhead: the central processor within the flash memory controller must dedicate significant processing time to storage management tasks, potentially impacting other critical operations; 2) latency: searching for available storage units can cause read / write operation delays, especially as storage capacity increases; 3) scalability challenges: as flash memory capacity grows, the complexity of managing larger address spaces becomes more pronounced, potentially leading to performance bottlenecks. SUMMARY

[0005] In view of the above, one of the objectives of the present disclosure is to provide a hardware-based buffer management control architecture that utilizes dedicated hardware within a flash memory controller to perform buffer management tasks. Specifically, the present disclosure introduces a flag management mechanism implemented in hardware that works in conjunction with firmware executed by a central processor within the flash memory controller. By utilizing dedicated hardware to implement buffer management and track the availability status of storage units, the task can be effectively offloaded from the central processor within the flash memory controller, allowing the central processor to focus on other critical operations, thereby improving overall system performance. Furthermore, the hardware-based buffer management control architecture maintains storage unit status through a compact representation, such as using a high-speed, low-latency bitmap or bit vector in dedicated memory, enabling fast status checking and updating. Compared to software solutions, the present disclosure can reduce buffer management latency by an order of magnitude and significantly reduce read and write operation latency. Moreover, the hardware-based buffer management control architecture is capable of quickly identifying available storage units and reporting this information back to firmware, greatly reducing the time required for space allocation decisions. As a result, the central processor within the flash memory controller can simultaneously handle complex tasks, such as garbage collection, wear leveling algorithms, and advanced error correction, to improve system efficiency and overall throughput.

[0006] Embodiments of the present disclosure provide a buffer management control device for a flash memory controller, the buffer management control device comprising a flag table and a flag management engine. The flag table is configured to track availability status of a plurality of configuration units in a shared memory of the flash memory controller. The flag management engine is configured to allocate one or more configuration units from the plurality of configuration units to buffer read data associated with a host read command, and update the flag table according to the allocated one or more configuration units to indicate that the allocated one or more configuration units are occupied.

[0007] Embodiments of the present disclosure provide a buffer management control method for a flash memory controller, the method comprising tracking availability status of a plurality of configuration units in a shared memory of the flash memory controller using a flag table; and allocating one or more configuration units from the plurality of configuration units to buffer read data associated with a host read command using a flag management engine, and updating the flag table according to the allocated one or more configuration units to indicate that the allocated one or more configuration units are occupied. BRIEF DESCRIPTION OF DRAWINGS

[0008] Figure 1 Architectural diagram of an electronic device and data storage device according to embodiments of the present disclosure.

[0009] Figure 2 Buffer management control architecture according to embodiments of the present disclosure.

[0010] Figure 3 Architecture diagram of the buffer management control device of the embodiment of the present application.

[0011] Figure 4 Diagram of the index-based allocation mechanism of the embodiment of the present application.

[0012] Figure 5 Flowchart of the buffer management control method of the embodiment of the present application.

[0013]

Symbol explanation

[0014] 10 electronic device

[0015] 50 host device

[0016] 52 processor

[0017] 54 random access memory

[0018] 100 data storage device

[0019] 110 memory controller

[0020] 112 processing unit

[0021] 112M read-only memory

[0022] 112C program code

[0023] 113 internal memory

[0024] 118 transmission interface circuit

[0025] 120 NV memory

[0026] 121 page buffer

[0027] 122_1~122_NV memory elements

[0028] 123 control circuit

[0029] 130 ECC processing circuit

[0030] 140 front-end control circuit

[0031] 150 flash memory control circuit

[0032] 180 buffer management control device

[0033] 181 flag update buffer

[0034] 182 flag update engine

[0035] 183 flag table

[0036] 184 flag management engine DETAILED DESCRIPTION

[0037] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the application. However, it will be understood by those skilled in the art that the present application can be practiced without these specific details. In other instances, well-known methods, procedures, components and materials have not been described in detail so as not to unnecessarily obscure aspects of the present application.

[0038] Reference throughout this specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. Thus, appearances of the phrase "in one embodiment" in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the described particular features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0039] Figure 1 is a schematic diagram of an electronic device and a data storage device according to an embodiment of the application. As shown, the electronic device 10 includes a host device 50 and a data storage device 100. The host device 50 can include at least one processor 52 for controlling operations of the host device 50, and a random access memory 54 for storing data and information required by the processor 52. Examples of the host device 50 can include, but are not limited to, a smart phone, a tablet computer, a wearable device, a personal computer (e.g., a desktop computer or a laptop computer), an imaging device (e.g., a digital camera or a camcorder), a game console, a car navigation system, a printer, a scanner, or a server system. Examples of the data storage device 100 can include, but are not limited to, a portable memory device (e.g., a memory card conforming to SD / MMC, CF, MS, XD, or UFS specifications), a solid-state drive (SSD), and various embedded storage devices (e.g., an embedded storage device conforming to UFS or eMMC specifications).

[0040] In various embodiments, the data storage device 100 may include a controller (e.g., a memory controller 110) and may further include non-volatile (NV) memory 120. NV memory 120 is used to store data and information. NV memory 120 may include one or more NV memory elements, such as multiple NV memory elements 122_1 to 122_N. For example, NV memory 120 may be flash memory, and NV memory elements 122_1 to 122_N may be multiple flash memory chips or multiple flash memory dies, but the invention is not limited thereto. Furthermore, NV memory 120 may include memory cells with a two-dimensional structure or a three-dimensional structure.

[0041] like Figure 1 As shown, the memory controller 110 may include a processing unit 112, a read-only memory (ROM) 112M, internal memory 113, a transmission interface circuit 118, an error correction code (ECC) processing circuit 130, a front-end control circuit 140, a flash control circuit 150, and a buffer control management device 180. At least some of these circuits and components may be coupled to each other via buses. The internal memory 113 may be implemented by one or more memory devices. For example, the internal memory 113 may include static random access memory (SRAM) and / or dynamic random access memory (DRAM). The internal memory 113 may be used to provide internal storage space for the memory controller 110, such as temporarily storing information like data, addresses, commands, mapping information, variables, and / or parameters. In some embodiments, the memory controller 110 may not include internal memory 113. Conversely, the memory controller 110 may rely on host memory buffer (HMB) technology. Through HMB technology, the memory controller 110 may utilize the host device 50's memory 54 (e.g., DRAM) as all, part, or an extension of the internal memory 113, thereby improving the read and write performance of the data storage device 100.

[0042] In addition, the ROM 112M in the present embodiment is used to store program code 112C, and the processor 112 is used to execute the program code 112C to control access to the NV memory 120. The program code 112C can include one or more program modules, such as a boot loader code. When the data storage device 100 obtains power from the host device 50, the processing unit 112 can execute the initialization process of the data storage device 100 by executing the program code 112C. During the initialization process, the microprocessor 112 can load a set of in-system programming (ISP) code (not shown in the figure) from the NV memory 120. The microprocessor 112 can execute the ISP code to enable the data storage device 100 to perform various functions. According to one embodiment of the present application, the ISP code set can include, but is not limited to, one or more program modules related to memory access (e.g., read, write, and erase), such as a read operation module, a lookup table module, a wear-leveling module, a read refresh module, a read reclaim module, and a garbage collection module, a sudden power-off recovery (SPOR) module, which are used to perform corresponding read, lookup table query, wear-leveling, read refresh, read reclaim, garbage collection, sudden power-off recovery, and other operations. Figure 1

[0043] ​The memory controller 110 controls reading, writing, and erasing of the NV memory 120 through the flash memory control circuit 150. In addition, the memory controller 110 can simultaneously perform data writing based on a host command from the host device 50 and writing of valid data read from the NV memory 120 through a garbage collection and / or wear leveling operation. The transmission interface circuit 118 can comply with a specific communication specification, such as a Universal Serial Bus (USB) specification, a Secure Digital (SD) interface, an Ultra High Speed-I (UHS-I) interface, an Ultra High Speed-II, a CompactFlash (CF) interface, a Multimedia card (MMC) interface, an Embedded Multimedia card (eMMC) specification, an Advanced Technology Attachment (ATA), a Serial Advanced Technology Attachment (SATA), a Parallel Advanced Technology Attachment (PATA), a Peripheral Component Interconnect Express (PCI-E), and a Universal Flash Storage (UFS) specification, and can communicate with the host device 50 according to the specific communication specification.

[0044] Generally, the host device 50 can indirectly access the memory device 100 by transmitting host commands and corresponding logical addresses to the memory controller 110. The memory controller 110 receives the host commands and logical addresses and converts the host commands to memory operation commands to further control the NV memory 120 to perform read, programming or erase operations on memory cells or data pages having physical addresses within the NV memory 120. The NV memory 120 includes one or more page buffers 121 (which can be implemented by SRAM) and one or more control circuits 123. The memory controller 110 attempts to program data to the NV memory 120, which will be written to the page buffers 121 before being programmed to the memory cells. The one or more control circuits 123 will read, program or erase data according to the memory operation commands sent by the memory controller 110. When the memory controller 110 performs an erase operation on any of the NV memory elements 122_1-122_N, at least one block in the NV memory element 122_k can be erased. In addition, each block of the NV memory element 122_k can include multiple pages and perform access operations (e.g., read or write) on one or more pages.

[0045] In an embodiment, each of the NV memory elements 122_1-122_N can be an NV memory die or chip. Each of the NV memory dies 122_1-122_N is equipped with control circuits for performing memory operation commands issued by the memory controller 110. In addition, each of the NV memory dies 122_1-122_N can include multiple planes. Each plane can have multiple blocks of memory cells, as well as associated column and row control circuits. The memory cells in each plane can be arranged in a 2D or 3D memory structure. In addition, various memory operations can be performed in parallel or simultaneously on different planes through multi-plane operation commands. That is, memory operations can be applied in parallel or simultaneously on memory blocks of different planes to perform multi-plane read, write or erase operations. In an embodiment, the memory controller 110 can be configured to group memory blocks of the NV memory 120 into multiple super blocks. In an embodiment, the composition of a super block can span across the NV memory chips 122_1-122_N. In addition, a super block can serve as one or more storage blocks for each of the NV memory chips 122_1-122_N.

[0046] In one embodiment, a logical-to-physical (L2P) address mapping table having a plurality of L2P address mapping entries can be divided into a plurality of mapping groups. Each mapping group contains a portion of the L2P address mapping table entries and is used to perform logical-to-physical address translation. These L2P mapping groups are permanently stored in a block of the NV memory 120 and are loaded into the internal memory 113 when needed. Similarly, a physical-to-logical (P2L) address mapping table having a plurality of P2L address mapping entries can be divided into a plurality of mapping groups. Each mapping group contains a portion of the P2L address mapping table entries and is used to perform physical-to-logical address translation. These P2L mapping groups are permanently stored in a block of the NV memory 120.

[0047] In embodiments of the present application, the memory controller 110 can be operable to support multiple write modes. In a single-level cell (SLC) write mode supported by the memory controller 110, one bit of data is written in each memory cell. In a multiple-level cell (MLC) write mode supported by the memory controller 110, two bits of data are written in each memory cell. In a triple-level cell (TLC) write mode supported by the memory controller 110, three bits of data are written in each memory cell. In a quad-level cell (QLC) write mode supported by the memory controller 110, four bits of data are written in each memory cell. Thus, the memory controller 110 can select a supported write mode to perform a write operation on the NV memory 120.

[0048] On the other hand, each of the NV memory elements 122_1-122_N of the NV memory 120 can be configured as a flash memory that stores one or more bits of data in each memory cell, such as an SLC flash memory configured to store one bit of data in each memory cell, an MLC flash memory configured to store two bits of data in each memory cell, a TLC flash memory configured to store three bits of data in each memory cell, and a QLC flash memory configured to store four bits of data in each memory cell. In addition, a block of the NV memory 120 can contain pages, where each block can serve as a minimum erase unit. Each page of the NV memory 120 contains memory cells connected to a single word line and serves as a unit of data write / read operation. In addition, a word line can also serve as a unit of data write / read operation.

[0049] In one embodiment, the NV memory 120 can be configured as MLC flash memory capable of storing 2 bits per memory cell. Typically, 2 pages of data (i.e., lower page data and upper page data) are written into the memory cells connected to a single word line, causing each memory cell to store 2 bits. However, any region (e.g., one or more blocks) of the MLC flash memory 120 can be selectively designated as a special region configured to store only 1 bit per memory cell for performance improvement. This flexibility allows for the creation of an SLC region (i.e., SLC cache) within the MLC memory 120 itself. The memory controller 110 performs write operations in SLC write mode to program data into the SLC region, where only 1 page of data is written into the memory cells connected to a single word line. This ensures that in the SLC region, each block operates as an SLC block with data storage capacity adjusted to store only 1 bit per memory cell.

[0050] In one embodiment, the NV memory 120 can be configured as TLC flash memory capable of storing 3 bits per memory cell. Typically, 3 pages of data (i.e., lower page data, middle page data, and upper page data) are written into the memory cells connected to a single word line, causing each memory cell to store 3 bits. However, any region (e.g., one or more blocks) of the TLC flash memory 120 can be selectively designated as an SLC region (1 bit per memory cell) and / or an MLC region (2 bits per memory cell) for performance improvement. This flexibility allows for the creation of an SLC region (i.e., SLC cache) and / or an MLC region within the TLC memory 120 itself. The memory controller 110 performs write operations in MLC write mode to program data into the MLC region, where 2 pages of data are written into the memory cells connected to a single word line. This ensures that in the MLC region, each block operates as an MLC block with data storage capacity adjusted to store only 2 bits per memory cell.

[0051] In one embodiment, the NV memory 120 can be set up as QLC flash memory capable of storing 4 bits per memory cell. Typically, 4 pages of data (i.e., lower page data, middle page data, upper page data, and top page data) are written into the memory cells connected to a single word line, causing each memory cell to store 4 bits. However, any region (e.g., one or more blocks) of the QLC flash memory 120 can be selectively designated as an SLC region (1 bit per memory cell), an MLC region (2 bits per memory cell), and / or a TLC region (3 bits per memory cell) to improve performance. This flexibility allows SLC regions (i.e., SLC cache), MLC regions, and / or TLC regions to be created within the QLC memory 120. The memory controller 110 performs write operations in a TLC write mode to program data into the TLC regions, where 3 pages of data are written into the memory cells connected to a single word line. This ensures that in the TLC regions, each block operates as a TLC block, and the data storage capacity is adjusted to only 3 bits per memory cell.

[0052] Figure 2 A buffer management control architecture of an embodiment of the present application is illustrated. As shown, a shared memory 160 is integrated within the memory controller 110. Part or all of the shared memory 160 is used to cache data required for various operations of the memory controller 110, including but not limited to: caching read / write data associated with host commands, storing valid data collected during garbage collection operations, performing wear leveling operations, caching frequently accessed data to improve read performance, temporarily storing metadata for flash translation layer (FTL) operations, caching data for ECC computation, storing intermediate results for parallel operations such as multi-plane or multi-die operations, saving firmware code segments for fast execution, maintaining lookup tables for logical to physical or physical to logical address mapping.

[0053] In various embodiments of the present application, the shared memory 160 can be implemented as a partitioned portion of the internal memory 116 or as a separate memory module independent of the internal memory 116. In one embodiment, the shared memory 160 is logically divided into a plurality of allocation units, e.g., memory blocks, denoted as AU_l to AU_n. These allocation units serve as the basic unit of memory management within the shared memory 160. In one particular implementation, each allocation unit can be configured to have a fixed size of 4 KB (4096 bytes). However, the size and configuration of these allocation units can be adjusted according to various requirements.

[0054] In addition, the buffer management control 180 manages the allocation and de-allocation of storage space within the shared memory 160 and tracks the availability of each allocation unit (e.g., AU_l to AU_n) based on a flag table 183 (to be explained later). The firmware executed by the processing unit 112 requests the buffer management control 180 to determine the available allocation units for caching the data corresponding to each read or write operation. In response to a host command, the firmware executed by the processing unit 112 sends a request to the buffer management control 180 to allocate storage space within the shared memory 160. Specifically, the firmware provides the buffer management control 180 with information on the number of allocation units (e.g., the number of memory blocks) required. Subsequently, the buffer management control 180 searches the flag table 183 to identify the available allocation units and accordingly selects and allocates one or more allocation units to satisfy the request sent by the firmware.

[0055] In addition, the buffer management control 180 also performs an address mapping to convert the logical identifiers of the selected / allocated allocation units to their respective physical addresses within the shared memory 160. The buffer management control 180 employs a flexible addressing scheme to communicate with the firmware executed by the processing unit 112. For contiguous memory allocation, the buffer management control 180 sends the basic physical address and the number of contiguous addresses (as an offset) to minimize data transfer. For example, the buffer management control 180 can send a 32-bit basic physical address and a 16-bit offset (representing the number of contiguous physical addresses) to the firmware executed by the processing unit 112. In addition, for non-contiguous allocation, the buffer management control 180 can choose to send individual physical addresses to provide greater flexibility.

[0056] The buffer management control device 180 also updates the flag table 183 to mark the selected configuration unit as occupied (i.e., in use). When the firmware executed by the processing unit 112 no longer needs certain configuration units (e.g., when certain data is no longer needed to be cached), the firmware can send a de-allocation request to the buffer management control device 180 to release storage space within the shared memory 160. In response, the buffer management control device 180 updates the flag table 183 to mark the previously occupied configuration units as available (i.e., idle).

[0057] The following description provides a more specific example. Initially, the host device 50 can send a host command to the memory controller 110 to read data from or program data to the NV memory 120. Upon detecting a host read command, the front-end control circuit 140 notifies the firmware executed by the processing unit 112 that the host read command has been received. In response, the firmware initiates an allocation request to the buffer management control device 180 to instruct the buffer management control device 180 to perform buffer management control (i.e., select / allocate a configuration unit for caching read data, and mark the selected / allocated configuration unit as occupied) and issue a command to the flash memory control circuit 150 to instruct it to initiate a read operation (e.g., a direct memory access (DMA) operation) on the NV memory 120.

[0058] Upon receiving the command from the processing unit 112, the flash memory control circuit 150 sends a memory operation command to the NV memory 120 to instruct the NV memory 120 to perform the read operation. Upon receiving the memory operation command, the control circuit 123 of the NV memory 120 reads data from at least one of the NV memory elements 122_1-122_N. The NV memory 120 then returns the read data to the flash memory control circuit 150. In response, the flash memory control circuit 150 stores the read data associated with the host read command into the shared memory 160 based on the physical address information of the allocated configuration unit (determined by the buffer management control device 180). Upon completion of storing the read data into the shared memory 160, the flash memory control circuit 150 sends a completion message to the firmware.

[0059] Upon receiving the completion message from the flash memory control circuit 150, the firmware executed by the processing unit 112 sends a command to the front-end control circuit 140 instructing it to perform a read operation (e.g., a DMA operation) to obtain the read data from the shared memory 160 and send the read data to the host device 50 accordingly. Upon sending the read data to the host device 50, the front-end control circuit 140 sends a completion message to the buffer management control device 180. Upon receiving the completion message from the front-end control circuit 140, the buffer management control device 180 performs buffer management control (i.e., releases the previously occupied configuration unit).

[0060] Figure 3 An architecture diagram of the buffer management control device of an embodiment of the present application is shown. As shown, the buffer management control device 180 includes a flag update buffer 181, a flag update engine 182, a flag table 183, and a flag management engine 184. The flag update buffer 181 (which can be implemented by a first-in, first-out (FIFO) buffer) is used to store update information. Specifically, the update information can be related to the completion message from the front-end control circuit 140, which indicates that the read data has been sent to the host device 50. The flag update engine 182 is used to read and process the update information stored in the flag update buffer 181. Based on the read update information, the flag update engine 182 sends an update request to the flag management engine 184 to trigger the flag management engine 184 to update the flag table 183.

[0061] The flag table 183 (which can be implemented by a bit vector or a bitmap stored in a storage device (e.g., an SRAM)) is used to track the availability status of the configuration units AU l ~ AU n. Each bit in the bitmap or bit vector of the flag table 183 corresponds to one of the configuration units AU l ~ AU n to indicate the availability status of the corresponding configuration unit. For example, a first logic value (e.g., 0) can represent that the corresponding configuration unit is available (i.e., idle), while a second logic value (e.g., 1) can represent that the corresponding configuration unit is occupied (in use). The implementation of the flag table 183 in the form of a bitmap or a bit vector can make the status checking and update operations more efficient.

[0062] Flag management engine 184 is used to maintain and update flag table 183. When it receives an allocation request from firmware executed by processing unit 112, flag management engine 184 selects / allocates one or more configuration units from configuration units AU_1 to AU_n of shared memory 160 based on the number of configuration units required by the cache for reading data (such information may be provided by the firmware). Specifically, flag management engine 184 maintains a pointer, such as a circular pointer. This pointer tracks the bit positions of the bitmap or bit vector in flag table 183 (e.g., executing a round-robin allocation strategy). The bit position currently indicated by the pointer corresponds to the next potentially available configuration unit. See also... Figure 4 It details the index-based allocation mechanism in the embodiments of the present invention.

[0063] like Figure 4 As shown, flag table 183 may contain n bits, where each bit position (numbered from #1 to #n) corresponds to one of the configuration units AU_1 to AU_n. In case (a), all bits in flag table 183 are initialized to the first logical value "0", indicating that all configuration units are available. In this case, the index maintained by flag management engine 184 is initially set to bit position #1. In case (b), flag management engine 184 has selected / allocated the first four consecutive configuration units (e.g., AU_1 to AU_4) for the read data cache. Therefore, the corresponding bits in bit positions #1 to #4 are set to the second logical value "1", indicating that configuration units AU_1 to AU_4 have been occupied. In this case, the index maintained by flag management engine 184 is incremented to point to bit position #5 in flag table 183. This also means that flag management engine 184 will start searching for available configuration units for subsequent read operations from bit position #5.

[0064] In scenario (c), after confirming that the data stored in the first two configuration units (e.g., AU_1 to AU_2) has been successfully sent to the host device 50, the flag management engine 184 sets bits at positions #1 and #2 in the flag table 183 to the first logical value "0" to release the corresponding configuration units AU_1 to AU_2, indicating that from this moment on, the corresponding configuration units AU_1 to AU_2 are available. It is worth noting that the indicator can continue its forward momentum (after allocating another configuration unit) and continue forward to bit position #7 in the flag table 183, regardless of the availability status of the most recently released configuration units AU_1 and AU_2.

[0065] In case (d), the index maintained by the flag management engine 184 reaches bit position #n, which is the last bit of the flag table 183. At this time, the circular mechanism will be triggered. If the contiguous allocation units pointed by the current index position are not enough to satisfy the space required for caching the read data, the flag management engine 184 will first select / allocate the available allocation unit corresponding to the end of the flag table 183 from the current position, and then circle to the beginning of the flag table 183 to continue searching for available allocation units (pointed by the first logical value "0").

[0066] This searching process continues until enough allocation units are found to satisfy the cache requirement, or a complete traversal of the flag table 183 is completed (indicating that the memory is exhausted). In case (d), if the allocation unit AU_n itself is not enough to cache the read data, the flag management engine 184 can employ a non-contiguous allocation strategy. That is, the flag management engine 184 first selects the allocation unit AU_n, and then further selects the allocation units AU_1 to AU_3 as needed after circling to the beginning.

[0067] By performing efficient bit operations on the flag table 183, the buffer management control device 180 can quickly determine which allocation units are available for storing data and which allocation units are currently occupied. Setting or clearing individual bits in the flag table 183 causes the buffer management control device 180 to set the allocation units as available or occupied, respectively.

[0068] In addition, the flag management engine 184 performs an address mapping to convert the bit positions in the bitmap or bit vector of the flag table 183 to physical addresses of the shared memory 160. Thus, the physical address(es) of the shared memory 160 corresponding to the allocation unit(s) allocated for the read data are sent to the flash memory control circuit 150. Based on the physical address(es) of the shared memory 160 determined by the flag management engine 184, the flash memory control circuit 150 stores the read data into the shared memory 160.

[0069] Figure 5 A flowchart illustrating a buffer management control method according to an embodiment of the present application is shown. As shown, the buffer management control method comprises the following steps:

[0070] S210: tracking the availability status of a plurality of allocation units in a shared memory of a flash memory controller using a flag table; and

[0071] S220: allocating one or more allocation units from the plurality of allocation units for caching read data associated with a host read command using a flag management engine, and updating the flag table according to the allocated one or more allocation units to indicate that the allocated one or more allocation units are occupied.

[0072] Since the principles and specific details of the above steps have been described in the above embodiments, they will not be repeated here. It should be noted that the above process can achieve better read / write performance of the flash memory by adding other additional steps or making appropriate modifications and / or adjustments.

[0073] In summary, the present application introduces a hardware buffer management control architecture for flash memory controllers, solving the limitations of traditional firmware methods. By transferring the buffer management task to dedicated hardware, the system achieves significant improvements in performance, efficiency, and scalability. The flag management mechanism implemented by hardware, using a compact bitmap or bit vector, can quickly check and update the status of storage units. This method not only reduces the delay of read / write operations, but also allows the processing unit to focus on other critical tasks. This provides a more responsive and efficient flash memory system that can handle larger storage capacities while maintaining high performance.

[0074] The above only describes the preferred embodiments of the present application, and any equivalent changes and modifications made within the scope of the patent application of the present application shall be included in the scope of the present application.

Claims

1. A buffer management control device for a flash memory controller, comprising: A flag table is used to track the availability status of multiple allocation units within a shared memory of the flash memory controller; and A flag management engine is used to allocate one or more configuration units from the plurality of configuration units to cache read data associated with a host read command and update the flag table based on the allocated one or more configuration units, thereby indicating that the allocated one or more configuration units are occupied.

2. The buffer zone management and control device as described in claim 1, characterized in that, Also includes: A flag update buffer is used to store update information corresponding to one or more completion messages, wherein the one or more completion messages indicate that the read data has been sent to a host device; as well as A flag update engine is used to read the update information from the flag update buffer, and send one or more update requests to the flag management engine according to the update information to trigger the flag management engine to update the flag table, thereby releasing the one or more previously allocated configuration units from the occupied state.

3. The buffer zone management and control device as described in claim 1, characterized in that, The flag table contains a bitmap or a bit vector, where each bit position in the bitmap or bit vector corresponds to one of the plurality of configuration units and indicates the availability status of the corresponding configuration unit.

4. The buffer zone management and control device as described in claim 3, characterized in that, The flag management engine is used to maintain a pointer associated with the bitmap or bit vector, which tracks the bit position within the bitmap or bit vector corresponding to the next potential available configuration unit.

5. The buffer zone management and control device as described in claim 4, characterized in that, The flag management engine is used to update the tracked bit position indicated by the metric according to a round-robin strategy after allocating one or more configuration units for the cache of the read data.

6. The buffer zone management and control device as described in claim 5, characterized in that, Even if one or more previous bit positions within the bitmap or bit vector corresponding to one or more recently released configuration units are currently displayed as available, the flag management engine moves the indicator forward to the next bit position within the bitmap or bit vector corresponding to the next potentially available configuration unit.

7. The buffer zone management and control device as described in claim 3, characterized in that, The flag management engine is used to perform address mapping to translate bit positions within the bitmap or bit vector into corresponding physical addresses in the shared memory.

8. The buffer zone management and control device as described in claim 7, characterized in that, A flash memory control circuit in the flash memory controller is used to store the read data into the shared memory based on the entity address information provided by the flag management engine.

9. A flash memory controller comprising the buffer management control means as described in claim 1.

10. A data storage device comprising a flash memory controller and a flash memory, as described in claim 1.

11. A buffer management control method for a flash memory controller, comprising: The availability status of multiple configuration units within a shared memory of the flash memory controller is tracked using a flag table; and A flag management engine is used to allocate one or more hives from the plurality of hives to cache read data associated with a host read command, and to update the new flag table based on the allocated one or more hives, thereby indicating that the allocated one or more hives are occupied.

12. The buffer management and control method as described in claim 11, characterized in that, Also includes: The flag update buffer stores an update message corresponding to one or more completion messages, wherein the one or more completion messages indicate that the read data has been sent to a host device; as well as The flag update engine reads the update information from the flag update buffer and sends one or more update requests to the flag management engine based on the update information, thereby triggering the flag management engine to update the flag table and release the previously allocated one or more configuration units from the occupied state.

13. The buffer management and control method as described in claim 11, characterized in that, The flag table contains a bitmap or bit vector, where each bit position in the bitmap or bit vector corresponds to one of the plurality of configuration units, and indicates the availability status of the corresponding configuration unit.

14. The buffer management and control method as described in claim 13, characterized in that, The steps to update this flag table include: Maintain a metric associated with the bitmap or bit vector that tracks a bit position within the bitmap or bit vector corresponding to the next potential available configuration unit.

15. The buffer management and control method as described in claim 14, characterized in that, The steps to maintain this metric include: After allocating one or more configuration units to the cache for the read data, the tracked bit position indicated by the metric is updated according to a round-robin strategy.

16. The buffer management and control method as described in claim 15, characterized in that, The steps to maintain this metric include: Even if one or more previous bit positions within the bitmap or bit vector corresponding to one or more recently released configuration units are currently displayed as available, move the index forward to the next bit position within the bitmap or bit vector corresponding to the next potentially available configuration unit.

17. The buffer management and control method as described in claim 13, characterized in that, The steps of allocating one or more configuration units to the cache for reading data include: Perform address mapping to translate bit positions within the bitmap or bit vector into corresponding physical addresses in the shared memory.

18. The buffer management and control method as described in claim 17, characterized in that, Also includes: Based on the entity address information provided by the flag management engine, the read data is stored in the shared memory.

Images