Method and apparatus for driving a redundant array of independent disks engine
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SILICON MOTION INC
- Filing Date
- 2021-12-23
- Publication Date
- 2026-06-23
Smart Images
Figure CN116340047B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to a storage device, and more particularly, to a device and method for driving a redundant array of independent disks (RAID) engine. BACKGROUND
[0002] Flash memory is generally classified into NOR flash memory and NAND flash memory. NOR flash memory is a random access device, and a host can provide any address for accessing the NOR flash memory on an address pin and obtain data stored at the address from a data pin of the NOR flash memory in time. In contrast, NAND flash memory is not random access but serial access. Unlike NOR flash memory, the host needs to write serial byte values into the NAND flash memory to define the type of a requested command (e.g., read, write, erase, etc.) and an address used in the command, instead of accessing any random address. The address can point to a page (the minimum data block for a write operation in the flash memory) or a block (the minimum data block for an erase operation in the flash memory).
[0003] A flash memory controller generally uses error correcting code (ECC) to repair errors occurring in user data when passing through a channel or storage. When data is written, the flash memory controller encodes the user data to generate redundant information of the ECC. The redundant information allows the flash memory controller to correct a limited number of error bits occurring in any position of the user data when the data is read without re-reading. To prevent a significant error from occurring in the user data of a read page due to more error bits than the ECC can correct, the flash memory controller can form a default number of pages into a page group and generate a parity code of the page group based on user data of the page group. A dedicated RAID engine is generally included in a NAND flash memory to calculate the parity code of the page group, however, driving the RAID engine requires a large amount of time and operation resources of a processing unit. Accordingly, the present application proposes a device and method for driving a redundant array of independent disks (RAID) engine to improve overall performance of a system. SUMMARY
[0004] Therefore, how to reduce or eliminate the above-mentioned deficiencies in the related art is a problem to be solved.
[0005] This invention relates to an apparatus for driving a Redundant Array of Independent Disks (RAID) engine, comprising: a command queue; a lookup table; a converter; a configuration register; and a RAID controller. The command queue stores multiple commands pushed in by a processing unit, each command containing an opcode and parameters for instructing physical layer interaction with the RAID engine. The lookup table contains multiple records, each storing a drive value corresponding to a specific opcode and specific parameters for driving the interface with the RAID engine. The converter retrieves the corresponding drive value from the lookup table based on the opcode and parameters of any command in the command queue. The configuration register stores the drive value retrieved by the converter. The RAID controller performs a series of physical layer signal interactions with the RAID engine based on the drive value in the configuration register.
[0006] The present invention also relates to a method for driving an Independent Redundancy Array (RAID) engine, executed by an RAID controller, the RAID controller including a configuration register. The method includes: performing a series of physical layer signal interactions with the RAID engine based on a drive value in the configuration register to complete a drive operation, wherein the drive value corresponds to a command issued by a processing unit, and during the period when the RAID controller and the RAID engine cooperate to complete the drive operation, the processing unit performs computational tasks unrelated to the encoding and decoding of parity codes for page groups.
[0007] One advantage of the above embodiments is that, by setting the RAID controller as described above, the time and computing resources required for the processing unit to directly drive the RAID engine to control the physical layer signals communicating with the RAID engine, as well as the preparation time for waiting for the RAID engine to complete the drive operation, are avoided.
[0008] Other advantages of the present invention will be explained in more detail below in conjunction with the accompanying drawings. Attached Figure Description
[0009] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application.
[0010] Figure 1 A schematic diagram illustrating the logical data organization of the display page, parity check page, and its error correction code.
[0011] Figure 2 This is a system architecture diagram of an electronic device according to an embodiment of the present invention.
[0012] Figure 3This is a hardware block diagram of a Redundant Array of Independent Disks (RAID) preprocessor according to an embodiment of the present invention.
[0013] Figure 4 This is a timing diagram of an interrupt procedure according to an embodiment of the present invention.
[0014] Figure 5 This is a timing diagram for initializing the RAID engine between the RAID controller and the RAID engine according to an embodiment of the present invention.
[0015] Figure 6 This is a flowchart of a method for driving a RAID engine according to an embodiment of the present invention.
[0016] In the attached figures, the following labels are used:
[0017] 10 Electronic devices
[0018] 110 Host
[0019] 130 Flash Controller
[0020] 131 Host Interface Controller
[0021] 132 bus architecture
[0022] 134 processing units
[0023] 135 Independent Disk Redundancy Array Preprocessor
[0024] 136 Random Access Memory
[0025] 137 Independent Disk Redundancy Array Engine
[0026] 139 Flash Interface Controller
[0027] 150 flash memory modules
[0028] 322 Command Queue
[0029] 324 converter
[0030] 326 Comparison Table
[0031] 332 Configuration of temporary storage circuit
[0032] 334 Configuration Register
[0033] 342 Read Engine
[0034] 344 Read First-In-First-Out Buffer
[0035] 352 Write Engine
[0036] 354 Write to FIFO buffer
[0037] 362 Output Register
[0038] 364 Output Components
[0039] 372 Output Queue
[0040] Failure signals 412, 422, 434
[0041] 414, 424, 432 Activation Signal
[0042] S610~S660 Method Steps Detailed Implementation
[0043] The embodiments of the present invention will be described below with reference to the accompanying drawings. In these drawings, the same reference numerals denote the same or similar components or method flows.
[0044] It must be understood that the use of terms such as "comprising" or "including" in this specification is intended to indicate the presence of specific technical features, values, method steps, work processes, elements and / or components, but does not preclude the addition of more technical features, values, method steps, work processes, elements, components, or any combination thereof.
[0045] In this invention, terms such as "first," "second," and "third" 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, or the chronological order of the execution of method steps. They are only used to distinguish components with the same name.
[0046] It's important to understand that when a component is described as "connected" or "coupled" to another component, it can be a direct connection or coupling to other components, and there may be intermediate components. 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 relationships between components can be interpreted similarly, such as "between" versus "directly between," or "adjacent" versus "directly adjacent," and so on.
[0047] To achieve data fault tolerance, the flash memory controller generates an error-correcting code (ECC) based on the user data for each page and writes the user data along with the ECC to the flash memory module. This allows for the correction of user data containing erroneous bits read from the flash memory module in the future. The error-correcting code can be a low-density parity check code (LDPC), a Bose-Chaudhuri-Hocquenghem code, or other types of encoding. For example, per 1KB of user data, a BCH code can provide correction for up to 72 error bits, while an LDPC can provide correction for up to 128 error bits. However, the user data read from a page may contain more error bits than the error-correcting code can correct. Therefore, the flash memory controller can group a default number of pages into a page group and generate a parity page based on the user data of the page group. (See reference) Figure 1 The data organization shown in the example is such that seven pages, P#0 to P#6, form a page group. Each page contains 4096 bits of user data, which are used to generate the corresponding ECC. For example, the error correction code for page 0, P#0, is ECC#0, the error correction code for page 1, P#1, is ECC#1, and so on. It is important to note here that... Figure 1 The example shown is a logical viewpoint and does not represent that the user data and its error correction code, parity check page and its error correction code of a page group are actually stored in the same physical block. To optimize system performance, the user data page and its error correction code, parity check page and its error correction code of a page group may be stored in parallel in physical blocks of multiple Logical Number Units (LUNs) in different channels, and this invention is not limited thereto. The data for the parity check page can be generated using formula (1):
[0048] P j =d p0,j ⊕d p1,j ⊕d p2,j ⊕d p3,j ⊕d p4,j ⊕d p5,j ⊕d p6,j ,
[0049] Where j is any integer from 0 to 4095, p0 represents page 0, p1 represents page 1, p2 represents page 2, and so on, P j d represents the value of the j-th bit in the parity check page. p0,j d represents the value of the j-th bit in page 0. p1,jd represents the value of the j-th bit in the first page. p2,j This represents the value of the j-th bit in page 2, and so on. When the error bits in a page cannot be corrected using the corresponding error correction code, the flash memory controller can discard the page and use a mutual exclusion OR operation based on the contents of other pages in the page group and the parity check page to generate the user data for the corrected page. If the error bits in page 1 cannot be corrected using the corresponding error correction code, formula (2) can be used to recover the error page:
[0050] d p1,j =d p0,j ⊕d p2,j ⊕d p3,j ⊕d p4,j ⊕d p5,j ⊕d p6,j ⊕P j .
[0051] The parity check code for a page group, based on its function, can also be called the Redundant Array of Independent Disks (RAID ECC) error correction code. Although the above example uses a 4K-bit page, this is only for illustration; those skilled in the art can apply it to encodings containing fewer or more bits per page, such as 512B, 1K, 2K, 8K, and 16K pages.
[0052] Typically, NAND flash memory includes a dedicated RAID engine to calculate parity codes for page groups. In some implementations, the RAID engine is driven by the processing unit when it loads and executes the firmware to perform the calculations described above. However, when the processing unit directly drives the RAID engine, it consumes time and computing resources to control the physical layer signals communicating with the RAID engine, as well as the preparation time for waiting for the RAID engine to complete specific operations.
[0053] refer to Figure 2Electronic device 10 includes a host side 110, a flash memory controller 130, and a flash memory module 150, which can be collectively referred to as the device side. Electronic device 10 can be implemented in electronic products such as personal computers, laptop PCs, tablets, mobile phones, digital cameras, and digital camcorders. The host side 110 and the host interface controller 131 of the flash memory controller 130 can communicate with each other using 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), and Embedded Multi-Media Card (eMMC). The flash interface controller 139 of the flash controller 130 and the flash module 150 can communicate with each other using a Double Data Rate (DDR) communication protocol, such as Open NAND Flash Interface (ONFI), DDR Toggle, or other communication protocols. The flash controller 130 includes a processing unit 134, which can be implemented in various ways, such as using general-purpose hardware (e.g., a single processor, a multiprocessor with parallel processing capabilities, a graphics processor, or other processor with computing power), and provides the functions described later when executing software and / or firmware instructions. The processing unit 134 receives host commands, such as read commands, write commands, erase commands, etc., through the host interface controller 131, and schedules and executes these commands.The flash memory controller 130 further includes a random access memory (RAM) 136, which can be implemented as dynamic random access memory (DRAM), static random access memory (SRAM), or a combination of the two. This RAM is used to configure space as a data buffer, storing user data (also referred to as host data), parity codes, etc., read from the host 110 and about to be written to the flash memory module 150; user data read from the flash memory module 150 and about to be output to the host 110; and ECC codes, parity codes, etc., read from the flash memory module 150 for data repair. The RAM 136 can also store data required during execution, such as variables, data tables, host-to-flash (H2FTable) tables, and flash-to-host (F2H) tables. The flash interface controller 139 includes a NAND flash controller (NFC) that provides the functions required for accessing the flash module 150, such as a command sequencer, an ECC encoder, and an ECC decoder. The ECC encoder is used to generate corresponding ECC codes based on the contents of a user data page or a RAID ECC page.
[0054] The flash memory controller 130 includes a configurable bus architecture 132 for coupling components to each other to transmit data, addresses, and control signals. These components include a host interface controller 131, a processing unit 134, a RAID pre-processor 135, RAM 136, a RAID engine 137, and a flash memory interface controller 139. The bus consists of parallel physical lines connecting two or more components in the flash memory controller 130. The bus is a shared transmission medium; at any given time, only two devices can use these lines to communicate with each other and transmit data. Data and control signals can propagate bidirectionally between components along data and control lines, respectively, but address signals can only propagate unidirectionally along address lines. For example, when the processing unit 134 wants to read data at a specific address in RAM 136, the processing unit 134 transmits this address to RAM 136 on the address line. The data at that address is then sent back to the processing unit 134 on the data line. Control signals are transmitted using control lines to complete the data read operation.
[0055] The flash memory controller 130 may include a RAID engine 137, which includes mutex gates and registers for performing operations as described in formulas (1), (2), or similar. The flash memory controller 130 also includes a RAID preprocessor 135, coupled to RAM 136 via a bus architecture 132, for reading user data or parity codes from a specified address in RAM 136 and storing user data or parity codes to a specified address in RAM 136. The RAID preprocessor 135 may also be coupled to a processing unit 134 via a processor bus and to the RAID engine 137 via a RAID bus, without needing to communicate with the RAID engine 137 via the bus architecture 132 and the processing unit 134. For example, the RAID preprocessor 135 and the RAID engine 137 may be used to support encoding programs, decoding programs, termination procedures, and resume procedures. Figure 1 In the encoding process, the host interface controller 131 can receive user data pages P#0 to P#6 from the host 110 and store it in a designated address in RAM 136 via bus architecture 132. The RAID preprocessor 135 can read user data pages P#0 to P#6 one by one from the designated address in RAM 136 via bus architecture 132, enabling the RAID engine 137 to perform a mutual exclusion OR operation on the read pages to generate parity codes for the parity check pages. Then, the RAID preprocessor 135 can store the parity codes of the parity check pages in a designated address in RAM 136 via bus architecture 132.
[0056] If the flash interface controller 139 reads user data from pages P#0 to P#6 of the flash module 150 and stores it in a designated address in RAM 136 via the bus architecture 132, but finds that the error bits in page P#1 cannot be corrected using the corresponding error correction code, a decoding procedure is triggered. In the decoding procedure, the flash interface controller 139 can read the parity code of the parity code page from the designated address of the flash module 150 and store it in a designated address in RAM 136 via the bus architecture 132. The RAID preprocessor 135 can read user data from pages P#0, P2 to P#6, and the parity code of the parity code page page by page from the designated address in RAM 136 via the bus architecture 132, enabling the RAID engine 137 to perform a mutual exclusion OR operation on the read pages to generate user data for page P#1. Then, the RAID preprocessor 135 stores the user data of page P#1 in a designated address in RAM 136 via the bus architecture 132.
[0057] Suppose that the RAID engine 137 is interrupted after encoding user data for pages P#0 to P#3: In the interrupt procedure, the RAID preprocessor 135 can store the temporary encoding results of pages P#0 to P#3 generated by the RAID engine 137 to a specified address in RAM 136 via the bus architecture 132. After the RAID preprocessor 135 is instructed to perform a recovery procedure, it starts the recovery procedure. In the recovery procedure, the RAID preprocessor 135 can read the temporary encoding results of pages P#0 to P#3 and the user data for pages P#4 to P#6 page by page from the specified address in RAM 136 via the bus architecture 132, enabling the RAID engine 137 to perform a mutual exclusion OR operation on the read pages to generate the parity code for the parity code page. Then, the RAID preprocessor 135 stores the parity code of the parity code page to the specified address in RAM 136 via the bus architecture 132.
[0058] Before executing the procedures described above, the RAID preprocessor 135 may notify the RAID engine 137 to perform initialization operations, such as switching groups, clearing data in the current group, and setting the operating mode.
[0059] Flash module 150 provides a large storage space, typically hundreds of gigabytes (GB) or even several terabytes (TB), for storing large amounts of user data, such as high-resolution images and videos. Flash module 150 includes control circuitry and a memory array. The storage cells in the memory array can include single-level cells (SLCs), multiple-level cells (MLCs), triple-level cells (TLCs), quad-level cells (QLCs), or any combination thereof. Processing unit 134 writes user data, ECC codes, and parity codes to a designated address (destination address) in flash module 150 via flash interface controller 139, and reads user data, ECC codes, and parity codes from a designated address (source address) in flash module 150. The flash interface controller 139 uses several electronic signals to coordinate the data and command transmission between the flash controller 130 and the flash module 150, including data lines, clock signals, and control signals. Data lines can be used to transmit commands, addresses, read data, and write data; control signal lines can be used to transmit control signals such as Chip Enable (CE), Address Latch Enable (ALE), Command Latch Enable (CLE), and Write Enable (WE).
[0060] refer to Figure 3 The diagram shows a hardware block diagram of the RAID preprocessor 135. The RAID preprocessor 135 includes a RAID controller 310, which assists in firmware scheduling operations in each program executed in the processing unit 134, and in signal interaction with the RAID engine 137. See also... Figure 4The timing diagram of the interrupt procedure shown illustrates, for example, that one clock cycle after the RAID controller 310 sends a de-assertion signal 412 (enc_in_en) to the RAID engine 137 to initiate the output encoding input, it detects an interrupt confirmation signal 414 (term_valid) from the RAID engine 137 to confirm that the RAID engine 137 has entered the interrupt procedure and started outputting the first batch of temporary encoding results. Five clock cycles after the RAID controller 310 sends a de-assertion signal 422 (term_pls) to the RAID engine 137, it receives an interrupt output confirmation signal 424 (term_out_valid) from the RAID engine 137 for a default time period, enabling the RAID controller 310 to receive the first batch of temporary encoding results from the RAID engine 137 within this time interval. The RAID controller 310 can simultaneously output a "term_out_valid" failure signal 432 to the RAID engine 137 during an output interrupt, and detect a "term_valid" success signal 434 from the RAID engine 137 to confirm that the RAID engine 137 is about to output the temporary encoding results for the second batch. In previous embodiments, the processing unit (not shown) had to spend a continuous period of time detecting signals input from the RAID engine (not shown) and controlling the analog circuitry of the corresponding interface to output signals to the RAID engine (not shown) until the entire interrupt procedure was completed.
[0061] To reduce the time and computational resources required for the processing unit 134 to drive the RAID engine 137, the RAID preprocessor 135 also includes a command queue 322 for the processing unit 134 to write high-level commands to drive the RAID engine 137. Each command may contain an 8-bit opcode and 24-bit parameters, indicating the physical layer interaction with the RAID engine 137. The processing unit 134 also assigns a unique command number to each command as an identifier. After the processing unit 134 pushes a high-level command into the command queue 322, it can switch to executing other tasks without waiting for these commands to be executed. On the other hand, the RAID controller 310 can be used to control a series of associated signal interactions of all commands in the command queue 322, and output the execution results to the output queue 372 after signal interactions with the RAID engine 137, allowing the processing unit 134 to retrieve the execution results of these commands from the output queue 372. The RAID preprocessor 135 may include a converter 324 and a lookup table 326. Lookup table 326 may contain multiple records, each storing the setting values (which may be referred to as low-level drive values) corresponding to a specific opcode and specific parameters used to drive the interface between the RAID engine 137. This allows converter 324 to retrieve the setting values from lookup table 326 based on the opcode and parameters of any command in command queue 322, and set these values to registers in configuration caching circuit 332. For example, to initialize RAID engine 137, processing unit 134 may push four commands into command queue 322, as shown in Table 1:
[0062] Table 1
[0063]
[0064] These four commands are used to switch the RAID engine 137 to a specified group, clear the data in the previous group, set a specified operating mode, and start the Direct Memory Access (DMAController) in the RAID engine 137, respectively. The converter 324 can sequentially retrieve the setting values from the lookup table 326 according to the opcodes and parameters of these four commands in the command queue 322, and set these values to the registers in the configuration temporary storage circuit 332.
[0065] Each time the RAID controller 310 performs a series of physical layer signal interactions with the RAID engine 137 to complete a specified drive operation based on the settings in the configuration register 334, it sends a triggering signal to the configuration buffer circuit 332 and the converter 324. When the output element in the configuration buffer circuit 332 detects the triggering signal, it outputs the settings in the register of the configuration buffer circuit 332 to the configuration register 324 to overwrite the settings in the status register 324. When the converter 324 detects the triggering signal, it extracts the top command from the command queue 322, retrieves the corresponding settings from the lookup table 326 according to the opcode and parameters in the extracted command, and sets these values to the register in the configuration buffer circuit 332 to overwrite the settings in the register of the configuration buffer circuit 332. For example, suppose at time t0, configuration register 334 stores the drive value associated with the first command in Table 1, the register in configuration buffer circuit 332 stores the drive value associated with the second command in Table 1, and command queue 322 sequentially stores the third and fourth commands in Table 1. At time t1, after the RAID controller 310 performs a series of physical layer signal interactions with the RAID engine 137 based on the drive value in configuration register 334 to switch to the designated group, it sends a start signal to configuration buffer circuit 332, causing the output element in configuration buffer circuit 332 to output the drive value associated with the second command in Table 1 to configuration register 334; and sends a start signal to converter 324, causing converter 324 to deselect the top command associated with the third command in Table 1 from command queue 322, retrieve the drive value from lookup table 326 according to the opcode and parameters in the third command, and set these drive values to the register in configuration buffer circuit 332. At time t2, the RAID controller 310, based on the drive value in the configuration register 334, performs a series of physical layer signal interactions with the RAID engine 137 to clear the data from the previous group, and then sends a start signal to the configuration buffer circuit 332 and the converter 324, and so on. Corresponding to the commands in Table 1, Figure 5 This diagram shows the timing diagram of the initialization of the RAID engine between the RAID controller 310 and the RAID engine 137 according to an embodiment of the present invention.
[0066] In the encoding, decoding, or recovery process, the RAID controller 310 can send a start signal and related parameters to the read engine 342 based on the drive value in the configuration register 334. This instructs the read engine 342 to read user data, parity codes, or temporary encoding results from a specified address in RAM 136. The read engine 342 obtains the user data, parity codes, or temporary encoding results of the specified page through the bus architecture 132 and stores them in the first-in-first-out (FIFO) buffer 344. Then, the RAID controller 310 obtains the user data, parity codes, or temporary encoding results of the specified page from the read FIFO 344 and transmits them to the RAID engine 137 via the data line "enc_dat_in".
[0067] In the decoding or interrupt routine, the RAID controller 310 can obtain temporary encoding results or parity codes for one or more pages from the RAID engine 137 via the data line "enc_dat_out" based on the drive value in the configuration register 334, and store them in the write FIFO 354. Then, the RAID controller 310 can send a start signal and related parameters to the write engine 352, instructing the write engine 352 to write the temporary encoding results or parity codes to a specified address in RAM 136. The write engine 352 obtains the temporary encoding results or parity codes from the write FIFO 354 and writes them to the specified address in RAM 136 via the bus architecture 132.
[0068] Each time the RAID controller 310 performs a series of physical layer signal interactions with the RAID engine 137 based on the settings in the configuration register 334 and obtains the execution result, it sends a start signal to the output element 364 and then stores the execution result in the output register 362. The execution result may include the command number, the interrupt page number, etc. When the output element 364 detects the start signal, it pushes the execution result in the output register 362 to the bottom of the output queue 372.
[0069] In response to the hardware architecture of the RAID preprocessor 135, this embodiment of the invention proposes a method for driving the RAID engine, executed by the RAID controller 310. (See reference...) Figure 6 The detailed steps are as follows:
[0070] Step S610: Complete the specified drive operation according to the drive value in the configuration register 334. The drive value in the configuration register 334 corresponds to the command issued by the processing unit 134, and during the period when the RAID controller 310 and the RAID engine 137 cooperate to complete the drive operation, the processing unit 134 can perform calculation tasks unrelated to the encoding and decoding of the parity code of the page group.
[0071] In some embodiments, the RAID controller 310 may perform a series of physical layer signal interactions with the RAID engine 137 based on the drive value in the configuration register 334 to complete the specified drive operation.
[0072] In some embodiments of the encoding, decoding, or recovery process, the RAID controller 310 may instruct the read engine 342, based on the drive value in the configuration register 334, to read one or more pages of user data, parity code, or temporary encoding results from a specified address in the RAM 136 via the bus architecture 132, and store the user data, parity code, or temporary encoding results in the FIFO 344. After a default time, the RAID controller 310 retrieves the user data, parity code, or temporary encoding results from the read FIFO 344 for the specified page. Then, the RAID controller 310 performs a series of physical layer signal interactions with the RAID engine 137 to transmit the acquired user data, parity code, or temporary encoding results to the RAID engine 137 via the data line.
[0073] In some embodiments of the encoding, decoding, or interrupt routines, the RAID controller 310 may perform a series of physical layer signal interactions with the RAID engine 137 based on the drive value in the configuration register 334 to receive one or more pages of user data, temporary encoding results, or parity codes from the RAID engine 137 via data lines, and store the user data, temporary encoding results, or parity codes in the write FIFO 354. Then, the RAID controller 310 instructs the write engine 352 to write the user data, temporary encoding results, or parity codes to a specified address in the RAM 136 via the bus architecture 132.
[0074] Step S620: Send a start signal to the configuration temporary storage circuit 332 to drive the configuration temporary storage circuit 332 to store the drive value therein into the configuration register 334.
[0075] Step S630: Send a start signal to converter 324 to drive converter 324 to obtain the corresponding drive value from lookup table 326 according to the opcode and parameters in the command at the top of command queue 322, and set these values to the register in configuration temporary storage circuit 332.
[0076] Step S640: Determine whether it is necessary to report the execution result to processing unit 134. If yes, the process continues to step S650; otherwise, the process continues to step S610 and starts the next drive operation.
[0077] Step S650: A start signal is sent to the output element 364, driving the output element 364 to push the execution result of the output register 362 into the bottom of the output queue 372. It should be noted here that since the execution result contains the command number, the processing unit 134 can use the command number to correspond to the specific command previously pushed into the command queue 322.
[0078] Step S660: Store the obtained execution result in the output register 362.
[0079] Although Figure 2 , Figure 3 It includes the components described above, but does not preclude the use of other additional components to achieve better technical results without violating the spirit of the invention. Furthermore, although... Figure 6 The flowchart describes the steps in a specified order. However, those skilled in the art can modify the order of these steps to achieve the same effect without violating the spirit of the invention. Therefore, this invention is not limited to using only the order described above. Furthermore, those skilled in the art can integrate several steps into one step, or perform more steps sequentially or in parallel, in addition to these steps, and this invention should not be limited thereto.
[0080] The above description is only a preferred embodiment of the present invention, but it is not intended to limit the scope of the present invention. Any person 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 scope of protection of the present invention shall be determined by the scope defined in the claims of this application.
Claims
1. A device for driving an independent disk redundancy array engine, characterized in that, include: A command queue is used to store multiple commands pushed in by the processing unit, each command containing an opcode and a first parameter indicating physical layer interaction with the independent disk redundancy array engine; The lookup table contains multiple records, each of which stores the opcode and the first parameter corresponding to the drive value used to drive the interface with the independent disk redundancy array engine. A converter, coupled to the command queue and the lookup table, is used to obtain the corresponding drive value from the lookup table based on the opcode of any of the commands in the command queue and the first parameter; A configuration register for storing the drive value acquired by the converter; as well as Independent Disk Redundancy Array (IDA) controller, coupled to the configuration register, is used to complete a series of physical layer signal interactions with the IDA engine based on the drive value in the configuration register.
2. The apparatus for driving an independent disk redundancy array engine as described in claim 1, characterized in that, include: Read the buffer; The read engine is coupled to the read buffer; The independent disk redundancy array controller is coupled to the read buffer and the read engine. It sends a first start signal and a second parameter to the read engine according to the drive value in the configuration register. The second parameter is used to instruct the read engine to read user data, parity check code or temporary encoding result from the first address of random access memory, and to store the user data, parity check code or temporary encoding result to the read buffer. Read the user data, the parity check code, or the temporary encoding result from the read buffer; and transmit the user data, the parity check code, or the temporary encoding result to the independent disk redundancy array engine via a data line.
3. The apparatus for driving an independent disk redundancy array engine as described in claim 1, characterized in that, include: Write to the buffer; The write engine is coupled to the write buffer; The independent disk redundancy array controller is coupled to the write buffer and the write engine. Based on the drive value in the configuration register, it obtains a temporary encoding result or parity check code from the independent disk redundancy array engine via a data line; and stores the temporary encoding result or the parity check code in the write buffer. The system also sends a second start signal and a third parameter to the write engine, instructing the write engine to read the temporary encoding result or the parity check code from the write buffer and write the temporary encoding result or the parity check code to a second address in the random access memory.
4. The apparatus for driving an independent disk redundancy array engine as described in claim 1, characterized in that, include: Configuration buffer circuitry, coupled to the converter and the configuration register, includes output elements and registers. Specifically, after the Independent Disk Redundancy Array (IDA) controller completes the operation of driving the IDA engine based on the drive value in the configuration register, it sends a third start signal to the configuration buffer circuit to drive the output element to output the drive value of the register to the configuration register; and sends a fourth start signal to the converter to drive the converter to obtain a command from the command queue, obtain the corresponding drive value from the lookup table based on the opcode and parameters in the obtained command, and set the newly obtained drive value to the register in the configuration buffer circuit.
5. The apparatus for driving an independent disk redundancy array engine as described in claim 1, characterized in that, include: The output queue is coupled to the independent disk redundancy array controller. The Independent Disk Redundancy Array (IDA) controller outputs the execution result corresponding to the command to the output queue after completing the physical layer signal interaction with the IDA engine.
6. The apparatus for driving an independent disk redundancy array engine as described in claim 5, characterized in that, include: An output element, coupled to the output queue and the independent disk redundancy array controller; as well as The output register is coupled to the output element and the independent disk redundancy array controller. The Independent Disk Redundancy Array controller sends a fifth start signal to the output element after completing the physical layer signal interaction with the Independent Disk Redundancy Array engine, which drives the output element to push the execution result in the output register into the output queue. And store the execution result corresponding to the command in the output register.
7. A method for driving an Independent Disk Redundancy Array (IDA) engine, executed by an IDA preprocessor, wherein the IDA preprocessor includes an IDA controller and configuration registers, characterized in that, The method for driving the independent disk redundancy array engine includes: The command queue stores multiple commands pushed in by the processing unit, wherein each command contains an opcode and a first parameter for instructing physical layer interaction between the device and the independent disk redundancy array engine. A lookup table is provided, containing multiple records, each of which stores the opcode and the first parameter corresponding to the drive value of the interface used to drive the independent disk redundancy array engine; The converter obtains the corresponding drive value from the lookup table based on the opcode of any of the commands in the command queue and the first parameter; The configuration register stores the drive value obtained from the converter; The Independent Disk Redundancy Array (IDA) controller interacts with the IDA engine through a series of physical layer signals based on the drive value in the configuration register to complete the drive operation. The driving value corresponds to a command issued by the processing unit, and during the period when the independent disk redundancy array controller and the independent disk redundancy array engine cooperate to complete the driving operation, the processing unit performs computational tasks unrelated to the encoding and decoding of parity codes of page groups.
8. The method for driving a Redundant Array of Independent Disks (RAD) engine as described in claim 7, wherein the RAD controller comprises a read engine and a read buffer, characterized in that, The method for driving the independent disk redundancy array engine includes: The drive value in the configuration register instructs the read engine to read one or more pages of user data, parity code, or temporary encoding result from random access memory, and to store the user data, parity code, or temporary encoding result in the read buffer. After a default period of time, the user data, the parity check code, or the temporary encoding result are retrieved from the read buffer; and A series of physical layer signal interactions are performed with the Independent Disk Redundancy Array Engine to transmit the user data, the parity check code, or the temporary encoding result to the Independent Disk Redundancy Array Engine via a data line.
9. The method for driving a Redundant Array of Independent Disks (RAD) engine as described in claim 7, wherein the RAD controller includes a write engine and a write buffer, characterized in that, The method for driving the independent disk redundancy array engine includes: Based on the drive value in the configuration register, a series of physical layer signal interactions are performed with the Independent Disk Redundancy Array Engine to receive user data, temporary encoding results, or parity check codes for one or more pages from the Independent Disk Redundancy Array Engine via a data line; Store the user data, the temporary encoding result, or the parity check code in the write buffer; and The write engine is instructed to write the user data, the temporary encoding result, or the parity check code into the random access memory.
10. The method for driving an Independent Disk Redundancy Array (IDA) engine as described in claim 7, wherein the IDA controller comprises a configuration buffer circuit, the command queue, the converter, and the lookup table, characterized in that, The method for driving the independent disk redundancy array engine includes: After completing the driving operation, a first start signal is sent to the configuration temporary storage circuit to drive the output element in the configuration temporary storage circuit to output the driving value of the register in the configuration temporary storage circuit to the configuration register; and After the driving operation is completed, a second start signal is sent to the converter to drive the converter to obtain the corresponding driving value from the lookup table according to the opcode and parameters in the command at the top of the command queue, and set the corresponding driving value to the register in the configuration temporary storage circuit.
11. The method for driving a Redundant Array of Independent Disks (RAD) engine as described in claim 7, wherein the RAD controller includes an output queue, characterized in that... The method for driving the independent disk redundancy array engine includes: After completing the driving operation, determine whether it is necessary to report the execution result corresponding to the command to the processing unit; and When it is necessary to report the execution result to the processing unit, the execution result is pushed into the output queue, so that the processing unit can obtain the execution result from the output queue.