Processing method for automatically verifying chip interruption

Abstract

The invention relates to the technical field of electric digital data processing, in particular to a processing method for automatically verifying chip interruption. The method comprises the following steps: acquiring a target interrupt test table corresponding to an interrupt to be tested; analyzing the table to obtain interrupt information corresponding to each record, a verification scene name and an error injection code; for any record, generating a test case and an error injection code file corresponding to the record; in the process of testing the interrupt corresponding to the ith record, setting the running test case as the test case corresponding to the ith record, and activating the error injection code in the error injection code file corresponding to the ith record through a command line with the name of the test case corresponding to the ith record, the interrupt information corresponding to the ith record is sent to the detector; and if the detector judges that the interrupt collected by the monitor is the interrupt corresponding to the ith record, outputting a report that the interrupt corresponding to the ith record passes the test. According to the invention, the interrupt verification cost is reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of electronic digital data processing, and in particular to a processing method for automatically verifying chip interruption. Background Art

[0002] As chips evolve, their functionality becomes increasingly richer and systems become larger. Consequently, the number of interrupt sources increases, and interrupt systems become increasingly complex, which in turn increases the cost of interrupt verification. Currently, the industry generally uses a targeted testing approach for interrupt verification. Verifiers typically manually write specific test cases for each interrupt. If a large number of interrupts require verification, this requires extensive test case development, incurring significant writing costs. Furthermore, verifiers must perform targeted debugging on each test case to ensure accuracy, which incurs significant debugging costs. Summary of the Invention

[0003] The present invention aims to provide a method for automatically verifying chip interrupts, so as to reduce the cost of interrupt verification and improve the efficiency of interrupt verification.

[0004] According to the present invention, a method for automatically verifying chip interrupt processing is provided, the method comprising the following steps: S100, obtain the target interrupt test table corresponding to the interrupt to be tested; the target interrupt test table includes n records, any record includes the preset type information of the corresponding interrupt to be tested, the preset type information includes the interrupt source name, interrupt type, interrupt ID, verification scenario name, error code and whether to recover flag, and n is the number of interrupts to be tested.

[0005] S200, parsing the target interruption test table to obtain the interruption information, verification scenario name and error code corresponding to each record; the interruption information includes the interruption source name, interruption type and interruption ID.

[0006] S300, for any record, generate a test case and annotated code file corresponding to the record; the test behavior of the test case corresponding to the record is the same as the test behavior of the test case corresponding to the verification scenario name corresponding to the record, and the annotated code file corresponding to the record includes a preset detection function and annotated code. The preset detection function is used to detect whether the command line contains a simulation parameter with a preset parameter name during the simulation run, and execute the annotated code after detecting the simulation parameter with the preset parameter name. The preset parameter name is the name of the test case corresponding to the record.

[0007] S400, in the process of testing the interrupt corresponding to the i-th record, the running test case is set to the test case corresponding to the i-th record, the error code in the error code file corresponding to the i-th record is activated through the command line with the name of the test case corresponding to the i-th record, and the interrupt information corresponding to the i-th record is sent to the detector, so that the detector determines whether the interrupt collected by the monitor is the interrupt corresponding to the i-th record based on the received interrupt information; the value range of i is 1 to n.

[0008] S500: If the monitor collects an interruption within a preset time period, and the detector determines that the interruption collected by the monitor is the interruption corresponding to the i-th record, a report indicating that the interruption test corresponding to the i-th record has passed is output.

[0009] Compared with the prior art, the present invention has at least the following beneficial effects: The present invention obtains a target interrupt test table corresponding to the interrupt to be tested, and the table stores information such as the interrupt source name, interrupt type, interrupt ID, verification scenario name, error code, and whether to recover flag of each interrupt to be tested. Based on the interrupt test table, the present invention realizes systematic management of test content, which is convenient for testers to view and maintain test cases; and for any interrupt to be tested, the present invention uses a preset detection function to flexibly activate the corresponding error code according to different test case names, thereby realizing accurate testing of different interrupt scenarios; compared with the method in which the verification personnel manually write a specific test case for each interrupt in the prior art, the present invention only requires the verification personnel to build a target interrupt test table, and the table only requires the verification personnel to write the error code and determine the name of the verification scenario, without having to write the verification scenario code, which can reduce the workload of the interrupt personnel in writing test cases; after the target interrupt test table is built, the present invention automatically generates test cases and error code files, without having to manually write a large amount of test code, greatly reducing the workload of the test personnel and shortening the test cycle. As a result, the present invention can reduce the cost of interrupt verification and improve the efficiency of interrupt verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0011] Figure 1 This is a flowchart of a method for processing an automatic verification chip interrupt provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0012] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only 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 those skilled in the art without making any creative efforts shall fall within the scope of protection of the present invention.

