A Method for Verifying the CPU Abnormal Function of Fault Injection

Abstract

The present invention discloses a method for verifying the abnormal function of a CPU with fault injection, belonging to the field of processor verification. A test case is processed by a compiler to be converted into a target assembly file, and the target assembly file at least includes first assembly code; determining a target exception code to be inserted into the first assembly code and its insertion address; modifying the original exception handler and the original jump code; inserting the target exception code at the insertion address in the first assembly code to obtain second assembly code; compiling the second assembly code, and processing the second assembly code by an assembler to be converted into a binary format for the simulation model and the CPU under test to execute the binary file; comparing the execution results of the simulation model and the CPU under test, and verifying whether the function of the CPU under test is normal according to the comparison result, so as to complete the verification of the CPU under test. The present application can fully verify the function of the CPU.

Description

Technical Field

[0001] This application relates to the field of processor verification, and particularly to a method for verifying the abnormal functions of a CPU with fault injection. Background Art

[0002] During the verification process of the abnormal functions of a chip, since it is difficult to construct test cases for abnormal function scenarios, the test cases of the constructed abnormal code need to be tested separately through a directed test method during the test process. In this scenario, whether the CPU can continue to process normal instructions after completing the processing of the abnormal code cannot be covered by the verification environment, which poses a risk to the completeness verification of the CPU.

[0003] Therefore, there is a technical problem in the prior art that the function verification of the CPU is insufficient. Summary of the Invention

[0004] The main purpose of this application is to provide a method for verifying the abnormal functions of a CPU with fault injection, aiming to solve the technical problem of insufficient function verification of the CPU.

[0005] To achieve the above purpose, this application provides a method for verifying the abnormal functions of a CPU with fault injection, and the method for verifying the abnormal functions of a CPU with fault injection includes the following steps:

[0006] Convert the test case into a target assembly file through compiler processing, and the target assembly file at least includes a first assembly code;

[0007] Determine the target abnormal code to be inserted into the first assembly code and its insertion address;

[0008] Modify the original abnormal handler and the original jump code, so that after the simulation model and the CPU under test execute the target abnormal code, they can process the target abnormal code based on the modified original abnormal handler and the original jump code, and execute the next line of code;

[0009] Insert the target abnormal code at the insertion address in the first assembly code to obtain a second assembly code;

[0010] Convert the second assembly code into a binary file through assembler processing for the simulation model and the CPU under test to execute the binary file;

[0011] Compare the execution results of the simulation model and the CPU under test, and verify whether the function of the CPU under test is normal according to the comparison result.

[0012] In a possible implementation manner of the present application, the target assembly file includes the target assembly file. The step of determining the target exception code to be inserted into the first assembly code and its insertion address includes:

[0013] Judge the matching degree between the file line characters in the target assembly file and each exception scenario character in the preset configuration parameters;

[0014] Use the exception scenario character with the highest matching degree as the target exception code, and use the address of the file line character corresponding to the exception scenario character with the highest matching degree in the target assembly file as the insertion address.

[0015] In a possible implementation manner of the present application, the step of judging the matching degree between the file line characters in the target assembly file and each exception scenario character in the preset configuration parameters includes:

[0016] Identify all characters of the instruction address, machine code, and assembly instruction in the target assembly file;

[0017] Match all the characters with the exception scenario characters in the preset configuration parameters in sequence from the starting character to the ending character to obtain the matching degree between all the characters and each exception scenario character.

[0018] In a possible implementation manner of the present application, after the step of determining the target exception code to be inserted into the first assembly code and its insertion address, the method further includes:

[0019] Record the PC value of the insertion address through the exception handling register;

[0020] When the target exception code is executed, monitor whether the PC value of the insertion address recorded in the exception handling register is consistent with the address where the currently executed target exception code is located;

[0021] If they are consistent, execute the steps of modifying the original exception handling program and the original jump code.

[0022] In a possible implementation manner of the present application, the steps of modifying the original exception handling program and the original jump code include:

[0023] Modify the original exception handling program according to the target exception code;

[0024] Modify the PC value of each address after the insertion address and its subsequent addresses in the original jump code to the PC value plus the preset number of addresses.

