Method and apparatus for writing data to a flash memory

Abstract

The present invention relates to a method and apparatus for writing data to a flash memory. The method for writing data to the flash memory is executed by a controller of an accelerator and includes: reading operation settings of a virtual vehicle from a static random access memory; when the operation settings indicate that first data of the virtual vehicle needs to go through an intermediate processing stage, setting a redundant array of independent disks (RAID) engine according to an intermediate parameter set stored in the static random access memory; when the operation settings indicate that the first data of the virtual vehicle does not need to go through the intermediate processing stage, or the first data of the virtual vehicle has already gone through the intermediate processing stage, determining whether second data of the virtual vehicle needs to go through a post-processing stage according to the operation settings; and when the operation settings indicate that the second data of the virtual vehicle needs to go through the post-processing stage, sending a programming index to a data access engine according to a post-processing parameter set stored in the static random access memory. Through the setting of a dedicated accelerator, the main processing unit does not need to supervise the operation of the entire data write 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 method and 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, and a central processing unit (Host) can provide any address for accessing the NOR flash memory on an address pin and obtain the data stored at that address from a data pin of the NOR flash memory in a timely manner. In contrast, a NAND flash memory is not a random access device but a serial access device. A NAND flash memory cannot access any random address like a NOR flash memory. Instead, the central processing unit needs to write the values of a series of 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 a flash memory) or a block (the smallest data block for an erase operation in a 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 method and apparatus for writing data to a flash memory to improve the data writing performance. Summary of the Invention

[0003] In view of this, how to alleviate 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 controller of an accelerator and includes: reading operation settings of a virtual vehicle from a static random access memory; when the operation settings indicate that first data of the virtual vehicle needs to go through an intermediate processing stage, setting a Redundant Array of Independent Disks (RAID) Engine according to an intermediate parameter set stored in the static random access memory; when the operation settings indicate that the first data of the virtual vehicle does not need to go through the intermediate processing stage, or the first data of the virtual vehicle has already gone through the intermediate processing stage, determining whether second data of the virtual vehicle needs to go through a post-processing stage according to the operation settings; and when the operation settings indicate that the second data of the virtual vehicle needs to go through the post-processing stage, sending a programming index to a data access engine according to a post-processing parameter set stored in the static random access memory.

[0005] The present invention also relates to a device for writing data to a flash memory, comprising: a static random access memory; and a controller coupled to the static random access memory. The controller is configured to read the operation settings of a virtual vehicle from the static random access memory; when the operation settings indicate that the first data of the virtual vehicle needs to go through an intermediate processing stage, set a redundant array of independent disks (RAID) engine according to a set of intermediate parameters stored in the static random access memory; when the operation settings indicate that the first data of the virtual vehicle does not need to go through an intermediate processing stage, or the first data of the virtual vehicle has already gone through an intermediate processing stage, determine whether the second data of the virtual vehicle needs to go through a post-processing stage according to the operation settings; and when the operation settings indicate that the second data of the virtual vehicle needs to go through a back-end processing stage, send a programming index to a data access engine according to a set of back-end parameters stored in the static random access memory.

[0006] One of the advantages of the above embodiments is that a dedicated routing engine and accelerator are used to integrate the operations of the host interface, RAID engine, and data access engine to complete various data writing operations, so that the main processing unit of the flash controller does not need to supervise the entire data writing data stream operation and wait for the status responses of the host interface, RAID engine, and data access engine during the data stream operation. These saved time and computing resources allow the main processing unit of the flash controller to perform other tasks, improving the overall performance of the system.

[0007] Another advantage of the above embodiments is that through the rack position flag, the items that the host interface can execute out of order and separately in the front-end processing stage can be restored to the original execution order by the accelerator in the intermediate and back-end processing stages.

[0008] 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 intermediate and / or back-end processing stages that do not need to be executed, providing configuration flexibility.

[0009] Other advantages of the present invention will be explained in more detail in conjunction with the following description and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0013] Figure 3 It is a data writing flowchart according to an embodiment of the present invention.

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

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

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

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

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

[0019] Among them, a brief description of the symbols in the drawings is as follows:

[0020] 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: Pre-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

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

[0022] It must be understood that the words "including", "comprising", 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.

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

[0024] 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. Conversely, 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.

[0025] In a flash memory controller, the entire data write data stream can be divided into three processing stages: front-end; mid-end; and 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 the 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 known as 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 above problems, 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.

[0026] ReferenceFigure 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 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 (Read Command), write commands (Write Command), discard commands (Discard Command), erase commands (Erase Command), 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 known as host data) read from the host side 110 and about to be written to the flash memory module 150, as well as 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 also 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.

[0027] 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, and 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 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, control signals are transmitted using the control lines.

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

