Interrupt verification method, verification platform, electronic device, readable storage medium and computer program product

Abstract

This application discloses an interrupt verification method, verification platform, electronic device, readable storage medium, and computer program product, belonging to the field of chip verification technology. The method includes: triggering an interrupt event from an interrupt source corresponding to a target interrupt bit in the device under test (DUT); monitoring the interrupt output signal output by the DUT based on the interrupt event; in response to the interrupt output signal changing to an interrupt state, sending an interrupt clearing command to the DUT to cause the DUT to perform an interrupt clearing operation on the target interrupt bit; wherein the interrupt state indicates that the interrupt source corresponding to the target interrupt bit has been triggered; and determining whether the interrupt source corresponding to the target interrupt bit is the actual interrupt source that generated the interrupt event based on the state change of the interrupt output signal after performing the interrupt clearing operation.

Description

Technical Field

[0001] This application relates to the field of chip verification technology, and in particular to an interrupt verification method, verification platform, electronic device, readable storage medium, and computer program product. Background Technology

[0002] During operation, chips can utilize interrupt functionality to perform concurrent multitasking, improving responsiveness and real-time performance. Therefore, the interrupt functionality of a chip needs to be verified before it is put into use or mass production.

[0003] In traditional System-on-Chip (SoC) designs, various modules typically report events or abnormal states to the processor via interrupt mechanisms, which then execute interrupt routines. Existing interrupt verification technologies often rely on internal module signals as interrupt sources, making them difficult to observe and locate, and thus difficult to determine which interrupt source triggered the interrupt output. Furthermore, interrupt verification heavily depends on the processor executing interrupt service routines, making it impossible to achieve isolated verification of hardware logic. Summary of the Invention

[0004] This application provides an interrupt verification method, verification platform, electronic device, readable storage medium, and computer program product, which can solve the problems that existing interrupt verification technologies cannot directly observe and locate the interrupt source, and that interrupt verification highly depends on the processor executing interrupt service routines, thus failing to achieve isolated verification of hardware logic.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows: Firstly, an interruption verification method is provided, applied to a verification platform, including: Trigger the interrupt source corresponding to the target interrupt bit in the device under test to generate an interrupt event; Monitor the interrupt output signal output by the device under test based on the interrupt event; In response to the interrupt output signal becoming an interrupt state, an interrupt clearing command is sent to the device under test (DUT) to cause the DUT to perform an interrupt clearing operation on the target interrupt bit; wherein, the interrupt state indicates that the interrupt source corresponding to the target interrupt bit has been triggered; Based on the state change of the interrupt output signal after the interrupt clearing operation, determine whether the interrupt source corresponding to the target interrupt bit is the actual interrupt source that generated the interrupt event.

[0006] Secondly, a verification platform is provided, including: The interrupt trigger module is used to trigger the interrupt source corresponding to the target interrupt bit in the device under test to generate an interrupt event; An interrupt monitoring module is used to monitor the interrupt output signal output by the device under test based on the interrupt event; An interrupt driver module is configured to send an interrupt clear command to the device under test (DUT) in response to the interrupt output signal changing to an interrupt state, so that the DUT performs an interrupt clear operation on the target interrupt bit; wherein, the interrupt state indicates that the interrupt source corresponding to the target interrupt bit has been triggered; The interrupt determination module is used to determine whether the interrupt source corresponding to the target interrupt bit is the actual interrupt source that generated the interrupt event, based on the state change of the interrupt output signal after the interrupt clearing operation.

[0007] Thirdly, an electronic device is provided, comprising a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement the above-described interrupt verification method.

[0008] Fourthly, a readable storage medium is provided, wherein at least one computer program is stored in the readable storage medium, the computer program being loaded and executed by a processor to implement the above-described interrupt verification method.

[0009] Fifthly, a computer program product is provided, the computer program product comprising at least one computer program, the computer program being loaded and executed by a processor to implement the interrupt verification method provided in the various optional implementations described above.

[0010] The present application provides an interrupt verification method, verification platform, electronic device, readable storage medium, and computer program product that can accurately locate unobservable interrupt sources through a reverse verification mechanism. It can complete the automatic verification of interrupt triggering, clearing, and interrupt source without relying on the processor, thereby improving the universality, reliability, and coverage of verification.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0013] Figure 1 This invention illustrates a structural block diagram of a verification platform provided in an exemplary embodiment of this application. Figure 2 This invention illustrates a structural block diagram of a verification platform provided in an exemplary embodiment of this application. Figure 3A flowchart of an exemplary embodiment of the present application is shown; Figure 4 A flowchart illustrating the verification of the interrupt masking function provided in an exemplary embodiment of this application is shown; Figure 5 A structural block diagram of an electronic device provided in an exemplary embodiment of this application is shown. Detailed Implementation