[0025] In a possible implementation manner of the present application, before the step of determining the target exception code to be inserted into the first assembly code and its insertion address, the method further includes:

[0026] Select whether to insert the target exception code into the first assembly code according to the probability generated by calling the random function;

[0027] If it is selected to insert, execute the step of determining the target exception code to be inserted into the first assembly code and its insertion address.

[0028] In a possible implementation manner of the present application, the second assembly code includes normal code. The step of comparing the simulation model and the execution result of the CPU under test, and verifying whether the function of the CPU under test is normal according to the comparison result includes:

[0029] Execute the binary file through the simulation model and the CPU under test respectively to obtain a first abnormal execution result, a first normal execution result, a second abnormal execution result, and a second normal execution result;

[0030] Based on the comparison between the first normal execution result and the second normal execution result, and the comparison between the first abnormal execution result and the second abnormal execution result, verify whether the function of the CPU under test is normal.

[0031] The present application provides a method for verifying the abnormal function of a CPU with fault injection. Compared with the prior art where in the testing process, it is necessary to test the test cases of the constructed abnormal code separately through a directed testing method. In this scenario, the verification environment cannot cover whether the CPU can continue to process normal instructions after completing the processing of the abnormal code. In contrast, in the present application, the test cases are processed by a compiler and converted into a target assembly file, and the target assembly file at least includes a first assembly code; target abnormal code is inserted into the first assembly code, and the original exception handler and the original jump code are modified so that they can process the inserted target abnormal code and can also continue to execute the next line of code in the original code order after processing the target abnormal code, that is, the target abnormal code can be executed without affecting the execution of the original code. The second assembly code after inserting the target abnormal code is processed by a reporter and converted into a binary format for the simulation model and the CPU under test to execute the binary file. Finally, the execution results of the simulation model and the CPU under test are compared, and according to the comparison result, it is verified whether the function of the CPU under test is normal, so as to complete the verification of the CPU under test. During the verification process, it is not necessary to separately construct the abnormal code, nor to separately test the abnormal code one by one, and it can also verify whether the CPU under test can continue to execute the original normal code normally after executing the target abnormal code. Therefore, the present application can fully verify the function of the CPU. Description of the Drawings

[0032] Figure 1 It is a schematic flowchart of the first embodiment of a method for verifying the abnormal function of a CPU with fault injection according to the present application;

[0033] Figure 2 It is the first logical architecture diagram of the method for verifying the abnormal function of a CPU with fault injection according to the first embodiment of the present application;

[0034] Figure 3 It is the second logical architecture diagram of the method for verifying the abnormal function of a CPU with fault injection according to the first embodiment of the present application.

[0035] The implementation, functional characteristics and advantages of the object of the present invention will be further described with reference to the embodiments and the drawings. Detailed Embodiments

[0036] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0037] The embodiments of the present invention provide a method for verifying the abnormal function of a CPU with fault injection, referring to Figure 1 , Figure 1 It is a schematic flowchart of the first embodiment of a method for verifying the abnormal function of a CPU with fault injection according to the present application.

[0038] In this embodiment, the method for verifying the CPU abnormal function of fault injection includes:

[0039] Step S10: Convert the test case into a target assembly file through compiler processing, where the target assembly file includes at least a first assembly code;

[0040] Step S20: Determine the target abnormal code to be inserted into the first assembly code and its insertion address;

[0041] Step S30: Modify the original exception handler and the original jump code so that after the simulation model and the CPU under test execute the target abnormal code, they can process the target abnormal code based on the modified original exception handler and the original jump code, and execute the next line of code;

[0042] Step S40: Insert the target abnormal code at the insertion address in the first assembly code to obtain a second assembly code;

[0043] Step S50: Convert the second assembly code into a binary file through assembler processing for the simulation model and the CPU under test to execute the binary file;

[0044] Step S60: Compare the execution results of the simulation model and the CPU under test, and verify whether the function of the CPU under test is normal according to the comparison result.

[0045] The purpose of this embodiment is to solve the problem that during the verification process of the abnormal function of the chip, since it is difficult to construct test cases for abnormal function scenarios, during the test process, it is necessary to use the method of directed testing to separately test the test cases of the constructed abnormal code. As a result, the verification environment cannot verify whether the chip can continue to execute normal code after processing the abnormal code, and thus the verification of the CPU is not complete.

