Computer-readable storage medium, method and device for writing data to a flash memory

Abstract

The present invention relates to a computer-readable storage medium, a method and an apparatus for writing data into a flash memory. The method for writing data into the flash memory is executed by a main processing unit of a flash memory controller and includes: generating a front-end parameter set, a middle-end parameter set, and a back-end parameter set for each item of data writing; transmitting the front-end parameter set of each item to a routing engine so that the routing engine drives a host interface according to the content of the front-end parameter set; transmitting the middle-end parameter set of each item to an accelerator so that the accelerator drives a redundant array of independent disks (RAID) engine according to the content of the middle-end parameter set; and transmitting the back-end parameter set of each item to the accelerator so that the accelerator drives a data access engine according to the content of the back-end parameter set. Through the setting of an exclusive routing engine and accelerator, the main processing unit does not need to supervise the operation of the entire data writing data stream, improving the overall performance of the system.

Description

Technical Field

[0001] The present invention relates to a storage device, and more particularly to a computer-readable storage medium, a method and an apparatus for writing data to a flash memory. Background Art

[0002] Flash memories are generally classified into NOR flash memories and NAND flash memories. A NOR flash memory is a random access device. A central processing unit (Host) can provide any address for accessing the NOR flash memory on an address pin, and timely obtain data stored at the address from a data pin of the NOR flash memory. In contrast, a NAND flash memory is not random access but serial access. A NAND flash memory cannot access any random address like a NOR flash memory. Instead, the central processing unit needs to write a value of a serial group of bytes (Bytes) into the NAND flash memory to define the type of a request command (such as read, write, erase, etc.) and the address used for this command. The address can point to a page (the smallest data block for a write operation in the flash memory) or a block (the smallest data block for an erase operation in the flash memory). Improving the data writing performance of a flash memory module has always been an important issue affecting the overall performance of a flash memory controller system. Therefore, the present invention provides a computer-readable storage medium, a method and an apparatus for writing data to a flash memory to improve data writing performance. Summary of the Invention

[0003] In view of this, how to mitigate or eliminate the deficiencies in the above-related fields is indeed a problem to be solved.

[0004] The present invention relates to a method for writing data to a flash memory, which is executed by a main processing unit of a flash memory controller and includes: generating a front-end parameter set, a middle-end parameter set, and a back-end parameter set for each item of data writing; transmitting the front-end parameter set of each item to a routing engine, so that the routing engine drives a host interface according to the content of the front-end parameter set to obtain data from a host side and store the obtained data in a first address in a random access memory; transmitting the middle-end parameter set of each item to an accelerator, so that the accelerator drives a redundant array of independent disks engine (RAID Engine) according to the content of the middle-end parameter set to obtain original data from a second address in the random access memory, encrypt the original data or generate parity check page data according to the original data of multiple pages, and store the encrypted or encoded result in a third address in the random access memory; and transmitting the back-end parameter set of each item to the accelerator, so that the accelerator drives a data access engine according to the content of the back-end parameter set to obtain the source data from a fourth address in the random access memory and write the source data to a specified physical address of a flash memory module.

[0005] The present invention also relates to a computer-readable storage medium for storing program code that can be loaded and executed by a main processing unit of a flash memory controller, and when the program code is executed by the main processing unit, the method for writing data to a flash memory as described above is implemented.

[0006] The present invention also relates to a device for writing data to a flash memory, comprising: a routing engine coupled to a host interface; an accelerator coupled to a redundant array of independent disks (RAID) engine and a data access engine; and a main processing unit coupled to the routing engine and the accelerator. The main processing unit is configured to generate a front-end parameter set, a middle-end parameter set, and a back-end parameter set for each item of data writing; transmit the front-end parameter set of each item to the routing engine, such that the routing engine drives the host interface according to the content of the front-end parameter set to obtain data from a host side and store the obtained data in a first address in a random access memory; transmit the middle-end parameter set of each item to the accelerator, such that the accelerator drives the RAID engine according to the content of the middle-end parameter set to obtain original data from a second address in the random access memory, encrypt the original data or generate parity check page data based on the original data of multiple pages, and store the encrypted or encoded result in a third address in the random access memory; and transmit the back-end parameter set of each item to the accelerator, such that the accelerator drives the data access engine according to the content of the back-end parameter set to obtain the source data from a fourth address in the random access memory and write the source data to a specified physical address of a flash module.

[0007] The front-end parameter set includes information of a host write command and a first address in the random access memory configured to store data obtained from the host side. The middle-end parameter set includes a second address in the random access memory configured to store original data and a third address for storing the encrypted or encoded result, and parameters for setting the RAID engine. The back-end parameter set includes a programming table and an index of the programming table, and the programming table includes a fourth address in the random access memory configured to store source data.

[0008] One of the advantages of the above embodiments is that through an exclusive routing engine and accelerator, the operations of the host interface, the RAID engine, and the data access engine are integrated to complete various data writing operations, such that the main processing unit of the flash memory controller does not need to monitor the entire data writing data stream operation and wait for status responses from the host interface, the RAID engine, and the data access engine during the data stream operation. The saved time and computing resources can enable the main processing unit of the flash memory controller to execute other tasks, improving the overall performance of the system.

[0009] Another advantage of the above embodiments is that, through the cabinet position flag, the host interface can execute out-of-order and separate items in the front-end processing stage, and the accelerator can restore them to the original execution order in the middle-end and back-end processing stages.

[0010] Another advantage of the above embodiments is that, through the operation settings of the item summary, the routing engine can skip the front-end processing stage that does not need to be executed, and the accelerator can skip the middle-end and / or back-end processing stages that do not need to be executed, providing configuration flexibility.

[0011] Other advantages of the present invention will be explained in more detail in conjunction with the following description and drawings. Description of the Drawings

[0012] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation of the present application.

[0013] Figure 1 It is a system architecture diagram of an electronic device according to an embodiment of the present invention.

[0014] Figure 2 It is a schematic diagram of a flash memory module according to an embodiment of the present invention.

[0015] Figure 3 It is a data writing flow chart according to an embodiment of the present invention.

[0016] Figure 4 It is a schematic diagram of an item summary according to an embodiment of the present invention.

[0017] Figure 5 It is a block diagram of a routing engine according to an embodiment of the present invention.

