A fine-grained, lockstep-tolerant, superscalar out-of-order processor design method and system

Abstract

This invention discloses a fine-grained, lock-step-tolerant, superscalar out-of-order processor design method and system. The method includes: reading the current instruction address and performing branch prediction to obtain the fetch address of the next instruction; decoding the instruction fetch to extract the opcode, source operand register number, and destination operand register number; renaming the instruction decoding result; processing the renamed instruction decoding result through a reservation station module; performing arithmetic and logical operations on the arbitrated instruction decoding result; comparing and checking the results of executed instructions and writing them into the system; reordering and buffering the written results of executed instructions before committing them to construct the superscalar out-of-order processor. This invention improves the fault detection and recovery capabilities of superscalar out-of-order processors. As a fine-grained, lock-step-tolerant, superscalar out-of-order processor design method and system, this invention can be applied to the field of fault-tolerant processor design technology.

Description

Technical Field

[0001] This invention relates to the field of fault-tolerant processor design technology, and in particular to a fine-grained lockstep fault-tolerant superscalar out-of-order processor design method and system. Background Technology

[0002] As the automotive industry becomes increasingly intelligent, automotive electronic systems are becoming more complex, placing higher demands on processor performance. Simple sequential single-issue processors can no longer provide sufficient real-time processing capabilities. Superscalar out-of-order processors, however, can fully utilize inter-instruction parallelism to effectively improve processor performance and provide the high real-time processing capabilities required for scenarios such as autonomous driving. A superscalar out-of-order processor is a highly efficient processor design that can execute multiple instructions within the same clock cycle, improving processor execution efficiency. The out-of-order execution mechanism in a superscalar out-of-order processor allows the processor to arbitrarily adjust the execution order of instructions based on their dependencies and executable states, thereby fully utilizing processor resources and improving instruction execution efficiency. However, the out-of-order execution mechanism also introduces some problems, such as data conflicts and instruction exceptions, which may affect the processor's operational stability. In addition, as processor chips gradually adopt nanoscale manufacturing processes, while processor performance has been significantly improved, the reduction in integrated circuit feature size and the increase in frequency have made processors extremely sensitive to various noise interferences such as crosstalk, voltage disturbances, electromagnetic interference, and radiation. This can lead to erroneous operations, causing the failure rate of microprocessors to rise continuously and the reliability of processors to decline. Advanced processes often use lower supply voltages, which further exacerbates the noise impact of switching current. On the other hand, the power density of processors is constantly increasing, doubling every 18-24 months, a phenomenon known as Moore's Law. Increased power density causes the temperature of system components to rise continuously, exacerbating the impact of heat on system reliability. Generally speaking, from a room temperature of 21 degrees Celsius, the failure rate of the system doubles for every 10-degree increase in temperature. These factors affect the reliability of system components, further impacting the reliability of the system. In the context of autonomous driving in automobiles, in addition to high real-time performance, high reliability is also crucial. Any failure in the processor could cause personal injury or death to the driver, pedestrians, or occupants of nearby vehicles. Therefore, the ISO 26262 standard proposes functional safety requirements for automotive electronics, necessitating the provision of effective safety mechanisms in automotive electronic systems. In line with the requirements of the ISO 6262 standard, superscalar out-of-order processors used in automobiles also require fault-tolerant design to improve their ability to detect and recover from faults. Current fault-tolerant designs for processors suffer from coarse granularity, long fault detection and recovery times, low fault coverage, and insufficient handling capabilities for faults caused by common-mode failures. Summary of the Invention

[0003] To address the aforementioned technical problems, the present invention aims to provide a fine-grained, lockstep-tolerant superscalar out-of-order processor design method and system. By implementing fine-grained locksteps in the superscalar out-of-order processor pipeline, the time from the occurrence of a fault to its detection and recovery to a safe and correct processor state is reduced, thereby improving the fault detection and recovery capabilities of the superscalar out-of-order processor.

[0004] The first technical solution adopted in this invention is: a fine-grained, lockstep-tolerant, superscalar out-of-order processor design method, comprising the following steps:

[0005] Read the current instruction address and perform branch prediction to obtain the fetch address of the next instruction;

[0006] Obtain the corresponding fetch instruction based on the fetch address of the next instruction;

[0007] The opcode, source operand register number, and destination operand register number are extracted from the fetch instruction to obtain the instruction decoding result;

[0008] The instruction decoding result is renamed to obtain the renamed instruction decoding result;

[0009] The renamed instruction decoding result is stored, the master-slave core is compared, and the arbitration instruction is output through the retention station module to obtain the arbitration instruction decoding result;

[0010] The corresponding operations are performed on the decoded result of the instruction after the arbitration is selected to obtain the result of the executed instruction. The corresponding operations include arithmetic logic, multiplication and division, status register operations and memory access operations.

[0011] The results of the executed instructions are compared, checked, and written to obtain the written results of the executed instructions.

[0012] After reordering and buffering the written completed instructions, the results are submitted to construct a superscalar out-of-order processor.

[0013] Furthermore, the step of reading the current instruction address and performing branch prediction to obtain the fetch address of the next instruction specifically includes:

[0014] The main core processor reads the current instruction address and performs branch prediction to obtain the fetch address of the next instruction and the branch prediction direction of the main core.

[0015] Read the current instruction address from the kernel processor and perform branch prediction to obtain the fetch address of the next instruction from the kernel and the branch prediction direction from the kernel;

[0016] The fetch address of the next instruction of the master core and the fetch address of the next instruction of the slave core are determined, as are the branch prediction directions of the master core and the branch prediction directions of the slave core.

[0017] The prediction direction of the main core branch and the prediction direction of the slave core branch are judged. If the prediction direction of the main core branch and the prediction direction of the slave core branch are consistent and are jumps, then the instruction fetch address comparison judgment is performed.

[0018] If the fetch address of the next instruction of the master core is the same as the fetch address of the next instruction of the slave core, then the fetch address of the next instruction is obtained.

[0019] If the fetch address of the next instruction of the master core is inconsistent with the fetch address of the next instruction of the slave core, then the instruction fetching is paused;

[0020] If the main core branch prediction direction is consistent with the slave core branch prediction direction and is not a jump, then the fetch address of the next instruction obtained from the branch prediction is not used, and the sequentially incremented address is used as the fetch address of the next instruction.

[0021] If the predicted direction of the main kernel branch is inconsistent with the predicted direction of the slave kernel branch, then the instruction fetching process is paused.

[0022] If the instruction fetched at the current instruction address is determined to be a branch instruction during the decoding stage, then the fetch address of the next instruction obtained from branch prediction is used;

[0023] If the instruction fetched at the current instruction address is determined to be a non-branch instruction during the decoding stage, the fetch address of the next instruction obtained from branch prediction will not be used; instead, the sequentially incremented address will be used as the fetch address of the next instruction.