[0046] As an example, the CPU is called the central processing unit, abbreviated as the processor. The CPU architecture is divided into two types: the instruction set architecture and the microarchitecture; the instruction set is a set of instructions, and an instruction refers to the smallest unit for the processor to perform operations. With the instruction set architecture, different processor hardware implementation schemes can be used to design processors with different performances. The CPU architectures include Intel x86, ARM, MIPS, SPARC, Power, and RISC-V, etc., and specific details are not limited. For the convenience of description, the following specifically takes the CPU architecture of RISC-V as an example for illustration.

[0047] As an example, the verification of the CPU abnormal function is to verify whether the CPU processes instructions normally.

[0048] As an example, a test case is a description of the test task for the CPU, reflecting the test plan, methods, techniques, and strategies.

[0049] As an example, as Figure 2 shown, generally, in the CPU verification process of the RISC-V architecture, the test case will first be converted into an ELF file (executable file in Executable and Linkable Format) required by the simulation model. The simulation model will send the predicted results to the UVM Scoreboard (scoreboard), and at the same time, a binary file stored in the CPU MEM Model (maximum entropy Markov model) will be generated. The CPU will execute the instructions and send the results to the UVM Scoreboard.

[0050] Among them, UVM is the Universal Verification Methodology, which is a verification platform development framework mainly based on the SystemVerilog class library. Verification engineers can use its reusable components to build a functional verification environment with a standardized hierarchical structure and interfaces.

[0051] In this embodiment, the specific steps of the CPU exception function verification method for fault injection are as follows:

[0052] Step S10: Convert the test case into a target assembly file through compiler processing. The target assembly file includes at least the first assembly code;

[0053] As an example, the compilation process is to convert a high-level language into assembly language and then into machine language. The assembly process is to translate assembly language into machine language.

[0054] As an example, converting the test case into a target assembly file means compiling the test case through a compiler, and the disassembly file of the test case obtained is the target assembly file. The target assembly file includes the first assembly code and the test case code, etc. This first assembly code is the instruction.

[0055] As an example, the tool for compiling the test case can be a RISC-V compilation tool, an ARM compilation tool, etc., and specific limitations are not made.

[0056] For the convenience of description, this embodiment takes the CPU architecture as RISC-V for specific illustration. Therefore, this embodiment also takes the RISC-V compilation tool and the RISC-V instructions obtained by assembly as examples for specific illustration.

[0057] As an example, the test cases are assembled through the RISC-V compilation tool to generate a target assembly file, which includes the first assembly code and the test case code. The first assembly code is the RISC-V instruction, and the target assembly file is a merged file in which the RISC-V instructions and the test case code are in one-to-one correspondence. In the previous verification methods, the target assembly file is only a log file for assisting verification engineers to eliminate vulnerabilities. If the simulation result is normal, verification engineers will not actively view it, but in this embodiment, the target assembly file will be actively analyzed.

[0058] Step S20: Determine the target exception code to be inserted into the first assembly code and its insertion address;

[0059] As an example, the target exception code is the exception code to be inserted into the first assembly code, that is, the target exception code, which is determined by analyzing the target assembly file.

[0060] As an example, the target exception code is the target exception instruction, and the normal code is the normal instruction.

[0061] In this embodiment, after generating the target assembly file, analyze the target assembly file to determine the target exception code in the first assembly code to be inserted into the target assembly file, and the insertion position for inserting the target exception code.

[0062] As an example, analyze the target assembly file, that is, analyze the RISC-V instructions and the corresponding test case code, and select possible common faults or special faults, etc. in the target assembly file, which are not specifically limited; that is, determine the target exception code corresponding to the scenario fault or special fault, etc., and the insertion position for inserting the target exception code.

[0063] In this embodiment, the step of determining the target exception code to be inserted into the first assembly code and its insertion address includes:

[0064] Step A1: Judge the matching degree between the file line characters in the target assembly file and each exception scenario character in the preset configuration parameters;

[0065] As an example, the method of determining the target exception code to be inserted into the first assembly code in the target assembly file and the insertion position for inserting the target exception code can be to judge the matching degree between the file line characters in the target assembly file and each exception scenario character in the preset configuration parameters, or randomly select a target exception code from each exception scenario, etc., which are not specifically limited.