[0014] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0015] In existing interrupt verification technologies, interrupt sources are usually internal signals of modules, which cannot be directly observed or located, making it difficult to determine which interrupt source triggered the interrupt output. Moreover, the existing interrupt verification process is usually as follows: the hardware generates an interrupt signal, the Central Processing Unit (CPU) receives the interrupt signal, jumps to execute the interrupt service routine (software code), and the software reads the status register and writes the clear register to clear the interrupt. This relies on the execution timing and correctness of the software and cannot independently verify the hardware interrupt logic. In other words, the existing interrupt verification process is highly dependent on the processor executing the interrupt service routine and cannot achieve the problem of isolated verification of hardware logic.

[0016] To address the aforementioned problems in the prior art, embodiments of this application provide an interruption verification method applied to a verification platform. To facilitate understanding of the interruption verification method provided in these embodiments, a brief introduction to the verification platform is first given.

[0017] Figure 1 A structural block diagram of a verification platform 100 illustrated in an exemplary embodiment of this application is shown. Figure 1As shown, the verification platform 100 provided in this embodiment includes: an interrupt activation module 101, an interrupt monitoring module 102, an interrupt driving module 103, and an interrupt judgment module 104. In this embodiment, the interrupt activation module 101 is used to trigger the interrupt source corresponding to the target interrupt bit in the device under test to generate an interrupt event; the interrupt monitoring module 102 is used to monitor the interrupt output signal (interrupt) output by the device under test based on the interrupt event; the interrupt driving module 103 is used to send an interrupt clearing instruction to the device under test in response to the interrupt output signal becoming an interrupt state, so as to perform an interrupt clearing operation on the target interrupt bit; wherein, the interrupt state indicates that the interrupt source corresponding to the target interrupt bit has been triggered; the interrupt judgment module 104 is used to determine whether the interrupt source corresponding to the target interrupt bit is the real interrupt source that generated the interrupt event based on the state change of the interrupt output signal after the interrupt clearing operation.