[0024] Furthermore, the step of the main core processor reading the current instruction address and performing branch prediction is the same as the step of the slave core processor reading the current instruction address and performing branch prediction, wherein the branch prediction step is specifically as follows:

[0025] The determination is based on the branch target cache module to determine whether the current instruction address exists in the branch target cache module;

[0026] If the current instruction address is determined to exist, the fetch address of the next instruction at the current instruction address is obtained through the branch target cache module or the return address stack module.

[0027] If it is determined that the current instruction address does not exist, the instruction fetch address of the next instruction is obtained through the instruction fetch address sequence increment module.

[0028] Furthermore, the step of renaming the instruction decoding result specifically includes:

[0029] The instruction decoding result is sent to the register renaming mapping table module, which is used to store the mapping relationship between architectural registers and physical registers.

[0030] Based on the instruction decoding result, determine whether a destination register exists;

[0031] If a destination register exists, the free physical register number is read from the free physical register list module, and a new register mapping relationship is obtained;

[0032] Write the new mapping relationship to the register and rename the mapping table module;

[0033] The checkpoint is used to save the register mapping relationship from the previous moment from the kernel save and restore module.

[0034] Furthermore, the step of storing the renamed instruction decoding result, comparing the master and slave cores, and arbitrating the instruction output through the retention station module specifically includes:

[0035] Get the decoded result of the renamed instruction;

[0036] The renamed instruction decoding result is stored through inbound and table entry movement logic, storing the corresponding opcode and operand register number;

[0037] After the master core processor completes the instruction inbound process, it reads out the renaming result of the instruction to be inbound from the slave core and compares it with the result of the slave core. The comparison result is then updated to the corresponding reserved station instruction table entries of the master and slave cores in sequence.

[0038] Commands that match the comparison results are selected by arbitration transmission logic and sent out of the station to the functional unit;

[0039] Before renaming instructions with inconsistent comparison results, the pipeline pauses. After the pause, fault recovery is initiated, flushing out older instructions in the pipeline than the instructions with inconsistent comparison results.

[0040] Furthermore, the step of performing corresponding calculations on the decoding result of the selected arbitration transmission specifically includes:

[0041] Each functional unit module completes the calculations required for the corresponding arbitration transmission command decoding result;

[0042] The required operations for the decoded command result after arbitration transmission are determined. If the decoded command result after arbitration transmission requires corresponding operations, then the corresponding operations are performed on the decoded command result after arbitration transmission through various functional unit modules, including:

[0043] If the decoded result of the arbitrated instruction requires arithmetic or logical operations, then the arithmetic or logical operations are performed on the decoded result of the arbitrated instruction through the arithmetic logic unit (ALU) module.

[0044] If the decoded result of the arbitrated instruction requires multiplication or division, then the multiplication or division operation module is used to perform multiplication or division operations on the decoded result of the arbitrated instruction.

[0045] If the arbitrated instruction decoding result requires status register operation, the status register operation is performed on the arbitrated instruction decoding result through the status register operation module.

[0046] The memory access module executes LOAD / STORE instructions to read and write data.

[0047] Furthermore, the step of comparing, checking, and writing the results of the executed instructions specifically includes:

[0048] The results of the executed instructions are obtained through several functional unit modules, including the main core execution completion results and the slave core execution completion results;

[0049] The main core execution completion result is cached through the main core result delay caching unit;

[0050] The cached execution result of the main core is compared and checked with the execution result of the slave core by the main-slave core execution result comparison and update module.

[0051] If the comparison results are consistent, the comparison results will be updated to the instruction table entries of the corresponding reordering buffers of the master and slave cores in sequence, and the program will wait for the submission logic to select and leave the reordering buffer.

[0052] If the comparison results are inconsistent, the pipeline before the execution stage is paused to perform fault recovery and flush out instructions in the pipeline that are older than the instruction corresponding to the comparison result.

[0053] Furthermore, the step of reordering and buffering the written executed instruction results before submission specifically includes:

[0054] Upon submission, the command entry check result field is checked. If the check passes and there are no errors, the command is released from the reordering buffer.

[0055] For commands that are not checked or fail the check and do not meet the requirements, fault recovery is performed for those that fail the check.

[0056] Furthermore, the step of checking the result field of the inspection instruction table item specifically includes:

[0057] Perform a master-slave XOR operation on the results of the executed instructions that have been written;

[0058] If the XOR operation result is 1, then the results of the executed instructions written by the master and slave cores are not equal to the input comparison signals, i.e., the check fails.

[0059] If the XOR operation result is 0, then the results of the executed instructions written by the master and slave cores are equal to the input comparison signal, and the check passes.

[0060] The second technical solution adopted in this invention is: a fine-grained, lockstep-tolerant, superscalar out-of-order processor design system, comprising:

[0061] The branch prediction module is used to read the current instruction address and perform branch prediction to obtain the fetch address of the next instruction.

[0062] The instruction fetch module is used to obtain the corresponding instruction fetch instruction based on the instruction fetch address of the next instruction;

[0063] The decoding module is used to extract the opcode, source operand register number and destination operand register number according to the instruction fetch instruction, and obtain the instruction decoding result;

[0064] The renaming module is used to rename the instruction decoding result to obtain the renamed instruction decoding result;

[0065] The retention station module is used to store the renamed instruction decoding results, compare master and slave cores, and arbitrate instructions to obtain the arbitrated instruction decoding results.

[0066] The execution module is used to perform corresponding operations on the instruction decoding result after the selected arbitration transmission to obtain the result of the executed instruction. The corresponding operations include arithmetic logic, multiplication and division, status register operations and memory access operations.

[0067] The write-back module is used to compare, check, and write the results of the executed instructions to obtain the written results of the executed instructions.

[0068] The reordering buffer module is used to reorder and buffer the results of the executed instructions before submitting them, thus constructing a superscalar out-of-order processor.

[0069] The beneficial effects of the method and system of this invention are as follows: This invention performs branch prediction on the current instruction address. Inconsistent branch instruction hits and branch prediction directions will prevent instruction fetching, pausing until the result is consistent or the instruction is determined to be a branch instruction during the decoding stage, deciding whether to jump or not. The instruction fetch address is incremented, and further decoding and renaming processing is performed on the fetched instruction. When inconsistencies are found in the comparison of the corresponding entries of the master core and slave core in the reserved station, the checkpoint logic will restore the previously saved register renaming results. After re-fetching the instruction using the faulty instruction fetch address, the correct program flow can be restored. Finally, the corresponding operation and reordering buffer is performed, restricting the submission of instructions that have not undergone comparison checks, avoiding processor back-end failures and disrupting the processor state. Finally, a comparison check is performed, and the data is written to the physical register only after the comparison passes. By performing fine-grained lockstep on the superscalar out-of-order processor pipeline, the time from the occurrence of a fault to the fault being detected and restored to a safe and correct processor state is reduced, which can improve the fault detection and recovery capability of superscalar out-of-order processors. Attached Figure Description