[0018] Figure 6 It is a method flow chart of a front-end processing stage according to an embodiment of the present invention.

[0019] Figure 7 It is a block diagram of an accelerator according to an embodiment of the present invention.

[0020] Figure 8 It is a method flow chart of a middle-end and back-end processing stage according to an embodiment of the present invention.

[0021] Among them, the simple descriptions of the symbols in the drawings are as follows:

[0022] 10: Electronic device; 110: Host side; 130: Flash memory controller; 131: Host interface; 132: Routing engine; 133: Accelerator; 134: First processing unit; 135: RAID engine; 136: Random access memory; 137: Data access engine; 138: Second processing unit; 139: Flash memory interface; 150: Flash memory module; 151: Interface; 153#0 to 153#15: NAND flash memory cells; CH#0 to CH#3: Channels; CE#0 to CE#3: Start signals; S310 to S360: Method steps; 410: Preceding information; 420: Bin location flag; 510: Status queue; 520: Controller; 530: Start queue; S610 to S670: Method steps; 710: Controller; 720: Execution table; 730: Middle-end parameter set; 740: Back-end parameter set; 750: Programming table; S810 to S880: Method steps. Detailed implementation manners

[0023] The embodiments of the present invention will be described below in conjunction with the relevant drawings. In these drawings, the same reference numerals denote the same or similar components or method flows.

[0024] It must be understood that the words "comprising", "including", etc. used in this specification are used to indicate the existence of specific technical features, numerical values, method steps, operations, components, and / or components, but do not exclude the addition of more technical features, numerical values, method steps, operations, components, components, or any combination of the above.

[0025] In the present invention, words such as "first", "second", "third", etc. are used to modify the components in the claims, and do not indicate a priority order, precedence relationship, or that one component precedes another component, or the chronological order when performing method steps, but are only used to distinguish components with the same name.

[0026] It must be understood that when a component is described as "connected" or "coupled" to another component, it may be directly connected or coupled to other components, and intermediate components may occur. On the contrary, when a component is described as "directly connected" or "directly coupled" to another component, there are no intermediate components. Other words used to describe the relationship between components can be interpreted in a similar manner, such as "between" versus "directly between", or "adjacent" versus "directly adjacent", etc.

[0027] In a flash memory controller, the entire data write data stream can be divided into three processing stages: the front-end; the mid-end; and the back-end. The front-end processing stage is responsible for obtaining the data to be written, which also includes information such as the source address of the data, the size of the data, and the location in the static random access memory (SRAM) where these data are temporarily stored. The mid-end processing stage involves data security, which includes operations such as data reordering, coordinating with a redundant array of independent disks engine (RAID Engine) to perform data encryption, and generating parity pages. The back-end processing stage includes operations such as obtaining data from the static random access memory, post-data processing (including data scrambling, adding low-density parity check codes to the data, etc.), and control of physical data writing. It should be noted that the system can ignore any one or two of the above three stages according to different characteristics of data writing. In previous embodiments, when the flash memory controller executes a host write command, firmware (also called the firmware translation layer, FTL) is usually used to initiate, control, and monitor the data stream, so that most of the processor load and computing resources are consumed on the tasks described above. Specifically, the firmware may consume a large amount of time and computing resources to check whether the necessary data has been stored in the specified location in the static random access memory, query relevant hardware (such as the redundant array of independent disks engine, flash memory interface, etc.), and wait for a reply to know the operating status, etc. To solve the problems described above, embodiments of the present invention modify the current architecture and set up a dedicated hardware circuit that can cooperate with the firmware to accelerate the overall processing of data writing.

[0028] Reference Figure 1. The electronic device 10 includes a host side 110, a flash memory controller 130, and a flash memory module 150, and the flash memory controller 130 and the flash memory module 150 can be collectively referred to as the device side. The electronic device 10 can be implemented in electronic products such as personal computers, laptop PCs, tablet computers, mobile phones, digital cameras, digital video cameras, etc. The host side 110 and the host interface 131 of the flash memory controller 130 can communicate with each other through communication protocols such as Universal Serial Bus (USB), advanced technology attachment (ATA), serial advanced technology attachment (SATA), peripheral component interconnect express (PCI-E), Universal Flash Storage (UFS), Embedded Multi-Media Card (eMMC), etc. The flash memory interface 139 of the flash memory controller 130 and the flash memory module 150 can communicate with each other through a Double Data Rate (DDR) communication protocol, for example, Open NAND Flash Interface (ONFI), DDR Toggle, or other communication protocols. The flash memory controller 130 includes a first processing unit 134 (also referred to as the primary processing unit, Primary Processing Unit), which can be implemented in various ways, such as using general-purpose hardware (for example, a single processor, a multi-processor with parallel processing capabilities, a graphics processor, or other processors with computing capabilities), and provides the functions described later when executing software and / or firmware instructions. The processing unit 134 receives host commands through the host interface 131, such as read commands (ReadCommand), write commands (Write Command), discard commands (Discard Command), erase commands (EraseCommand), etc., schedules and executes these commands.The flash memory controller 130 further includes a Random Access Memory (RAM) 136, which can be implemented as a Dynamic Random Access Memory (DRAM), a Static Random Access Memory (SRAM), or a combination of the two, for configuring space as a data buffer to store user data (also referred to as host data) read from the host side 110 and about to be written to the flash memory module 150, and user data read from the flash memory module 150 and about to be output to the host side 110. The random access memory 136 can further store data required during the execution process, such as variables, data tables, a Host-to-Flash Address Mapping Table (abbreviated as H2F table), a Flash-to-Host Address Mapping Table (abbreviated as F2H table), etc.

[0029] A shared bus architecture can be configured in the flash memory controller 130 for coupling components to each other to transfer data, addresses, control signals, etc. These components include a host interface 131, a first processing unit 134, a RAID engine 135, a RAM 136, a Data Access Engine 137, etc. The bus includes parallel physical lines connecting more than two components in the flash memory controller 130. The shared bus is a shared transmission medium. At any given time, only two devices can use these lines to communicate with each other for transferring data. Data and control signals can propagate bidirectionally between components along the data and control lines respectively. On the other hand, the address signal can only propagate unidirectionally along the address line. For example, when the processing unit 134 wants to read data at a specific address in the RAM 136, the processing unit 134 transmits this address to the RAM 136 on the address line. Then, the data at this address is replied to the processing unit 134 on the data line. To complete the data read operation, the control signal is transmitted using the control line.

