A method for processing automatic verification chip interruption

Abstract

This application relates to the field of electronic digital data processing technology, and in particular to an automated method for verifying chip interrupt processing. It includes: obtaining a target interrupt test table corresponding to the interrupt to be tested; parsing the table to obtain the interrupt information, verification scenario name, and error annotation code corresponding to each record; for any record, generating a test case and error annotation code file corresponding to that record; during the testing of the interrupt corresponding to the i-th record, setting the running test case to the test case corresponding to the i-th record, 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, and sending the interrupt information corresponding to the i-th record to the detector; if the detector determines that the interrupt collected by the monitor is the interrupt corresponding to the i-th record, then outputting a report that the interrupt test corresponding to the i-th record has passed. This invention reduces the cost of interrupt verification.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and in particular to an automated method for processing chip interruptions. Background Technology

[0002] As chips have evolved, their functions have become increasingly richer and systems increasingly larger. This has led to a corresponding increase in interrupt sources and the complexity of interrupt systems, thus increasing the cost of interrupt verification. Currently, the industry primarily uses targeted testing for interrupt verification. Typically, verification personnel manually write specific test cases for each interrupt. If a large number of interrupts need verification, verification personnel need to write a large number of test cases, incurring significant writing costs. Furthermore, verification personnel need to perform targeted debugging on each test case to ensure its accuracy, which also incurs substantial debugging costs. Summary of the Invention

[0003] The purpose of this invention is to provide an automated method for handling chip interrupts, so as to reduce the cost of interrupt verification and improve the efficiency of interrupt verification.

[0004] According to the present invention, an automated verification chip interrupt handling method is provided, the method comprising the following steps:

[0005] S100, obtain the target interrupt test table corresponding to the interrupt to be tested; the target interrupt test table includes n records, each record includes the preset type information of the corresponding interrupt to be tested, the preset type information includes interrupt source name, interrupt type, interrupt ID, verification scenario name, error code and whether to restore, and n is the number of interrupts to be tested.

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

[0007] S300, for any record, generate the corresponding test case and error annotation code file; 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 of the record. The error annotation code file corresponding to the record includes a preset detection function and error annotation 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 executes the error annotation 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.

[0008] S400, during the testing of the interrupt corresponding to the i-th record, the test case to be run 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 by 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 can determine whether the interrupt collected by the monitor is the interrupt corresponding to the i-th record based on the received interrupt information; the value of i is in the range of 1 to n.

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

[0010] Compared with the prior art, the present invention has at least the following beneficial effects:

[0011] This invention obtains a target interrupt test table corresponding to each interrupt to be tested. This table stores information such as the interrupt source name, interrupt type, interrupt ID, verification scenario name, annotation code, and recovery flag for each interrupt to be tested. Based on this interrupt test table, this invention achieves systematic management of test content, facilitating testers' viewing and maintenance of test cases. Furthermore, for any interrupt to be tested, this invention utilizes a preset detection function to flexibly activate corresponding annotation codes based on different test case names, achieving precise testing of different interrupt scenarios. Compared to the existing technology where verifiers manually write specific test cases for each interrupt, this invention only requires verifiers to construct the target interrupt test table. The table only requires verifiers to write the annotation code and determine the verification scenario name, eliminating the need to write verification scenario code, thus reducing the workload of interrupt verifiers. After the target interrupt test table is constructed, this invention automatically generates test case and annotation code files, eliminating the need for manually writing large amounts of test code, significantly reducing the workload of testers and shortening the testing cycle. Therefore, this invention reduces the cost of interrupt verification and improves the efficiency of interrupt verification. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A flowchart of an automated verification chip interrupt handling method provided in an embodiment of the present invention. Detailed Implementation

[0014] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0015] According to this embodiment, an automated verification chip interrupt handling method is provided, the method including the following steps, such as... Figure 1 As shown:

[0016] S100, obtain the target interrupt test table corresponding to the interrupt to be tested; the target interrupt test table includes n records, each record includes the preset type information of the corresponding interrupt to be tested, the preset type information includes interrupt source name, interrupt type, interrupt ID, verification scenario name, error code and whether to restore, and n is the number of interrupts to be tested.

[0017] 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 interrupt recovery flag is no; if the interrupt type of a certain interrupt to be tested is abnormal, then the interrupt recovery flag is yes.

[0018] Optionally, the preset type information may also include an interruption description, which is an explanation of the interruption.

[0019] In one specific implementation, the target interrupt test table is constructed by the interrupt verifier. The interrupt source name, interrupt type, interrupt ID, interrupt description, and recovery flag are known information about the interrupt under test. 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-checking 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 it in; they do not need to write the verification scenario code. This reduces the workload of the interrupt verifier in writing test cases.

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

[0021] Table 1

[0022]

[0023] It should be understood that only one record is shown in Table 1.

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

[0025] 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 is the interruption description, the third column is the interruption type, the fourth column is the interruption ID, the fifth column is the verification scenario name, the sixth column is the error code, and the seventh column is the recovery flag. Based on knowing 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.

[0026] S300, for any record, generate the corresponding test case and error annotation code file; 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 of the record. The error annotation code file corresponding to the record includes a preset detection function and error annotation 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 executes the error annotation 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.

[0027] 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 of that record.

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

[0029] In a preferred embodiment, the name of the test case corresponding to any record is a concatenation of the verification scenario name and the interruption source name of that record. Therefore, based on the name of the test case corresponding to any record, it is possible to know which verification scenario the test case was based on and which interruption source it corresponds to, facilitating traceability. 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 this name, it can be known that the verification scenario for this test case is soc_system_ip_a_basic_test, and the interruption source for this test case is timeout.