[0070] Figure 1 This is a flowchart illustrating the steps of a fine-grained, lockstep-tolerant, superscalar out-of-order processor design method according to an embodiment of the present invention.

[0071] Figure 2 This is a structural block diagram of a fine-grained, lockstep-tolerant, superscalar out-of-order processor design system according to an embodiment of the present invention.

[0072] Figure 3 This is a schematic diagram illustrating the steps of a superscalar out-of-order processor design method according to a specific embodiment of the present invention;

[0073] Figure 4 This is a pipeline architecture diagram of a superscalar out-of-order processor according to a specific embodiment of the present invention;

[0074] Figure 5 This is a schematic diagram of the branch prediction logic in a specific embodiment of the present invention;

[0075] Figure 6 This is a schematic diagram of branch prediction logic fault detection in a specific embodiment of the present invention;

[0076] Figure 7 This is a flowchart of the branch prediction logic fault handling process in a specific embodiment of the present invention;

[0077] Figure 8 This is a schematic diagram of register renaming in a specific embodiment of the present invention;

[0078] Figure 9 This is a schematic diagram of the reserved station and reordering buffer table entries in a specific embodiment of the present invention;

[0079] Figure 10This is a schematic diagram of the reordering buffer entries in a specific embodiment of the present invention;

[0080] Figure 11 This is a schematic diagram of the front-end fault retention station detection before the detection comparison in a specific embodiment of the present invention;

[0081] Figure 12 This is a schematic diagram of the front-end fault retention station detection after the main core table entry is updated, according to a specific embodiment of the present invention.

[0082] Figure 13 This is a schematic diagram illustrating the detection and comparison of the front-end fault retention station after the kernel table entry is updated, according to a specific embodiment of the present invention.

[0083] Figure 14 This is a schematic diagram of front-end fault recovery according to a specific embodiment of the present invention;

[0084] Figure 15 This is a schematic diagram of a write storage buffer table entry in a specific embodiment of the present invention;

[0085] Figure 16 This is a schematic diagram of backend fault write-back detection in a specific embodiment of the present invention;

[0086] Figure 17 This is a schematic diagram of backend fault submission and recovery in a specific embodiment of the present invention. Detailed Implementation

[0087] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. The step numbers in the following embodiments are only for ease of explanation and do not limit the order of the steps. The execution order of each step in the embodiments can be adapted according to the understanding of those skilled in the art.

[0088] This invention divides the superscalar out-of-order processor into three logical parts: branch prediction, front-end, and back-end. Different fault detection and handling mechanisms are proposed for each stage of the processor logic. By employing dual-core lockstep operation and proposing a fine-grained fault-tolerance mechanism, the fault detection and recovery capabilities of the superscalar out-of-order processor are improved, and fault handling time is reduced.

[0089] Reference Figure 1 , Figure 3 and Figure 4 This invention provides a fine-grained, lockstep-tolerant, superscalar out-of-order processor design method, which includes the following steps:

[0090] S1. Read the current instruction address and perform branch prediction to obtain the fetch address of the next instruction;

[0091] Among them, such as Figure 5 As shown, the steps for instruction branch prediction include:

[0092] S11. The main core processor reads the current instruction address and performs branch prediction to obtain the fetch address of the next instruction of the main core and the branch prediction direction of the main core.

[0093] S12. Read the current instruction address from the core processor and perform branch prediction to obtain the fetch address of the next instruction from the core and the branch prediction direction from the core.

[0094] Specifically, the branch target cache module is used to determine whether the current instruction address exists. If the current instruction address exists, the fetch address of the next instruction is obtained through the branch target cache module or the return address stack module. If the current instruction address does not exist, the fetch address of the next instruction is obtained through the instruction fetch address order increment module.

[0095] S13. Determine the fetch address of the next instruction of the master core and the fetch address of the next instruction of the slave core, and determine the branch prediction direction of the master core and the branch prediction direction of the slave core;

[0096] S14. Determine the main core branch prediction direction and the slave core branch prediction direction. If the main core branch prediction direction and the slave core branch prediction direction are consistent and it is a jump, then perform an instruction fetch address comparison judgment.

[0097] S15. If the fetch address of the next instruction of the master core is the same as the fetch address of the next instruction of the slave core, then obtain the fetch address of the next instruction; if the fetch address of the next instruction of the master core is different from the fetch address of the next instruction of the slave core, then pause the fetch.

[0098] S16. If the main core branch prediction direction is consistent with the slave core branch prediction direction and is not a jump, then the fetch address of the next instruction obtained by the branch prediction is not used, and the sequentially incremented address is used as the fetch address of the next instruction.

[0099] S17. If the prediction direction of the main kernel branch is inconsistent with the prediction direction of the slave kernel branch, then pause the instruction fetching.

[0100] S18. If the instruction fetched at the current instruction address is determined to be a branch instruction during the decoding stage, the fetch address of the next instruction obtained from branch prediction is used. If the instruction fetched at the current instruction address is determined to be a non-branch instruction during the decoding stage, the fetch address of the next instruction obtained from branch prediction is not used, and the sequentially incremented address is used as the fetch address of the next instruction.

[0101] The instruction branch prediction module includes the following modules:

[0102] The Branch Target Cache (BTB) module is used to store the fetch address, type, and historical target address of branch instructions;

[0103] The Return Address Stack (RAS) module is used to store the address of the next instruction after a branch instruction of type CALL. When a branch instruction of type RET is encountered, the stored address is used as the target address.

[0104] The instruction fetch address sequential increment module is used to increment the current instruction address as the fetch address for the next instruction when branch prediction and jump are not performed.

[0105] The Branch History Register (BHT) is used to determine the branch direction of the current branch instruction, whether to jump or not, based on a two-bit saturation prediction mechanism.

[0106] The BTB, RAS, and BHT modules are master-slave core comparison and update modules used to compare various prediction sources of the master and slave cores, output comparison inconsistency error signals, pause instruction fetching, obtain the decoding result, determine the branch prediction result, and output it to the instruction fetch module.

[0107] The instruction fetch address sequential auto-incrementing three-modular redundancy voting module is used to fetch the instruction address from three identical instruction fetch address sequential auto-incrementing modules according to the majority vote and output it to the instruction fetch module.

[0108] S2. Obtain the corresponding instruction fetch based on the fetch address of the next instruction;