[0030] A dedicated bus can also be configured in the flash memory controller 130, independent of the shared bus architecture, to connect the first processing unit 134, the routing engine 132, and the accelerator 133 to each other for transmitting control signals and control information. The routing engine 132 is used to complete the tasks in the front-end processing stage, and the accelerator 133 is used to complete the tasks in the middle-end and back-end processing. The routing engine 132 and the accelerator 133 may not be coupled to the shared bus architecture to avoid occupying the bandwidth of the shared bus architecture and reducing the overall system performance.

[0031] The flash memory module 150 provides a large amount of storage space, usually hundreds of gigabytes (GB), or even several terabytes (TB), for storing a large amount of user data, such as high-resolution pictures, videos, etc. The flash memory module 150 includes a control circuit and a memory array. The storage cells in the memory array can be configured as single level cells (SLCs), multiple level cells (MLCs), triple level cells (TLCs), quad-level cells (QLCs), or any combination thereof. The first processing unit 134 can write user data to a specified address (destination address) in the flash memory module 150 and read user data from a specified address (source address) in the flash memory module 150 through the flash memory interface 139. The flash memory interface 139 uses several electronic signals to coordinate the data and command transmission between the flash memory controller 130 and the flash memory module 150, including data lines, clock signals, and control signals. The data lines can be used to transmit commands, addresses, read and write data; the control signal lines can be used to transmit control signals such as chip enable (CE), address latch enable (ALE), command latch enable (CLE), write enable (WE), etc.

[0032] Reference Figure 2, the interface 151 in the flash memory module 150 may include four input / output channels (I / O channels, hereinafter referred to as channels) CH#0 to CH#3, and each channel is connected to four NAND flash memory cells. For example, channel CH#0 is connected to NAND flash memory cells 153#0, 153#4, 153#8, and 153#12. Each NAND flash memory cell may be encapsulated as an independent chip (die). The flash memory interface 139 may issue one of the activation signals CE#0 to CE#3 through the interface 151 to activate NAND flash memory cells 153#0 to 153#3, 153#4 to 153#7, 153#8 to 153#11, or 153#12 to 153#15, and then read user data from the activated NAND flash memory cells in a parallel manner, or write user data to the activated NAND flash memory cells.

[0033] Reference Figure 3The flowchart of the data writing shown. In the front - end processing stage, the operation settings are checked to determine whether there is a task to be executed associated with the host interface 131 (step S310). If so (the path of "Yes" in step S310), the host interface 131 is driven to obtain data from the host side 110 and store the data at a specified address in the RAM 136 (step S320). Otherwise (the path of "No" in step S310), the process directly enters the next stage (i.e., the middle - end processing stage) (step S330). In the middle - end processing stage, the operation settings are checked to determine whether there is a task to be executed associated with the RAID engine 135 (step S330). If so (the path of "Yes" in step S330), the RAID engine 135 is driven to read data from a specified address in the RAM 136, re - order the obtained data to restore the original data order, encrypt the data group of the re - ordered data or generate parity - check page data, and store the encrypted data or parity - check page data at a specified address in the RAM 136 (step S340). Otherwise (the path of "No" in step S330), the process directly enters the next stage (i.e., the back - end processing stage) (step S350). In the back - end processing stage, the operation settings are checked to determine whether there is a task to be executed associated with the data access engine 137 (step S350). If so (the path of "Yes" in step S350), the data access engine 137 is driven to read data from a specified address in the RAM 136. These data can be the data obtained from the host side 110, the encrypted data by the RAID engine 135, the parity - check page data generated by the RAID engine 135, etc. In addition, the data access engine 137 is driven to perform post - processing on the read data, such as scrambling the read data, attaching low - density parity - check codes of the read data, etc., and writing the post - processed data to a specified address in the flash memory module 150 (step S360). Otherwise (the path of "No" in step S350), the process ends.

[0034] In the previous embodiment, the firmware is usually executed by the first processing unit 134 to start, control, and supervise the entire data - writing data stream. In order to reduce the time and computing resources occupied by the first processing unit 134, in the embodiment of the present invention, a routing engine 132 and an accelerator 133 implemented by dedicated circuits are provided in the flash memory controller 130, so that the first processing unit 134 can selectively start the routing engine 132, the accelerator 133, and the second processor 138 through a control protocol, and the execution of the entire data stream can be cascaded by the routing engine 132, the accelerator 133, and the second processor 138 themselves. In addition, this control protocol can also selectively ignore one or two stages in the data stream according to the characteristics of the data writing.

[0035] Embodiments of the present invention propose to manage the entire data flow operation of data writing in a transaction - by - transaction manner, so that the data to be written can flow through specified hardware for processing. In order for the routing engine 132, the accelerator 133, and the second processor 138 to know the transaction profile of the data writing, embodiments of the present invention enable the first processing unit 134 to generate and transmit leading information and cargo flags to the routing engine 132 and the accelerator 133, for notifying the routing engine 132, the accelerator 133, and the second processor 138 which carrier the data to be written for each item (also referred to as a data - writing item) belongs to, the preparation status of each cargo in this carrier, and information such as which processing stages this carrier needs to go through, etc., to coordinate the execution among the routing engine 132, the accelerator 133, and the second processor 138. Refer to Figure 4Schematic diagram of the project summary, including preamble information 410 of 2 bytes (Byte0 - Byte1) and cargo flags 420 of 4 bytes (Byte2 - Byte5). Assuming that writing 128KB of data to the flash memory module 150 at a time can achieve better performance: the flash memory controller 130 can drive the data access engine 137 to write 128KB of data to multiple NAND flash memory cells in the flash memory module 150 in a multi-channel interleaved manner after each collection of 128KB of data is completed. In response to the above example, the 0th byte (Byte0) of the preamble information 410 stores the carrier ID, which is used to indicate a specific 128KB of data. The 1st byte (Byte1) of the preamble information 410 stores information about the operation setting, and the lowest three bits of it store information about whether to start three processing stages. For example, when the lowest three bits in the 1st byte are "0b111", it means that the front-end, middle-end, and back-end processing stages are all to be started. By providing the carrier ID, 128K data with the same carrier ID is like being loaded on the same virtual carrier, coordinating the operation of each project between the routing engine 132 and the accelerator 133. It should be noted here that a virtual carrier can also load different sizes of data according to different types of flash memory modules, such as data of sizes 16KB, 32KB, 64KB, etc. Since a project may not be sufficient to control the entire 128KB of data write operation, each bit in the cargo flags 420 is used to indicate whether the data at a specific position (also called a cargo location) in the 128KB of data is ready, where "1" means ready and "0" means not ready. For example, when the lowest two bits in the 2nd byte (Byte2) are "0b11", it means that the 0th and 1st 4KB of data in the 128KB of data are ready. When the lowest two bits in the 3rd byte (Byte3) are "0b11", it means that the 8th and 9th 4KB of data in the 128KB of data are ready. It should be understood here that in some system settings, 4KB of data can also be regarded as the data of a host page (including eight consecutive LBAs).