[0066] As an example, the preset configuration parameters in the verification environment include exception codes corresponding to various exception scenarios, that is, target exception codes.

[0067] As an example, there is more than one file line in the target assembly file. Therefore, it is necessary to compare the characters of each file line with the characters of each exception scenario one by one.

[0068] In this embodiment, by comparing the characters of the file lines in the target assembly file with the characters of the exception codes corresponding to the various exception scenarios, multiple degrees of matching are obtained.

[0069] Step A2: Use the character of the exception scenario with the highest degree of matching as the target exception code, and use the address of the file line character corresponding to the character of the exception scenario with the highest degree of matching in the target assembly file as the insertion address.

[0070] As an example, use the character of the exception scenario with the highest degree of matching among the multiple degrees of matching as the target exception code. At the same time, use the address of the file line character corresponding to the character of the exception scenario with the highest degree of matching in the target assembly file as the insertion address.

[0071] As an example, the insertion address is the exception address. For example, according to the above steps, 40100c1c in the first assembly code is determined as the insertion address.

[0072] In this embodiment, the step of determining the degree of matching between the characters of the file lines in the target assembly file and the characters of each exception scenario in the preset configuration parameters includes:

[0073] Step B1: Identify all the characters of the instruction address, machine code, and assembly instruction in the target assembly file;

[0074] As an example, the method of comparing the characters of each file line with the characters of each exception scenario one by one as described above can be to compare each character of the instruction address, machine code, and assembly instruction in the target assembly file with each exception scenario in turn; or only compare each character of the assembly instruction in the target assembly file; or compare multiple preset strings in the target assembly file, etc., which is not specifically limited.

[0075] As an example, the purpose of identifying all the characters of the instruction address, machine code, and assembly instruction in the target assembly file can be to screen out important characters through identification to simplify the comparison process, or it is just the character extraction process before comparison.

[0076] Step B2: Match all the characters with the abnormal scenario characters in the preset configuration parameters from the start character to the end character to obtain the matching degrees of all the characters with each abnormal scenario character.

[0077] As an example, match all the recognized characters with the abnormal scenario characters from the start character to the end character to obtain the matching degrees of each file line character with each abnormal scenario character, and then the abnormal scenario character with the highest matching degree can be used as the target abnormal code.

[0078] Step S30: Modify the original exception handler and the original jump code so that after the simulation model and the CPU under test execute the target abnormal code, they can process the target abnormal code based on the modified original exception handler and the original jump code and execute the next line of code;

[0079] As an example, generally, there is an original exception handler and an original jump code in the CPU; among them, the original exception handler is used to process general or common target abnormal codes, but it may not be able to process the target abnormal code to be inserted. Therefore, it is necessary to modify the original exception handler so that it can process the inserted target abnormal code.

[0080] Among them, the original jump code is used to jump to the next line of code to be processed according to the original jump code after processing the current code. If the current code is the inserted target abnormal code, after processing the target abnormal code, it is also necessary to process other codes after the target abnormal code. Therefore, it is necessary to modify the original jump code so that after the target abnormal code is executed, other codes can be processed normally.

[0081] As an example, based on the modified original exception handler, the simulation model and the CPU under test can smoothly process the target abnormal code when executing the target abnormal code; based on the modified original jump code above, the simulation model and the CPU under test can smoothly execute the next line of code after executing the target abnormal code.

[0082] As an example, based on the modified original exception handler and the original jump code above, when the simulation model and the CPU under test execute the target abnormal code, they can smoothly process the inserted target abnormal code. After the processing is completed, they can smoothly jump to the original normal code described by the 40400c1c address and execute normally in the original code order.

[0083] In this embodiment, after the step of determining the target abnormal code to be inserted into the first assembly code and its insertion address, the method further includes:

[0084] Step C1: Record the PC value of the insertion address through an exception handling register;

[0085] As an example, the PC value is the address of the code to be executed currently, that is, when the CPU under test finishes executing the current code, it is the address of the next line of code to be executed.

[0086] In this embodiment, after determining the target exception code to be inserted into the first assembly code and its insertion address, the PC value of the insertion address will be recorded through an exception handling register.