[0013] According to this embodiment, a method for processing an automatic verification chip interrupt is provided, the method comprising the following steps: Figure 1 As shown: S100, obtain the target interrupt test table corresponding to the interrupt to be tested; the target interrupt test table includes n records, any record includes the preset type information of the corresponding interrupt to be tested, the preset type information includes the interrupt source name, interrupt type, interrupt ID, verification scenario name, error code and whether to recover flag, and n is the number of interrupts to be tested.

[0014] In this embodiment, the interrupt type is normal or abnormal; if the interrupt type of a certain interrupt to be tested is normal, then the recovery flag of the interrupt to be tested is no; if the interrupt type of a certain interrupt to be tested is abnormal, then the recovery flag of the interrupt to be tested is yes.

[0015] Optionally, the preset type information further includes an interruption description, where the interruption description is an explanation of the interruption.

[0016] As a specific implementation method, a target interrupt test table is constructed for an interrupt verifier, wherein the interrupt source name, interrupt type, interrupt ID, interrupt description, and whether the recovery flag are known information of the interrupt to be tested. Optionally, this information is pre-set by the chip designer or chip architect, and the interrupt verifier can directly obtain this information when constructing the table. The verification scenario name and error code need to be configured and verified by the interrupt verifier. It should be noted that when constructing the table, the verifier only needs to determine the name of the verification scenario and fill in the name of the verification scenario in the table, without having to write the verification scenario code. This can reduce the workload of the interrupt verifier in writing test cases.

[0017] As a specific implementation, the target interruption test table is shown in Table 1.

[0018] Table 1

[0019] It should be understood that Table 1 only shows one record.

[0020] S200, parsing the target interruption test table to obtain the interruption information, verification scenario name and error code corresponding to each record; the interruption information includes the interruption source name, interruption type and interruption ID.

[0021] In this embodiment, the correspondence between each column of the target interruption test table and each preset type of information is known. As shown in Table 1, the first column of the target interruption test table is the interruption source name, the second column of the target interruption test table is the interruption description, the third column of the target interruption test table is the interruption type, the fourth column of the target interruption test table is the interruption ID, the fifth column of the target interruption test table is the verification scenario name, the sixth column of the target interruption test table is the error code, and the seventh column of the target interruption test table is the recovery flag. Based on the knowledge of the correspondence between each column of the target interruption test table and each preset type of information, the target interruption test table can be automatically parsed to obtain each preset type of information corresponding to each record.

[0022] S300, for any record, generate a test case and annotated code file corresponding to the record; the test behavior of the test case corresponding to the record is the same as the test behavior of the test case corresponding to the verification scenario name corresponding to the record, and the annotated code file corresponding to the record includes a preset detection function and annotated code. The preset detection function is used to detect whether the command line contains a simulation parameter with a preset parameter name during the simulation run, and execute the annotated code after detecting the simulation parameter with the preset parameter name. The preset parameter name is the name of the test case corresponding to the record.

[0023] In this embodiment, the test behavior of the test case corresponding to any record is a complete copy of the test behavior of the test case corresponding to the verification scenario name corresponding to the record.

[0024] In this embodiment, a verification scenario code library is pre-established. The verification scenario code library includes code for test cases corresponding to several verification scenarios. The code for each test case corresponding to each verification scenario is correct. Based on the code for each test case corresponding to each verification scenario, the device under test can be operated in the corresponding verification scenario. Based on the verification scenario name included in any record, the code for the corresponding test case can be obtained from the verification scenario code library.

[0025] As a preferred specific implementation, the name of the test case corresponding to any record is a concatenation of the verification scenario name and the interrupt source name of the record. Thus, based on the name of the test case corresponding to any record, it is possible to know which verification scenario the test case is based on, and which interrupt source the test case corresponds to, for ease of tracing. For example, the name of the test case corresponding to the first record in Table 1 is soc_system_ip_a_basic_test_timeout. Based on the name of the test case, it can be known that the verification scenario corresponding to the test case is soc_system_ip_a_basic_test, and the interrupt source corresponding to the test case is timeout.

