Full-link lockstep verification system compatible with fault injection and dual-core lockstep architecture

Abstract

The invention relates to the technical field of microprocessor verification, in particular to a full-link lockstep verification system compatible with fault injection and a dual-core lockstep architecture, and the system comprises a fault injection unit which is used for injecting a fault into a single-core register file of the dual-core lockstep architecture; the driving component is used for driving the dual-core lockstep architecture to perform hardware simulation based on the test case; the monitoring component is used for monitoring the actual execution result of the dual-core lockstep architecture and the reference execution result of the test case, comparing the actual execution result with the reference execution result, and verifying the fault recovery performance of the dual-core lockstep architecture after fault injection according to the comparison result; and the comparison control unit is used for acquiring the fault injection time and the PC value of the fault recovery process, and controlling the next fault injection action of the fault injection unit according to the fault injection time and the PC value. Therefore, the problems that full-link verification cannot be supported during fault injection in the prior art, the verification efficiency is low, and the consumed time is long are solved.

Description

Technical Field

[0001] The present application relates to the field of microprocessor verification technology, and in particular to a full-link lock-step verification system and a dual-core lock-step architecture compatible with fault injection. Background Art

[0002] DCLS (Dual-Core Lockstep) is a parallel architecture designed to improve computing fault tolerance and security. It consists of two or more independent processing cores that can run synchronously with each other and execute the same instruction sequence at the same time. When any processing core deviates from the predetermined execution path, the system will take corresponding measures, such as resetting, recovering or entering a safe state, to ensure data consistency and correctness.

[0003] Since DCLS is a fault-tolerant system, the verification of its hardware implementation cannot be limited to the verification of the normal execution function of the processor instructions, but it is necessary to inject faults during the normal execution process to trigger the recovery mechanism of DCLS and verify the entire process. Within a period of time after the fault is injected, an erroneous execution result will inevitably appear and trigger the recovery mechanism, while the erroneous execution flow before the successful recovery is allowed. Therefore, for the DCLS system, if fault injection is performed, the verification system in the relevant technology cannot support full-link verification (for a test program, if it can be compared from the beginning to the end of its execution to ensure the correctness of the execution flow), and the fault is injected according to a certain time or space probability distribution in the entire design to be tested. When facing the DCLS system, it is impossible to fully utilize the characteristics of fault propagation in the processor, resulting in low efficiency and long running time. Summary of the invention

[0004] The present application provides a full-link lock-step verification system and a dual-core lock-step architecture compatible with fault injection to solve the problems that related technologies cannot support full-link verification when performing fault injection, and have low verification efficiency and long time.

[0005] The first aspect of the present application provides a full-link lock-step verification system compatible with fault injection, including: a fault injection unit, used to inject faults into a single-core register stack of a dual-core lock-step architecture; a driving component, used to drive the dual-core lock-step architecture to perform hardware simulation based on a test case; a monitoring component, used to monitor the actual execution results of the dual-core lock-step architecture and the reference execution results of the test case, compare the actual execution results with the reference execution results, and verify the fault recovery performance of the dual-core lock-step architecture after fault injection according to the comparison results; a comparison control unit, used to obtain the fault injection time of the fault injection unit and the PC value of the fault recovery process of the dual-core lock-step architecture, and control the next fault injection action of the fault injection unit according to the fault injection time and the PC value.

[0006] Optionally, after the comparison control unit determines that the dual-core lock-step architecture has been successfully recovered after the fault injection according to the fault injection time and the PC value, the fault injection unit is controlled to perform the next fault injection action.

[0007] Optionally, the driving component includes a test case serialization unit and a driving unit, wherein the test case serialization unit is used to serialize the test cases; and the driving unit uses the serialized test cases as excitation for the dual-core lock-step architecture.

[0008] Optionally, the serialized test case includes at least one of an instruction start address, an offset address and a program segment running on the dual-core lock-step architecture.