[0109] Specifically, the main core processor reads the current instruction address and performs branch prediction to obtain the fetch address of the next instruction and the branch prediction direction of the main core; the slave core processor reads the current instruction address and performs branch prediction to obtain the fetch address of the next instruction and the branch prediction direction of the slave core; the fetch address of the next instruction of the main core and the fetch address of the next instruction of the slave core are compared, as are the branch prediction directions of the main core and the slave core; if the branch prediction directions of the main core and the slave core are the same and it is a jump, then the fetch address comparison is performed; if the fetch address of the next instruction of the main core and the fetch address of the next instruction of the slave core are the same, then the fetch address of the next instruction is obtained; if the fetch address of the next instruction of the main core and the fetch address of the next instruction of the slave core are different, then the fetch is paused; if the branch prediction direction of the main core and the branch prediction direction of the slave core are the same and it is not a jump, then the fetch address of the next instruction obtained by branch prediction is not used, and the sequentially incremented address is used as the fetch address of the next instruction.

[0110] If the main core branch prediction direction is inconsistent with the slave core branch prediction direction, instruction fetching is paused. If the instruction fetched at the current instruction address is determined to be a branch instruction during the decoding stage, the fetch address of the next instruction obtained from branch prediction is used. If the instruction fetched at the current instruction address is determined to be a non-branch instruction during the decoding stage, the fetch address of the next instruction obtained from branch prediction is not used, and the sequentially incremented address is used as the fetch address of the next instruction.

[0111] In this embodiment, the PC level is responsible for generating the fetch address of the next instruction based on the current instruction address. Superscalar out-of-order processors generally have branch prediction capabilities, so the generation of this address is not a simple sequential increment (PC+8 in this example). If the current instruction address is the fetch address of a branch instruction, the address of the next instruction may also be the historical destination address of the branch instruction obtained from the branch predictor. The branch predictor determines whether to predict the branch to execute based on the execution results of historical branch instructions, i.e., the direction and destination address of the branch.

[0112] The branch predictor used in this example includes BTB branch target cache prediction and RAS return address stack prediction. The branch history table (BHT) provides a prediction of the branch prediction direction for the branch instruction address that hits the BTB. If the hit branch instruction address is a RET instruction address, the target address is obtained from the RAS; if it is an unconditional jump JMP instruction address or a BHT-predicted jump, the target address is obtained from the BTB. The instruction address (PC) and target address (Target) stored in the BTB and RAS are the execution results of past branch instructions, obtained during the processor commit phase. The fault-tolerant design of this invention can detect and handle faults during instruction dispatch to the Reserved Station (RS) and instruction commit in the Reorder Buffer (ROB). If the branch instruction is inconsistent during dispatch or commit, the result of that branch instruction will not enter the branch predictor, so the instruction address and its target address that enter the branch predictor are correct.

[0113] S3. Extract the opcode, source operand register number, and destination operand register number from the instruction fetch instruction to obtain the instruction decoding result;

[0114] In this embodiment, the master core and slave core run simultaneously at the PC level, comparing the directions of branch predictions—that is, comparing whether the current instruction prediction should branch or not. If the results from the branch direction control logic of the master and slave cores are inconsistent, the predicted address of the next instruction may be incorrect. There are two scenarios: First, the current instruction address is not a branch instruction address, but a fault in the branch control logic causes a hit and fetches the destination address of a branch instruction from the BTB (Branch Target Block), resulting in an incorrect instruction entering the pipeline. Since the instruction fetched at this address is not a branch instruction, the correct address of the next instruction cannot be obtained from its execution result, causing the entire processor to execute the program along an incorrect instruction flow, resulting in an incorrect program outcome. Second, the current instruction address is a branch instruction address. Whether or not a branch is predicted will not affect the correct execution of the program, because the destination address of this branch instruction address, i.e., the address of the next instruction, is itself obtained through prediction. Regardless of whether a branch occurs, the result of the write-back phase of the current branch instruction needs to be compared with the correct branch destination address obtained from the branch instruction execution. If the comparison is consistent, the prediction is correct and no additional processing is needed; otherwise, the prediction fails, the fetched instruction is overwritten, and the program jumps to the correct destination address. Simultaneously, the branch information needs to be updated in the branch predictor. Therefore, when it is unclear whether the current instruction address is a branch instruction, this invention provides two processing methods: one is to directly assume that the current instruction address is not a branch instruction address, and then increment the address of the next instruction sequentially. After decoding and determining the instruction information, if it is found that the instruction fetched at the current instruction address is not a branch instruction, everything is normal and no additional processing is needed; if it is a branch instruction, the possible prediction failure is accepted, the penalty for branch prediction failure is borne, and the program jumps to the correct destination address, but the program will still execute normally. Second, the current instruction address is kept unchanged, and the use of the current instruction address for repeated instruction fetching (Stallfetch) is suspended until the PC level provides a consistent branch prediction direction or the instruction fetched at the current instruction address enters the decoding stage and it is confirmed whether it is a branch instruction. If it is a branch instruction, the branch is executed, and the branch destination address is used as the address of the next instruction. If it is not a branch instruction, the address of the next instruction is the current instruction address incremented sequentially, and the processor resumes correct instruction fetching. The fault handling process flowchart is as follows: Figure 7 .

[0115] S4. Rename the instruction decoding result to obtain the renamed instruction decoding result;

[0116] The steps for renaming include:

[0117] S41. Send the instruction decoding result to the register renaming mapping table module. The register renaming mapping table module is used to store the mapping relationship between architectural registers and physical registers.

[0118] S42. Based on the instruction decoding result, determine whether a destination register exists;

[0119] S43. If a destination register exists, read the free physical register number from the free physical register list module and obtain the new register mapping relationship;

[0120] S44. Write the new mapping relationship to the register and rename the mapping table module;

[0121] S45. The register mapping relationship of the previous moment is saved from the kernel save and restore module through the checkpoint.

[0122] The renaming process includes the following modules:

[0123] The Register Rename Map (RAT) module is used to store the mapping relationship between architectural registers and physical registers;

[0124] The Free list module is used to store free physical register numbers and allocate a physical register to store the operation result for a register containing a destination operand.

[0125] The Checkpoint module saves and restores the cores, saving the correct RAT and Free list Header pointers. When a fault is found during a master-slave core comparison at the reserved station, the contents saved by the Checkpoint are restored to the master-slave core renaming module.

[0126] In this embodiment, to address branch prediction failures, the branch generation logic is copied and compared to prevent branch logic failures from outputting incorrect instruction streams to non-branch instruction addresses, thus avoiding irrecoverable failures. For inconsistent branch prediction directions provided by the copied logic, two fault handling schemes are offered: one is simple instruction address sequential auto-increment, and the other is to pause instruction fetching until instruction decoding determines whether the instruction fetched at the current instruction address is the result of a branch instruction. If it is a branch instruction, the branch prediction is accepted and branching is performed; otherwise, instructions are fetched sequentially. This branch prediction fault handling method not only ensures the correctness of the instruction stream but also avoids time losses caused by potential branch failures.

[0127] In this embodiment, the slave core's instructions are fetched from the master core, and the LOAD instruction data also comes from the master core. However, unlike the simultaneous execution of PC-level locksteps, the slave core's input lags behind the master core by a certain number of cycles, which is one cycle in this example. The instructions fetched by the master and slave cores are decoded and renamed in registers before the instruction information is written to the reserved station and reordering buffer.