[0018] In some embodiments, such as Figure 2 As shown, the verification platform 100 may also include an interrupt transaction configuration module 105, which is used to configure and manage interrupt verification transactions (int_item). The interrupt verification transaction may include interrupt check enable information (err_chk_valid), timing parameters (such as interrupt wait duration (wait_time), clear delay duration (clr_time), and status check duration (chk_time), interrupt clear information (interrupt_clear_info), mask test enable information (mask_test_en), loop count (loop_cnt), etc., to provide a unified parameterized configuration for the verification process.

[0019] For example, the verification platform is a verification platform based on the Universal Verification Methodology (UVM) environment. In the UVM verification environment, the functions of each module in this embodiment can be implemented by interrupting the verification agent, which includes at least components such as a sequencer, a driver, and a monitor.

[0020] In practical implementation, the interrupt interface (int_io) of the device under test (DUT) needs to be uniformly modeled first. This interrupt interface includes at least the interrupt output signal (interrupt), the interrupt check enable signal (err_chk_valid), the interrupt clear signal (int_clr), and the status clear signal (status_clr). The interrupt output signal indicates whether the DUT has generated an interrupt; the interrupt check enable signal controls the validity of different interrupt sources for the DUT; the interrupt clear signal clears the externally visible interrupt status of the DUT; and the status clear signal clears the internal interrupt status information of the DUT. By abstracting these signals, a unified interrupt verification environment can be achieved between different DUTs.

[0021] After completing the interface modeling, an interrupt verification agent is built and integrated into the verification environment. This interrupt verification agent mainly includes a driver and a sequencer. The driver is responsible for the core interrupt detection and verification logic. At the same time, the sequencer of the interrupt verification agent needs to be connected to the virtual sequencer of the verification environment so that it can work in conjunction with the functional stimulus sequence. In addition, the interrupt interface needs to be connected to the device under test (DUT) in the testbench to realize the driving and monitoring of actual hardware signals.

[0022] The following explanation combines module functionality with UVM implementation: For example, the interrupt stimulus module 101 can be implemented by a sequence generator in the UVM environment to generate a stimulus sequence and drive the driver to apply a stimulus to the device under test to activate the interrupt source corresponding to the target interrupt bit of the device under test.

[0023] For example, the function of the interrupt monitoring module 102 can be implemented by a monitor in the UVM environment. The monitor continuously collects the interrupt output signal output by the device under test and transmits the signal status to the verification platform to determine whether the signal has entered the interrupt state indicating that the interrupt has been triggered.

[0024] For example, the function of the interrupt driver module 103 can be implemented by a driver in the UVM environment to drive the interrupt clear signal and the status clear signal, and perform the interrupt clear operation to clear the externally visible interrupt status and the interrupt status information inside the device under test, respectively.

[0025] For example, the interrupt determination module 104 can continuously monitor the state changes of the interrupt output signal through a monitor: if the signal recovers from the interrupt state to the non-interrupt state, the target interrupt source is determined to be the real interrupt source; if the signal remains in the interrupt state, it is determined that there is a non-target interrupt source or an interrupt logic anomaly.

[0026] In some embodiments, the interruption verification transaction configuration information of each of the above modules can be stored in the interruption transaction configuration module 105. Developers can configure the relevant parameters of the interruption verification transaction configuration information through an external interface, and each module can execute the verification process by calling the configuration information through a communication interface. Of course, the storage and calling methods of the interruption verification transaction configuration information can also adopt other implementation forms, and this application embodiment does not limit them.

[0027] The embodiments of this application are as follows: Figure 1 The illustrated method is provided as an example to introduce the system, and is merely an illustrative illustration, not a limitation thereof. The verification platform provided by the embodiments of this application enables hardware interrupt logic isolation verification without relying on the processor. It solves the problem of unobservable interrupt sources through a reverse verification mechanism, improving the universality, reliability, and coverage of the verification.

[0028] The following will combine Figures 3 to 4 The interruption verification method applied to the above-described verification platform, as provided in the embodiments of this application, will be explained and described in detail. These embodiments are only used to explain this application and do not constitute a limitation thereof.

[0029] Figure 3 A flowchart illustrating an exemplary embodiment of this application is shown, demonstrating an interruption verification method that can be executed by the aforementioned verification platform. Figure 3 As shown, the method mainly includes the following steps (S101-S104): S101. Trigger the interrupt source corresponding to the target interrupt bit in the device under test to generate an interrupt event; In this step, the verification platform applies an excitation to the device under test through the interrupt excitation module, triggering the interrupt source corresponding to the target interrupt bit in the device under test, causing it to generate an interrupt event.

[0030] In some embodiments, the method provided in this application further includes the step of configuring an interrupt verification transaction before triggering an interrupt event. In some embodiments, before executing step S101 to trigger an interrupt event from the interrupt source corresponding to the target interrupt bit in the device under test, the method further includes: configuring an interrupt verification transaction, wherein the interrupt verification transaction includes at least interrupt check enable information, and the interrupt check enable information is used to configure the target interrupt bit to be verified as valid, so as to control whether different interrupt sources participate in interrupt verification detection.

[0031] In practice, the device under test (DUT) (such as a chip) can invoke different types of interrupt functions in different application scenarios. Furthermore, each type of interrupt function can correspond to multiple interrupt bits, with each interrupt bit corresponding to one interrupt source. Therefore, verification engineers need to build a suitable verification environment based on actual verification requirements. Then, verification engineers can verify the target interrupt function based on the built verification environment.

[0032] For example, the interrupt check enable information (err_chk_valid) can be a multi-bit configuration vector, where each bit in err_chk_valid corresponds to an interrupt bit in the device under test. Each bit can be either "0" or "1". For instance, an 8-bit interrupt check enable information might have an initial state of "00000000". When a bit is configured as valid (e.g., logic 1), it indicates that the bit is the target interrupt bit for this verification; when configured as invalid (e.g., logic 0), it indicates that the bit is not involved in this verification.

[0033] In some embodiments, step S101 specifically includes: when the target interrupt bit is in a valid state, triggering the interrupt source corresponding to the target interrupt bit to generate an interrupt event according to the interrupt check enable information. For example, if the third bit in the interrupt check enable information is configured to be in a valid state (bit3=1), the verification platform will only trigger the interrupt source corresponding to the third bit in the device under test, generating one interrupt event. This configuration ensures that the verification object is clear, avoids invalid verification, and improves verification reliability.

[0034] S102. Monitor the interrupt output signal of the device under test based on the interrupt event; In this embodiment, the verification platform monitors the interrupt output signal output by the device under test based on the interrupt event generated in step S101 through the interrupt monitoring module.

[0035] In some embodiments, the interrupt verification transaction may further include at least one timing parameter selected from interrupt wait duration, clearing delay duration, and status check duration. Of course, the interrupt verification transaction may also include other types of parameters, and this application embodiment does not limit this. In this embodiment, the interrupt wait duration (wait_time) is used to limit the maximum wait period for interrupt triggering; the clearing delay duration (clr_time) is used to control the time interval between interrupt triggering and triggering the clearing operation; and the status check duration (chk_time) is used to limit the maximum wait period for verifying whether interrupt clearing was successful.

[0036] In some embodiments, the interrupt verification transaction includes an interrupt waiting period. Step S102 specifically includes: within the interrupt waiting period, monitoring whether the interrupt output signal output by the device under test based on the interrupt event changes to an interrupt state. For example, if the interrupt waiting period is configured to 100 clock cycles, the verification platform will continuously monitor the interrupt output signal for 100 clock cycles after the interrupt event is triggered, determining whether it changes to an interrupt state indicating that an interrupt has been triggered. In this embodiment, by setting the interrupt waiting period, quantitative verification of the interrupt trigger response speed can be achieved, avoiding infinite waiting and improving verification execution efficiency and stability.

[0037] For example, during the test execution phase, the interrupt verification sequence needs to run in conjunction with the functional stimulus sequence. First, a specific interrupt scenario is triggered via the functional stimulus sequence, such as the activation of an interrupt source. Then, after entering the execution phase, the interrupt verification agent's driver drives the interrupt check enable signal (err_chk_valid) according to the interrupt verification transaction configuration information, and continuously monitors whether the interrupt output signal is pulled high within the set interrupt wait time. If no interrupt signal is detected to be pulled high within the interrupt wait time, the test is considered to have failed, thus verifying the correctness of the interrupt triggering logic.

[0038] S103. In response to the interrupt output signal becoming interrupted, an interrupt clear command is sent to the device under test so that the device under test performs an interrupt clear operation on the target interrupt bit. In this step, when the interrupt monitoring module detects that the interrupt output signal has changed to an interrupt state, the interrupt driver module of the verification platform will send an interrupt clearing command to the device under test to perform an interrupt clearing operation on the target interrupt bit in the device under test.

[0039] In this embodiment, the interrupt status indicates that the interrupt source corresponding to the target interrupt bit has been triggered. In some embodiments, the interrupt status is represented by a general level state, which includes a high level state and a low level state. For example, if the interrupt output of the device under test is active high, the interrupt status is high; that is, if the interrupt output signal level is detected to be high and greater than a preset active high level threshold, the interrupt output signal is considered to have changed to an interrupt status. If it is active low, the opposite is true. This design is compatible with different hardware interfaces and improves the versatility of the verification method.

[0040] In some embodiments, the interrupt verification transaction further includes a clearing delay duration. Between steps S102 and S103, the method provided in this application embodiment further includes: delaying and waiting according to the clearing delay duration. After detecting that the interrupt output signal has changed to an interrupt state, the interrupt clearing command is sent to the device under test after waiting for the clearing delay duration. For example, if the clearing delay duration is configured to 20 clock cycles, the verification platform will wait for 20 clock cycles after detecting the interrupt state before sending the interrupt clearing command. By setting the clearing delay duration, design requirements such as hardware interrupt retention and state stability can be met, conforming to real hardware behavior and improving verification accuracy.

[0041] For example, the interrupt clearing instruction includes an interrupt clearing signal instruction and a status clearing signal instruction. The interrupt clearing signal instruction is used to drive the interrupt clearing signal (int_clr) to clear the interrupt status visible to the outside of the device under test and ensure that the interrupt signal of the external interface returns to normal. The status clearing signal instruction is used to drive the status clearing signal (status_clr) to clear the interrupt status information inside the device under test and avoid the internal status residue from affecting the subsequent verification process.

[0042] In one application example, when an interrupt output signal is detected to be pulled high, the verification process enters the interrupt clearing phase. The driver first waits for a preset clearing delay (clr_time), and then drives the interrupt clearing signal (int_clr) and the status clearing signal (status_clr) according to the configuration information in the interrupt verification transaction. Subsequently, it continuously monitors whether the interrupt output signal is pulled low within the status check duration (chk_time) window. If the interrupt output signal is successfully pulled low, the interrupt clearing process is considered correct; otherwise, it is determined to have failed.

[0043] In this embodiment, the interrupt clearing operation is executed independently by the interrupt driver module of the verification platform, without relying on the processor (CPU) to execute the interrupt service routine. It does not require reading the status register or writing the clear register through software code, thus achieving isolated verification of the hardware interrupt logic and avoiding interference from software timing and correctness on the verification results.

[0044] S104. Based on the state change of the interrupt output signal after the interrupt clearing operation, determine whether the interrupt source corresponding to the target interrupt bit is the actual interrupt source that generated the interrupt event.

[0045] In this step, the interrupt judgment module of the verification platform determines whether the actual interrupt source of this interrupt event is the interrupt source corresponding to the target interrupt bit in step S101 based on the state change of the interrupt output signal after the interrupt clearing operation.

[0046] In some embodiments, step S104 specifically includes: when the interrupt output signal recovers from the interrupt state to the non-interrupt state after performing an interrupt clearing operation, determining that the interrupt source corresponding to the target interrupt bit is the real interrupt source that generated the interrupt event; when the interrupt output signal remains in the interrupt state, determining that there is a non-target interrupt source or an interrupt logic anomaly.

[0047] In some embodiments, the non-interrupt state, corresponding to the interrupt state, is also represented by a general level state. For example, if the interrupt output of the device under test is active high, the non-interrupt state is a low level state, that is, if the interrupt output signal level is detected to be pulled low and is less than a preset active low level threshold, it is considered that the interrupt output signal has changed to a non-interrupt state; if it is active high, the opposite is true.

[0048] In some embodiments, the interrupt verification transaction includes a status check duration, which, based on the status change of the interrupt output signal after the interrupt clearing operation, includes: monitoring whether the interrupt output signal recovers from an interrupted state to a non-interrupted state within the status check duration. For example, if the status check duration is configured to 50 clock cycles, the verification platform will continuously monitor the signal status for 50 clock cycles after the clearing operation to determine whether it has recovered. By setting the status check duration, a quantitative check of the interrupt clearing speed and effectiveness can be achieved, improving the robustness of the verification process.

[0049] In one application example, assume that the target interrupt bit for this verification is the 5th bit (bit5) of the device under test, the interrupt check enable information (err_chk_valid) is configured as bit5=1 (valid state), the interrupt output signal is active high, the clear delay duration is configured as 15 clock cycles, and the status check duration is configured as 40 clock cycles. After executing step S101, the interrupt source corresponding to bit5 is triggered. In step S102, it is detected that interrupt is pulled high (becoming an interrupt state) within the waiting time. In step S103, after waiting for 15 clock cycles, an interrupt clearing instruction is sent, driving the int_clr and status_clr signals to perform a clearing operation on bit5. In step S104, it is detected that interrupt is pulled low from high level (returning to non-interrupt state) within 40 clock cycles, then it is determined that the interrupt source corresponding to bit5 is the real interrupt source of this interrupt event. If interrupt remains high level (interrupt state) within 40 clock cycles, it indicates that other non-target interrupt sources (such as bit3 and bit6) are triggered at the same time, or the interrupt clearing logic is abnormal (such as the int_clr signal not being effectively driven, the status_clr signal not clearing its internal state, etc.).

[0050] The key innovation of this application lies in its use of a reverse verification mechanism to address the problem of unobservable interrupt sources. Specifically, since interrupt source signals are typically not exposed externally, it's impossible to directly determine which interrupt source triggered the interrupt. Therefore, in this embodiment, indirect verification is performed by simply clearing the bit corresponding to the target interrupt source and observing whether the interrupt output signal disappears. If the interrupt output signal successfully goes low after clearing the corresponding bit, it indicates that the interrupt source was indeed triggered; otherwise, it suggests a possible incorrect interrupt source triggering or a problem with the interrupt logic design. This method effectively verifies the correctness of the interrupt source without accessing internal signals and is entirely independent of the processor (CPU), with the judgment completed solely by the verification platform's hardware logic.

[0051] Based on the above-mentioned basic method and process, this application also provides a variety of extended embodiments to cover more complex verification scenarios.

[0052] In some embodiments, the method provided in this application further includes interrupting the masking function verification. The interrupt verification transaction also includes mask test enable information (mask_test_en), which can be preset to a valid or invalid state. For example, setting the mask test enable information to 1 indicates a valid state. When the mask test enable information is in a valid state, it indicates that the interrupting masking function verification process needs to be executed in this test. Figure 4 A flowchart illustrating the interrupt masking function verification of an exemplary embodiment of this application is shown, which can be executed by the aforementioned verification platform. Figure 4 As shown, the verification process for this interrupt masking function mainly includes the following steps (S201-S202): S201. When the shielding test enable information is in an effective state, configure the interrupt check enable information to be in an invalid state for the target interrupt bit, trigger the interrupt source corresponding to the target interrupt bit in the device under test to generate an interrupt event again, and monitor the interrupt output signal. S202. If the interrupt output signal does not change to an interrupt state, determine that the interrupt masking function is effective; if the interrupt output signal changes to an interrupt state, determine that the interrupt masking function is ineffective.

[0053] For example, if the masking test enable information is in a valid state (e.g., mask_test_en=1), the verification platform will set the interrupt check enable information corresponding to the target interrupt bit to an invalid state (e.g., err_chk_valid of the corresponding bit is set to 0) to simulate the scenario where the bit is masked. At this time, if the interrupt source is triggered again and the interrupt output signal does not change to an interrupt state (e.g., it is not pulled high), it indicates that the masking function is normal; if the signal still changes to an interrupt state (e.g., it is pulled high), it indicates that the masking function is abnormal. Through this embodiment, verification of normal and masking functions can be completed within the same verification framework, improving verification coverage and efficiency.

[0054] In some embodiments, to verify the stability of the interrupt logic, the interrupt verification transaction further includes a loop count (loop_cnt), which indicates the number of times the verification process of steps S101 to S104 is repeated. The method provided in this application embodiment further includes: repeatedly executing the verification process of interrupt triggering, interrupt monitoring, interrupt clearing, and interrupt source determination multiple times according to the loop count, performing a complete interrupt detection and clearing process in each loop, thereby effectively discovering potential state machine anomalies or boundary problems to verify the stability of the interrupt logic.

[0055] For example, if the loop count is configured to 1000 times, the verification platform will repeatedly execute the complete verification process 1000 times. By repeatedly triggering and clearing, potential problems such as interrupted state machine exceptions, boundary errors, and race conditions can be effectively exposed, improving the comprehensiveness of the verification.

[0056] In some embodiments, the method provided in this application further includes: simulating processor interrupt handling behavior through an extensible interrupt handling interface in response to an interrupt output signal changing to an interrupt state. The processor interrupt handling behavior includes at least one of register access, interface signal driving, state recovery, or reset. For example, the verification platform can simulate operations such as reading the status register and writing to the clear register performed by the processor after receiving an interrupt through the extensible interface, to more closely resemble the operating scenario of a real system. This embodiment, based on pure hardware verification, is compatible with system-level verification scenarios, balancing the flexibility of verification with the realism of the system.

[0057] To address the scenario where actual chip interrupt handling relies on the processor (CPU) to execute interrupt service routines, this application also provides an extensible interrupt handling function interface. Within this function, verification personnel can simulate the processor's (CPU's) interrupt handling behavior, such as register access or interface signal driving, according to the design specifications of specific modules. By connecting relevant interface signals to the interrupt verification proxy, modeling and verification of complex interrupt handling paths can be achieved. If some interrupts are handled as reset operations, the processing logic can be simplified, and verification can be completed simply by clearing the interrupt signal.