[0009] Optionally, the monitoring component includes a PC monitoring subcomponent, a data monitoring subcomponent and a comparison unit, wherein the PC monitoring subcomponent is used to obtain a reference execution result of the test case; the data monitoring subcomponent is used to obtain the actual execution result of the dual-core lock-step architecture; and the comparison unit is used to compare the actual execution result with the reference execution result.

[0010] Optionally, the PC monitoring subcomponent includes a PC monitoring unit, a reference execution transaction converter, a PC monitoring queue and a reference data queue, wherein the PC monitoring queue and the reference data queue are both connected to the comparison unit, wherein the PC monitoring unit obtains the PC value of the fault recovery process of the dual-core lock-step architecture and puts the PC value into the PC monitoring queue; the reference execution transaction converter queries the reference execution result of the test case according to the PC value and puts the reference execution result of the test case into the reference data queue.

[0011] Optionally, the PC monitoring unit provides the comparison control unit with a PC value of a fault recovery process of the dual-core lock-step architecture, and performs a monitoring action according to a control instruction of the comparison control unit.

[0012] Optionally, the data monitoring subcomponent includes a data monitoring unit and a data monitoring queue, and the data monitoring queue is connected to the comparison unit, wherein the data monitoring unit is used to monitor the actual execution result of the dual-core lock-step architecture and put the actual execution result of the dual-core lock-step architecture into the data monitoring queue.

[0013] A second aspect of the present application provides a dual-core lock-step architecture, which utilizes the full-link lock-step verification system compatible with fault injection of the above-mentioned embodiment to perform full-link lock-step verification.

[0014] A third aspect of the present application provides a full-link lock-step verification method compatible with fault injection, which uses the full-link lock-step verification system compatible with fault injection of the above-mentioned embodiment to perform full-link lock-step verification on a dual-core lock-step architecture, including the following steps: driving the dual-core lock-step architecture to perform hardware simulation based on a test case; injecting a fault into a single-core register stack of the dual-core lock-step architecture, monitoring the actual execution results of the dual-core lock-step architecture and the reference execution results of the test case, comparing the actual execution results with the reference execution results, and verifying the fault recovery performance of the dual-core lock-step architecture after fault injection according to the comparison results; obtaining the fault injection time and the PC value of the fault recovery process of the dual-core lock-step architecture, and controlling the next fault injection action according to the fault injection time and the PC value.

[0015] Therefore, this application includes the following beneficial effects:

[0016] The embodiment of the present application can inject faults into the single-core register stack of the dual-core lock-step architecture, improve verification efficiency, reduce the running time of the verification platform, and by adding a monitoring component, the dual-core lock-step architecture executes the test program and performs fault injection. The whole process of monitoring and comparison, even after the fault injection, the abnormal execution flow that occurs during the recovery process will not cause the verification platform to report an error and interrupt the operation. Only the execution flow is recorded without comparison between the fault injection and the successful recovery and execution to the injection position, and full-link verification is supported to ensure the correctness of the system-level program execution flow. The comparison control unit can control the next fault injection action of the fault injection unit according to the fault injection time and PC value after the fault is recovered, thereby improving the verification efficiency. Thus, the problems that the related technology cannot support full-link verification when performing fault injection, and there are problems such as low verification efficiency and long time consumption are solved.

[0017] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0019] Figure 1 A block diagram of a full-link lock-step verification system compatible with fault injection provided according to an embodiment of the present application;

[0020] Figure 2 An example control diagram of a dual-core lockstep architecture execution flow and a verification flow provided according to an embodiment of the present application;

[0021] Figure 3 A detailed example diagram of a full-link lock-step verification system compatible with fault injection provided according to an embodiment of the present application;