[0087] Step C2: When the target exception code is triggered, monitor whether the PC value of the insertion address recorded by the exception handling register is the same as the address where the current target exception code is executed;

[0088] As an example, as Figure 3 shown, when the simulation model and the CPU under test are about to trigger the target exception code, the exception monitoring component monitors whether the PC value of the insertion address recorded by the exception handling register is the same as the address where the current target exception code is executed.

[0089] As an example, as Figure 3 shown, the exception handling register can be MCAUSE, MEPC, MTVAL, MSTATUS, etc., and there is no specific limitation. The exception handling register records the information of this exception, that is, the information of the exception includes the characters of the target exception instruction and the address where the target exception instruction is located, etc.

[0090] Step D3: If they are the same, execute the steps of modifying the original exception handling program and the original jump code.

[0091] As an example, if they are the same, execute the steps of modifying the original exception handling program and the original jump code in the first embodiment. If they are not the same, it is necessary to terminate this verification and report an error for the operator to debug this error.

[0092] In this embodiment, the steps of modifying the original exception handling program and the original jump code include:

[0093] Step D1: Modify the original exception handling program according to the target exception code;

[0094] In this embodiment, the original exception handling program is modified based on the target exception code so that the modified exception handling program can execute the target exception code normally.

[0095] Step D2: Modify the PC value of each address after the insertion address in the original jump code to the PC value plus the number of preset addresses.

[0096] In this embodiment, the address of the currently to-be-executed instruction at each address after the insertion address in the original jump code is incremented by a preset number of addresses, and the address of the currently to-be-executed instruction at each address after the insertion address is updated.

[0097] As an example, the preset number of addresses is determined according to the number of addresses between instructions in assembly language.

[0098] As an example, the address where the normal code is located is 40100c1c. After inserting the target exception code at the address 40100c1c, the address where the target exception code is located is 40100c1c. If it is desired to continue executing the original normal code after executing the target exception code, the original jump code program can be modified to add the preset number of addresses to the PC value. For example, in assembly language, if the address interval between each line of code is 4, then the PC values of the addresses where the target exception code is located and the normal code after it are modified to PC + 4, PC + 8, PC + 12... Then, the address where the original normal code at 40100c1c is located is modified to addresses 40100c20, 40100c24, 40100c28... After executing the target exception code, it is possible to directly jump to 40100c20 to execute the original normal code.

[0099] Step S40: Insert the target exception code at the insertion address in the first assembly code to obtain a second assembly code;

[0100] In this embodiment, the target exception code and the insertion address have been determined, and the original exception handler and the original jump code have been modified. Then, by inserting the target exception code at the insertion address in the first assembly code, the second assembly code can be obtained, and the fault injection operation is completed.

[0101] As an example, if an exception code is inserted at the address 40100c1c in the first assembly code, that is, the original normal instruction described by the address 40400c1c is copied, and the instruction described by the address 40400c1c is modified to the target exception code. Therefore, there are two lines of code in the first assembly code with the same address 40400c1c but different instructions.

[0102] Step S50: Process the second assembly code by an assembler to convert it into a binary file for the simulation model and the CPU under test to execute the binary file;

[0103] In this embodiment, since the simulation model and the CPU under test can only process machine language, it is necessary to process the second assembly code by an assembler to convert it into a binary file.

[0104] As an example, the binary file includes an ELF file (executable code) for the simulation model to execute and binary code for the CPU under test to execute.

[0105] As an example, the second assembly code contains target exception code and normal code, that is, the second assembly code includes normal code and target exception code.

[0106] As an example, the next line of code is target exception code or normal code, that is, the next line of code is the next instruction, and the next instruction is an exception instruction or a normal instruction.

[0107] Step S60: Compare the execution results of the simulation model and the CPU under test, and verify whether the functions of the CPU under test are normal according to the comparison results.

[0108] In this embodiment, the execution result of the simulation model is a control group of the execution result of the CPU under test.

[0109] As an example, as Figure 3 shown, the simulation model and the CPU under test in the verification environment are both started separately, execute the second assembly code in binary format, and send the results to the UVM Scoreboard. By comparing the execution results of the two in the UVM Scoreboard, it is possible to determine what defects exist in the functions of the CPU under test, or what advantages there are, etc.