[0029] 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 memory cells in the memory array can be configured as single-level cells (SLCs), multi-level cells (MLCs), triple-level cells (TLCs), quad-level cells (QLCs), or any combination of the above. 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 written 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.

[0030] 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 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 parallel, or write user data to the activated NAND flash memory cells.

[0031] Reference Figure 3The flowchart of 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, reorder the obtained data to restore the original data order, encrypt the data group of the reordered data or generate parity check page data, and store the encrypted data or the 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 data encrypted 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, appending 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.

[0032] 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. To reduce the time and computing resources occupied by the first processing unit 134, in the flash memory controller 130 of the present invention embodiment, a routing engine 132 and an accelerator 133 implemented by dedicated circuits are provided, for the first processing unit 134 to selectively start the routing engine 132, the accelerator 133, and the second processor 138 through a control protocol, and enable the execution of the entire data stream to be concatenated 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 data writing.

[0033] 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 the 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 of information such as which carrier the data to be written for each item (also referred to as the data writing item) belongs to, the preparation status of each cargo in this carrier, and 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 to Byte1) and cargo flags 420 of 4 bytes (Byte2 to 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, after each collection of 128KB of data, drive the data access engine 137 to write the 128KB of data into multiple NAND flash memory cells in the flash memory module 150 in a multi-channel interleaved manner. 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, the 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 location (also called a bin) in the 128KB of data is ready. "1" means it is ready, and "0" means it is 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 the settings of some systems, 4KB of data can also be regarded as the data of a host page (including eight consecutive LBAs).

[0034] For example, when the firmware executed by the first processing unit 134 receives a host write command from the host side 110 through 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 stages; the cabinet position flag is "0x00000000" (which can be called the initialized cabinet position flag), indicating that no data is ready. Then, the first processing unit 134 transmits the project summary, the host write command, and the specified 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 include the following information: operation code, starting logical block address number (Logic Block Address, LBA Number), LBA length, etc. The host write command and the destination address can be collectively referred to as the front-end parameter set (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.

[0035] For another example, when the firmware executed by the first processing unit 134 receives a host write command from the host side 110 through 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 cabinet position flag is "0xFFFF0000" (which can be called the initialized cabinet position flag), indicating that the data in the 0th to 15th cabinet positions is not ready, while the data in the 16th to 31st cabinet positions is ready (which also implies that these data can be ignored and no longer need to be processed). Then, the first processing unit 134 transmits the project summary, the information of the host write command, and the specified address in the RAM 136 for storing 64 KB of data to the routing engine 132.

[0036] 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 stage; the cabinet position flag is "0xFFFFFFFF" (which can be called the initialized cabinet position flag), indicating that all data is ready.

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

[0038] Before actually pushing the preamble 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 a number (for example, 64) of items in 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 the 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.

[0039] In response to a series of host write commands or the execution of background programs, the first processing unit 134 generates pre-information for multiple items, an initial cabinet position flag, a front-end parameter set, middle-end parameters, and a back-end parameter set. After the first processing unit 134 transmits the pre-information for multiple items, the initial cabinet position flag, and the front-end parameter set to the routing engine 132, and transmits the pre-information for multiple items, the initial cabinet position flag, the middle-end parameters, 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 system performance. 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.

[0040] The routing engine 132 receives an operation setting and a front-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 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, causing the host interface 131 to obtain data from the host 110 and store the obtained data at a specified address in the random access memory 136 through the shared bus architecture.

[0041] 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 through 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 by the starting LBA number and the LBA length), and the specified location in the RAM 136 where the host data is stored.

[0042] See also Figure 6 Method flowchart of the front-end processing stage 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 stage based on the operation settings in the item (step S620). If so (the "yes" path in step S620), the small loop is started 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.

[0043] 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 bin flag to reflect the execution status of the host interface 131 (step S640), and pushes the preamble information and the updated bin flag into the startup queue 530 for the accelerator 133 to decide whether to start the operations in the subsequent processing stage (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 bin 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 bin flag to "0xFFFF00FF", and pushes the updated item summary (including the vehicle identification code "0x01"; the operation setting "0x07"; and the bin flag "0xFFFF00FF") into the startup queue 530. After the execution of the second batch of 32KB data is successful, the controller 520 updates the bin flag to "0xFFFFFF00", and pushes the updated item summary (including the vehicle identification code "0x01"; the operation setting "0x07"; and the bin flag "0xFFFFFF00") into the startup queue 530.

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

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

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

[0047] 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 the item summaries of multiple items (i.e., virtual vehicles), and the content of the execution table 720 is filled by the first processing unit 134. An example of the execution table 720 is shown in Table 1:

[0048] Table 1

[0049] Project Number Pre-information Cargo Location Flag 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

[0050] 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 mid - 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.

[0051] If there are any projects that need to be processed by the RAID engine 135, the first processing unit 134 stores the corresponding mid - end parameter set 730 in a specified address in the SRAM of the accelerator 133 in advance, so that the controller 710 can set the RAID engine 135 accordingly to complete the mid - 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 a specified address in the SRAM of the accelerator 133 in advance, 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.

[0052] Another reference Figure 8Method flowchart of the middle and back-end processing stages executed by the controller 710 as 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 cabinet flag in the pushed item and the corresponding cabinet flag in the execution table 720, and updating the calculation result back to the corresponding cabinet flag in the execution table 720 (step S820), and determining whether the cabinet 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 stage of the zeroth item has been completed or the front-end processing stage does not need to be executed, and the zeroth item in the execution table 720 enters the middle-end processing stage (steps S840 to S860). If not (the "no" path in step S830), it means that the front-end processing stage 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).

[0053] 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 cabinet flag is "0x00000000". The first item contains the following item summary: vehicle identification code is "0x11"; operation setting is "0x07"; and cabinet flag is "0x00000000".

[0054] 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 cabinet flag is "0x0000FFFF" (step S810). The controller 710 performs a logical OR operation on the cabinet flag "0x0000FFFF" in the pushed item and the corresponding cabinet flag (i.e., the cabinet flag of the zeroth item) "0x00000000" in the execution table 720, and updates the calculated result "0x0000FFFF" back to the corresponding cabinet flag in the execution table 720 (step S820). Since the cabinet 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.

[0055] 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 cabinet position flag is "0xFFFFFFFF" (step S810). The controller 710 performs a logical OR operation on the cabinet position flag "0xFFFFFFFF" in the dequeued item and the corresponding cabinet position flag (i.e., the cabinet position flag of the first item) "0x00000000" in the execution table 720, and updates the calculated result "0xFFFFFFFF" back to the corresponding cabinet position flag in the execution table 720 (step S820). Since the cabinet position 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.

[0056] 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 cabinet position flag is "0xFFFF0000" (step S810). The controller 710 performs a logical OR operation on the cabinet position flag "0xFFFF0000" in the dequeued item and the corresponding cabinet position flag (i.e., the cabinet position flag of the zeroth item) "0x0000FFFF" in the execution table 720, and updates the calculated result "0xFFFFFFFF" back to the corresponding cabinet position flag in the execution table 720 (step S820). Since the cabinet position 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 to say, the zeroth item in the updated execution table 720 contains the following summary information: vehicle identification code is "0x11"; operation setting is "0x07"; and cabinet position flag is "0xFFFFFFFF".

[0057] At the beginning of the mid-end processing stage, the controller 710 determines whether the data of the zero-th 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 zero-th item, so as to drive the RAID engine 135 to complete the specified data encryption or data encoding operation for the data of the zero-th 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).