[0022] Figure 4 This is a flowchart of a full-link lock-step verification method compatible with fault injection according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0024] The following describes the full-link lock-step verification system and dual-core lock-step architecture compatible with fault injection of the embodiment of the present application with reference to the accompanying drawings. In response to the problems mentioned in the above background technology, the present application provides a full-link lock-step verification system compatible with fault injection, in which the fault is injected into the single-core register stack of the dual-core lock-step architecture, the verification efficiency is improved, the running time of the verification platform is reduced, and the monitoring component is added to monitor and compare the entire process of executing the test program and performing fault injection in the dual-core lock-step architecture. Even after the fault injection, the abnormal execution flow that occurs during the recovery process will not cause the verification platform to report an error and interrupt the operation. Only the execution flow is recorded without comparison between the fault injection and the successful recovery and execution to the injection position, and the full-link verification is supported to ensure the correctness of the system-level program execution flow, and the comparison control unit can control the next fault injection action of the fault injection unit according to the fault injection time and PC value after the fault is recovered, thereby improving the verification efficiency. Thus, the problems that the related technology cannot support full-link verification when performing fault injection, and there are problems such as low verification efficiency and long time spent are solved.

[0025] Specifically, Figure 1 It is a block diagram of a full-link lock-step verification system compatible with fault injection according to an embodiment of the present application.

[0026] like Figure 1 As shown, the full-link lock-step verification system 10 compatible with fault injection includes: a fault injection unit 100, a driving component 200, a monitoring component 300 and a comparison control unit 400.

[0027] Among them, the fault injection unit 100 is used to inject faults into the single-core register stack of the dual-core lock-step architecture DCLS; the driving component 200 is used to drive the dual-core lock-step architecture to perform hardware simulation based on the test case; the monitoring component 300 is used to monitor the actual execution results of the dual-core lock-step architecture and the reference execution results of the test case, compare the actual execution results with the reference execution results, and verify the fault recovery performance of the dual-core lock-step architecture after fault injection according to the comparison results; the comparison control unit 400 is used to obtain the fault injection time of the fault injection unit and the PC value of the fault recovery process of the dual-core lock-step architecture, and control the next fault injection action of the fault injection unit according to the fault injection time and PC value.

[0028] It is understandable that when the fault injection unit 100 injects a fault into a single-core register stack of the DCLS, the driving component 200 will run the processor according to the predetermined test case to drive the dual-core lock-step architecture DCLS to perform hardware simulation, and the monitoring component 300 will monitor the actual execution of the dual-core lock-step architecture DCLS in real time, and compare it with the pre-calculated reference result, timely discover and record the recovery after the fault occurs, and ensure the accuracy of the verification process. The comparison control unit 400 receives the time point information of the fault injection from the fault injection unit, and captures the key signal from the DCLS to determine whether the recovery is successful. Based on this information, it is determined when to allow the next fault injection, and the verification flow is precisely controlled. The comparison behavior of the verification platform is suspended from the fault injection to the completion of the recovery, and only the execution flow is recorded without comparison. The comparison is restarted until the recovery is successful and the correct execution flow continues, ensuring that the full link verification is achieved.

[0029] As shown in Figure 2, for a specific fault injection, the verification platform controls the execution flow and verification flow. The yellow line in the figure indicates the normal execution flow of the processor core if no fault injection is performed, which is also the execution flow of the simulator. The red part in the figure indicates the actual execution flow of DCLS after a fault injection: forward according to the original execution flow or the execution flow with an error → the redundant detection unit of DCLS detects the error and starts the recovery process → the recovery is completed, the state changes to the state of the last backup point → continue to execute backward at the last backup point. The green part in the figure indicates the verification flow of the verification platform, that is, after the fault injection, the verification platform stops the comparison behavior and only monitors the running state and execution flow of the processor core; wait until the processor core completes the recovery and continues the correct execution flow until the fault injection location, and then restarts the comparison behavior of the verification platform. If there is a problem in the backup or recovery mechanism, it will be exposed in the monitoring and comparison of the verification platform after the recovery.