[0128] The register renaming phase involves a physical register file (PRF) containing more registers than the instruction set specifies (architecture registers, ARF). Reduced instruction sets typically have 32 architecture registers; for example, the RISC-CV instruction set used in this example has 32 general-purpose registers (r0-r31), and the example uses 64 physical registers. In superscalar out-of-order processors, register renaming involves mapping the architecture register number (Areg) obtained after instruction decoding to the physical register number (Preg) through a table that stores the associations between architecture registers and physical registers (Register Rename Mapping Table, RAT). Figure 6 The physical register corresponding to the source register is obtained by reading the RAT. For the destination register, the original old mapped physical register Opreg is first read from the RAT, and then the new mapped physical register Preg is obtained from the free physical register table (Free list) via the Head pointer and written to the RAT. The Head pointer reads the free physical register number in the table and moves, while the Tail pointer writes and moves the physical register number released during the commit phase. During the instruction issue phase, the reservation station stores the source register number and destination register number after the instruction has been renamed. Both of these register numbers are physical register numbers. During the instruction execution phase, the input operands of the functional unit are read from the physical register file according to the register number stored in the reservation station. During the instruction write-back phase, the destination register is the renamed physical register.

[0129] S5. The renamed instruction decoding result is stored, the master and slave cores are compared, and the arbitration instruction is output through the retention station module to obtain the arbitration instruction decoding result.

[0130] The specific steps for storing, comparing, and arbitrating instructions include:

[0131] S51. Obtain the decoded result of the renamed instruction;

[0132] S52. Store the renamed instruction decoding result through the inbound and table entry movement logic, and store the corresponding opcode and operand register number;

[0133] S53. After the main core processor completes the instruction loading, it reads out the renaming result of the instruction to be loaded into the slave core processor and compares it with the result of the instruction to be loaded into the slave core processor. The comparison result is then updated to the corresponding reserved station instruction table entries of the main and slave cores in sequence.

[0134] S54. Commands with consistent comparison results are selected through arbitration transmission logic and sent out of the station to the functional unit;

[0135] S55. Before renaming instructions with inconsistent comparison results, the pipeline is paused. After the pause, fault recovery is initiated, and older instructions in the pipeline than the instructions with inconsistent comparison results are flushed out.

[0136] The storage, comparison, and arbitration of instructions include the following modules:

[0137] The push and entry movement logic is used to move all entries in the reserved station after the oldest instruction entry leaves the station and to accept the latest renaming instruction for entry.

[0138] Pop and entry arbitration launch logic are used to select the oldest entries (equal to the pipeline launch execution width) from the prepared source operands and instruction entries that have passed the master-slave core comparison check, and launch them to the functional unit for execution.

[0139] The instruction table entry storage is used to save instruction operation information distributed to the reservation station awaiting launch execution;

[0140] The master-slave core reserved station entry comparison and update module is used to read the corresponding instruction entries of the master and slave cores for comparison. If the comparison passes, the reserved station 0 checked field is updated to 1, and the instruction source operand is waited for arbitration and issued to the functional unit for execution. If the comparison fails, the reserved station 0 checked field is updated to 0, a fault is reported, and the pipeline before the renaming stage is flushed.

[0141] The reserved stations and reordering buffers used in this example are as follows: Figure 8 , Figure 9The reservation station has 8 entries, with two entries per row, for a total of four rows. The reordering buffer is organized as a circular queue, also with 8 entries. When the bottom row of the reservation station is free, the entire reservation station moves down one row, and the two renamed instructions are fed into the two entries of the top row of the reservation station. If the bottom row is not free, the reservation station does not accept new instructions. The reordering buffer's Tail specifies the most recent instruction entering the pipeline, and the Head specifies the oldest instruction in the pipeline that is about to be committed. If there are two free entries in the reordering buffer, the two instructions are written sequentially; if there are fewer than two free entries, the reordering buffer does not accept new instructions. Renamed instructions are only allowed to be written to these two components when both the reservation station and the reordering buffer have enough free entries.

[0142] S6. Perform corresponding operations on the decoded result of the instruction after the selected arbitration transmission to obtain the result of the executed instruction. The corresponding operations include arithmetic logic, multiplication and division, status register operations and memory access operations.

[0143] The specific steps for performing corresponding calculations on the decoded command results after arbitration transmission include:

[0144] S61. The calculations required to complete the corresponding arbitration transmission instruction decoding results are performed by each functional unit module.

[0145] S62. Determine the required operations for the decoded command result after the arbitration transmission. If the decoded command result after the arbitration transmission requires corresponding operations, perform the corresponding operations on the decoded command result after the arbitration transmission through each functional unit module, including:

[0146] S63. If the arbitrated instruction decoding result requires arithmetic or logical operations, then the arithmetic or logical operations are performed on the arbitrated instruction decoding result through the Arbitration Logic Unit (ALU) module:

[0147] S64. If the decoded result of the arbitrated instruction needs to be multiplied or divided, then the multiplication or division operation module is used to perform multiplication or division operations on the decoded result of the arbitrated instruction.

[0148] S65. If the arbitrated instruction decoding result needs to be operated on a status register, then the status register operation module is used to perform a status register operation on the arbitrated instruction decoding result.

[0149] S66. Read and write data by executing LOAD / STORE instructions through the memory access module.

[0150] The functional units include the following modules:

[0151] The Arithmetic Logic Unit (ALU) module is used to perform addition, subtraction, shifting, and common logical operations (AND, OR, XOR, etc.);

[0152] The multiplication, division, or status register operation module is used to perform multiplication, division, and status register operations that require multiple cycles to obtain the result;

[0153] The memory access module is used to execute LOAD / STORE instructions to read and write data.

[0154] In this embodiment, the decoding and renaming results of the master and slave core front-ends are compared after the instruction is dispatched to the reservation station and reordering buffer, and before the instruction is issued to the functional unit. Unlike the PC-level simultaneous lockstep check of branch instruction prediction results, the master and slave cores do not lockstep simultaneously when receiving and executing the same instruction; instead, they can differ by a certain number of cycles. This avoids situations where the processor cannot detect faults due to common-mode failures. This invention adds an additional 0-checked field to the reservation station entries, restricting instructions that have not undergone comparison checks from being arbitrated and issued to the functional unit for execution. This prevents processor front-end faults from further propagating to the processor back-end, thereby disrupting the processor's state and outputting errors outside the processor. For processor front-end fault handling, this invention uses the Checkpoint method for the slave core. When there is inconsistency in the comparison of the master and slave core reservation stations, the correct Register Rename Map (RAT) and Free List Head pointer saved in the past Checkpoint are used to restore the erroneous modifications made during the register renaming stage. By re-fetching instructions using the PC address of the faulty instruction, the processor can recover to the correct program flow.