[0110] In this embodiment, the second assembly code includes normal code. The step of comparing the execution results of the simulation model and the CPU under test and verifying whether the functions of the CPU under test are normal includes:

[0111] Step E1: Respectively execute the second assembly code through the simulation model and the CPU under test to obtain a first abnormal execution result, a first normal execution result, a second abnormal execution result, and a second normal execution result;

[0112] In this embodiment, the simulation model and the CPU under test respectively execute the second assembly code. The second assembly code includes normal code and target exception code. The simulation model obtains a first abnormal execution result and a first normal execution result by executing the target exception code and normal code in the binary file; the CPU under test obtains a second abnormal execution result and a second normal execution result by executing the target exception code and normal code in the binary file.

[0113] Step E2: Based on the comparison of the first normal execution result and the second normal execution result, as well as the comparison of the first abnormal execution result and the second abnormal execution result, verify whether the function of the CPU under test is normal.

[0114] In this embodiment, as Figure 3 shown, after the normal code is executed, the first normal execution result and the second normal execution result are sent to the UVM Scoreboard for comparison to obtain the processing performance of the CPU under test for the normal code; after the target abnormal code is executed, the first abnormal execution result and the second abnormal execution result are sent to the UVM Scoreboard for comparison to obtain the processing performance of the CPU under test for the abnormal code; if the execution results obtained by the CPU under test and the simulation model for the same code are quite different or inconsistent, it is determined that there is a defect in the function of the CPU under test, and the address of the code corresponding to this defect is recorded.

[0115] In this embodiment, as Figure 3 shown, by converting the test case into a target assembly file through compiler processing, the target assembly file at least includes the first assembly code; target abnormal code is inserted into the first assembly code. When selecting the inserted target abnormal code, the most matching abnormal scenario is selected by comparing various abnormal scenarios with the original normal code, which can simulate a more realistic abnormal environment, and the original abnormal handler and the original jump code are modified so that they can handle the inserted target abnormal code and can continue to execute the next line of code in the original code order after processing the target abnormal code, that is, the target abnormal code can be executed without affecting the execution of the original code. The second assembly code after inserting the target abnormal code is converted into a binary format through assembler processing for the simulation model and the CPU under test to execute the binary file, and finally the execution results of the simulation model and the CPU under test are compared. According to the comparison results, it is verified whether the function of the CPU under test is normal, and thus the verification of the CPU under test can be completed. During the verification process, there is no need to separately construct abnormal code or separately test each abnormal code one by one. After the abnormal event is triggered and the abnormal handling is executed, the normal function test of the original test case is not affected, and it can also be verified whether the CPU under test can continue to execute the original normal code normally after executing the target abnormal code. Moreover, when the target abnormal code is triggered, the recording of the abnormal information is monitored. If an error occurs, the verification program is exited. The verification stage covers all aspects of normal instruction processing, abnormal instruction processing, and abnormal exit from the program, improving the verification completeness of the CPU processor.

[0116] Further, based on the first embodiment of the present application, a second embodiment of the present application is provided. In this embodiment, the steps of verifying the CPU exception function of the fault injection include:

[0117] In this embodiment, before the step of determining the target exception code to be inserted into the first assembly code and its insertion address, the method further includes:

[0118] Step F1: Select whether to insert the target exception code into the first assembly code according to the probability generated by calling a random function;

[0119] In the normal working scenario of the CPU in this embodiment, the exception function is randomly triggered. Therefore, in order to better simulate the randomness of the occurrence probability of the exception code in reality, in the verification environment, according to the probability generated by calling a random function, randomly select whether to insert the target exception code into the first assembly code. If the randomly generated probability is higher than the preset probability value, it is determined to select to insert the target exception code; otherwise, it is not inserted.

[0120] Step F2: If the selection is to insert, then execute the step of determining the target exception code to be inserted into the first assembly code and its insertion address.

[0121] As an example, if the selection is to insert the exception code, then continue to execute the step of determining the target exception code to be inserted into the first assembly code and its insertion address.

[0122] As an example, if the selection is not to insert the exception code, then return to the normal verification process, start the verification simulation process, and perform verification comparison.