[0030] In an embodiment of the present application, fault injection is performed on the general register stack of a single core of the DCLS system. Faults occurring in the data stream of the processor core will first propagate to the register stack, and then propagate outside the core by the storage instruction and be detected by the redundant detection unit, or remain in the register stack; faults on the non-data stream of the processor core can be divided into pipeline control state faults and execution flow faults. The former can be directly detected by the redundant detection unit, while the latter is detected by sending incorrect value information to the instruction cache. Therefore, in the verification of the DCLS system, only registers are selected as the target of fault injection, which is representative and efficient. By focusing on the register stack, the complexity of fault injection on the verification platform can be reduced, and the control and observation of the fault injection and detection process can be more direct and easy.

[0031] Furthermore, when actually performing fault injection, the embodiment of the present application also needs to consider the probability of faults occurring in different registers. For register stacks, faults usually occur evenly in all registers; however, since the register stack not only represents those faults that were initially generated in the register stack, but also brings together all faults generated in the data streams at all levels of the pipeline. In the embodiment of the present application, the verification platform performs multiple random and evenly distributed bit fault injections for each register independently, and obtains statistical results after a large number of repetitions. The advantage of this fault injection mechanism is that the independent fault injection data of each register can be summarized, and different processing methods can be selected according to different requirements when the final data is processed, thereby improving the flexibility of data analysis. For example: Pure average: When calculating the fault detection and recovery effects, all registers are given the same weight. Therefore, this method corresponds to fault injection in a register stack, where the probability of all registers is equal. Weighted average: When calculating the fault detection and recovery effects, they are weighted according to the number of times they are written during execution, thereby considering the impact of faults in the data streams at all levels of the pipeline on the propagation of specific registers. Multi-factor distribution: When calculating the effectiveness of fault detection and recovery, weights are applied based on the impact of specific factors of interest on individual registers. For example, if the model believes that the probability of a fault is proportional to the area of ​​the execution level used by the instruction, then the register written by each instruction in the test program is used as the benchmark, and the execution level area used is used as the weight for weighting.

[0032] In one embodiment of the present application, the driving component 200 includes a test case serialization unit and a driving unit, wherein the test case serialization unit is used to serialize the test cases; and the driving unit uses the serialized test cases as excitation for the dual-core lock-step architecture.

[0033] The serialized test case includes at least one of an instruction start address, an offset address and a program segment running in the dual-core lock-step architecture.

[0034] like Figure 3As shown, the dual-core lock-step architecture includes: a main core, a check core and a redundant detection unit, wherein the main core and the check core are the main objects of verification, and the redundant detection unit is used to assist the work of the check core. The drive component 200 of the embodiment of the present application includes a test case serialization unit and a drive unit, which mainly provides incentives for the dual-core lock-step architecture, where the incentives are the instruction start address, offset address, program segment, etc. of the dual-core lock-step architecture. It should be noted that the above content provided by each test case is not the same and is not specifically limited.

[0035] In one embodiment of the present application, the monitoring component 300 includes a PC monitoring subcomponent, a data monitoring subcomponent and a comparison unit, wherein the PC monitoring subcomponent is used to obtain a reference execution result of a test case; the data monitoring subcomponent is used to obtain an actual execution result of a dual-core lock-step architecture; and the comparison unit is used to compare the actual execution result with the reference execution result.

[0036] Furthermore, the PC monitoring subcomponent includes a PC monitoring unit, a reference execution transaction converter, a PC monitoring queue and a reference data queue, wherein the PC monitoring queue and the reference data queue are both connected to the comparison unit, wherein the PC monitoring unit obtains the PC value of the fault recovery process of the dual-core lock-step architecture and puts the PC value into the PC monitoring queue; the reference execution transaction converter queries the reference execution result of the test case according to the PC value and puts the reference execution result of the test case into the reference data queue. The PC monitoring unit provides the PC value of the fault recovery process of the dual-core lock-step architecture to the comparison control unit, and performs the monitoring action according to the control instruction of the comparison control unit.