[0058] The RAID engine 135 can execute functions such as Clear and Encode, Encode, Terminate Encode, Terminate, and Resume after Terminate 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 (such as 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 to the specified address (which can be called the destination address) of the RAM 136 through the shared bus.

[0059] For example, the first processing unit 134 can store 64 items (whose vehicle identification codes are sequentially from "0x20" to "0x5F") in the execution table. 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.

[0060] 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 based on 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).

[0061] 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 RAM136 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.

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

[0063] The design described above enables the entire system to flexibly configure the data flow. 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 into a pipelined parallel execution.

[0064] Table 2

[0065]

[0066]

[0067] 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 into a pipelined parallel execution.

[0068] Table 3

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

[0070] 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 into a pipelined parallel execution.

[0071] Table 4

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

[0073] 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 into a pipelined parallel execution.

[0074] Table 5

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

[0076] 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 brevity. 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, CD-ROM, USB flash drive, hard disk, or can also be placed on a network server accessible through a network (for example, the Internet, or other appropriate media).

[0077] 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 to achieve better technical effects without violating the spirit of the invention. In addition, although Figure 3 , Figure 6 , Figure 8 's flowchart is executed in a 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 execute more steps sequentially or in parallel in addition to these steps, and the present invention should not be limited thereby.

[0078] The above 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 to a flash memory, which is executed by a controller of an accelerator, characterized in that, The method of writing data to a flash memory includes: Reading the operation settings of a virtual vehicle from a static random access memory, where the accelerator includes the static random access memory; When the operation settings indicate that the first data of the virtual vehicle needs to go through an intermediate processing stage, setting a redundant array of independent disks (RAID) engine according to the intermediate parameter set stored in the static random access memory, for driving the RAID engine to complete specified data encryption or data encoding operations for the first data of the virtual vehicle; When the operation settings indicate that the first data of the virtual vehicle does not need to go through an intermediate processing stage, or the first data of the virtual vehicle has already gone through an intermediate processing stage, judging whether the second data of the virtual vehicle needs to go through a post - processing stage according to the operation settings; and When the operation settings indicate that the second data of the virtual vehicle needs to go through the post - processing stage, sending a programming index to a data access engine according to the post - end parameter set stored in the static random access memory, so that the data access engine reads a programming table from the static random access memory according to the programming index, and writes the second data of the virtual vehicle to a specified address of a flash module according to the content of the programming table.