[0058] In some embodiments, for cases involving multiple interrupt sources, the interrupt verification method described above in this application can be applied to each interrupt source based on the verification platform. For example, in terms of test case construction, for a device under test containing multiple interrupt sources, corresponding verification test cases can be constructed for each interrupt source. Typically, each interrupt source requires at least two types of test cases: one type to verify the normal triggering and clearing process, and another type to verify whether the masking function is effective. For cases where multiple interrupt sources trigger simultaneously, multiple bits of the target interrupt bit can be configured according to the design specifications to cover complex interrupt combination scenarios.

[0059] The interrupt verification method provided in this application can accurately locate unobservable interrupt sources through a reverse verification mechanism. It can complete the automatic verification of interrupt triggering, clearing, and interrupt sources without relying on the processor, thereby improving the universality, reliability, and coverage of verification.

[0060] like Figure 1 and Figure 2 As shown, the verification platform 100 provided in this application embodiment includes: an interrupt activation module 101, an interrupt monitoring module 102, an interrupt driving module 103, an interrupt judgment module 104, and an interrupt transaction configuration module 105. The verification platform 100 provided in this application embodiment can achieve the following: Figures 3 to 4 All or part of the contents of any of the embodiments shown. The following is only a brief description of other functions of the verification platform 100. For other matters not covered, please refer to the relevant descriptions in the above-described interruption verification method. The embodiments of the verification platform 100 correspond to the embodiments of the above-described interruption verification method. All implementation processes and methods of the above-described method embodiments can be applied to the embodiments of the verification platform 100 and can achieve the same technical effect.

