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 includes: an accelerator obtains an execution table, a first mid-end parameter set, a first back-end parameter set, a second mid-end parameter set, and a second back-end parameter set from a processing unit. Among them, the execution table includes a first virtual vehicle and a second virtual vehicle. The first virtual vehicle includes a first bin flag, and the second virtual vehicle includes a second bin flag. The execution table indicates that the data of the first virtual vehicle must enter the mid-end processing stage and the back-end processing stage earlier than the data of all other virtual vehicles in the execution table; and after obtaining a third bin flag associated with the second virtual vehicle from a routing engine, it is determined according to the information in the first bin flag that there is still data in the bins of the first virtual vehicle that has not been completed, and the second virtual vehicle is not allowed to continue the mid-end processing stage and the back-end processing stage.

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. A central processing unit (Host) can provide any address for accessing the NOR flash memory on an address pin, and obtain 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 values of a serial group 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 mitigate or eliminate the defects 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, including: an accelerator obtains an execution table, a first mid-end parameter set, a first back-end parameter set, a second mid-end parameter set, and a second back-end parameter set from a processing unit, where the execution table includes a first virtual vehicle and a second virtual vehicle, the first virtual vehicle includes a first bin flag indicating which bins in the first virtual vehicle need to have their data prepared in a front-end processing stage, the second virtual vehicle includes a second bin flag indicating which bins in the second virtual vehicle need to have their data prepared in the front-end processing stage, and the execution table indicates that the data of the first virtual vehicle must enter a mid-end processing stage and a back-end processing stage earlier than the data of all other virtual vehicles in the execution table; and after obtaining a third bin flag associated with the second virtual vehicle from a routing engine, determining, according to information in the first bin flag, that there is still data in a bin of the first virtual vehicle that has not been completed, and not allowing the second virtual vehicle to continue with the mid-end processing stage and the back-end processing stage, where the third bin flag indicates that the data of all bins in the second virtual vehicle has been prepared in the front-end processing stage.

[0005] The present invention also relates to a device for writing data into a flash memory, comprising: a processing unit; a routing engine coupled to the processing unit; and an accelerator coupled to the processing unit and the routing engine. The accelerator is configured to obtain an execution table, a first mid-end parameter set, a first back-end parameter set, a second mid-end parameter set, and a second back-end parameter set from the processing unit. The execution table includes a first virtual vehicle and a second virtual vehicle. The first virtual vehicle includes a first bin flag indicating which bins in the first virtual vehicle need to have their data prepared during the front-end processing stage. The second virtual vehicle includes a second bin flag indicating which bins in the second virtual vehicle need to have their data prepared during the front-end processing stage. The execution table indicates that the data of the first virtual vehicle must enter the mid-end processing stage and the back-end processing stage earlier than the data of all other virtual vehicles in the execution table. After obtaining a third bin flag associated with the second virtual vehicle from the routing engine, the accelerator determines that there is still data in some bins of the first virtual vehicle that has not been completed based on the information in the first bin flag, and does not allow the second virtual vehicle to continue with the mid-end processing stage and the back-end processing stage, where the third bin flag indicates that the data of all bins in the second virtual vehicle has been prepared during the front-end processing stage.

[0006] One of the advantages of the embodiment 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 flow operation and wait for the status responses of the host interface, RAID engine, and data access engine during the data flow operation. The time and computing resources saved can allow the main processing unit of the flash controller to perform other tasks, improving the overall system performance.

[0007] Another advantage of the above embodiment is that, through the bin flags, the items that the host interface can execute in an out-of-order and separate manner during the front-end processing stage can be restored to the original execution order by the accelerator during the mid-end and back-end processing stages.

[0008] Another advantage of the above embodiment is that, through the operation setting 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 mid-end 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. Description of the Drawings

[0010] The drawings described herein are used to provide a further understanding of the present application and form 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.

[0011] Figure 1 System architecture diagram of an electronic device according to an embodiment of the present invention.

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

[0013] Figure 3 Data writing flowchart according to an embodiment of the present invention.

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

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

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

[0017] Figure 7 Block diagram of an accelerator according to an embodiment of the present invention.

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