[0155] In this embodiment, when the main core receives a new instruction in cycle 1, it enters the two entries in the top row of the reserved station and the entries in the reordering buffer with ROBid values ​​of 0 and 1. For simplicity, only one entry from a pair of instructions is listed; in reality, both entries perform the same operation. Other irrelevant entries are not listed, such as... Figure 9 In cycle 2, if the master core does not receive any new instructions, it compares the top two entries in the master core's reserved station with the two new instructions entering the slave core's reserved station. It also compares the two entries in the master core's reorder buffer with ROBid values ​​of 0 and 1 with the two new instructions entering the slave core's reorder buffer. If both slave core instructions match the master core's, the `checked` field of the master core's reserved station entry 0 is updated to 1, indicating that the entry has been checked, passed, and has no errors. If any instruction does not match, the `Valid` field of both the reserved station and reorder buffer instructions must be updated to 0. Figure 10 The 0-checked fields from the kernel's reserved station and reorder buffer will be delayed until cycle 3 for updates, as... Figure 11 , Figure 12 and Figure 13 As shown. In an out-of-order processor, if all source operands of an entry are calculated by the functional unit, it indicates that the corresponding instruction can be issued to the functional unit for execution, and the rdy signal of the corresponding source operand in the entry is set high. In a non-fault-tolerant design, as long as all the source operations required by the instruction are ready (rdy signal high), arbitration will be conducted during the instruction issuance phase to determine whether to read the physical register and send it to the functional unit for execution. For the fault-tolerant processor design of this invention, the 0checked field also needs to be checked; if it is 1, it can be arbitrated and sent to the functional unit for execution. If the comparison in cycle 2 fails, it indicates a fault in the processor's front-end logic, requiring flushing of the pipeline before the register renaming phase. The PC address corresponding to the older instruction in the pair of instructions that failed the comparison is retrieved from the reordering buffer, and the reordering buffer Tail is set to ROBid 0, i.e., the location of the older instruction in the faulty instruction group. In addition, the RAT and Free list of the register renaming phase also need to be restored, such as Figure 14 For RAT recovery, this invention uses a checkpoint to completely save a copy of the RAT before the faulty instruction group was changed, called the ckp RAT. This ckp RAT can be used to restore the RAT from the renaming stage. For the free list, it is not necessary to restore its contents; only a Head pointer saved by this invention before the faulty instruction group was changed, called the ckp Head pointer, needs to be used to restore the Head pointer from the renaming stage.

[0156] S7. Compare and check the results of the executed instructions and write them to obtain the written results of the executed instructions.

[0157] The writing of instructions includes the following modules:

[0158] The physical register file stores the execution results of instructions that have been completed and passed the comparison check between the master and slave cores;

[0159] The main core result delay cache is used to temporarily store the main core result before the slave core finishes execution;

[0160] The master-slave core execution result comparison and update module is used to read the master core result delay cache and the slave core execution result, as well as the corresponding entries in the write storage buffer module for comparison and checking. If the check passes, the checked and nofault fields of the master-slave core physical register file and the reordering buffer instruction entry are updated to 1. If the check fails, writing to the physical register file is prevented, the checked and nofault fields are updated to 1 and 0 respectively, and the pipeline before the execution stage is flushed.

[0161] The reordering buffer processing includes the following modules:

[0162] The allocation module is used to allocate the positions of entries in the reordering buffer for the renamed instructions according to the original instruction order of the program, specified by the tail pointer.

[0163] The commit module is used to commit instruction entries that have been executed and passed the comparison check between the master and slave cores, and to update the processor state. The position of the entry is specified by the head pointer.

[0164] The master-slave core reordering buffer entry allocation comparison update module works together with the master-slave core reserved station entry comparison update module to read the corresponding reordering buffer entries of the master and slave cores for comparison. If the comparison passes, the reserved station and reordering buffer 0 checked fields are updated to 1; if the comparison fails, the reserved station and reordering buffer 0 checked fields are updated to 0, a fault is reported, and the pipeline before the renaming stage is flushed.

[0165] The master-slave core reordering buffer entry submission arbitration module is used to submit and release free physical registers for instruction entries that have completed arbitration execution without exceptions and have passed the master-slave core comparison check. It reads the checked and nofault fields of the instruction entry to be submitted from the reordering buffer; if both are 1, a normal submission is performed; if the checked and nofault fields are 1 and 0 respectively, submission is not allowed, and the entire pipeline is flushed for recovery.

[0166] The RAT, Free list, and Busy Table recovery module during the renaming phase is used to restore the processor state in case of faults discovered during the instruction write-back or commit phase. It retrieves the Areg and Opreg values ​​from the entries pointed to by the tail pointer (Tail) to the head pointer (Head) in the reorder buffer, from the latest instruction to the oldest faulty instruction, and restores the RAT, Free list, and Busy Table modifications made by instructions present in the destination register.

[0167] like Figure 16 and Figure 17 As shown, the XOR operation is performed on the results of the executed instructions written by the master and slave cores. If the XOR operation result is 1, the input comparison signals of the executed instructions written by the master and slave cores are not equal, that is, the check fails. If the XOR operation result is 0, the input comparison signals of the executed instructions written by the master and slave cores are equal, and the check passes.

[0168] In this embodiment, after the instruction execution yields a result, the physical register file and write-store cache (STB) are updated. These results will change the processor state during the write-back or commit phase. The example uses the write-store cache as follows: Figure 13This invention writes the execution results of instructions that update the physical register file on the master core to a delay buffer. When the slave core obtains the corresponding instruction result one cycle later, it compares this result with the delay buffer to prevent erroneous results from entering the physical register file. For the write buffer, the result obtained one cycle later on the slave core is compared with the result of the corresponding entry on the master core, similar to the comparison process performed in a reserved station. After the comparison, the `checked` field of the corresponding entry in the master core reorder buffer is updated to 1, indicating that the entry has been checked, and the `nofault` field is updated to 1, indicating that the check passed and there are no errors, allowing normal updates to the physical register file and write buffer. If the check fails, the `nofault` field is updated to 0, `Write` is set to 0 to prevent writing to the physical register, and the `Valid` field of the write buffer is updated to 0, flushing the pipeline before the execution phase. During the instruction commit phase, retirement checks are performed on the two ROB entries specified by the Head pointer. Instructions are allowed to retire from the ROB only if they have been executed and have no exceptions. For the fault-tolerance design of this invention, the `checked` and `nofault` fields are also checked; only if both are 1 can the normal instruction retirement process proceed. If the nofault field is found to be 0 during the commit phase, it indicates that the instruction execution failed. This instruction and all subsequent instructions are invalid and cannot be committed, causing the Valid field of the corresponding entries in the reorder buffer and write storage buffer to be set to 0. Simultaneously, the entire pipeline needs to be flushed, retrieving the PC address corresponding to the instruction from the ROB to fetch the instruction again. In addition, the RAT from the renaming phase must be restored. This can be done by writing back the old mapping relationships corresponding to each instruction stored in the ROB one by one to the RAT. Starting from the latest instruction in the ROB to the oldest failed instruction (i.e., the entries pointed to by Tail to Head), retrieve the Areg and Opreg values, and update the RAT accordingly. The RAT will then be restored to the old mapping relationships before the renaming failed instruction. Figure 15 For Free list recovery, since a free physical register is allocated and the Head pointer is moved forward only if the instruction has a destination register, when using ROB to recover the RAT, if the ROB entry contains a destination register, the Head pointer will be moved backward, thus freeing the corresponding physical register. For faults discovered during the commit phase, the Busy Table, which records whether physical registers have been written to the instruction execution results, also needs to be recovered. When recovering a faulty instruction, subsequent instructions may have already completed execution and modified the Busy Table. Similar to Free list repair, when using ROB to recover the RAT, if the ROB entry contains a destination register and the instruction execution is complete, the Busy Table content corresponding to the Preg is invalidated. After fault recovery, subsequent instructions will not use the incorrect physical register value.