[0061] In some embodiments, the interrupt determination module 104 is used to determine whether the interrupt source corresponding to the target interrupt bit is the real interrupt source that generates the interrupt event based on the state change of the interrupt output signal after the interrupt clearing operation is performed. This includes: determining that the interrupt source corresponding to the target interrupt bit is the real interrupt source that generates the interrupt event when the interrupt output signal recovers from the interrupt state to the non-interrupt state after the interrupt clearing operation is performed; and determining that there is a non-target interrupt source or an interrupt logic abnormality when the interrupt output signal remains in the interrupt state.

[0062] In some embodiments, the interrupt transaction configuration module 105 is used to configure an interrupt verification transaction. The interrupt verification transaction includes at least interrupt check enable information, which is used to configure the target interrupt bit to be verified to be in a valid state.

[0063] In some embodiments, the interrupt activation module 101 is used to trigger the interrupt source corresponding to the target interrupt bit in the device under test to generate an interrupt event, including: when the target interrupt bit is in an active state, triggering the interrupt source corresponding to the target interrupt bit to generate an interrupt event according to the interrupt check enable information.

[0064] In some embodiments, the interrupt monitoring module 102 is used to monitor the interrupt output signal of the device under test based on the interrupt event, including: monitoring whether the interrupt output signal of the device under test based on the interrupt event changes to an interrupt state within the interrupt waiting time.