[0037] Furthermore, the data monitoring subcomponent includes a data monitoring unit and a data monitoring queue, and the data monitoring queue is connected to the comparison unit, wherein the data monitoring unit is used to monitor the actual execution result of the dual-core lock-step architecture and put the actual execution result of the dual-core lock-step architecture into the data monitoring queue.

[0038] Specifically, if Figure 3 As shown, the PC monitoring subcomponent is mainly used to provide the PC value of the dual-core lock-step architecture execution to the reference execution transaction converter, and is connected to the function of the reference execution transaction converter through the API interface, and the ideal execution result is obtained by querying the reference execution result of the test case executed by the simulator. The data monitoring unit subcomponent is used to monitor the actual execution results of the instructions in the dual-core lock-step architecture. The ideal execution result and the actual execution result will be sent to the comparison unit for comparison. If the comparison is wrong, relevant information (such as instruction PC, correct and incorrect execution results, etc.) will be printed to assist in troubleshooting. In the actual execution process, the data transmission between each module is connected using FIFO (first-in-first-out queue) to adapt to the cycle difference between the dual-core lock-step architecture hardware simulation execution results and the reference model.

[0039] In one embodiment of the present application, after the comparison control unit 400 determines that the dual-core lock-step architecture has been successfully recovered after the fault injection according to the fault injection time and the target signal, the fault injection unit is controlled to perform the next fault injection action.

[0040] In order to realize recovery tracking and post-recovery execution flow comparison, the comparison control unit 400 of the embodiment of the present application is used to implement the verification flow control logic described in the above embodiment. It obtains the time of fault injection from the fault injection unit 100, uses the interface (interface module) to obtain the key target signal of the control recovery process from the dual-core lock-step architecture, and controls whether to allow the next fault injection on this basis.

[0041] From the perspective of general verification methodology, the comparison control unit 400 still inherits the Monitor class because it needs to collect some signal values ​​in the dual-core lock-step architecture to determine Figure 2 The position of each moment in the program. The fault injection unit 100 of the embodiment of the present application is used to inject faults into the single-core register stack of the dual-core lock-step architecture DCLS at a specific moment. The fault injection unit 100 is implemented as a Driver in the UVM component system, but there is no test case serialization unit connected to it, and it randomly flips bits in the register set by the execution script as fault injection.

[0042] In order to observe the hardware's fault detection and recovery after a fault injection, the fault injection unit 100 is set to perform the next fault injection only after a fault injection is successfully recovered. Whether the recovery is successful is determined by the comparison control unit 400 monitoring the core lockstep architecture.

[0043] Specifically, 1. If a software backup and recovery system is used: the corresponding backup and recovery programs are all embodied in the form of interrupt handlers, and the successful recovery mark is that the monitored PC value reaches the last instruction PC of the corresponding interrupt handler; 2. If some form of hardware-assisted recovery is used: the comparison control unit needs to monitor the signal that the hardware recovery module controls the recovery, and judge the successful recovery mark through the logical combination of the corresponding signals.

[0044] In summary, the full-link lock-step verification system compatible with fault injection in the embodiment of the present application adds a mechanism for controlling the verification flow (i.e., the order in which the executed instructions are compared) relative to the traditional verification system. After fault injection, the execution result of the instruction in the processor core or the instruction execution flow may produce errors, and these errors are predictable before correct recovery. In addition, due to the existence of the recovery mechanism, there may be a period of abnormal execution flow (software recovery) or several cycles of abnormal response (hardware recovery) during the recovery process, and the abnormal conditions of these processor cores are also predictable. Finally, after the recovery is successful, the execution flow of the program will return to a previous backup point, and the normal execution flow has passed this position and continues to execute backwards, and in the traditional processor core verification platform, this repetition will cause the verification platform to report an exception.