[0026] In this embodiment, the process of testing the interruption corresponding to the i-th record using the test case and error annotation file code corresponding to the i-th record includes: in the compilation stage, compiling the test case and error annotation code file corresponding to the i-th record; in the running stage, setting the running test case to the test case corresponding to the i-th record, and activating the error annotation code in the error annotation code file corresponding to the i-th record through a command line with the name of the test case corresponding to the i-th record.

[0027] As a specific implementation, the error annotation file is a separate SystemVerilog file (e.g., timeout_error.sv) that contains the injection logic for a specific interrupt (e.g., a timeout interrupt). This file uses the SystemVerilog runtime check function $test$plusargs() to implement conditional execution control. For example, in the SystemVerilog file, the interrupt injection code (also known as the error annotation code) is written after the content of if ($test$plusargs("soc_system_ip_a_basic_test_timeout"))begin. The specific structure is as follows: if ($test$plusargs("soc_system_ip_a_basic_test_timeout")) begin / / Error code end Therefore, the corresponding error-annotated code can be executed after soc_system_ip_a_basic_test_timeout appears in the command line.

[0028] S400, in the process of testing the interrupt corresponding to the i-th record, the running test case is set to the test case corresponding to the i-th record, the error code in the error code file corresponding to the i-th record is activated through the command line with the name of the test case corresponding to the i-th record, and the interrupt information corresponding to the i-th record is sent to the detector, so that the detector determines whether the interrupt collected by the monitor is the interrupt corresponding to the i-th record based on the received interrupt information; the value range of i is 1 to n.

[0029] In this embodiment, the process of the detector judging whether the interruption collected by the monitor is the interruption corresponding to the i-th record based on the received interruption information includes: matching the interruption source name, interruption type and interruption ID of the interruption collected by the monitor with the interruption source name, interruption type and interruption ID corresponding to the i-th record respectively; if all matches are successful, it is judged that the interruption collected by the monitor is the interruption corresponding to the i-th record; otherwise, it is judged that the interruption collected by the monitor is not the interruption corresponding to the i-th record.

[0030] In this embodiment, by sending the interruption information associated with the test case corresponding to the i-th record to the detector, it is possible to automatically determine whether the interruption collected by the monitor is the interruption corresponding to the i-th record, thereby improving the automation and efficiency of the interruption testing process.

[0031] Those skilled in the art know that the process of testing an interruption based on a device under test (DUT), a monitor, and a checker is an existing technology and will not be described in detail here.

[0032] S500: If the monitor collects an interruption within a preset time period, and the detector determines that the interruption collected by the monitor is the interruption corresponding to the i-th record, a report indicating that the interruption test corresponding to the i-th record has passed is output.

[0033] In this embodiment, S500 further includes: if the detector determines that the interrupt collected by the monitor is the interrupt corresponding to the i-th record, then information that the interrupt test has passed is sent to the recovery module, so that the recovery module recovers the device under test under the condition that the information that the interrupt test has passed is received and the recovery flag included in the i-th record is yes. Optionally, recovering the device under test includes a process of resetting the device under test and verifying whether the reset is successful after the reset. As a specific embodiment, during the process of testing the interrupt corresponding to the i-th record, the recovery flag included in the i-th record is sent to the recovery module, and the recovery module determines whether to recover the device under test based on the received recovery flag. If recovery is not required, the interrupt test corresponding to the i-th record ends.

[0034] In this embodiment, if the monitor does not collect an interrupt within a preset time period, or the detector determines that the interrupt collected by the monitor is not the interrupt corresponding to the i-th record, the detector outputs a report that the interrupt test corresponding to the i-th record has failed.