[0065] In some embodiments, the interrupt driver module 103 is further configured to delay waiting according to the clearing delay duration after the interrupt output signal changes to an interrupt state and before sending an interrupt clearing command to the device under test.

[0066] In some embodiments, the interrupt determination module 104 is used to monitor whether the interrupt output signal has recovered from the interrupt state to the non-interrupt state based on the state change of the interrupt output signal after the interrupt clearing operation is performed.

[0067] In some embodiments, such as Figure 2 As shown, the verification platform 100 also includes a shielding test module 106, and the interrupt verification transaction also includes shielding test enable information. The shielding test module 106 is used to trigger the interrupt transaction configuration module 105 to configure the interrupt check enable information to the target interrupt bit as invalid when the shielding test enable information is in an effective state, and then trigger the interrupt excitation module 101 to trigger the interrupt source corresponding to the target interrupt bit in the device under test to generate an interrupt event. The interrupt monitoring module 102 also monitors the interrupt output signal. The shielding test module 106 is also used to determine that the interrupt shielding function is effective when the interrupt output signal does not change to an interrupt state, and to determine that the interrupt shielding function is ineffective when the interrupt output signal changes to an interrupt state.

[0068] In some embodiments, the interrupt verification transaction further includes a loop count, which indicates the number of times the process of repeatedly executing the process from triggering the device under test to generate an interrupt event to determining whether the interrupt source corresponding to the target interrupt bit is the actual interrupt source that generated the interrupt event is repeated.

[0069] In some embodiments, the interrupt driver module 103 is further configured to simulate processor interrupt handling behavior through an extensible interrupt handling interface in response to an interrupt output signal changing to an interrupt state. The processor interrupt handling behavior includes at least one of register access, interface signal driving, state recovery, or reset.

[0070] The verification platform provided in this application embodiment enables hardware interrupt logic isolation verification without relying on the processor. It solves the problem of unobservable interrupt sources through a reverse verification mechanism, thereby improving the universality, reliability and coverage of verification.

[0071] Figure 5 A structural block diagram of an electronic device 1000 illustrating an exemplary embodiment of this application is shown. The electronic device 1000 can be implemented as the verification platform described above, which can be configured in electronic devices such as smartphones, tablets, laptops, desktop computers, smartwatches, televisions, or servers.