[0045] According to the full-link lock-step verification system compatible with fault injection proposed in the embodiment of the present application, the fault is injected into the single-core register stack of the dual-core lock-step architecture, the verification efficiency is improved, the running time of the verification platform is reduced, and the monitoring component is added to monitor and compare the entire process of executing the test program and performing fault injection in the dual-core lock-step architecture. Even after the fault injection, the abnormal execution flow that occurs during the recovery process will not cause the verification platform to report an error and interrupt the operation. Only the execution flow is recorded without comparison between the fault injection and the successful recovery and execution to the injection position. Full-link verification is supported to ensure the correctness of the system-level program execution flow, and the comparison control unit can control the next fault injection action of the fault injection unit according to the fault injection time and PC value after the fault is recovered, thereby improving the verification efficiency. Thus, the problems that the related technology cannot support full-link verification when performing fault injection, and there are problems such as low verification efficiency and long time consumption are solved.

[0046] Secondly, a full-link lock-step verification method compatible with fault injection proposed according to an embodiment of the present application is described with reference to the accompanying drawings. The method utilizes the full-link lock-step verification system compatible with fault injection of the above-mentioned embodiment to perform full-link lock-step verification on the dual-core lock-step architecture.

[0047] Figure 4 A flowchart of a full-link lock-step verification method compatible with fault injection provided in an embodiment of the present application.

[0048] like Figure 4 As shown, the full-link lock-step verification method compatible with fault injection includes the following steps:

[0049] In step S101 , a dual-core lock-step architecture is driven to perform hardware simulation based on a test case.

[0050] In step S102, a fault is injected into a single-core register stack of the dual-core lock-step architecture, the actual execution result of the dual-core lock-step architecture and the reference execution result of the test case are monitored, the actual execution result and the reference execution result are compared, and the fault recovery performance of the dual-core lock-step architecture after the fault injection is verified according to the comparison result.

[0051] In step S103, the fault injection time and the PC value of the fault recovery process of the dual-core lock-step architecture are obtained, and the next fault injection action is controlled according to the fault injection time and the PC value.

[0052] It should be noted that some of the explanations of the aforementioned embodiment of the full-link lock-step verification system compatible with fault injection are also applicable to the full-link lock-step verification method compatible with fault injection of this embodiment. To avoid redundancy, they will not be repeated here.

[0053] According to the full-link lock-step verification method compatible with fault injection proposed in the embodiment of the present application, the fault is injected into the single-core register stack of the dual-core lock-step architecture to improve the verification efficiency and reduce the running time of the verification platform. By monitoring and comparing the entire process of executing the test program and performing fault injection in the dual-core lock-step architecture, even after the fault injection, the abnormal execution flow that occurs during the recovery process will not cause the verification platform to report an error and interrupt the operation. Only the execution flow is recorded without comparison between the fault injection and the successful recovery and execution to the injection position. Full-link verification is supported to ensure the correctness of the system-level program execution flow, and after the fault is recovered, the next fault injection action of the fault injection unit can be controlled according to the fault injection time and PC value, thereby improving the verification efficiency. Thus, the problems that the related technology cannot support full-link verification when performing fault injection, and there are problems such as low verification efficiency and long time consumption are solved.

[0054] In addition, an embodiment of the present application also provides a dual-core lock-step architecture, which uses the full-link lock-step verification system compatible with fault injection of the above-mentioned embodiment to perform full-link lock-step verification.

[0055] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0056] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0057] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or N executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0058] It should be understood that the various parts of the present application can be implemented in hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, the steps or methods can be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array, a field programmable gate array, etc.

[0059] A person of ordinary skill in the art may understand that all or part of the steps carried by the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the above-mentioned program may be stored in a computer-readable storage medium, which, when executed, includes one of the steps of the method embodiment or a combination thereof.