2. The method for writing data to a flash memory according to claim 1, characterized in that, The operation settings are generated by a processing unit, and the processing unit does not directly drive 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, characterized in that, The intermediate parameter set includes a first address in the random access memory configured to store the first data of the virtual vehicle, a second address for storing the encrypted or encoded result, and parameters for setting the RAID engine; the random access memory is disposed outside the accelerator.

4. The method for writing data to a flash memory according to claim 3, characterized in that, The programming table includes the address of the random access memory where the second data of the virtual vehicle is stored, a series of flash commands and their programming parameters; the random access memory is disposed outside the accelerator.

5. The method for writing data to a flash memory according to claim 1, characterized in that, Includes: After setting the RAID engine, continuously sending queries to the RAID engine until the status replied by the RAID engine indicates that the intermediate processing stage has been completed.

6. The method for writing data to a flash memory according to claim 1, characterized in that, Includes: Obtaining a first cabinet flag associated with the virtual vehicle from a routing engine; Reading a second cabinet flag of the virtual vehicle from the static random access memory; Generating a third cabinet flag according to the first cabinet flag and the second cabinet flag; and After judging according to the information in the third cabinet flag that all the data in the cabinets of the virtual vehicle have gone through a front - end processing stage or do not need to go through the front - end processing stage, judging whether the operation settings indicate that the first data of the virtual vehicle needs to go through an intermediate processing stage.

7. The method for writing data to a flash memory according to claim 6, characterized in that, The third cabinet flag is the result of a logical OR operation of the first cabinet flag and the second cabinet flag, and all bits in the third cabinet flag are "1".

8. An apparatus for writing data to a flash memory, characterized in that, Includes: A static random access memory for storing operation settings of a virtual vehicle; A controller, coupled to the static random access memory, for reading the operation settings of the virtual vehicle from the static random access memory; when the operation settings indicate that the first data of the virtual vehicle needs to go through an intermediate processing stage, setting a redundant array of independent disks (RAID) engine according to the intermediate parameter set stored in the static random access memory, for driving the RAID engine to complete specified data encryption or data encoding operations for the first data of the virtual vehicle; when the operation settings indicate that the first data of the virtual vehicle does not need to go through the intermediate processing stage, or the first data of the virtual vehicle has already gone through the intermediate processing stage, judging whether the second data of the virtual vehicle needs to go through a post-processing stage according to the operation settings; and when the operation settings indicate that the second data of the virtual vehicle needs to go through the post-processing stage, sending a programming index to a data access engine according to the post-processing parameter set stored in the static random access memory, so that the data access engine reads a programming table from the static random access memory according to the programming index, and writes the second data of the virtual vehicle to a specified address of a flash memory module according to the content of the programming table.

9. The apparatus for writing data to a flash memory according to claim 8, characterized in that, The operation settings are generated by a processing unit, and the processing unit does not directly drive the RAID engine and the data access engine during the data writing process.

10. The apparatus for writing data to a flash memory according to claim 8, characterized in that, The intermediate parameter set includes a first address in the random access memory configured to store the first data of the virtual vehicle, a second address for storing the encrypted or encoded result, and parameters for setting the RAID engine; the random access memory is disposed outside the device.

11. The apparatus for writing data to a flash memory according to claim 8, characterized in that, The programming table includes the address of the random access memory where the second data of the virtual vehicle is stored, a series of flash memory commands and their programming parameters; the random access memory is disposed outside the device.

12. The apparatus for writing data to a flash memory according to claim 8, characterized in that, The controller is configured to continuously send queries to the RAID engine after setting the RAID engine until the status replied by the RAID engine indicates that the intermediate processing stage has been completed.

13. The apparatus for writing data to a flash memory according to claim 8, wherein, The controller is configured to obtain a first cabinet position flag associated with the virtual vehicle from a routing engine; read a second cabinet position flag of the virtual vehicle from the static random access memory; generate a third cabinet position flag according to the first cabinet position flag and the second cabinet position flag; and judge whether the operation settings indicate that the first data of the virtual vehicle needs to go through an intermediate processing stage after judging that all the data in all cabinet positions of the virtual vehicle have gone through a front-end processing stage or do not need to go through the front-end processing stage according to the information in the third cabinet position flag.

14. The apparatus for writing data to a flash memory according to claim 13, wherein, The third cabinet position flag is the result of a logical OR operation of the first cabinet position flag and the second cabinet position flag, and all bits in the third cabinet position flag are "1".

Images