[0072] Typically, electronic device 1000 includes a processor 1001 and a memory 1002.

[0073] Processor 1001 may include one or more processing cores, such as a quad-core processor, a deca-core processor, etc. Processor 1001 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1001 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1001 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1001 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0074] The memory 1002 may include one or more computer-readable storage media, which may be non-transitory. The memory 1002 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1002 is used to store at least one instruction, which is executed by the processor 1001 to implement all or part of the steps in the interrupt verification method shown in the method embodiments of this application.

[0075] Those skilled in the art will understand that Figure 5 The structure shown does not constitute a limitation on the electronic device 1000, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0076] In one exemplary embodiment, a readable storage medium is also provided, which stores a program or instructions that, when executed by a processor, implement all or part of the steps in the interrupt verification method described above. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0077] In one exemplary embodiment, a computer program product is also provided, comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform the aforementioned... Figures 3 to 4 All or part of the steps of the interrupt verification method shown in any embodiment.

[0078] It should be understood that the training and prediction processes of the AI ​​models involved in the various embodiments of this specification all adhere to multiple legal and compliant principles, including legal data sources, compliant data content, compliant data governance, compliant training objectives and schemes, compliant training processes, compliant training environments and tools, and compliant ethical verification of training results, and comply with relevant laws and regulations. Among these: Data source legitimacy: All datasets used for AI model training were obtained through legal means, covering three categories: publicly authorized data, data authorized by partners, and self-collected compliant data. Publicly authorized data originates from compliant data sources that comply with relevant open-source agreements, with complete copyright attribution and authorization scope clearly marked, and no unauthorized open-source code or data reuse. Data authorized by partners has been subject to formal data usage agreements, clearly defining the scope, duration, and confidentiality obligations, and possessing a complete authorization chain. For self-collected data involving personal information, strict informed consent procedures have been followed, and anonymization processes (including but not limited to field masking, feature anonymization, and differential privacy technology) have been implemented to remove personally identifiable information, fully complying with relevant laws and regulations.

[0079] Data content compliance: The AI ​​model's dataset undergoes multiple screenings and cleaning processes to remove all non-compliant information and ensures that there is no illegal acquisition or use of genetic resources. For data in sensitive areas, an additional privacy-preserving computation module (including federated learning and secure multi-party computation technology) is used to ensure that the data is "usable but not visible," avoiding compliance risks during the original data transmission process and ensuring that the data application scenarios and uses comply with public order and good morals and industry regulatory requirements.

[0080] Data governance norms: A complete data traceability system is established during the AI ​​model training process to automatically record the source, collection time, annotation process, cleaning rules, and permission allocation of training data, generating traceable compliance reports to ensure that the data is verifiable throughout its entire lifecycle. The dataset annotation process for AI models is completed by a professional human R&D team, clearly defining the proportion of human creative contributions, avoiding reliance on AI-generated data that has not undergone substantial human modification, and complying with relevant laws and regulations.

[0081] Training objectives and plans are compliant: The AI ​​model training objective focuses on the industry knowledge system of large industry models. The training scheme and the final output results do not violate any mandatory provisions of laws and administrative regulations, do not harm the public interest or the legitimate rights and interests of others, and do not pose any potential risks of being used for illegal activities, privacy infringement, or public safety disruption. The training strictly adheres to the ethical principle of "intelligent for good".

[0082] Training process compliance: A closed-loop training framework is adopted to ensure compliance and controllability of the training process. The specific process is as follows: First, training samples are obtained through compliant data sources. After the aforementioned data cleaning and desensitization processes, the samples are input into the neural network model to generate preliminary training results. Second, an expert system is introduced to verify the preliminary results. Based on preset rules and human expert experience, the feasibility of the results is evaluated, and outputs that may pose ethical risks or compliance hazards are corrected (such as removing decision-making logic that violates public order and good morals, and adjusting model parameters that do not comply with safety regulations). Finally, the loss function weights are dynamically optimized based on expert system feedback to strengthen the model's learning of compliant results, avoid overfitting errors or non-compliant labels, and form a closed-loop control of "data input - model training - expert verification - parameter optimization - result feedback" to ensure that the entire training process complies with relevant laws and regulations.

[0083] Training environment and tool compliance: AI model training is implemented using nationally licensed chips and a compliant training platform. All open-source frameworks and components used in the training process have obtained their corresponding licenses, and copyright statements and patent citation information are fully retained, with no instances of infringement or reuse. The training environment is built using virtual devices (containers / virtual machines) with fixed random seeds and initial parameter configurations to ensure the reproducibility of the training process. Furthermore, through access control and operation log recording, risks such as data leakage and parameter tampering during training are prevented, ensuring the security and compliance of the training process.

[0084] Training results ethical verification compliance: After the model is trained, it undergoes additional third-party ethical compliance assessment and algorithm filing review to verify that the model output does not violate social morality or harm public interests. For potentially sensitive scenarios, a dedicated result verification mechanism is established to ensure that the model always complies with relevant laws and regulations in practical applications.