[0036] For example, when the firmware executed by the first processing unit 134 receives a host write command from the host 110 via the host interface 131 to indicate writing 128 KB of data, the following project summary is generated: the vehicle identification code is "0x00"; the operation setting is "0x07", indicating that this project needs to start the front-end, middle-end, and back-end processing phases; the bin flag is "0x00000000" (which can be called the initialized bin flag), indicating that no data is ready. Then, the first processing unit 134 transmits the project summary, the host write command, and the designated address (which can also be called the destination address) in the RAM 136 for storing 128 KB of data to the routing engine 132. The host write command may contain the following information: the operation code, the starting logical block address number (Logic Block Address, LBA Number), the LBA length, etc. The host write command and the destination address can be collectively referred to as the Front-end Parameter Set. An LBA usually points to 512 B of data, and a host page contains data of eight consecutive LBAs. Although the embodiments of the present invention describe that the size of an LBA is 512 B and a host page contains data of eight LBAs, those skilled in the art can modify the size of an LBA to other lengths (such as 256 B, 1 KB, 2 KB, etc.) and / or modify a host page to contain more or fewer LBAs of data according to the needs of the system.

[0037] For another example, when the firmware executed by the first processing unit 134 receives a host write command from the host 110 via the host interface 131 to indicate writing 64 KB of data, the following preamble information is generated: the vehicle identification code is "0x01"; the operation setting is "0x07"; the bin flag is "0xFFFF0000" (which can be called the initialized bin flag), indicating that the data in bins 0 to 15 is not ready, while the data in bins 16 to 31 is ready (which also implies that these data can be ignored and no longer processed). Then, the first processing unit 134 transmits the project summary, the information of the host write command, and the designated address in the RAM 136 for storing 64 KB of data to the routing engine 132.

[0038] For another example, when the firmware executed by the first processing unit 134 collects 128 KB of data during the garbage collection process, the following preamble information is generated: the vehicle identification code is "0x01", the operation setting is "0x04", indicating that this project only needs to start the back-end processing phase; the bin flag is "0xFFFFFFFF" (which can be called the initialized bin flag), indicating that all data is ready.

[0039] The first processing unit 134 transmits the initial bin flags of each of the above-described items to the routing engine 132 and the accelerator 133, for notifying the routing engine 132 and the accelerator 133 of which parts of the data in each of the items need to be prepared and completed in the front-end processing stage.

[0040] Before actually pushing the pre-information and the front-end parameter set of an item into the routing engine 132, the first processing unit 134 also needs to prepare the mid-end parameter set and the back-end parameter set associated with this item. The firmware executed by the first processing unit 134 can store the operation details of the mid-end and back-end processing stages of at most no more than a number (e.g., 64) of items into the static random access memory in the accelerator 133. The mid-end parameter set indicates the details of how to drive the RAID engine 135 to complete the mid-end processing stage, and may include the source address configured in the RAM 136 to store the original data, the parameters for setting the encryption or encoding of the RAID engine 135, the destination address configured in the RAM 136 to store the encrypted or encoded result, etc. The back-end parameter set indicates the details of how to drive the data access engine 137 to complete the back-end processing stage, and may include a programming table and the index of this programming table. The index of this programming table can be used to calculate the address configured in the SRAM of the accelerator 133 to store this programming table. The programming table includes the address configured in the RAM 136 to store the source data (which can be called the source address), a series of flash commands and their programming parameters (such as command type, programming mode, physical address to be written, etc.). The physical address (which can be called the destination address) may include information such as channel number, physical block number, physical page number, section number, etc.

[0041] In response to a series of host write commands or the execution of background programs, the first processing unit 134 generates pre-information of multiple items, an initial cabinet location flag, a front-end parameter set, a middle-end parameter, and a back-end parameter set. After the first processing unit 134 transmits the pre-information of multiple items, the initial cabinet location flag, and the front-end parameter set to the routing engine 132, and transmits the pre-information of multiple items, the initial cabinet location flag, the middle-end parameter, and the back-end parameter set to the accelerator 133, the routing engine 132, the accelerator 133, and the data access engine 137 can complete various data write operations accordingly, without the first processing unit 134 supervising the entire data write data flow operation and waiting for status responses from the host interface 131, the RAID engine 135, and the data access engine 137 during the data flow operation. In other words, the first processing unit 134 does not directly drive the host interface 131, the RAID engine 135, and the data access engine 137 to complete the operations in the front-end, middle-end, and back-end processing stages as described above during the data write process, but instead completes the driving of the host interface 131, the RAID engine 135, and the data access engine 137 through the routing engine 132 and the accelerator 133. These saved time and computing resources allow the first processing unit 134 to execute other tasks, improving the overall performance of the system. After that, the first processing unit 134 can read the execution status of each item from a specified address in the RAM 136 at regular intervals, or query the routing engine 132 and / or the accelerator 133 to obtain the execution status of each item.

[0042] The routing engine 132 receives an operation setting and a front-end parameter set of an item from the first processing unit 134, and the operation setting indicates information on whether each of the front-end processing stage, the middle-end processing stage, and the back-end processing stage needs to be started. When the routing engine 132 determines, based on the operation setting, that the front-end processing stage needs to be started, it drives the host interface 131 according to the front-end parameter set, so that the host interface 131 obtains data from the host side 110 and stores the obtained data at a specified address in the random access memory 136 through the shared bus architecture.