[0019] Among them, a simple 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 denote the same or similar components or method flows.

[0022] It should be understood that terms such as "comprising" and "including" used in this specification are used to indicate the presence of specific technical features, numerical values, method steps, operations, components, and / or assemblies, but do not exclude the addition of more technical features, numerical values, method steps, operations, components, assemblies, or any combination thereof.

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

[0024] It should 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 terms 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", and so on.

[0025] In a flash memory controller, the data stream for the entire data writing 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 the redundant array of independent disks (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 after 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 start, control, and supervise 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 the relevant hardware (such as the RAID 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.

[0026] 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 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 referred to 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 returned to the processing unit 134 on the data line. To complete the data read operation, control signals are transmitted using the control line.

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

[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 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, attaching low-density parity check codes to 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 embodiments, 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 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 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 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 the preamble information 410 of 2 bytes (Byte0 to Byte1) and the 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 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 the information of the operation setting, and the lowest three bits of it store the information of 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 16KB, 32KB, 64KB, etc. Since a project may not be able to control the entire 128KB of data writing operation, each bit in the cargo flag 420 is used to indicate whether the data at a specific position (also called a cargo position) in the 128KB of data is ready. "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).

[0034] 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 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 110 via the host interface 131 to indicate writing 64 KB of data, the following pre-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 cabinets is not ready, while the data in the 16th to 31st cabinets is ready (which also implies that these data can be ignored and no further processing is required). 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 pre-information is generated: The vehicle identification code is "0x01", and 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 in the front-end processing stage.

[0038] 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 a number (for example, 64) of items into the static random access memory (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) can 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 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 for multiple items, the initial cabinet location flag, and the front-end parameter set to the routing engine 132, and transmits the pre-information for 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 thereby complete various data write operations without the first processing unit 134 supervising the entire data write data flow operation and waiting for status replies from the host interface 131, the RAID engine 135, and the data access engine 137 during the data flow operation. In other words, during the data write process, 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, 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. The time and computing resources saved can enable the first processing unit 134 to execute other tasks and improve the overall performance of the system. Subsequently, 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, 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, such that the host interface 131 obtains data from the host 110 and stores 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, for indicating 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.

[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 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 of 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 cabinet flag to reflect the execution status of the host interface 131 (step S640), and pushes the preamble information and the updated cabinet flag into the startup queue 530 for the accelerator 133 to determine 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 cabinet 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 flag to "0xFFFF00FF", and pushes the updated item summary (including the vehicle identification code "0x01"; the operation setting "0x07"; and the cabinet 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 flag to "0xFFFFFF00", and pushes the updated item summary (including the vehicle identification code "0x01"; the operation setting "0x07"; and the cabinet 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 controller 520 pushes the original or updated item summary 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, such 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, such 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 an advanced high-performance 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]

[0050] The first processing unit 134 sequentially fills in the project summary (including pre - information and cabinet location 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 cabinet location flag (cargoFlag#10), the project summary of the 11th project includes the corresponding pre - information (leadInfo#11) and cabinet location flag (cargoFlag#11), and so on. Although the pushing order of the projects in the startup 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 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 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 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.

[0052] Another reference Figure 8The method flowchart of the middle and back-end processing stages 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 startup 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 calculated 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 does not require execution of the front-end processing stage, 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 startup 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 startup 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 in the execution table 720 (i.e., the cabinet flag of the zeroth item) "0x00000000", 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 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.

[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 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 to say, the zeroth item of the updated execution table 720 contains the following summary information: vehicle identification code is "0x11"; operation setting is "0x07"; and bin flag is "0xFFFFFFFF".

[0057] 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), then 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 according to the instructions issued 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.

[0059] For example, the first processing unit 134 may store 64 items in the execution table (whose vehicle identification codes 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.

[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 pipeline for parallel execution.

[0064] Table 2

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

[0066] 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 pipeline for parallel execution.

[0067] Table 3

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

[0069] 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 pipeline for parallel execution.

[0070] Table 4

[0071]

[0072]

[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 pipeline for 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 according to the present invention can be implemented by a computer program, such as a 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 suitable 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 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 a specified order, but without violating the spirit of the invention, those skilled in the art can modify the order between these steps on the premise of achieving the same effect. 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, execute more steps sequentially or in parallel, 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 intended 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 in the claims of this application.

Claims

1. A method for writing data into a flash memory, implemented in a flash memory controller, the flash memory controller including a processing unit, a routing engine, and an accelerator, characterized in that, the method for writing data into the flash memory includes: the accelerator obtains an execution table, a first mid-end parameter set, a first back-end parameter set, a second mid-end parameter set, and a second back-end parameter set from the processing unit, wherein the execution table includes a first virtual vehicle and a second virtual vehicle, the first virtual vehicle includes a first bin flag, the first mid-end parameter set and the first back-end parameter set are associated with the first virtual vehicle, the first bin flag indicates which bins in the first virtual vehicle need to have their data prepared in the front-end processing stage, the second virtual vehicle includes a second bin flag, the second mid-end parameter set and the second back-end parameter set are associated with the second virtual vehicle, the second bin flag indicates which bins in the second virtual vehicle need to have their data prepared in the front-end processing stage, and the execution table indicates that the data of the first virtual vehicle must enter the mid-end processing stage and the back-end processing stage earlier than the data of all other virtual vehicles in the execution table; the routing engine obtains the first virtual vehicle, a first front-end parameter set associated with the first virtual vehicle, the second virtual vehicle, and a second front-end parameter set associated with the second virtual vehicle from the processing unit, wherein the first virtual vehicle includes the first bin flag, and the second virtual vehicle includes the second bin flag; the routing engine drives the host interface according to the second front-end parameter set to obtain the data of all bins in the second virtual vehicle from the host side and store it at a specified address in the random access memory; the routing engine updates the second bin flag to be a third bin flag, which is used to indicate that the data of all bins in the second virtual vehicle has been prepared in the front-end processing stage; and after obtaining the third bin flag associated with the second virtual vehicle from the routing engine, the accelerator determines that there is still data in some bins of the first virtual vehicle that has not been completed through the information in the first bin flag, and does not allow the second virtual vehicle to continue with the mid-end processing stage and the back-end processing stage.

2. The method for writing data into a flash memory according to claim 1, characterized in that, the time when the first virtual vehicle arrives at the routing engine is earlier than the time when the second virtual vehicle arrives at the routing engine.

3. The method for writing data into a flash memory according to claim 1, characterized in that, it includes: the routing engine drives the host interface according to the first front-end parameter set to obtain the data of a first part of the bins in the first virtual vehicle from the host side and store it at a specified address in the random access memory; the routing engine updates the first bin flag to be a fourth bin flag, which is used to indicate that the data of the first part of the bins in the first virtual vehicle has been prepared in the front-end processing stage; and After the accelerator obtains the fourth bin flag associated with the first virtual vehicle from the routing engine, it generates a fifth bin flag based on the first bin flag and the fourth bin flag, determines that there is still data in the bins of the first virtual vehicle that has not been completed through the information in the fifth bin flag, and does not allow the first virtual vehicle to continue with the middle-end processing stage and the back-end processing stage.

4. The method of writing data to a flash memory as claimed in claim 3, wherein, the fifth bin flag is the result of a logical OR operation on the first bin flag and the fourth bin flag, and at least one bit in the fifth bin flag is "0".

5. The method of writing data to a flash memory as claimed in claim 3, wherein, comprising: The routing engine drives the host interface according to the first front-end parameter set to obtain data of a second part of the bins in the first virtual vehicle from the host side and store it at a specified address in the random access memory; The routing engine updates the first bin flag to be a sixth bin flag to indicate that the data of the second part of the bins in the first virtual vehicle has been prepared and completed in the front-end processing stage; and After the accelerator obtains the sixth bin flag associated with the first virtual vehicle from the routing engine, it generates a seventh bin flag based on the fifth bin flag and the sixth bin flag, determines that all the data in the bins of the first virtual vehicle has been completed through the information in the seventh bin flag, and allows the first virtual vehicle to continue with the middle-end processing stage and the back-end processing stage.

6. The method of writing data to a flash memory as claimed in claim 5, wherein, the seventh bin flag is the result of a logical OR operation on the fifth bin flag and the sixth bin flag, and all bits in the seventh bin flag are "1".

7. An apparatus for writing data to a flash memory, wherein, comprising: a processing unit; a routing engine coupled to the processing unit; an accelerator coupled to the processing unit and the routing engine Wherein, the accelerator obtains an execution table, a first mid-end parameter set, a first back-end parameter set, a second mid-end parameter set, and a second back-end parameter set from the processing unit. The execution table includes a first virtual vehicle and a second virtual vehicle. The first virtual vehicle includes a first bin flag. The first mid-end parameter set and the first back-end parameter set are associated with the first virtual vehicle. The first bin flag indicates which bins in the first virtual vehicle need to have their data prepared during the front-end processing stage. The second virtual vehicle includes a second bin flag. The second mid-end parameter set and the second back-end parameter set are associated with the second virtual vehicle. The second bin flag indicates which bins in the second virtual vehicle need to have their data prepared during the front-end processing stage. And the execution table indicates that the data of the first virtual vehicle must enter the mid-end processing stage and the back-end processing stage earlier than the data of all other virtual vehicles in the execution table; Wherein, the routing engine obtains the first virtual vehicle, a first front-end parameter set associated with the first virtual vehicle, the second virtual vehicle, and a second front-end parameter set associated with the second virtual vehicle from the processing unit. The first virtual vehicle includes the first bin flag, and the second virtual vehicle includes the second bin flag; drives the host interface according to the second front-end parameter set to obtain the data of all bins in the second virtual vehicle from the host side and stores it at a specified address in the random access memory; updates the second bin flag to become a third bin flag for indicating that the data of all bins in the second virtual vehicle has been prepared during the front-end processing stage; and wherein, after the accelerator obtains the third bin flag associated with the second virtual vehicle from the routing engine, it determines through the information in the first bin flag that there is still data in some bins of the first virtual vehicle that has not been completed, and does not allow the second virtual vehicle to continue with the mid-end processing stage and the back-end processing stage.

8. The apparatus for writing data to a flash memory according to claim 7, wherein, the time when the first virtual vehicle arrives at the routing engine is earlier than the time when the second virtual vehicle arrives at the routing engine.

9. The apparatus for writing data to a flash memory according to claim 7, wherein, the routing engine drives the host interface according to the first front-end parameter set to obtain the data of the first part of the bins in the first virtual vehicle from the host side and stores it at the specified address in the random access memory; updates the first bin flag to become a fourth bin flag for indicating that the data of the first part of the bins in the first virtual vehicle has been prepared during the front-end processing stage; and After obtaining the fourth bin flag associated with the first virtual vehicle from the routing engine, the accelerator generates a fifth bin flag based on the first bin flag and the fourth bin flag, determines that there is still data in the bins of the first virtual vehicle that has not been completed through the information in the fifth bin flag, and does not allow the first virtual vehicle to continue with the middle-end processing stage and the back-end processing stage.

10. The apparatus for writing data to a flash memory as claimed in claim 9, wherein, the fifth bin flag is the result of a logical OR operation between the first bin flag and the fourth bin flag, and at least one bit in the fifth bin flag is "0".

11. The apparatus for writing data to a flash memory as claimed in claim 9, wherein, the routing engine drives the host interface according to the first front-end parameter set to obtain data of a second part of the bins in the first virtual vehicle from the host side and store it at a specified address in the random access memory; the routing engine updates the first bin flag to be a sixth bin flag to indicate that the data of the second part of the bins in the first virtual vehicle has been prepared in the front-end processing stage; after obtaining the sixth bin flag associated with the first virtual vehicle from the routing engine, the accelerator generates a seventh bin flag based on the fifth bin flag and the sixth bin flag, determines that the data of all bins in the first virtual vehicle has been completed through the information in the seventh bin flag, and allows the first virtual vehicle to continue with the middle-end processing stage and the back-end processing stage.

12. The apparatus for writing data to a flash memory as claimed in claim 11, wherein, the seventh bin flag is the result of a logical OR operation between the fifth bin flag and the sixth bin flag, and all bits in the seventh bin flag are "1".

Images