[0169] S8. After reordering and buffering the results of the executed instructions, submit them to construct a superscalar out-of-order processor.

[0170] In this embodiment, the execution results of instructions from the master and slave cores are compared before writing instructions back to physical registers and writing to the memory buffer. Additional `checked` and `nofault` fields are added to the reorder buffer to restrict the submission of instructions that have not undergone comparison checks, preventing back-end processor failures that could disrupt the processor's state and output errors outside the processor. This invention provides a delay buffer for the master core, where the results of write-to-register instructions awaiting check are stored. Only after a successful comparison are the results written to the physical registers. Fault handling for the processor's back-end can be performed during the write-back or commit phase. When the `checked` field of a pending instruction entry is found to be 1 and the `nofault` field to be 0, the entire pipeline is flushed. Simultaneously, the architecture register (Areg) and its old mapped physical register (Opreg) of the instruction entry in the reorder buffer that has a destination register are fetched sequentially from the latest instruction to the oldest faulty instruction to update the register renaming mapping table. At the same time, the head pointer of the free physical register list is rolled back, and the contents of the physical registers are invalidated. By using the PC address of the faulty instruction to fetch the instruction again, the processor can resume the correct program flow.

[0171] In summary, this invention improves the fault detection and recovery capabilities for superscalar out-of-order processors. By implementing fine-grained lockstepping in the superscalar out-of-order processor pipeline, the time from fault occurrence to fault detection and recovery to a safe and correct processor state is reduced, providing a safe and effective guarantee for application scenarios requiring both high real-time performance and high reliability. This invention divides the processor into three stages: branch prediction, front-end decoding and renaming, and back-end execution and commit, implementing different lockstep fault-tolerance designs to detect and recover from faults before they propagate to the next stage. In the branch prediction stage, inconsistent branch instruction hits and branch prediction directions are prevented from fetching instructions. Fetching is paused until the two cores in the lockstep provide consistent results or the decoded instruction information is confirmed before determining the branch prediction direction. After front-end decoding and renaming, a checkpoint is performed to save the correct processor state. After instructions are dispatched to the holdout station, the front-end result is compared and checked by setting the 0-checked field before the instruction is allowed to leave the holdout station and enter the back-end execution. After the instruction execution results are obtained, a delay buffer is set to prevent unchecked results from entering physical registers and corrupting the processor state. Before the reorder buffer is committed, the checked field and the no-error field are checked to prevent faulty instructions from being committed during the commit phase and modifying the processor state and data storage. Modifications made during the register renaming phase are restored one by one through rollback instructions.

[0172] Reference Figure 2 A fine-grained, lockstep-tolerant, superscalar out-of-order processor design system, comprising:

[0173] The branch prediction module is used to read the current instruction address and perform branch prediction to obtain the fetch address of the next instruction.

[0174] The instruction fetch module is used to obtain the corresponding instruction fetch instruction based on the instruction fetch address of the next instruction;

[0175] The decoding module is used to extract the opcode, source operand register number and destination operand register number according to the instruction fetch instruction, and obtain the instruction decoding result;

[0176] The renaming module is used to rename the instruction decoding result to obtain the renamed instruction decoding result;

[0177] The retention station module is used to store the renamed instruction decoding results, compare master and slave cores, and arbitrate instructions to obtain the arbitrated instruction decoding results.

[0178] The execution module is used to perform corresponding operations on the instruction decoding result after the selected arbitration transmission to obtain the result of the executed instruction. The corresponding operations include arithmetic logic, multiplication and division, status register operations and memory access operations.

[0179] The write-back module is used to compare, check, and write the results of the executed instructions to obtain the written results of the executed instructions.

[0180] The reordering buffer module is used to reorder and buffer the results of the executed instructions before submitting them, thus constructing a superscalar out-of-order processor.

[0181] The content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0182] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A design method for a superscalar out-of-order processor with fine-grained lockstep fault tolerance, characterized in that It includes the following steps: Read the current instruction address and perform branch prediction to obtain the fetch address of the next instruction; Obtain the corresponding fetched instruction according to the fetch address of the next instruction; Extract the opcode, source operand register numbers, and destination operand register numbers from the fetched instruction to obtain the instruction decoding result; Perform renaming processing on the instruction decoding result to obtain the renamed instruction decoding result; Store, compare the master and slave cores, and arbitrate the instruction to exit the station through the reservation station module for the renamed instruction decoding result to obtain the arbitrated instruction decoding result; Perform corresponding operations on the instruction decoding result after selecting arbitration and emission to obtain the executed completed instruction result, and the corresponding operations include arithmetic logic, multiplication and division, status register operations, and memory access operations; Perform comparison check and write processing on the executed completed instruction result to obtain the written executed completed instruction result; Perform reorder buffer processing on the written executed completed instruction result and then submit it to construct a superscalar out-of-order processor.

2. The design method of a superscalar out-of-order processor with fine-grained lockstep fault tolerance according to claim 1, characterized in that The step of reading the current instruction address and performing branch prediction to obtain the fetch address of the next instruction specifically includes: The master core processor reads the current instruction address and performs branch prediction to obtain the fetch address of the next instruction of the master core and the master core branch prediction direction; The slave core processor reads the current instruction address and performs branch prediction to obtain the fetch address of the next instruction of the slave core and the slave core branch prediction direction; Judge the fetch address of the next instruction of the master core and the fetch address of the next instruction of the slave core, and judge the master core branch prediction direction and the slave core branch prediction direction; Judge the master core branch prediction direction and the slave core branch prediction direction. If the master core branch prediction direction and the slave core branch prediction direction are the same and it is a jump, perform fetch address comparison judgment; If the fetch address of the next instruction of the master core is the same as the fetch address of the next instruction of the slave core, obtain the fetch address of the next instruction; If the fetch address of the next instruction of the master core is different from the fetch address of the next instruction of the slave core, pause fetching; If the master core branch prediction direction and the slave core branch prediction direction are the same and not a jump, do not use the fetch address of the next instruction obtained by branch prediction, and use the sequential increment address as the fetch address of the next instruction; If the master core branch prediction direction and the slave core branch prediction direction are different, pause fetching; If the instruction fetched at the current instruction address is determined to be a branch instruction in the decoding stage, use the fetch address of the next instruction obtained by branch prediction; If the instruction fetched at the current instruction address is determined to be a non-branch instruction in the decoding stage, do not use the fetch address of the next instruction obtained by branch prediction, and use the sequential increment address as the fetch address of the next instruction.