[0123] In this embodiment, by randomly selecting whether to insert the target exception code into the first assembly code according to the probability generated by calling a random function in the verification environment, the random triggering of the exception function in the normal working scenario of the CPU is simulated, making the verification result more authentic.

[0124] It should be noted that in this article, the term "comprising", "including" or any other variant thereof is intended to cover a non-exclusive inclusion, so that a process, method, article or system including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or system. Without further limitations, the element defined by the statement "including an..." does not exclude the existence of additional identical elements in the process, method, article or system including the element.

[0125] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages and disadvantages of the embodiments.

[0126] The above are only the preferred embodiments of the present invention, and do not limit the patent scope of the present invention accordingly. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present invention, or directly or indirectly applied in other related technical fields, shall similarly be included within the patent protection scope of the present invention.

Claims

1. A method for verifying the CPU exception function of fault injection, characterized in that The verification of the CPU exception function for fault injection includes the following steps: Convert the test case into a target assembly file through compiler processing. The target assembly file includes at least the first assembly code; Determine the target exception code to be inserted into the first assembly code and its insertion address; Modify the original exception handler and the original jump code so that after the simulation model and the CPU under test execute the target exception code, they can process the target exception code based on the modified original exception handler and the original jump code, and execute the next line of code; Insert the target exception code at the insertion address in the first assembly code to obtain the second assembly code; Convert the second assembly code into a binary file through assembler processing for the simulation model and the CPU under test to execute the binary file; Compare the execution results of the simulation model and the CPU under test, and verify whether the function of the CPU under test is normal according to the comparison result.

2. The CPU abnormal function verification method for fault injection according to claim 1, wherein the target assembly file includes a target assembly file, characterized in that The step of determining the target exception code to be inserted into the first assembly code and its insertion address includes: Judge the matching degree between the file line characters in the target assembly file and each exception scenario character in the preset configuration parameters; Use the exception scenario character with the highest matching degree as the target exception code, and use the address of the file line character corresponding to the exception scenario character with the highest matching degree in the target assembly file as the insertion address.

3. The method for verifying the CPU abnormal function of fault injection according to claim 2, wherein The step of judging the matching degree between the file line characters in the target assembly file and each exception scenario character in the preset configuration parameters includes: Identify the instruction address, machine code, and all characters of the assembly instruction in the target assembly file; Match the all characters with the exception scenario characters in the preset configuration parameters in sequence from the starting character to the ending character to obtain the matching degree between the all characters and each exception scenario character.

4. The method for verifying the CPU exception function of fault injection according to claim 1, wherein After the step of determining the target exception code to be inserted into the first assembly code and its insertion address, the method further includes: Record the PC value of the insertion address through the exception handling register; When the target exception code is triggered, monitor whether the PC value of the insertion address recorded in the exception handling register is consistent with the address where the currently executed target exception code is located; If they are consistent, execute the step of modifying the original exception handler and the original jump code.

5. The method for verifying the CPU abnormal function of fault injection according to claim 4, wherein, The step of modifying the original exception handler and the original jump code includes: Modify the original exception handler correspondingly according to the target exception code; Modify the PC value of each address after the insertion address and the following addresses in the original jump code to the PC value plus the preset number of addresses.

6. The method for verifying the CPU exception function of fault injection according to claim 1, wherein Before the step of determining the target exception code to be inserted into the first assembly code and its insertion address, the method further includes: Select whether to insert the target exception code into the first assembly code according to the probability generated by calling a random function; If it is selected to insert, execute the step of determining the target exception code to be inserted into the first assembly code and its insertion address.

7. The method for verifying the CPU abnormal function of fault injection according to claim 1, wherein the second assembly code includes normal code, characterized in that The step of comparing the simulation model and the execution result of the CPU under test, and verifying whether the function of the CPU under test is normal according to the comparison result includes: Executing the binary file through the simulation model and the CPU under test respectively to obtain a first abnormal execution result, a first normal execution result, a second abnormal execution result, and a second normal execution result; Based on the comparison between the first normal execution result and the second normal execution result, and the comparison between the first abnormal execution result and the second abnormal execution result, verify whether the function of the CPU under test is normal.

Images