[0060] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A full-link lock-step verification system compatible with fault injection, characterized in that: include: A fault injection unit for injecting faults into a single core register file of a dual-core lockstep architecture; A driver component, used for driving the dual-core lock-step architecture to perform hardware simulation based on a test case; A monitoring component, used to monitor an actual execution result of the dual-core lock-step architecture and a reference execution result of the test case, compare the actual execution result with the reference execution result, and verify the fault recovery performance of the dual-core lock-step architecture after fault injection according to the comparison result; A comparison control unit is used to obtain the fault injection time of the fault injection unit and the PC value of the fault recovery process of the dual-core lock-step architecture, and control the next fault injection action of the fault injection unit according to the fault injection time and the PC value.

2. The full-link lock-step verification system compatible with fault injection according to claim 1, characterized in that: After the comparison control unit determines that the dual-core lock-step architecture has been successfully recovered after the fault injection according to the fault injection time and the PC value, the comparison control unit controls the fault injection unit to perform the next fault injection action.

3. The full-link lock-step verification system compatible with fault injection according to claim 1, characterized in that: The driving component includes a test case serialization unit and a driving unit, wherein: The test case serialization unit is used to serialize the test case; The driving unit uses the serialized test cases as incentives for the dual-core lock-step architecture.

4. The full-link lock-step verification system compatible with fault injection according to claim 3, characterized in that: The serialized test case includes at least one of an instruction start address, an offset address, and a program segment run by the dual-core lockstep architecture.

5. The full-link lock-step verification system compatible with fault injection according to claim 1, characterized in that: The monitoring component includes a PC monitoring subcomponent, a data monitoring subcomponent and a comparison unit, wherein: The PC monitoring subcomponent is used to obtain the reference execution result of the test case; The data monitoring subcomponent is used to obtain the actual execution result of the dual-core lock-step architecture; The comparison unit is used to compare the actual execution result with the reference execution result.

6. The full-link lock-step verification system compatible with fault injection according to claim 5, characterized in that: The PC monitoring subcomponent includes a PC monitoring unit, a reference execution transaction converter, a PC monitoring queue and a reference data queue, wherein the PC monitoring queue and the reference data queue are both connected to the comparison unit, wherein: The PC monitoring unit obtains a PC value of a fault recovery process of the dual-core lock-step architecture, and puts the PC value into the PC monitoring queue; The reference execution transaction converter queries the reference execution result of the test case according to the PC value, and puts the reference execution result of the test case into the reference data queue.

7. The full-link lock-step verification system compatible with fault injection according to claim 6, characterized in that: The PC monitoring unit provides the comparison control unit with a PC value of a fault recovery process of the dual-core lock-step architecture, and performs monitoring actions according to a control instruction of the comparison control unit.

8. The full-link lock-step verification system compatible with fault injection according to claim 7, characterized in that: The data monitoring subassembly includes a data monitoring unit and a data monitoring queue, wherein the data monitoring queue is connected to the comparison unit, wherein: The data monitoring unit is used to monitor the actual execution result of the dual-core lock-step architecture and put the actual execution result of the dual-core lock-step architecture into the data monitoring queue.

9. A dual-core lockstep architecture, characterized in that: The dual-core lock-step architecture uses the full-link lock-step verification system compatible with fault injection described in any one of claims 1-8 to perform full-link lock-step verification.

10. A full-link lock-step verification method compatible with fault injection, characterized in that: The method uses the full-link lock-step verification system compatible with fault injection according to any one of claims 1 to 8 to perform full-link lock-step verification on the dual-core lock-step architecture, wherein the method comprises the following steps: Driving the dual-core lockstep architecture to perform hardware simulation based on test cases; Injecting a fault into a single-core register stack of a dual-core lock-step architecture, monitoring an actual execution result of the dual-core lock-step architecture and a reference execution result of the test case, comparing the actual execution result with the reference execution result, and verifying fault recovery performance of the dual-core lock-step architecture after the fault injection according to the comparison result; The fault injection time and the PC value of the fault recovery process of the dual-core lock-step architecture are obtained, and the next fault injection action is controlled according to the fault injection time and the PC value.

Images