MCU kernel function verification method
By writing and executing test cases, verifying the instruction execution results of the MCU core, solving the problems of inefficient and limited accuracy of MCU core function verification in the prior art, and achieving efficient and accurate MCU core function verification.
Patent Information
- Application Number
- CN202311038736.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-08-16
- Publication Date
- 2025-02-21
Smart Images
Figure CN119494297A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of chip verification technology, and in particular to a method for verifying the core function of an MCU. Background Art
[0002] As digital chip design becomes increasingly complex, verification becomes a key step in the digital chip design process. Before a design is synthesized, the logic function must be verified to ensure the functional correctness of the module or chip.
[0003] MCU is a typical digital chip. The newly developed MCU core is usually based on the legacy instruction set system of the existing MCU core, with some new instruction sets added. When performing logical function verification, it is necessary to verify that the instructions of the legacy instruction set system are not affected by the structure of the newly added instructions. The current verification method is usually to manually write an assembly program, write the execution statement of each instruction, manually calculate the result after the instruction is executed and write the judgment condition based on the calculation result, use the Verilog module of the MCU core to run the assembly program, and determine the correctness of the program execution based on the judgment condition. This verification method is inefficient, and the accuracy of the verification is greatly affected by human factors. Summary of the invention
[0004] In view of this, it is necessary to provide a more efficient and accurate MCU core function verification method to quickly verify the legacy instruction set in the newly developed MCU core and accelerate the convergence of core verification.
[0005] The present invention provides an MCU core function verification method, which is used to verify the instruction execution result of a second MCU core according to a first MCU core, wherein the first MCU core is a mass-produced MCU core, and the second MCU core is an MCU core to be tested, and the instruction sets of the two are similar, and the number of instruction pipelines is consistent. The verification method comprises the following steps:
[0006] S1, obtaining the Verilog code files of the first MCU core function module, the second MCU core function module, and the Prom function module;
[0007] S2, writing test cases according to the instruction sets of the first MCU core and the second MCU core, and converting the test cases into hexadecimal codes and storing them in the Prom module;
[0008] S3, using System Verilog language to build a test check module, obtain the instruction code output by the Prom module and the values of the internal registers of the first MCU core module and the second MCU core module, and compare the test results according to the instruction code;
[0009] S4, construct the top-level module, instantiate the first MCU kernel module, the second MCU kernel module, the Prom module, and the test and inspection module;
[0010] S5, compile all module source codes, generate simulation executable files, start simulation, the Prom module reads the hexadecimal test case codes stored in its storage area in sequence at a preset time, the top module processes the hexadecimal codes, and the first MCU kernel module and the second MCU kernel module read, decode and execute instructions respectively;
[0011] S6, during the test case execution process, the test check module checks the values of instruction-related registers and program counters in the first MCU kernel module and the second MCU kernel module, and outputs the test results after comparison.
[0012] The MCU kernel function verification method of the present invention writes a test case for each instruction in the legacy instruction set list of the MCU kernel to be tested, compiles the test case to generate a hexadecimal code, and stores it in the Prom module. The Prom module reads the hexadecimal instructions in sequence at a preset time, and transmits them to the mass-produced MCU kernel module and the MCU kernel module to be tested. The two kernel modules read, decode, and execute the instructions respectively, and execute the test case in this way. During the execution of the test case, the test inspection module determines whether the decoding and execution results of the MCU kernel to be tested are correct based on the values of the registers of the mass-produced MCU kernel module and the value of the program counter. The test case can be executed individually or in a plurality of consecutive executions, and a single or multiple test cases can also be randomly selected. During the execution of the test case, the test results are output in real time. Therefore, the MCU kernel verification method of the present invention is implemented, and the legacy instruction set in the newly developed MCU kernel can be efficiently and accurately verified, and the convergence of kernel verification is accelerated. BRIEF DESCRIPTION OF THE DRAWINGS
[0013] The drawings described herein are used to provide further understanding of the present invention and constitute a part of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.
[0014] Figure 1 A schematic diagram of the steps of a method for verifying the function of an MCU core provided by an embodiment of the method for verifying the function of an MCU core of the present invention.
[0015] Figure 2 A schematic diagram of the module composition of an MCU kernel function verification method provided in an embodiment of the present invention.
[0016] Figure 3A schematic diagram of the top-level module instantiating each sub-module provided in an embodiment of an MCU core function verification method of the present invention.
[0017] Figure 4 A BCF instruction simulation test waveform diagram provided for an embodiment of an MCU core function verification method of the present invention. DETAILED DESCRIPTION
[0018] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0019] The present invention provides an MCU kernel function verification method, which is used to verify the instruction execution result of a second MCU kernel according to a first MCU kernel, wherein the first MCU kernel is a mass-produced MCU kernel, and the second MCU kernel is an MCU kernel to be tested, and the instruction sets of the two are similar, and the number of instruction pipelines is the same, and the method comprises the following steps:
[0020] S1, obtain the Verilog code files of the first MCU core function module, the second MCU core function module, and the Prom function module.
[0021] The first MCU core functional module, the second MCU core functional module, and the Prom functional module are all RTL-level hardware descriptions provided by front-end designers, wherein the Prom functional module is used to output data according to a clock signal.
[0022] S2, writing test cases according to the instruction sets of the first MCU core and the second MCU core, and converting the test cases into hexadecimal codes and storing them in the Prom module.
[0023] Test cases are written for instructions in the legacy instruction set, and the hexadecimal codes are stored in the internal array of the Prom module.
[0024] S3, using System Verilog language to build a test check module, obtain the instruction code output by the Prom module and the values of the internal registers of the first MCU core module and the second MCU core module, and compare the test results according to the instruction code.
[0025] The internal registers generally include registers where operands in the test case are located, registers for storing calculation results, status registers, etc.
[0026] S4, build the top-level module, instantiate the first MCU kernel module, the second MCU kernel module, the Prom module, and the test and inspection module.
[0027] For simplicity, the top-level module can provide the clock signal and reset signal required for testing each module.
[0028] S5, compile all module source codes, generate simulation executable files, start simulation, the Prom module reads the hexadecimal test case codes stored in its storage area in sequence at the preset time, the top-level module processes the hexadecimal code, and the first MCU kernel module and the second MCU kernel module read, decode and execute instructions respectively.
[0029] S6, during the test case execution process, the test check module checks the values of instruction-related registers and program counters in the first MCU kernel module and the second MCU kernel module, and outputs the test results after comparison.
[0030] In step S2, the specific steps of writing test cases and storing the test cases in the Prom module are as follows:
[0031] S21, selecting from the instruction set of the second MCU core the parts that overlap with or are similar to the instruction set of the first MCU core, to form a legacy instruction set list.
[0032] S22, writing an assembly language test case for the second MCU core for each instruction in the legacy instruction set list of the second MCU core.
[0033] S23, convert the written test case into hexadecimal code.
[0034] S24, storing the converted hexadecimal code in the data storage area of the Prom.
[0035] The step S23 comprises the following steps:
[0036] S231, use the mpasmx compiler to compile the .asm file corresponding to the test case and generate a hexadecimal .hex file.
[0037] S232, use the script to extract the address and data parts from the .hex file.
[0038] S233, write the address and data separated in step S232 into the .in file one by one, in the format of "@address hexadecimal instruction", with each line corresponding to one instruction.
[0039] Because the first MCU core and the second MCU core may have different PRM bit widths, instruction encodings, register addresses, etc., after step S4, the following steps are also included:
[0040] S41, in the top-level module, the hexadecimal instruction data of the second MCU core read by the Prom module is processed for compatibility with the first MCU core, and the processed data is passed to the first MCU core through the PROM input port, wherein the compatibility processing specifically includes:
[0041] S411, for the instructions in the legacy instruction set list, the hexadecimal instructions read by the Prom module are processed for compatibility with the first MCU core, including: PROM bit width compatibility, instruction decoding compatibility, and register address compatibility in the instruction.
[0042] S412: For instructions similar to the first MCU core, replace similar instructions.
[0043] During the test case execution, after the top-level module performs compatibility processing on the hexadecimal instruction data read by the Prom module, the first MCU core and the second MCU core read the instruction again in the next clock cycle. This setting is to allow the first MCU core and the second MCU core to obtain the correct instruction at the same time.
[0044] In step S6, the method in which the test and inspection module performs register inspection is as follows:
[0045] S61, determining whether the current status registers of the first MCU core and the second MCU core are consistent with the register values involved in the calculation during the decoding stage, and outputting error information if they are inconsistent.
[0046] S62, in the execution phase, determining whether the status registers of the first MCU core and the second MCU core and the register values written back by the calculation results are consistent after the instruction is executed, and outputting an error message if they are inconsistent.
[0047] In step S6, the test and check module performs a consistency check on the program counters of the first MCU core and the second MCU core in each clock cycle.
[0048] In step S5, the execution of the test case supports the following modes:
[0049] (1) Execute a single test case at a time.
[0050] (2) Multiple test cases are executed consecutively.
[0051] (3) Randomly execute single or multiple test cases.
[0052] The specific implementation method of the above mode is to modify the input of the Prom module to meet different test requirements. When the Prom module stores only the code corresponding to one test case, a single test case is executed. When the Prom module stores the code corresponding to multiple test cases, multiple test cases are executed. When the test cases stored in the Prom module are randomly selected single or multiple test cases, a single or multiple test cases are executed.
[0053] like Figure 1 FIG. 1 is a schematic diagram of the steps of the MCU core function verification method according to an embodiment of the present invention.
[0054] like Figure 2 , which is a schematic diagram of the module composition of the MCU core function verification method according to an embodiment of the present invention.
[0055] The technical solution of the present invention is described in detail below with a specific example.
[0056] FMD 6014 represents the first MCU core, which is the mass-produced MCU core. FDM 6017 represents the second MCU core, which is the MCU core under development. The instruction sets of FMD 6014 and FMD 6017 are similar, and both contain three-level pipelines: instruction fetch, instruction translation, and execution. FMD 6014 supports 49 instructions, and FMD 6017 supports 75 instructions. The PROM bit width of FMD 6014 is 14 bits, and the PROM bit width of FMD 6017 is 16 bits. The hexadecimal representation of the same instruction of FMD 6014 and FMD 6017 is different, and the register settings are also slightly different.
[0057] The simulation environment of this embodiment is a Linux computer, and the simulation software used is VCS of Synopsys.
[0058] The method for functional verification of FMD 6017 using FMD 6014 is as follows:
[0059] S1, obtain the Verilog code files of the FMD 6014 core function module, the FMD 6017 core function module, and the Prom function module.
[0060] The FMD 6014 core function module and the FMD 6017 core function module are RTL-level hardware descriptions of the core logic functions of FMD 6014 and FMD 6017 respectively, and the Prom function module is an RTL-level hardware description of Prom, which is used to output data according to a clock signal.
[0061] The Verilog code files of FMD 6014, FMD 6017 and Prom are provided by the front-end designers, and the size of Prom is 16K.
[0062] S2, write test cases according to the instruction sets of the FMD 6014 core and the FMD 6017 core, and convert the test cases into hexadecimal codes and store them in the Prom module. The specific steps are as follows:
[0063] S21, select some instructions that overlap or are similar to the instruction set of the FMD 6014 core from the instruction set of the FMD 6017 core to form a legacy instruction set list. Among the instructions of the FMD 6017 core, there are 42 instructions that overlap or are similar to those of the FMD 6014 core, and these 42 instructions form the legacy instruction set list of the FMD 6017 core.
[0064] S22, write assembly language test cases for the FMD 6017 core for each instruction in the legacy instruction set list of the FMD 6017 core;
[0065] The test cases are written in assembly language in the Linux desktop environment, saved as .asm files, and compiled using the mpasmx compiler.
[0066] Taking the bit operation instruction BCF as an example, the instruction BCF f,b,a means to clear the bth bit in the f register to 0, and the result is stored in the specified area according to the value of a. The assembly language test case written for the BCF instruction is as follows, which means: assign the FSR0L register to 0xFF, then clear the data of the 0th bit to 0, and judge whether the value of FSR0L becomes 0xFE, where FSR0L is the low byte register of the indirect data storage address pointer 0 of the FMD6017 internal. In order to facilitate the inspection of the execution results of the two MCU instructions, the FSR0L register is fixedly used in the test case to save the instruction execution results.
[0067] MOVLW H'FF'
[0068] MOVWF FSR0L,0
[0069] BCF FSR0L,0,0
[0070] MOVLW H'FE'
[0071] CPFSEQ FSR0L,0
[0072] GOTO$
[0073] S23, converting the written test case into hexadecimal code;
[0074] The specific steps are as follows:
[0075] S231, use the mpasmx compiler to compile the .asm file corresponding to the test case and generate a hexadecimal .hex file;
[0076] S232, use the script to extract the address and data parts from the .hex file;
[0077] S233, write the address and data separated in step S232 into the .in file one by one, in the format of "@address hexadecimal instruction", with each line corresponding to one instruction.
[0078] The contents of the .in file generated by compiling the above BCF test case are as follows:
[0079] @0021 4EFF
[0080] @0022AE50
[0081] @0023D050
[0082] @0024 4EFE
[0083] @0025A250
[0084] @0026 2F04
[0085] @0027F000
[0086] Each line consists of two parts, separated by a space. The part before the space is the address part, and the part after the space is the data part. The data part is the hexadecimal instruction corresponding to the test case.
[0087] S24, storing the converted hexadecimal code in the data storage area of the Prom.
[0088] Specifically, the content of the .in file generated in step S233 is copied to the Prom internal array through the Verilog system function $readmemh(). When copying, the hexadecimal instructions in each line of the .in file are copied to the offset address corresponding to the @ symbol in the line in the Prom internal array.
[0089] S3, using System Verilog language to build a test check module, obtain the instruction code output by the Prom module and the value of the internal register of the FMD 6014 core module and the FMD 6017 core module, and compare the test results according to the instruction code;
[0090] The registers accessed in the test and inspection module are mainly the following:
[0091] WREG register: The WREG register is a register inside the MCU that stores immediate values. The calculation of some instructions requires reading or writing to the WREG register.
[0092] STATUS register: It is a register inside the MCU that indicates the status of the calculation result, indicating the positive or negative, overflow, all zero, half borrow / borrow, carry / borrow of the current calculation result.
[0093] FSR0L register: The FSR0L register is the low byte of the indirect data memory address pointer 0 and is used to store instruction calculation results when verifying the MCU.
[0094] The workflow of the test inspection module is as follows:
[0095] (1) Pull out the internal signal pc_addr representing the pc value from the FMD 6014 core module and the FMD 6017 core module, and compare the values of the pc_addr of the two core modules at the rising edge of each clock cycle to determine whether the two are equal.
[0096] (2) For each instruction in the legacy instruction set list of the FMD 6017 core, the following checks are performed in three clock cycles according to the three-stage pipeline:
[0097] In the first clock cycle, the instruction content is obtained from prom_rdat.
[0098] The second clock cycle checks whether the instruction decoding is correct. The specific method is to determine whether the FMD 6014 core and the FMD 6017 core have the same interpretation of the opcode and operand based on the instruction content and the corresponding registers.
[0099] The third clock cycle checks whether the instruction is executed correctly. The specific method is to combine the instruction content and the corresponding register to determine whether the instruction execution results of the FMD 6014 core and the FMD 6017 core are consistent.
[0100] S4, build the top-level module, instantiate the FMD 6014 kernel module, FMD 6017 kernel module, Prom module, and test and inspection module;
[0101] Referencing another module in one module and making relevant connections to its ports is called module instantiation. Figure 3The figure shows the schematic diagram of the top-level module instantiating each sub-module, where tb_rsim is the top-level module, Dig_top is the FMD 6017 core function module, Fmd_core is the FMD 6014 core function module, Prom16k_time is the Prom module, and core_mon is the test and inspection module. The output of the Prom16k_time module is prom_rdat, which is connected to the PROM input port of Dig_top. Prom_rdat is also connected to the Prom_rdata process module. After the Prom_rdata process module processes prom_rdat, it outputs prom_rdat_porting to the PROM input port of Fmd_core. The Prom_rdata process module can be set as an independent module or directly used as part of the top-level module.
[0102] The clock and reset signals required for simulation are provided by the top-level module. A simple example of instantiating each module in the top-level module is as follows:
[0103] (1) The method of instantiating Prom is briefly expressed as follows, where clk and rst are the input ports of the Prom module, which are respectively connected to the clock signal top.clk and the reset signal top.rst provided by the top-level module; Prom_rdat is the output port of Prom, which is connected to the prom_rdat variable inside the top-level module.
[0104] Prom16k_time u_prom16k_time(
[0105] clk(top.clk),
[0106] rst(top.rst),
[0107] Prom_rdat(prom_rdat));
[0108] (2) The method of instantiating FMD 6014 is briefly expressed as follows, where clk and rst are the input ports of the FMD 6014 module, which are respectively connected to the clock signal top.clk and the reset signal top.rst provided by the top-level module; Prom_rdat is the PROM input port of the FMD 6014 module, which is connected to the prom_rdat_porting variable inside the top-level module.
[0109] Fmd_core fmd_core_6014(
[0110] clk(top.clk),
[0111] rst(top.rst),
[0112] Prom_rdat(prom_rdat_porting));
[0113] (3) The method of instantiating FMD 6017 is briefly expressed as follows, where clk and rst are the input ports of the FMD 6017 module, which are respectively connected to the clock signal top.clk and the reset signal top.rst provided by the top-level module; Prom_rdat is the PROM input port of the FMD 6017 module, which is connected to the prom_rdat variable inside the top-level module.
[0114] Dig_top u_dig_top(
[0115] clk(top.clk),
[0116] rst(top.rst),
[0117] Prom_rdat(prom_rdat));
[0118] (4) The method of instantiating the test and check module is briefly expressed as follows, where clk and rst are the input ports of the test and check module, which are respectively connected to the clock signal top.clk and the reset signal top.rst provided by the top-level module.
[0119] core_mon core_mon(
[0120] clk(top.clk),
[0121] rst(top.rst));
[0122] Because the PROM bit width, instruction decoding, register address setting, etc. of FMD 6017 and FMD 6014 are different, the following steps need to be added after step S4:
[0123] S41, in the top-level module, the hexadecimal instruction data read by the Prom module is processed for compatibility with the FMD 6014 core, and the processed data is passed to the FMD 6014 core through the PROM input port. The compatibility processing specifically includes:
[0124] S411, for the instructions in the legacy instruction set list, the hexadecimal instructions read by the Prom module are processed for compatibility with the FMD 6014 core, including: PROM bit width compatibility, instruction decoding compatibility, and register address compatibility in the instructions.
[0125] For example, for the instruction BCF FSR0L,1,0, the value read from prom_rdat is 0xd250, the hexadecimal value corresponding to BCF is 0xd in prom_rdat[15:12], the hexadecimal value corresponding to FSR0L is 0x50 in prom_rdat[7:0], the hexadecimal value corresponding to b is 0x1 in prom_rdat[11:9], and the hexadecimal value corresponding to a is 0x0 in prom_rdat[8], which means that the calculated result is written back to the original register. The meaning of this instruction is to clear bit 1 of the FSR0L0x50 register to 0, and store the result in the original register FSR0L 0x50.
[0126] For FMD 6014, the PROM interface is [13:0], a total of 14 bits, and the hexadecimal value corresponding to the instruction BCF is 0x8. The calculation result of the FMD 6014 instruction is stored in the register FSR0L, the address is 7'h4, so the value of the FMD 6014 input prom_rdat_porting is modified to 4'h8+prom_rdat[11:9]+7'h4, the specific value is 0x2084, and this value is used to pass into the PROM input port of FMD 6014.
[0127] Table 1 below lists the comparison of some instructions of FMD 6017 and FMD 6014. For example, the decoding value of BSF in FMD 6017 is 0b1100, and the decoding value in FMD 6014 is 0b1001, so 0b1001 needs to be passed in the prom_rdat_porting of the FMD 6014 PROM interface instead of 0b1100.
[0128] Table 1 Comparison of some instructions between FMD 6017 and FMD 6014
[0129]
[0130] S412, for instructions similar to the FMD 6014 core, replace similar instructions;
[0131] For example, if the Prom module reads the RLC F instruction of FMD 6017, replace prom_rdat_porting with the RLCF instruction.
[0132] S5, compile all module source codes, generate simulation executable files, start simulation, the Prom module reads the hexadecimal test case codes stored in its storage area in sequence at the preset time, the top module processes the hexadecimal codes, and the FMD 6014 core module and the FMD 6017 core module read, decode and execute instructions respectively;
[0133] During the execution of the test case, after the top-level module performs compatibility processing on the hexadecimal instruction data read by the Prom module, the FMD 6014 core and the FMD 6017 core read the instruction again in the next clock cycle.
[0134] The execution of test cases supports the following modes:
[0135] (1) Execute a single test case at a time. The specific implementation method is to store only the code corresponding to one test case in the Prom module each time;
[0136] (2) Multiple test cases are executed coherently. The specific implementation method is to merge the compiled hexadecimal codes of multiple test cases into one file and store the file content in the Prom module;
[0137] (3) Randomly execute single or multiple test cases. The specific implementation method is to randomly select a test case file and store it in the Prom module.
[0138] S6, during the test case execution, the test check module checks the values of instruction-related registers and program counters in the FMD 6014 core module and the FMD 6017 core module, and outputs the test results in real time after comparison.
[0139] The test check module performs consistency checks on the program counters of the FMD 6014 core and the FMD 6017 core at each clock cycle to ensure the integrity of the FMD 6017 instruction sequence execution.
[0140] Because both FMD 6017 and FMD 6014 use a three-stage pipeline to execute a single instruction, the execution of the instruction can be determined in the following way:
[0141] S61, in the decoding stage, it is determined whether the current status registers of the FMD 6014 core and the FMD 6017 core are consistent with the register values involved in the calculation, and an error message is output if they are inconsistent.
[0142] S62, in the execution phase, it is determined whether the status registers of the FMD 6014 core and the FMD 6017 core are consistent with the register values written back by the calculation results after the instruction is executed. If they are not consistent, an error message is output.
[0143] In the embodiment of the present application, the error information is output to the terminal through the $display function of System verilog.
[0144] At the end of the assembly program of the test case, let pc_addr jump to a fixed address, such as 0x0004. When the test check module detects that pc_addr has been stopped at address 0x0004 for 10 clock cycles, it will automatically stop checking the test results and output the overall test pass rate.
[0145] like Figure 4 The waveform diagram of the simulation test of the BCF instruction is shown in Figure 1. cpu_clk is the clock signal, prom_rdat[15:0] is the PROM input signal of FMD 6017, prom_rdat_porting[13:0] is the PROM input signal of FMD 6014, pc_check[7:0] is the value of the program counter of FMD 6017, pc_check_6014[7:0] is the value of the program counter of FMD 6014, bcf is the BCF instruction signal, 6014_fsr0l[7:0] is the value of the FMD 6014FSR0L register, and 6017_fsr0l[7:0] is the value of the FMD 6017FSR0L register.
[0146] The test check module compares the program counter values of FMD 6014 and FMD 6017 at the rising edge of each clock cycle, such as Figure 4 As shown, pc_check[7:0] and pc_check_6014[7:0] remain consistent in each clock cycle, which is the expected effect.
[0147] When the test module detects that the contents of prom_rdat and prom_rdat_porting are BCF instructions at the rising edge of cpu_clk, it will detect whether the value of FSR0L register of FMD 6017 is consistent with the value of FSR0L of FMD 6014 after 3 cycles. Figure 4 As shown, in the third clock cycle after the BCF signal becomes high, 6014_fsr0l[7:0] and 6017_fsr0l[7:0] both change from f0 to e0, which meets the test expectations.
[0148] In the process of writing test cases, test cases can also be written for all instructions of the FMD 6017 core. For instructions that are incompatible with the FMD 6014 core, NOP instructions can be used to replace the current instructions in the compatibility processing. For instructions that may cause program counter jumps in the FMD 6017 core and are not supported by the FMD 6014 core, when the test result check module compares the program counters, compatibility processing can be performed on the program counter of the FMD 6014, so that it can perform corresponding jump compensation calculations to facilitate comparison of the values of the program counters of the two cores.
[0149] The MCU kernel function verification method of the present invention writes a test case for each instruction in the legacy instruction set list of the MCU kernel to be tested, compiles the test case to generate a hexadecimal code, and stores it in the Prom module. The Prom module reads the hexadecimal instructions in sequence at a preset time, and transmits them to the mass-produced MCU kernel module and the MCU kernel module to be tested. The two kernel modules read, decode, and execute the instructions respectively, and execute the test case in this way. During the execution of the test case, the test inspection module determines whether the decoding and execution results of the MCU kernel to be tested are correct based on the values of the registers of the mass-produced MCU kernel module and the value of the program counter. The test case can be executed individually or in a plurality of consecutive executions, and a single or multiple test cases can also be randomly selected. During the execution of the test case, the test results are output in real time. Therefore, the MCU kernel verification method of the present invention is implemented, and the legacy instruction set in the newly developed MCU kernel can be efficiently and accurately verified, and the convergence of kernel verification is accelerated.
[0150] The above are only specific implementations of the present invention, which cannot be used to limit the scope of the present invention. Equivalent changes made by ordinary technicians in this technical field based on this creation, as well as changes known to technicians in this field, should still fall within the scope of the present invention.
Claims
1. A method for verifying the function of an MCU core, characterized in that: The method is used to verify the instruction execution result of the second MCU core according to the first MCU core, wherein the first MCU core is a mass-produced MCU core, and the second MCU core is an MCU core to be tested, and the instruction sets of the two are similar and the number of instruction pipelines is the same. The verification method includes the following steps: S1, obtaining the Verilog code files of the first MCU core function module, the second MCU core function module, and the Prom function module; S2, writing test cases according to the instruction sets of the first MCU core and the second MCU core, and converting the test cases into hexadecimal codes and storing them in the Prom module; S3, using System Verilog language to build a test check module, obtain the instruction code output by the Prom module and the values of the internal registers of the first MCU core module and the second MCU core module, and compare the test results according to the instruction code; S4, construct the top-level module, instantiate the first MCU kernel module, the second MCU kernel module, the Prom module, and the test and inspection module; S5, compile all module source codes, generate simulation executable files, start simulation, the Prom module reads the hexadecimal test case codes stored in its storage area in sequence at a preset time, the top module processes the hexadecimal codes, and the first MCU kernel module and the second MCU kernel module read, decode and execute instructions respectively; S6, during the test case execution process, the test check module checks the values of instruction-related registers and program counters in the first MCU kernel module and the second MCU kernel module, and outputs the test results after comparison.
2. The MCU core function verification method according to claim 1, characterized in that: In step S2, the specific steps of writing test cases and storing the test cases in the Prom module are as follows: S21, selecting from the instruction set of the second MCU core a portion that is overlapped with or similar to the instruction set of the first MCU core, to form a legacy instruction set list; S22, writing an assembly language test case for the second MCU core for each instruction in the legacy instruction set list of the second MCU core; S23, converting the written test case into hexadecimal code; S24, storing the converted hexadecimal code in the data storage area of the Prom.
3. The MCU core function verification method according to claim 2, characterized in that: The step S23 comprises the following steps: S231, use the mpasmx compiler to compile the .asm file corresponding to the test case and generate a hexadecimal .hex file; S232, use the script to extract the address and data parts from the .hex file; S233, write the address and data separated in step S232 into the .in file one by one, in the format of "@address hexadecimal instruction", with each line corresponding to one instruction.
4. The MCU core function verification method according to claim 2, characterized in that: After step S4, the method further includes: S41, in the top-level module, the hexadecimal instruction data of the second MCU core read by the Prom module is processed for compatibility with the first MCU core, and the processed data is passed to the first MCU core through the PROM input port, wherein the compatibility processing specifically includes: S411, for the instructions in the legacy instruction set list, the hexadecimal instructions read by the Prom module are processed for compatibility with the first MCU core, including: PROM bit width compatibility, instruction decoding compatibility, and register address compatibility in the instructions; S412: For instructions similar to the first MCU core, replace similar instructions.
5. The MCU core function verification method according to claim 2, characterized in that: During the execution of the test case, after the top-level module performs compatibility processing on the hexadecimal instruction data read by the Prom module, the first MCU core and the second MCU core read the instruction again in the next clock cycle.
6. The MCU core function verification method according to claim 1, characterized in that: In step S6, the method in which the test and inspection module performs register inspection is as follows: S61, determining whether the current state registers of the first MCU core and the second MCU core are consistent with the register values involved in the calculation during the decoding stage, and outputting error information if they are inconsistent; S62, in the execution phase, determining whether the status registers of the first MCU core and the second MCU core and the register values written back by the calculation results are consistent after the instruction is executed, and outputting an error message if they are inconsistent.
7. The MCU core function verification method according to claim 1, characterized in that: In step S6, the test and check module performs a consistency check on the program counters of the first MCU core and the second MCU core in each clock cycle.
8. The MCU core function verification method according to claim 1, characterized in that: In step S5, the execution of the test case supports the following modes: (1) Execute a single test case at a time; (2) Multiple test cases are executed continuously; (3) Randomly execute single or multiple test cases.