[0035] This embodiment obtains a target interrupt test table corresponding to the interrupt to be tested. The table stores information such as the interrupt source name, interrupt type, interrupt ID, verification scenario name, error code, and whether to recover for each interrupt to be tested. Based on the interrupt test table, this embodiment implements systematic management of test content, making it convenient for testers to view and maintain test cases. For any interrupt to be tested, this embodiment uses a preset detection function to flexibly activate the corresponding error code according to different test case names, thereby achieving accurate testing of different interrupt scenarios. Compared with the existing method in which verification personnel manually write specific test cases for each interrupt, this embodiment only requires verification personnel to build a target interrupt test table. In the table, verification personnel only need to write error codes and determine the name of the verification scenario, without having to write verification scenario code, which can reduce the workload of interrupt personnel in writing test cases. After the target interrupt test table is built, this embodiment automatically generates test cases and error code files, eliminating the need to manually write a large amount of test code, greatly reducing the workload of testers and shortening the testing cycle. As a result, this embodiment can reduce the cost of interrupt verification and improve the efficiency of interrupt verification.

[0036] Although some specific embodiments of the present invention have been described in detail by way of example, it should be understood by those skilled in the art that the above examples are for illustration only and are not intended to limit the scope of the present invention. It should also be understood by those skilled in the art that various modifications may be made to the embodiments without departing from the scope and spirit of the present invention. The scope of the present invention is defined by the appended claims.

Claims

1. A method for automatically verifying chip interruption processing, characterized in that: The method comprises the following steps: S100, obtaining a target interrupt test table corresponding to the interrupt to be tested; the target interrupt test table includes n records, each record includes preset type information of the corresponding interrupt to be tested, the preset type information includes the interrupt source name, interrupt type, interrupt ID, verification scenario name, error code, and whether to recover flag, and n is the number of interrupts to be tested; S200, parsing the target interruption test table to obtain the interruption information, verification scenario name and error code corresponding to each record; the interruption information includes the interruption source name, interruption type and interruption ID; S300: For any record, generate a test case and an error-annotated code file corresponding to the record; the test behavior of the test case corresponding to the record is the same as the test behavior of the test case corresponding to the verification scenario name corresponding to the record; the error-annotated code file corresponding to the record includes a preset detection function and an error-annotated code, the preset detection function is used to detect whether a simulation parameter with a preset parameter name is included in the command line during simulation operation, and execute the error-annotated code after detecting the simulation parameter with the preset parameter name, and the preset parameter name is the name of the test case corresponding to the record; S400, in the process of testing the interrupt corresponding to the i-th record, setting the running test case to be the test case corresponding to the i-th record, activating the error-annotated code in the error-annotated code file corresponding to the i-th record through a command line with the name of the test case corresponding to the i-th record, and sending the interrupt information corresponding to the i-th record to the detector, so that the detector determines whether the interrupt collected by the monitor is the interrupt corresponding to the i-th record based on the received interrupt information; the value range of i is 1 to n; S500: If the monitor collects an interruption within a preset time period, and the detector determines that the interruption collected by the monitor is the interruption corresponding to the i-th record, a report indicating that the interruption test corresponding to the i-th record has passed is output.

2. The method for processing an automatic verification chip interruption according to claim 1, characterized in that: The name of the test case corresponding to any record is the concatenation of the verification scenario name and the interrupt source name of the record.

3. The method for processing an automatic verification chip interruption according to claim 1, characterized in that: S500 also includes: if the detector determines that the interruption collected by the monitor is the interruption corresponding to the i-th record, it sends information that the interruption test is passed to the recovery module, so that the recovery module recovers the device under test when it receives the information that the interruption test is passed and the recovery flag included in the i-th record is yes.

4. The method for processing an automatic verification chip interruption according to claim 1, characterized in that: S500 further includes: if the monitor does not collect an interruption within a preset time period, or the detector determines that the interruption collected by the monitor is not the interruption corresponding to the i-th record, the detector outputs a report indicating that the interruption test corresponding to the i-th record has failed.

5. The method for processing an automatic verification chip interruption according to claim 1, characterized in that: The process of the detector judging whether the interrupt collected by the monitor is the interrupt corresponding to the i-th record based on the received interrupt information includes: matching the interrupt source name, interrupt type and interrupt ID of the interrupt collected by the monitor with the interrupt source name, interrupt type and interrupt ID corresponding to the i-th record respectively. If all matches are successful, it is judged that the interrupt collected by the monitor is the interrupt corresponding to the i-th record; otherwise, it is judged that the interrupt collected by the monitor is not the interrupt corresponding to the i-th record.

6. The method for processing an automatic verification chip interruption according to claim 1, characterized in that: The interrupt type is normal or abnormal.

7. The method for processing an automatic verification chip interruption according to claim 1, characterized in that: The preset type information also includes an interrupt description.

Images