[0085] In summary, the data and training process used in the AI ​​model in this specification strictly comply with relevant regulations and do not violate any laws, social ethics, public interests, or regulations on the use of genetic resources. Therefore, it fully meets the compliance requirements for patent authorization.

[0086] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0087] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. An interruption verification method, characterized in that, Applications in verification platforms include: Trigger the interrupt source corresponding to the target interrupt bit in the device under test to generate an interrupt event; Monitor the interrupt output signal output by the device under test based on the interrupt event; In response to the interrupt output signal becoming an interrupt state, an interrupt clearing command is sent to the device under test (DUT) to cause the DUT to perform an interrupt clearing operation on the target interrupt bit; wherein, the interrupt state indicates that the interrupt source corresponding to the target interrupt bit has been triggered; Based on the state change of the interrupt output signal after the interrupt clearing operation, determine whether the interrupt source corresponding to the target interrupt bit is the actual interrupt source that generated the interrupt event.

2. The method according to claim 1, characterized in that, The step of determining whether the interrupt source corresponding to the target interrupt bit is the actual interrupt source that generated the interrupt event based on the state change of the interrupt output signal after the interrupt clearing operation includes: When the interrupt output signal recovers from the interrupt state to the non-interrupt state after the interrupt clearing operation is performed, the interrupt source corresponding to the target interrupt bit is determined to be the real interrupt source that generated the interrupt event; If the interrupt output signal maintains the interrupt state, it is determined that there is a non-target interrupt source or an interrupt logic anomaly.

3. The method according to claim 2, characterized in that, The interrupted state and the non-interrupted state are represented by a general level state, which includes a high level state and a low level state.

4. The method according to claim 1, characterized in that, Before triggering an interrupt event from the interrupt source corresponding to the target interrupt bit in the device under test, the method further includes: Configure an interrupt verification transaction, which includes at least interrupt check enable information, which is used to configure the target interrupt bit to be verified to be in a valid state.

5. The method according to claim 4, characterized in that, The triggering of an interrupt event by the interrupt source corresponding to the target interrupt bit in the device under test includes: When the target interrupt bit is in an active state, the interrupt source corresponding to the target interrupt bit is triggered to generate an interrupt event based on the interrupt check enable information.

6. The method according to claim 4, characterized in that, The interrupted verification transaction also includes at least one timing parameter among interruption waiting time, clearing delay time, and status check time.

7. The method according to claim 6, characterized in that, The monitoring of the interrupt output signal output by the device under test based on the interrupt event includes: monitoring whether the interrupt output signal output by the device under test based on the interrupt event changes to the interrupt state within the interrupt waiting time.

8. The method according to claim 6, characterized in that, After the interrupt output signal becomes interrupted, and before sending an interrupt clearing command to the device under test, the method further includes: performing a delay wait according to the clearing delay duration.

9. The method according to claim 6, characterized in that, The state change based on the interrupt output signal after performing the interrupt clearing operation includes: During the state check duration, monitor whether the interrupt output signal recovers from the interrupt state to the non-interrupt state.

10. The method according to claim 4, characterized in that, The interruption verification transaction also includes masking the test enable information, and the method further includes: When the shielding test enable information is in an active state, the interrupt check enable information is configured to have the target interrupt bit in an inactive state, and the interrupt source corresponding to the target interrupt bit in the device under test is triggered to generate an interrupt event again, and the interrupt output signal is monitored. If the interrupt output signal does not change to the interrupt state, the interrupt masking function is determined to be effective; if the interrupt output signal changes to the interrupt state, the interrupt masking function is determined to be ineffective.

11. The method according to claim 4, characterized in that, The interrupt verification transaction also includes a loop count, which indicates the number of times the process of repeatedly executing the process from triggering the device under test to generate the interrupt event to determining whether the interrupt source corresponding to the target interrupt bit is the actual interrupt source that generated the interrupt event is repeated.

12. The method according to claim 1, characterized in that, The method further includes: In response to the interrupt output signal changing to the interrupt state, the processor interrupt handling behavior is simulated through the extensible interrupt handling interface, the processor interrupt handling behavior including at least one of register access, interface signal driving, state recovery or reset.

13. A verification platform, characterized in that, include: The interrupt trigger module is used to trigger the interrupt source corresponding to the target interrupt bit in the device under test to generate an interrupt event; An interrupt monitoring module is used to monitor the interrupt output signal output by the device under test based on the interrupt event; An interrupt driver module is configured to send an interrupt clear command to the device under test (DUT) in response to the interrupt output signal changing to an interrupt state, so that the DUT performs an interrupt clear operation on the target interrupt bit; wherein, the interrupt state indicates that the interrupt source corresponding to the target interrupt bit has been triggered; The interrupt determination module is used to determine whether the interrupt source corresponding to the target interrupt bit is the actual interrupt source that generated the interrupt event, based on the state change of the interrupt output signal after the interrupt clearing operation.

14. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions being executed by the processor to implement the steps of the interrupt verification method as described in any one of claims 1 to 12.

15. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the interrupt verification method as described in any one of claims 1 to 12.

16. A computer program product, characterized in that, The computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, implement the steps of the interrupt verification method as described in any one of claims 1 to 12.

Images