[0030] In this embodiment, the process of testing the interruption corresponding to the i-th record using the test case and error comment file code corresponding to the i-th record includes: in the compilation stage, compiling the test case and error comment code file corresponding to the i-th record; in the runtime stage, setting the test case to be run as the test case corresponding to the i-th record, and activating the error comment code in the error comment 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.

[0031] As a specific implementation, the error injection file is a separate SystemVerilog file (e.g., timeout_error.sv) that contains the injection logic for a specific interrupt (such as a timeout interrupt). This file uses the SystemVerilog runtime detection function `$test$plusargs()` to implement conditional execution control. For example, interrupt injection code (i.e., error injection code) is written after the `if ($test$plusargs("soc_system_ip_a_basic_test_timeout"))begin` statement in the SystemVerilog file, with the following structure:

[0032] if ($test$plusargs("soc_system_ip_a_basic_test_timeout")) begin

[0033] / / Error correction code

[0034] end

[0035] Therefore, the corresponding error-checking code can be executed after soc_system_ip_a_basic_test_timeout appears in the command line.

[0036] S400, during the testing of the interrupt corresponding to the i-th record, the test case to be run 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 by 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 can determine whether the interrupt collected by the monitor is the interrupt corresponding to the i-th record based on the received interrupt information; the value of i is in the range of 1 to n.

[0037] In this embodiment, the process by which 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 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. If all matches are successful, it is determined that the interrupt collected by the monitor is the interrupt corresponding to the i-th record; otherwise, it is determined that the interrupt collected by the monitor is not the interrupt corresponding to the i-th record.

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

[0039] Those skilled in the art will recognize that the process of testing interruptions based on the device under test (DUT), monitor, and checker is prior art and will not be described in detail here.

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

[0041] 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 it sends an interrupt test pass message to the recovery module, so that the recovery module can recover the device under test under the condition that it receives the interrupt test pass message and the recovery flag included in the i-th record is yes. Optionally, the recovery of the device under test includes resetting the device under test and verifying whether the reset was successful after resetting. As a specific implementation, during the test of 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.

[0042] In this embodiment, if the monitor fails to collect an interrupt within a preset time period, or if 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 failed.

[0043] This embodiment obtains a target interrupt test table corresponding to the interrupt to be tested. This table stores information such as the interrupt source name, interrupt type, interrupt ID, verification scenario name, annotation code, and recovery flag for each interrupt to be tested. Based on this interrupt test table, this embodiment achieves systematic management of test content, facilitating testers' viewing and maintenance of test cases. Furthermore, for any interrupt to be tested, this embodiment utilizes a preset detection function to flexibly activate the corresponding annotation code based on different test case names, achieving precise testing of different interrupt scenarios. Compared to the existing technology where verifiers manually write specific test cases for each interrupt, this embodiment only requires verifiers to construct the target interrupt test table. The table only requires verifiers to write the annotation code and determine the verification scenario name, eliminating the need to write verification scenario code, thus reducing the workload of interrupt verifiers in writing test cases. After the target interrupt test table is constructed, this embodiment automatically generates test case and annotation code files, eliminating the need to manually write a large amount of test code, significantly reducing the workload of testers and shortening the testing cycle. Therefore, this embodiment reduces the cost of interrupt verification and improves the efficiency of interrupt verification.

[0044] While specific embodiments of the invention have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. It should also be understood that various modifications can be made to the embodiments without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.

Claims

1. A method for automatically verifying chip interrupt handling, characterized in that, The method includes 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, each record includes the preset type information of the corresponding interrupt to be tested, the preset type information includes interrupt source name, interrupt type, interrupt ID, verification scenario name, error code and whether to recover, and n is the number of interrupts to be tested; S200, parse the target interrupt test table to obtain the interrupt information, verification scenario name and error code corresponding to each record; the interrupt information includes the interrupt source name, interrupt type and interrupt ID; S300, For any record, generate the test case and error annotation code file corresponding to that record; The test behavior of the test case corresponding to that record is the same as the test behavior of the test case corresponding to the verification scenario name of that record. The error annotation code file corresponding to that record includes a preset detection function and error annotation 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 error annotation code after detecting the simulation parameter with the preset parameter name. The preset parameter name is the name of the test case corresponding to that record. S400, during the testing of the interrupt corresponding to the i-th record, the test case to be run 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 can determine whether the interrupt collected by the monitor is the interrupt corresponding to the i-th record based on the received interrupt information; the value of i ranges from 1 to n. S500: If the monitor collects an interrupt within a preset time period, and the detector determines that the interrupt collected by the monitor is the interrupt corresponding to the i-th record, then output a report that the interrupt test corresponding to the i-th record has passed.

2. The method for handling automated verification chip interruptions according to claim 1, characterized in that, The name of the test case corresponding to any record is a combination of the verification scenario name and the interruption source name of that record.

3. The method for handling automated verification chip interruptions according to claim 1, characterized in that, S500 also includes: if the detector determines that the interrupt acquired by the monitor is the interrupt corresponding to the i-th record, it sends an interrupt test pass message to the recovery module so that the recovery module can recover the device under test under the condition that it receives the interrupt test pass message and the recovery flag included in the i-th record is yes.

4. The method for handling automated verification chip interruptions according to claim 1, characterized in that, S500 also includes: if the monitor does not collect an interrupt within a preset time period, or if 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.

5. The method for handling automated verification chip interruptions according to claim 1, characterized in that, The process by which 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 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. If all matches are successful, the interrupt collected by the monitor is determined to be the interrupt corresponding to the i-th record; otherwise, the interrupt collected by the monitor is determined not to be the interrupt corresponding to the i-th record.

6. The method for handling automated verification chip interruptions according to claim 1, characterized in that, The interrupt type is either normal or abnormal.

7. The method for handling automated verification chip interruptions according to claim 1, characterized in that, The preset type information also includes an interruption description.

Images