[0043] Reference Figure 5Block diagram of the routing engine 132 shown. The routing engine 132 includes a status queue 510, a controller 520, and a start queue 530. The controller 520 can be implemented using a general-purpose processor or dedicated circuitry, and the status queue 510 and the start queue 530 can be implemented in pre-configured spaces in SRAM. The routing engine 132 can perform a series of signal interactions with the first processing unit 134 via an Advanced High-Performance (AHB) bus. If there are any items (i.e., virtual vehicles) that need to obtain data from the host side 110 through the host interface 131, the firmware executed in the first processing unit 134 pushes the item summary (including the initialized bin flag) and the front-end parameter set into the status queue 510 to indicate to the routing engine 132 how to drive the host interface 131 to obtain the specified data and store it at the specified address in the RAM 136. The front-end parameter set indicates the logical address range of the host data (which can be represented using the starting LBA number and the LBA length), and the specified location in the RAM 136 where the host data is stored.

[0044] See also Figure 6 Method flowchart of the front-end processing phase executed by the controller 520 shown. This method repeatedly executes an outer loop (from step S610 to S670) and an inner loop (from step S630 to S660). Each iteration of the large loop starts with the controller 520 popping an item from the status queue 510 (step S610), and then determines whether the data of this item needs to go through the front-end processing phase based on the operation setting in the item (step S620). If so (the "yes" path in step S620), the small loop starts, which is used to drive (or start) the host interface 131 according to the content of the item to obtain the host data at the specified logical address from the host side 110, and store the obtained host data at the specified address in the RAM 136 (step S630). It should be noted that for better performance, the start order of the items in the queue may not be the same as the time order in which they arrive at the status queue 510. That is, the items that arrive at the status queue 510 earlier are not necessarily the items that are processed earlier by the controller 520. In other words, during the period when the controller 520 drives the host interface 131 to complete the operations indicated by the front-end parameter set of an item, there may still be earlier-arrived items stored in the status queue 510 that have not been processed.

[0045] Since the controller 520 may obtain the host data of a project in multiple batches, each time any host data of any main page (or any LBA range) has been successfully stored in the designated location in the RAM 136 (step S630), the controller 520 updates the cabinet position flag to reflect the execution status of the host interface 131 (step S640), and pushes the preamble information and the updated cabinet position flag into the startup queue 530 for the accelerator 133 to determine whether to start the operations in the subsequent processing stage accordingly (step S650). For example, the pushed item records the following item summary: the vehicle identification code is "0x01"; the operation setting is "0x07"; and the cabinet position flag is "0xFFFF0000", and the controller 520 uses two batches to drive the host interface 131 to complete the reading of the entire 64KB data. After the execution of the first batch of 32KB data is successful, the controller 520 updates the cabinet position flag to "0xFFFF00FF", and pushes the updated item summary (including the vehicle identification code "0x01"; the operation setting "0x07"; and the cabinet position flag "0xFFFF00FF") into the startup queue 530. After the execution of the second batch of 32KB data is successful, the controller 520 updates the cabinet position flag to "0xFFFFFF00", and pushes the updated item summary (including the vehicle identification code "0x01"; the operation setting "0x07"; and the cabinet position flag "0xFFFFFF00") into the startup queue 530.

[0046] If the operation setting in the project indicates that the data of this project does not need to go through the front-end processing stage (the "No" path in step S620), the controller 520 directly pushes the original item summary into the startup queue 530 (step S670).

[0047] Each time the original or updated item summary of the controller 520 is pushed into the startup queue 530, it can represent that the controller 520 notifies the accelerator 133 of the startup information of the corresponding project.

[0048] The accelerator receives an operation setting, a mid-end parameter set, and a back-end parameter set for an item from the first processing unit 134. The operation setting indicates information on whether each of the front-end processing stage, the mid-end processing stage, and the back-end processing stage needs to be started. When the accelerator 133 receives the start information for this item from the routing engine 132, and when the accelerator 133 determines, based on the operation setting, that the mid-end processing stage needs to be started, it drives the RAID engine 135 according to the mid-end parameter set, so that the RAID engine 135 obtains data from a specified address in the RAM 136 through the shared bus architecture, encrypts the obtained data, or generates parity-check page data based on the data of multiple obtained pages. Then, when the accelerator 133 determines, based on the operation setting, that this write item does not need to start the mid-end processing stage or the mid-end processing stage of this write item has been completed, and when the accelerator 133 determines, based on the operation setting, that the back-end processing stage needs to be started, it drives the data access engine 137 according to the back-end parameter set, so that the data access engine 137 obtains data from a specified address in the RAM 136 through the shared bus architecture and writes the obtained data to a specified address in the flash memory module 150.

[0049] Reference Figure 7 Referring to the block diagram of the accelerator 133 shown, the accelerator 133 includes a controller 710, an execution table 720, a mid-end parameter set 730, a back-end parameter set 740, and a programming table 750. The controller 710 can be implemented using a general-purpose processor or a dedicated circuit, and the execution table 720, the mid-end parameter set 730, the back-end parameter set 740, and the programming table 750 can be implemented in a pre-configured space in the SRAM of the accelerator 133. The accelerator 133 can perform a series of signal interactions with the first processing unit 134 through a high-performance advanced bus. The execution table 720 stores item summaries of multiple items (i.e., virtual vehicles), and the content of the execution table 720 is filled in by the first processing unit 134. An example of the execution table 720 is shown in Table 1:

[0050] Table 1

[0051] Project Number Pre-information Cargo Location Mark entry#0 leadInfo#10 cargoFlag#10 entry#1 leadInfo#11 cargoFlag#11 entry#2 leadInfo#12 cargoFlag#12 entry#3 leadInfo#13 cargoFlag#13 : : : entry#62 N / A N / A entry#63 N / A N / A