3. The design method of a superscalar out-of-order processor with fine-grained lockstep fault tolerance according to claim 2, wherein The step of the master core processor reading the current instruction address and performing branch prediction is the same as the step of the slave core processor reading the current instruction address and performing branch prediction. Among them, the steps of branch prediction are specifically as follows: The determination is based on the branch target cache module to determine whether the current instruction address exists in the branch target cache module; If the current instruction address is determined to exist, the fetch address of the next instruction at the current instruction address is obtained through the branch target cache module or the return address stack module. If it is determined that the current instruction address does not exist, the instruction fetch address of the next instruction is obtained through the instruction fetch address sequence increment module.

4. The design method of a superscalar out-of-order processor with fine-grained lockstep fault tolerance according to claim 3, characterized in that The step of renaming the instruction decoding result specifically includes: The instruction decoding result is sent to the register renaming mapping table module, which is used to store the mapping relationship between architectural registers and physical registers. Based on the instruction decoding result, determine whether a destination register exists; If a destination register exists, the free physical register number is read from the free physical register list module, and a new register mapping relationship is obtained; Write the new mapping relationship to the register and rename the mapping table module; The checkpoint is used to save the register mapping relationship from the previous moment from the kernel save and restore module.

5. A design method for a superscalar out-of-order processor with fine-grained lockstep fault tolerance according to claim 4, characterized in that, The step of storing the renamed instruction decoding result, comparing the master and slave cores, and arbitrating the instruction output through the retention station module specifically includes: Get the decoded result of the renamed instruction; The renamed instruction decoding result is stored through inbound and table entry movement logic, storing the corresponding opcode and operand register number; After the master core processor completes the instruction inbound process, it reads out the renaming result of the instruction to be inbound by the slave core processor and compares it with the result of the instruction to be inbound by the slave core processor. The comparison result is then updated to the corresponding reserved station instruction table entries of the master and slave cores in sequence. Commands that match the comparison results are selected by arbitration transmission logic and sent out of the station to the functional unit; Before renaming instructions with inconsistent comparison results, the pipeline pauses. After the pause, fault recovery is initiated, flushing out older instructions in the pipeline than the instructions with inconsistent comparison results.

6. The fine-grained, lockstep-tolerant, superscalar out-of-order processor design method according to claim 5, characterized in that, The step of performing corresponding calculations on the decoding results of the command after the selected arbitration transmission specifically includes: Each functional unit module completes the calculations required for the corresponding arbitration transmission command decoding result; The required operations for the decoded command result after arbitration transmission are determined. If the decoded command result after arbitration transmission requires corresponding operations, then the corresponding operations are performed on the decoded command result after arbitration transmission through various functional unit modules, including: If the decoded result of the arbitrated instruction requires arithmetic or logical operations, then the arithmetic or logical operations are performed on the decoded result of the arbitrated instruction through the arithmetic logic unit (ALU) module. If the decoded result of the arbitrated instruction requires multiplication or division, then the multiplication or division operation module is used to perform multiplication or division operations on the decoded result of the arbitrated instruction. If the arbitrated instruction decoding result requires status register operation, the status register operation is performed on the arbitrated instruction decoding result through the status register operation module. The memory access module executes LOAD / STORE instructions to read and write data.

7. The fine-grained, lockstep-tolerant, superscalar out-of-order processor design method according to claim 6, characterized in that, The step of comparing, checking, and writing the results of the executed instructions specifically includes: The results of the executed instructions are obtained through several functional unit modules, including the main core execution completion results and the slave core execution completion results; The main core execution completion result is cached through the main core result delay caching unit; The cached execution result of the main core is compared and checked with the execution result of the slave core by the main-slave core execution result comparison and update module. If the comparison results are consistent, the comparison results will be updated to the instruction table entries of the corresponding reordering buffers of the master and slave cores in sequence, and the program will wait for the submission logic to select and leave the reordering buffer. If the comparison results are inconsistent, the pipeline before the execution stage is paused to perform fault recovery and flush out instructions in the pipeline that are older than the instruction corresponding to the comparison result.

8. A design method for a fine-grained lockstep fault-tolerant superscalar out-of-order processor according to claim 7, characterized in that The step of reordering and buffering the written executed instruction results before submission specifically includes: Upon submission, the command entry check result field is checked. If the check passes and there are no errors, the command is released from the reordering buffer. For commands that are not checked or fail the check and do not meet the requirements, fault recovery is performed for those that fail the check.

9. A design method for a fine-grained lockstep fault-tolerant superscalar out-of-order processor according to claim 8, characterized in that The step of checking the result field of the instruction table entry specifically includes: Perform a master-slave XOR operation on the results of the executed instructions that have been written; If the XOR operation result is 1, then the results of the executed instructions written by the master and slave cores are not equal to the input comparison signals, i.e., the check fails. If the XOR operation result is 0, then the results of the executed instructions written by the master and slave cores are equal to the input comparison signal, and the check passes.

10. A superscalar out-of-order processor design system with fine-grained lockstep fault tolerance, characterized in that, Includes the following modules: The branch prediction module is used to read the current instruction address and perform branch prediction to obtain the fetch address of the next instruction. The instruction fetch module is used to obtain the corresponding instruction fetch instruction based on the instruction fetch address of the next instruction; The decoding module is used to extract the opcode, source operand register number and destination operand register number according to the instruction fetch instruction, and obtain the instruction decoding result; The renaming module is used to rename the instruction decoding result to obtain the renamed instruction decoding result; The retention station module is used to store the renamed instruction decoding results, compare master and slave cores, and arbitrate instructions to obtain the arbitrated instruction decoding results. The execution module is used to perform corresponding operations on the instruction decoding result after the selected arbitration transmission to obtain the result of the executed instruction. The corresponding operations include arithmetic logic, multiplication and division, status register operations and memory access operations. The write-back module is used to compare, check, and write the results of the executed instructions to obtain the written results of the executed instructions. The reordering buffer module is used to reorder and buffer the results of the executed instructions before submitting them, thus constructing a superscalar out-of-order processor.

Images