[0052] The first processing unit 134 sequentially fills in the project summary (including pre - information and bin flags) according to the execution order of the projects. For example, the first processing unit 134 sequentially fills in the project summaries of the 10th to 13th projects into entry #0 to entry #3 in the execution table 720. The project summary of the 10th project includes the corresponding pre - information (leadInfo#10) and bin flag (cargoFlag#10), the project summary of the 11th project includes the corresponding pre - information (leadInfo#11) and bin flag (cargoFlag#11), and so on. Although the pushing order of the projects in the start queue 530 is not necessarily the same as the order in which the first processing unit 134 originally pushed them into the status queue 510, the controller 710 must execute the projects according to the storage order in the execution table 720. That is, when the middle - end processing stage and / or the back - end processing stage required by the 10th project have not been completed, the controller 710 cannot drive the RAID engine 135 and the data access engine 137 for any of the 11th to 13th projects.

[0053] If there are any projects that need to be processed by the RAID engine 135, the first processing unit 134 stores the corresponding middle - end parameter set 730 in advance at a specified address in the SRAM of the accelerator 133, so that the controller 710 can set the RAID engine 135 accordingly to complete the middle - end processing operation of this project. If there are any projects that need to be processed by the data access engine 137, the first processing unit 134 stores the corresponding back - end parameter set 740 and the programming table 750 in advance at a specified address in the SRAM of the accelerator 133, so that the second processing unit 138 in the data access engine 137 can drive the flash interface 139 accordingly to complete the back - end processing operation of this project.

[0054] Another reference Figure 8The method flowchart of the middle and back-end processing phases executed by the controller 710 is shown. This method repeatedly executes a loop (from step S810 to S880). Each iteration of the loop starts with the controller 710 pushing an item from the start queue 530 (step S810), then performing a logical OR operation on the bin flag in the pushed item and the corresponding bin flag in the execution table 720, and updating the calculation result back to the corresponding bin flag in the execution table 720 (step S820), and determining whether the bin flag of the zeroth item in the execution table 720 is equal to 0xFFFFFFFF (step S830). If so (the "yes" path in step S830), it means that the front-end processing phase of the zeroth item has been completed or the front-end processing phase does not need to be executed, and the zeroth item in the execution table 720 enters the middle-end processing phase (steps S840 to S860). If not (the "no" path in step S830), it means that the front-end processing phase of the zeroth item has not been completed, and the controller 710 continues to push the next item from the start queue 530 for processing (step S810).

[0055] For example, assume that the execution table 720 stores two items. At time point t0, the zeroth item contains the following item summary: vehicle identification code is "0x10"; operation setting is "0x07"; and bin flag is "0x00000000". The first item contains the following item summary: vehicle identification code is "0x11"; operation setting is "0x07"; and bin flag is "0x00000000".

[0056] At time point t1, the controller 710 pushes an item from the start queue 530, which contains the following item summary: vehicle identification code is "0x10"; operation setting is "0x07"; and bin flag is "0x0000FFFF" (step S810). The controller 710 performs a logical OR operation on the bin flag "0x0000FFFF" in the pushed item and the corresponding bin flag in the execution table 720 (i.e., the bin flag of the zeroth item) "0x00000000", and updates the calculated result "0x0000FFFF" back to the corresponding bin flag in the execution table 720 (step S820). Since the bin flag "0x0000FFFF" of the zeroth item in the execution table 720 is not equal to 0xFFFFFFFF (the "no" path in step S830), the process cannot proceed downward.

[0057] At time point t2, the controller 710 dequeues an item from the startup queue 530, which contains the following item summary: vehicle identification code is "0x11"; operation setting is "0x07"; and bin flag is "0xFFFFFFFF" (step S810). The controller 710 performs a logical OR operation on the bin flag "0xFFFFFFFF" in the dequeued item and the corresponding bin flag (i.e., the bin flag of the first item) "0x00000000" in the execution table 720, and updates the calculated result "0xFFFFFFFF" back to the corresponding bin flag in the execution table 720 (step S820). Since the bin flag "0x0000FFFF" of the zeroth item in the execution table 720 is still not equal to 0xFFFFFFFF (the "no" path in step S830), even though the first item is ready, the process still cannot proceed downward.

[0058] At time point t3, the controller 710 dequeues an item from the startup queue 530, which contains the following item summary: vehicle identification code is "0x10"; operation setting is "0x07"; and bin flag is "0xFFFF0000" (step S810). The controller 710 performs a logical OR operation on the bin flag "0xFFFF0000" in the dequeued item and the corresponding bin flag (i.e., the bin flag of the zeroth item) "0x0000FFFF" in the execution table 720, and updates the calculated result "0xFFFFFFFF" back to the corresponding bin flag in the execution table 720 (step S820). Since the bin flag "0xFFFFFFFF" of the zeroth item in the execution table 720 is equal to 0xFFFFFFFF (the "yes" path in step S830), the process proceeds to the mid - processing stage of the zeroth item (steps S840 to S860). It should be noted here that when the process finishes the back - end processing stage, the controller 710 deletes the data of the original zeroth item in the execution table 720, and moves the data of the original first and subsequent items in the execution table 720 forward by one item. That is, the zeroth item in the updated execution table 720 contains the following summary information: vehicle identification code is "0x11"; operation setting is "0x07"; and bin flag is "0xFFFFFFFF".

[0059] At the beginning of the mid-end processing stage, the controller 710 determines whether the data of the zeroth item needs to go through the mid-end processing stage based on the operations set in the item (step S840). If so (the "Yes" path in step S840), the RAID engine 135 is set according to the mid-end parameter set 730 of the zeroth item to drive the RAID engine 135 to complete the specified data encryption or data encoding operation for the data of the zeroth item (step S850). Since the encoding of the RAID engine 135 takes some time, the controller 710 can send a Polling to the RAID engine 135 at regular intervals and determine whether the mid-end processing stage is completed based on the replied status (step S860). If the mid-end processing stage has not been completed (the "No" path in step S860), continue to wait and Poll. If the mid-end processing stage is completed (the "Yes" path in step S860), the process enters the next stage (i.e., the back-end processing stage) (steps S870 and S880). In addition, if the mid-end processing stage does not need to be executed (the "No" path in step S840), the process directly enters the next stage (steps S870 and S880).

[0060] The RAID engine 135 can execute functions such as Clear and Encode, Encode, Terminate Encode, Terminate, and Resume according to the instructions sent by the accelerator 133. When receiving the Clear and Encode instruction, the controller in the RAID engine 135 reads the data of multiple main pages (e.g., 32 main pages) from the specified address (which can be called the source address) of the RAM 136 through the shared bus, and overwrites the data stored in the SRAM in the RAID engine 135 with the read data. When receiving the Encode instruction, the controller in the RAID engine 135 reads the data of multiple main pages from the specified address of the RAM 136 through the shared bus, performs an Exclusive-OR calculation on the read data and the data stored in the SRAM in the RAID engine 135, and overwrites the data stored in the SRAM in the RAID engine 135 with the calculation result. When receiving the Terminate Encode instruction, the controller in the RAID engine 135 reads the data of multiple main pages from the specified address of the RAM 136 through the shared bus, performs an Exclusive-OR calculation on the read data and the data stored in the SRAM in the RAID engine 135, overwrites the data stored in the SRAM in the RAID engine 135 with the calculation result, and stores the calculation result in the specified address (which can be called the destination address) of the RAM 136 through the shared bus.

[0061] For example, the first processing unit 134 can store 64 items in the execution table (the vehicle identification codes of which are sequentially from "0x20" to "0x5F"). The mid-end parameter set 730 of the 0th item contains clear and encoding instructions, the mid-end parameter sets 730 of the 1st to 62nd items contain encoding instructions, and the mid-end parameter set 730 of the 63rd item contains an end encoding instruction. Thus, the first processing unit 134 can execute the instructions of these 64 items through the RAID engine 135 to obtain the parity page of the corresponding host data.

[0062] At the beginning of the back-end processing stage, the controller 710 determines whether the data of the 0th item needs to go through the back-end processing stage through the operation setting in the item (step S870). If so (the "yes" path in step S870), the controller 710 sends information to the second processing unit 138 according to the back-end parameter set 740 associated with the 0th item to complete the specified data writing operation (step S880). If it does not need to go through the back-end processing stage (the "no" path in step S870), the controller 710 continues to push the next item from the startup queue 530 for processing (step S810).

[0063] The information sent by the controller 710 to the second processing unit 138 includes a programming index and a source address. The programming index points to a specific address in the SRAM of the accelerator 133, and the source address points to the data to be written to the flash memory module 150 stored in the RAM 136. The second processing unit 138 reads the data from the specified address of the RAM 136 through the shared bus according to the source address, reads the programming table 750 corresponding to the 0th item from the SRAM of the accelerator 133 according to the programming index, and drives the flash memory interface 139 according to the flash memory commands and their programming parameters in the read programming table 750 to write the read data to the specified physical address in the flash memory module 150.

[0064] It should be noted here that the first processing unit 134 is responsible for the operation of the entire flash memory controller 130, including system startup, system shutdown, operation scheduling and execution of various host commands, scheduling and execution of background operations, processing of sudden power-off recovery (SPOR), etc., while the second processing unit 138 is mainly responsible for the tasks of interacting with the flash memory module 150, including driving the flash memory interface 139 to read data from the specified address of the flash memory module 150, writing data to the specified address of the flash memory module 150, erasing the specified physical block of the flash memory module 150, etc.

[0065] The design described above enables the entire system to flexibly configure the data stream. For example, Table 2 shows that the data writing of four items needs to go through the front-end, middle-end, and back-end processing stages and is configured as a pipelined execution in parallel.

[0066] Table 2

[0067] Time Carrier#0 Carrier#1 Carrier#2 Carrier#3 t0 Front-end Processing t1 Mid-end Processing Front-end Processing t2 Back-end Processing Mid-end Processing Front-end Processing t3 Back-end Processing Mid-end Processing Front-end Processing t4 Back-end Processing Mid-end Processing t5 Back-end Processing

[0068] Table 3 shows that the data writing of items 0 to 2 needs to go through the front-end and middle-end processing stages, and the data writing of item 3 needs to go through the front-end, middle-end, and back-end processing stages and is configured as a pipelined execution in parallel.

[0069] Table 3

[0070]

[0071]

[0072] Table 4 shows that the data writing of items 0 to 1 needs to go through the front-end and middle-end processing stages, the data writing of item 2 only needs to go through the middle-end processing stage, and the data writing of item 3 needs to go through the middle-end and back-end processing stages and is configured as a pipelined execution in parallel.

[0073] Table 4

[0074] Time Carrier#0 Carrier#1 Carrier#2 Carrier#3 t0 Front-end Processing t1 Mid-end Processing Front-end Processing t2 Mid-end Processing t3 Mid-end Processing t4 Mid-end Processing t5 Back-end Processing

[0075] Table 5 shows that the data writing of items 0 to 2 needs to go through the front-end processing stage, and the data writing of item 3 needs to go through the front-end and middle-end processing stages and is configured as a pipelined execution in parallel.

[0076] Table 5

[0077] Time Carrier#0 Carrier#1 Carrier#2 Carrier#3 t0 Front-end Processing t1 Front-end Processing t2 Front-end Processing t3 Front-end Processing t4 Mid-end Processing

[0078] All or part of the steps in the method of the present invention can be implemented by a computer program, such as the Firmware Translation Layer (FTL) in a storage device, a driver for specific hardware, or a software program. In addition, it can also be implemented in other types of programs as shown above. Those skilled in the art can write the method of the embodiments of the present invention into program code, which will not be described in detail for the sake of simplicity. The computer program implemented according to the method of the embodiments of the present invention can be stored in a suitable computer-readable storage medium, such as a DVD, a CD-ROM, a USB flash drive, a hard disk, or can also be placed in a network server accessible through a network (for example, the Internet, or other appropriate media).

[0079] Although Figure 1 、Figure 2 , Figure 5 , Figure 7 includes the components described above, but does not exclude the use of more other additional components without violating the spirit of the invention to achieve better technical effects. In addition, although Figure 3 , Figure 6 , Figure 8 's flowchart is executed in the specified order, but those skilled in the art can modify the order between these steps on the premise of achieving the same effect without violating the spirit of the invention. Therefore, the present invention is not limited to only using the order described above. In addition, those skilled in the art can also integrate several steps into one step, or in addition to these steps, perform more steps sequentially or in parallel, and the present invention should not be limited thereby.

[0080] The above description is only a preferred embodiment of the present invention, but it is not used to limit the scope of the present invention. Those skilled in the art can make further improvements and changes on this basis without departing from the spirit and scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the content defined by the claims of this application.

Claims

1. A method for writing data into a flash memory, which is executed by a main processing unit of a flash memory controller, characterized in that, The method of writing data to a flash memory includes: Generating a front-end parameter set, a middle-end parameter set, and a back-end parameter set for each item of data writing, wherein the front-end parameter set includes information of a host write command and a first address configured in a random access memory to store data obtained from the host side, the middle-end parameter set includes a second address configured in the random access memory to store original data, a third address to store an encrypted or encoded result, and parameters for setting a redundant array of independent disks (RAID) engine, and the back-end parameter set includes a programming table and an index of the programming table, and the programming table includes a fourth address configured in the random access memory to store source data; Transmitting the front-end parameter set of each item to a routing engine, such that the routing engine drives a host interface according to the content of the front-end parameter set to obtain data from the host side, and stores the obtained data to the first address in the random access memory; Transmitting the middle-end parameter set of each item to an accelerator, such that the accelerator drives the RAID engine according to the content of the middle-end parameter set to obtain original data from the second address in the random access memory, encrypt the original data or generate parity check page data based on the original data of multiple pages, and store the encrypted or encoded result to the third address in the random access memory; and Transmitting the back-end parameter set of each item to the accelerator, such that the accelerator drives a data access engine according to the content of the back-end parameter set to obtain the source data from the fourth address in the random access memory, and write the source data to a specified physical address of a flash module.

2. The method for writing data into a flash memory according to claim 1, wherein, The main processing unit does not directly drive the host interface, the RAID engine, and the data access engine during the data writing process.

3. The method for writing data to a flash memory according to claim 1, wherein, Includes: Transmitting a vehicle identification code corresponding to each item to the routing engine and the accelerator for coordinating the operation of each item between the routing engine and the accelerator.

4. The method of writing data to a flash memory according to claim 1, wherein, Includes: Transmitting information on whether each item needs to go through a front-end processing stage to the routing engine for the routing engine to determine whether to drive the host interface for each item.

5. The method of writing data to a flash memory according to claim 1, wherein Includes: Transmitting information on whether each item needs to go through a middle-end processing stage to the accelerator for the accelerator to determine whether to drive the RAID engine for each item; And Transmitting information on whether each item needs to go through a back-end processing stage to the accelerator for the accelerator to determine whether to drive the data access engine for each item.

6. The method for writing data to a flash memory as claimed in claim 5, wherein, Includes: Storing the middle-end parameter sets and the back-end parameter sets of multiple items in an execution table in the accelerator in a specified order, such that the accelerator starts the middle-end processing stage and / or the back-end processing stage for multiple items according to the specified order.

7. The method for writing data to a flash memory as claimed in claim 6, wherein, Includes: Transmit a plurality of initial bin flags of each of the items to the accelerator for notifying the accelerator about which parts of the data in each of the items need to be prepared and completed in the front-end processing stage.

8. A computer-readable storage medium for storing program code executable by a main processing unit of a flash memory controller, characterized in that, When the program code is executed by the main processing unit, it implements the method of writing data to the flash memory as described in any one of claims 1 to 7.

9. A device for writing data into a flash memory, characterized in that, Comprising: A routing engine coupled to the host interface; An accelerator coupled to the redundant array of independent disks engine and the data access engine; And A main processing unit coupled to the routing engine and the accelerator, configured to generate a front-end parameter set, a middle-end parameter set, and a back-end parameter set for each item of data writing, wherein the front-end parameter set includes information of a host write command and a first address configured in the random access memory to store data obtained from the host side, the middle-end parameter set includes a second address configured in the random access memory to store raw data and a third address to store an encrypted or encoded result, and parameters for setting the redundant array of independent disks engine, and the back-end parameter set includes a programming table and an index of the programming table, and the programming table includes a fourth address configured in the random access memory to store source data; transmit the front-end parameter set of each item to the routing engine, such that the routing engine drives the host interface according to the content of the front-end parameter set to obtain data from the host side, and stores the obtained data to the first address in the random access memory; transmit the middle-end parameter set of each item to the accelerator, such that the accelerator drives the redundant array of independent disks engine according to the content of the middle-end parameter set to obtain raw data from the second address in the random access memory, encrypt the raw data or generate parity check pages of data based on multiple pages of the raw data, and store the encrypted or encoded result to the third address in the random access memory; And transmit the back-end parameter set of each item to the accelerator, such that the accelerator drives the data access engine according to the content of the back-end parameter set to obtain the source data from the fourth address in the random access memory, and write the source data to a specified physical address of the flash module.

10. The apparatus for writing data to a flash memory according to claim 9, wherein, The main processing unit does not directly drive the host interface, the redundant array of independent disks engine, and the data access engine during the data writing process.

11. The apparatus for writing data to a flash memory according to claim 9, wherein, The main processing unit is configured to transmit a vehicle identification code corresponding to each item to the routing engine and the accelerator for coordinating the operation of each item between the routing engine and the accelerator.

12. The apparatus for writing data to a flash memory according to claim 9, wherein, The main processing unit is configured to transmit information about whether each item needs to go through the front-end processing stage to the routing engine for the routing engine to determine whether to drive the host interface for each item.

13. The apparatus for writing data to a flash memory according to claim 9, wherein, The main processing unit is used to transmit information on whether each of the items needs to go through the mid - end processing stage to the accelerator, so as to enable the accelerator to determine whether to drive the redundant array of independent disks (RAID) engine for each of the items; and transmit information on whether each of the items needs to go through the back - end processing stage to the accelerator, so as to enable the accelerator to determine whether to drive the data access engine for each of the items.

14. The apparatus for writing data to a flash memory according to claim 13, wherein The main processing unit is used to store the mid - end parameter sets and the back - end parameter sets of the multiple items in an execution table in the accelerator in a specified order, so that the accelerator starts the mid - end processing stage and / or the back - end processing stage for the multiple items in the specified order.

15. The apparatus for writing data to a flash memory according to claim 14, wherein, The main processing unit is used to transmit multiple initial cabinet location flags of each of the items to the accelerator, for notifying the accelerator about which parts of the data in each of the items need to be prepared and completed in the front - end processing stage.

Images