Interruption control method and apparatus, device, program, and readable storage medium

Abstract

The present application relates to the technical field of computers, and provides an interruption control method and apparatus, an electronic device, a computer program, and a computer-readable storage medium. The method comprises: acquiring a first execution result of a design under test for a benchmark test program and a second execution result of a software emulator for the benchmark test program; and when an interruption condition is satisfied, interrupting the operation of the design under test, wherein the interruption condition comprises at least one of the following: the first execution result does not match the second execution result; a hardware buffer zone corresponding to the design under test is full; the hardware buffer zone is used for recording operation data of the design under test; a software buffer zone corresponding to the software emulator is empty; and the software buffer zone is used for recording operation data of the software emulator. According to embodiments of the present application, in hardware verification, the execution results of the design under test and the software emulator can be automatically compared and checked, and interruption can be automatically triggered, thereby achieving a better debugging capability.

Description

Interrupt control method, device, equipment, program and readable storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on October 17, 2023, with application number 202311340376.2 and application name “A method, device, electronic device and readable storage medium for interrupt control”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of computer technology, and in particular to an interrupt control method, device, electronic device computer program, and computer-readable storage medium. Background Art

[0004] FPGA-accelerated verification and debugging technologies have been actively researched over the past few decades. FPGA-accelerated simulators are often used for architectural design and spatial exploration. For example, RAMP Gold is a cycle-accurate, full-system simulator running on FPGAs that separates the timing and functional models of a given instruction set architecture (ISA) to achieve greater flexibility while maintaining performance. FireSim provides cycle-accurate simulation accelerated by FPGAs and is deployed on AWS EC2 F1, improving usability. FPGAs can also be used to accelerate verification in specific areas such as machine learning, memory, and the Internet of Things. In prototype verification, specific FPGA features can also be leveraged to accelerate the debugging process. For example, readback technology can be used to create checkpoints during operation and move the state information of the design under test to an external software simulator, such as Model Sim, for further debugging. However, related technologies primarily focus on how to stop the design under test to obtain state information, but do not study when to intelligently stop the design under test.

[0005] Summary of the Invention

[0006] The embodiments of the present application provide an interrupt control method, apparatus, electronic device computer program, and computer-readable storage medium to solve the problem in the prior art that checkpoints or snapshot points need to be manually set and the design under test cannot be automatically stopped.

[0007] In a first aspect, an embodiment of the present application provides an interrupt control method, the method comprising:

[0008] Obtaining a first execution result of a design under test on a benchmark test program and a second execution result of a software simulator on the benchmark test program; the design under test runs in a programmable logic area of ​​a programmable logic chip, and the software simulator runs in a processing system of the programmable logic chip;

[0009] When an interruption condition is met, interrupting the operation of the design under test;

[0010] The interruption condition includes at least one of the following:

[0011] The first execution result does not match the second execution result;

[0012] The hardware buffer corresponding to the design to be tested is full; the hardware buffer is used to record the operation data of the design to be tested;

[0013] The software buffer corresponding to the software simulator is empty; the software buffer is used to record the running data of the software simulator.

[0014] In a second aspect, an embodiment of the present application provides an interrupt control device, the device comprising:

[0015] an acquisition module, configured to acquire a first execution result of a design under test on a benchmark test program and a second execution result of a software simulator on the benchmark test program; the design under test runs in a programmable logic region of a programmable logic chip, and the software simulator runs in a processing system of the programmable logic chip;

[0016] A first interrupt module, configured to interrupt the operation of the design under test when an interrupt condition is met;

[0017] The interruption condition includes at least one of the following:

[0018] The first execution result does not match the second execution result;

[0019] The hardware buffer corresponding to the design to be tested is full; the hardware buffer is used to record the operation data of the design to be tested;

[0020] The software buffer corresponding to the software simulator is empty; the software buffer is used to record the running data of the software simulator.

[0021] In a third aspect, an embodiment of the present application provides an electronic device, including a processor;

[0022] a memory for storing instructions executable by the processor;

[0023] The processor is configured to execute the instructions to implement the method of the first aspect.

[0024] In a fourth aspect, an embodiment of the present application provides a computer program, comprising a computer-readable code, which, when executed on a computing and processing device, causes the computing and processing device to execute the method of the first aspect.

[0025] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program as described in the fourth aspect. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the method of the first aspect.

[0026] In summary, the interrupt control method provided in the embodiment of the present application can determine when to stop the design under test during the hardware verification of the design under test based on whether the first execution result of the benchmark test program on the design under test matches the second execution result of the benchmark test program on the software simulator, and the data storage status of the hardware buffer and the software buffer. There is no need for the tester to manually set checkpoints or breakpoints. Compared with traditional FPGA prototypes that only capture a valid number of signals based on set checkpoints or snapshot points, the FPGA chip using the interrupt control method provided in the embodiment of the present application can automatically compare and check the execution results of the design under test and the software simulator during hardware verification, and automatically trigger an interrupt, which has better debugging capabilities.

[0027] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions in the embodiments of the present application, 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 application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0029] FIG1 is a flowchart of an embodiment of an interrupt control method of the present application;

[0030] FIG2 is a schematic diagram of the architecture of a differential verification framework of the present application;

[0031] FIG3 is a structural block diagram of an interrupt control device of the present application;

[0032] FIG4 schematically shows a block diagram of a computing and processing device for executing the method according to the present application;

[0033] FIG5 schematically illustrates a storage unit for holding or carrying program codes for implementing the method according to the present application;

[0034] FIG6 is a block diagram of an electronic device provided in an embodiment of the present application. Specific embodiments

[0035] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0036] The terms "first", "second", etc. in the specification and claims of this application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, the term "and / or" in the specification and claims is used to describe the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0037] 1 , there is shown a flowchart of an embodiment of an interrupt control method of the present application. The method may specifically include the following steps:

[0038] Step 101: Obtain a first execution result of a design under test on a benchmark test program and a second execution result of a software simulator on the benchmark test program.

[0039] Step 102: When an interruption condition is met, interrupt the operation of the design to be tested.

[0040] The interruption condition includes at least one of the following:

[0041] A1. The first execution result does not match the second execution result;

[0042] A2. The hardware buffer corresponding to the design under test is full; the hardware buffer is used to record the operating data of the design under test;

[0043] A3. The software buffer corresponding to the software simulator is empty; the software buffer is used to record the running data of the software simulator.

[0044] It should be noted that the design under test (DUT) refers to the circuit design or implementation to be tested in prototype verification. A software simulator (EMU) is a software program written in a high-level language to simulate the operating state of a CPU. In an embodiment of the present application, the software simulator serves as a reference model for the design under test and runs in the processing system of a programmable logic chip (Field Programmable Gate Array, FPGA). An FPGA chip (or FPGA system on chip) not only includes a programmable gate array circuit, but also includes one or more on-chip processors. Among them, the programmable gate array circuit is generally referred to as programmable logic (PL); the on-chip processor is generally an ARM processor, referred to as a processing system (PS). In an embodiment of the present application, the design under test runs in the programmable logic area of ​​the programmable logic chip, and the software simulator runs in the processing system of the programmable logic chip.

[0045] The benchmark program includes a series of programs used to test the performance or correctness of the design under test. In the embodiment of the present application, the design under test and the software simulator can be run on the FPGA chip. The design under test and the software simulator respectively execute the same benchmark program. The first execution result of the design under test and the second execution result of the software simulator are compared to determine whether there are errors in the design under test, and then debug and repair the errors.

[0046] It should be noted that, in an embodiment of the present application, the first execution result may include the CPU state information generated when the design under test is running, and the second execution result may include the CPU state information generated when the software simulator is running. The design under test and the software simulation run the same benchmark program, and the design under test and the software simulator can maintain instruction-level operation synchronization through the on-chip bus. Among them, the CPU state information may include the value of the program pointer, the value of the general register, etc. In actual applications, the specific content of the CPU state information can be specified according to the actual situation and specific verification requirements.

[0047] During the verification process, if at least one of the interrupt conditions A1 to A3 is met, the operation of the design under test can be interrupted.

[0048] Regarding item A1, if the first and second execution results do not match, it indicates an error in the design under test. In this case, the design under test needs to be interrupted to debug and repair potential design flaws. For example, a hardware snapshot mechanism can be used to quickly save and convert state information at the error site, import it into simulation software, and use the simulation software for fine-grained debugging.

[0049] Regarding item A2, if the hardware buffer corresponding to the design under test is full, it is no longer possible to write the running data of the design under test into the hardware buffer. Therefore, it is necessary to interrupt the design under test and wait for the hardware buffer to release the recorded data.

[0050] For item A3, if the software buffer corresponding to the software simulator is empty, it is impossible to compare the execution results of the design under test and the software simulator. It is necessary to interrupt the design under test and wait for the software to simulate its execution of the instructions in the benchmark program and write the running data into the software buffer.

[0051] In the embodiment of the present application, based on the interrupt conditions corresponding to A1 to A3, the verification platform or verification system can automatically determine when to stop the design under test, without the need for the tester to manually set checkpoints or breakpoints.

[0052] As an example, the interrupt control method provided in the embodiments of the present application can be applied to a differential verification framework. Referring to Figure 2, a schematic diagram of the architecture of a differential verification framework provided in the present application is shown. As shown in Figure 2, the differential verification framework includes hardware and software facilities. The hardware facilities run in the programmable logic area of ​​the FPGA chip, also known as the PL side, and the software facilities run in the processing system of the FPGA chip, also known as the PS side. The hardware facilities may specifically include: a checker, a snapshot, and an interrupt controller. The checker is used to collect test data and implement testing of the design under test. The snapshot and interrupt controller are used to create snapshots of the design under test and initiate interrupts. The software facilities may specifically include a memory controller, a software simulator, and a driver. The memory controller enables memory access by the design under test and the software simulator, as well as access by the design under test to external devices. The driver can monitor and retrieve key signals and data from registers, compress data packets for more efficient data transmission, manage access by the design under test to external devices, manage data communication between the PL and PS sides of the FPGA chip, and handle interrupt requests from the PL side, among other functions. It should be noted that the external devices in this application refer to devices that are mounted on the FPGA chip and belong neither to the PL side nor the PS side, such as Double Data Rate Synchronous Dynamic Random Access Memory (DDR), Universal Asynchronous Receiver / Transmitter (URAT), etc.

[0053] Furthermore, in the differential verification framework shown in Figure 2, the software simulator is designed for a given ISA, such as RISC-V, and abstracts the hardware implementation details by providing only a functional model for executing instructions. It should be noted that the software simulator is independent of the actual hardware implementation; therefore, when the hardware DUT is modified, the software simulator does not need to be replaced as long as the underlying ISA remains unchanged. Even for an instruction set architecture like RISC-V that can incorporate instruction extensions, supporting extended instructions in a software simulator is simpler than in an actual hardware implementation. By using the differential verification framework shown in Figure 2 to verify the design under test, automatic simulation environment reconstruction can be achieved directly in the software simulator, eliminating the need to build a complete software test platform. This reduces the workload of initial platform construction and helps improve verification efficiency.

[0054] Furthermore, the differential verification framework may also include an infrastructure module, which is used to provide a shell structure with placeholders for the design under test (DUT) to enable interaction between the DUT and the checker, snapshot and interrupt controller, software simulator, external devices, etc. For example, the infrastructure module may include two external interfaces: an AXI-MEM bus connected to the external memory, and an AXI-MMIO bus connected to other external devices such as UART and GPIO. The infrastructure module is responsible for maintaining communication between the PL and PS on the FPGA chip, and can generally transmit three types of data: execution results from the software simulator, instructions and data from external devices (such as DDR), and interrupt signals for interrupt testing generated by the snapshot and interrupt controller.

[0055] The checker can achieve the following functions: for the design under test and the software simulator, monitor the specified key signals, and dynamically collect the execution results of the design under test and the software simulator at runtime; support instruction-level synchronization between the design under test and the software simulator to ensure that the execution results of the two are correctly compared after the design under test and the software simulator execute each instruction of the benchmark program; compare the first execution result of the benchmark program of the design under test with the second execution result of the software simulator to determine whether there is a mismatch between the first execution result and the second execution result, and issue an exception reminder when the first execution result and the second execution result do not match, etc.

[0056] The checker is configured with a hardware buffer for the design under test, which is used to record the running data of the design under test; and a software buffer is also configured for the software simulator, which is used to record the running data of the software simulator.

[0057] In a possible implementation scenario, the design under test loads the benchmark program from the memory and executes it, and writes the first execution result to the hardware buffer after each instruction is executed. After startup, the software simulator executes the benchmark program, and writes the second execution result to the software buffer through the driver after each execution. The checker performs a differential comparison on the first execution result and the second execution result. If the first execution result and the second execution result do not match, that is, the design under test and the software simulator have different execution results for the same instruction in the benchmark program, then the checker can interrupt the operation of the design under test and the software simulator. In addition, if the hardware buffer is full and / or the software buffer is empty, the checker can also interrupt the operation of the design under test.

[0058] If the tester needs to set a checkpoint or snapshot point to monitor specific signals or status information, the snapshot and interrupt controller in Figure 2 can be used to set the checkpoint or snapshot point so that after the design under test and the software simulator run to the checkpoint or snapshot point, the operation of the design under test and the software simulator can be interrupted, and the hardware snapshot mechanism can be started to save the snapshot of the status information of the FPGA chip, such as the status information of the fly-by, on-chip memory, DSP, external devices, etc., so that simulation can be performed using the simulation software.

[0059] In an optional embodiment of the present application, in step 102, interrupting the operation of the design under test when an interruption condition is met includes:

[0060] Step S11: when the hardware buffer corresponding to the design to be tested is full, interrupt the operation of the design to be tested, wait for the hardware buffer to release data, and start an interrupt timer;

[0061] Step S12: When the value of the interrupt timer is greater than or equal to a preset value, checking whether there is an idle area in the hardware buffer;

[0062] Step S13: if there is an idle area in the hardware buffer, resuming the operation of the design to be tested;

[0063] Step S14: When there is no free area in the hardware buffer, continue to interrupt the operation of the design to be tested and wait for the hardware buffer to release data.

[0064] If the hardware buffer corresponding to the design under test is full, it is no longer possible to write the running data of the design under test into the hardware buffer. It is necessary to interrupt the running of the design under test and wait for the hardware buffer to release the data.

[0065] In this embodiment of the present application, the checker does not need to frequently check whether there is free space in the hardware buffer. Instead, it only needs to check whether there is free space in the hardware buffer when the value of the interrupt timer is greater than or equal to a preset value. Then, if there is free space in the hardware buffer, the operation of the design under test is resumed; if there is still no free space in the hardware buffer, the operation of the design under test is interrupted again and waits for the hardware buffer to release data.

[0066] It is understandable that the smaller the free storage space of the hardware buffer is, the more frequently the design to be tested will be interrupted due to the full hardware buffer, and frequent interruptions will increase hardware overhead and be prone to errors. Therefore, in an embodiment of the present application, an interrupt timer can be used to control the shortest time limit for the interruption of the design to be tested due to a full hardware buffer. For example, when the initial value of the interrupt timer is 0 and forward timing is performed, a larger preset value is set; or, if the interrupt timer uses a countdown method, a larger initial value can be set. As an example, the interrupt timer can be a counter with an initial value of 0. The count value of the counter is increased by 1 after each clock cycle. The preset value can be N, where N is a positive integer, for example, N=32.

[0067] Optionally, the method further includes: interrupting the operation of the software simulator when it is detected that the software buffer corresponding to the software simulator is full.

[0068] If it is detected that the software buffer corresponding to the software simulator is full, it is no longer possible to continue writing the running data of the software simulator into the software buffer. It is necessary to interrupt the running of the software simulator and wait for the software buffer to release the data.

[0069] In another optional embodiment of the present application, in step 102, when an interruption condition is met, interrupting the operation of the design under test includes:

[0070] Step S21: If the first execution result does not match the second execution result, interrupting the operation of the design under test and the software simulator;

[0071] Step S22: triggering a hardware snapshot mechanism to save the status information of the programmable logic chip;

[0072] Step S23: importing the state information into simulation software for simulation, so as to debug and repair the design to be tested.

[0073] If the first execution result of the design under test doesn't match the second execution result of the software simulator, it indicates an error in the design under test, and the design needs to be interrupted. Then, the hardware snapshot mechanism is triggered to save the FPGA chip's state information. This saved state information is then imported into the simulation software for simulation, allowing debugging and repair of the design under test.

[0074] Taking the differential verification framework shown in Figure 2 as an example, if the checker determines that the first execution result of the design under test does not match the second execution result of the simulator, it sends an interrupt signal to the design under test and the simulator. At the same time, the checker passes the interrupt signal to the controller. After both the design under test and the simulator are safely paused, the controller creates a snapshot of the entire FPGA chip. This snapshot contains the current design state, such as the values ​​of on-chip registers, the contents of BRAM, data in distributed memory, the contents of external devices, and so on.

[0075] Optionally, in order to reduce overhead, instead of reading the entire external device, such as DDR, only the address space pre-allocated for the external device may be read.

[0076] In an optional embodiment of the present application, in step 102, interrupting the operation of the design under test when an interruption condition is met includes:

[0077] Step S31: When at least two of the interruption conditions are met, determine a target interruption condition according to the priority of each interruption condition;

[0078] Step S32: performing interrupt control on the design under test according to the interrupt management mechanism corresponding to the target interrupt condition.

[0079] During the verification process of the design under test, multiple interrupt conditions corresponding to items A1 to A3 in the embodiment of the present application may be met at the same time. When different interrupt conditions are met at the same time, a target interrupt condition can be determined based on the priority of each interrupt condition, and then the interrupt control of the design under test can be performed according to the interrupt management mechanism corresponding to the target interrupt condition.

[0080] It can be understood that in the embodiment of the present application, generally the priority of A1 is higher than the priority of A2 which is higher than the priority of A3.

[0081] For example, if the interrupt conditions corresponding to A1 and A2 are simultaneously met, A1 is determined as the target interrupt condition, and interrupt control is performed on the design under test according to the interrupt management mechanism corresponding to steps S21 to S23. If the interrupt conditions corresponding to A2 and A3 are simultaneously met, A2 is determined as the target interrupt condition, and interrupt control is performed on the design under test according to the interrupt management mechanism corresponding to steps S11 to S14.

[0082] In an optional embodiment of the present application, before obtaining the first execution result of the design under test on the benchmark test program and the second execution result of the software simulator on the benchmark test program, the method further includes:

[0083] Step S41: When it is detected that the execution result of the first instruction in the benchmark test program by the design under test is written into the hardware buffer, an interrupt signal is sent to the design under test to suspend the operation of the design under test;

[0084] Step S42: When it is detected that the software simulator writes the execution result of the first instruction into the software buffer, an interrupt release signal is sent to the design under test to trigger the design under test to continue executing the instructions in the benchmark test program.

[0085] During the verification process, the design under test loads the benchmark program from the memory and executes it. After each instruction is executed, the first execution result is written to the hardware buffer. The software simulator starts after receiving the user's startup command and begins to execute the benchmark program. Normally, while the hardware simulator is executing the first instruction and writing the execution result into the hardware buffer, the software simulator has not yet completed the first instruction. At this time, the software buffer is empty, triggering an interrupt to the design under test and waiting for initial synchronization. When it is detected that the software simulator writes the execution result of the first instruction into the software buffer, that is, the software buffer is filled with the first set of running data, the interrupt of the design under test can be released at this time, triggering the design under test to continue executing the instructions in the benchmark program and complete the initial synchronization.

[0086] For example, in the differential verification framework shown in FIG2 , once the design under test is running, the running data will be written to the hardware buffer in the checker. The checker will check whether the software buffer is empty. If the software buffer is empty, it means that the software simulator has not yet started. The checker can send an interrupt signal to the design under test to suspend the running of the design under test and wait for initial synchronization. When the software simulator is started, the checker obtains the running data of the software simulator through the driver and writes the obtained running data into the software buffer. Once the first set of data is filled in the software buffer, the checker can send an interrupt release signal to the design under test, triggering the design under test to continue running and complete the initial synchronization.

[0087] In an optional embodiment of the present application, the method further includes:

[0088] Step S51: when it is detected that the design under test accesses an external device, interrupting the operation of the software simulator;

[0089] Step S52: When it is detected that the access to the design under test is completed, the operation of the software simulator is resumed.

[0090] When the DUT attempts to access external devices, such as DDR and UART, synchronization between the DUT and the simulator may be disrupted because the simulator does not provide a cycle-accurate model of such accesses. To address this issue, the DUT's access to external devices can be monitored during operation. Once an access to an external device is detected, a special interrupt to the simulator can be triggered to pause its execution and wait for the access to complete. Once the DUT's access to the external device is complete, the interrupt to the simulator can be released, resuming the simulator's operation.

[0091] Furthermore, the data read by the design under test from the external device can be transferred to the software simulator to restore the synchronous operation of both parties.

[0092] Optionally, step S52 interrupts the operation of the software simulator when it is detected that the design under test accesses an external device, including: when it is detected that the design under test accesses an external device, if the design under test outputs data through the first transceiver, interrupting the operation of the software simulator and interrupting the data output of the second transceiver of the software simulator until the first transceiver is idle, and then restoring the data output of the second transceiver.

[0093] When verifying the design under test, if the design under test accesses external devices and a transceiver such as UART is needed for output, the speed at which the design under test and the software simulator access external devices is different, and the sizes of the hardware buffer and software buffer are also different, the hardware buffer may be full during the verification process, and the design under test needs to interrupt and enter a loop to wait, while the software buffer is not full and data can be output. This will cause the design under test and the software simulator to have different instruction streams when running the same program, that is, the operation is not synchronized.

[0094] In an embodiment of the present application, when it is detected that the design under test is accessing an external device, if the design under test is outputting data through the first transceiver, the operation of the software simulator can be interrupted, and the data output of the second transceiver of the software simulator can be interrupted. The data output of the second transceiver will not be resumed until the first transceiver of the design under test is idle. A similar method can be used for different external devices to shield the impact of the software simulator and the external device driver of the design under test, ensuring that changes in the status of the external device will not affect the correct comparison of the execution results of the design under test and the software simulator.

[0095] In summary, the embodiments of the present application provide an interrupt control method. During the hardware verification of the design to be tested, it can determine when to stop the design to be tested based on whether the first execution result of the benchmark test program on the design to be tested matches the second execution result of the benchmark test program on the software simulator, and the data storage status of the hardware buffer and the software buffer. There is no need for the tester to manually set checkpoints or breakpoints. Compared with traditional FPGA prototypes that only capture a valid number of signals based on set checkpoints or snapshot points, the FPGA chip using the interrupt control method provided by the embodiments of the present application can automatically compare and check the execution results of the design to be tested and the software simulator during hardware verification, and automatically trigger an interrupt, which has better debugging capabilities.

[0096] It should be noted that for the method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present application are not limited by the order of the actions described, because according to the embodiments of the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present application.

[0097] Device embodiment

[0098] 3 , there is shown a block diagram of an interrupt control device of the present application, which may include:

[0099] An acquisition module 301 is configured to acquire a first execution result of a design under test on a benchmark test program and a second execution result of a software simulator on the benchmark test program; the design under test runs in a programmable logic region of a programmable logic chip, and the software simulator runs in a processing system of the programmable logic chip;

[0100] A first interrupt module 302, configured to interrupt the operation of the design under test when an interrupt condition is met;

[0101] The interruption condition includes at least one of the following:

[0102] The first execution result does not match the second execution result;

[0103] The hardware buffer corresponding to the design to be tested is full; the hardware buffer is used to record the operation data of the design to be tested;

[0104] The software buffer corresponding to the software simulator is empty; the software buffer is used to record the running data of the software simulator.

[0105] Optionally, the first interrupt module includes:

[0106] A first control submodule is configured to interrupt the operation of the design to be tested, wait for the hardware buffer to release data, and start an interrupt timer when the hardware buffer corresponding to the design to be tested is full;

[0107] a checking submodule, configured to check whether there is an idle area in the hardware buffer when the value of the interrupt timer is greater than or equal to a preset value;

[0108] A second control submodule is configured to resume the operation of the design under test when there is an idle area in the hardware buffer;

[0109] The third control submodule is configured to, when there is no free area in the hardware buffer, continue to interrupt the running of the design to be tested and wait for the hardware buffer to release data.

[0110] Optionally, the first interrupt module includes:

[0111] an interrupt submodule, configured to interrupt the operation of the design under test and the software simulator when the first execution result does not match the second execution result;

[0112] A snapshot submodule, configured to trigger a hardware snapshot mechanism to save state information of the programmable logic chip;

[0113] The information import submodule is used to import the state information into simulation software for simulation, so as to debug and repair the design to be tested.

[0114] Optionally, the first interrupt module includes:

[0115] a determination submodule, configured to determine a target interruption condition according to the priorities of the respective interruption conditions when at least two of the interruption conditions are satisfied;

[0116] The management submodule is used to perform interrupt control on the design under test according to the interrupt management mechanism corresponding to the target interrupt condition.

[0117] Optionally, the device further comprises:

[0118] A first sending module is configured to send an interrupt signal to the design under test to suspend the operation of the design under test when detecting that the execution result of the first instruction in the benchmark test program by the design under test is written into the hardware buffer;

[0119] The second sending module is used to send an interrupt release signal to the design under test when monitoring that the software simulator writes the execution result of the first instruction into the software buffer, so as to trigger the design under test to continue executing the instructions in the benchmark test program.

[0120] Optionally, the device further comprises:

[0121] A second interrupt module is used to interrupt the operation of the software simulator when it is detected that the design under test accesses an external device;

[0122] The recovery module is used to recover the operation of the software simulator when it is detected that the access to the design to be tested is completed.

[0123] Optionally, the second interrupt module includes:

[0124] The fourth control submodule is used to interrupt the operation of the software simulator and interrupt the data output of the second transceiver of the software simulator when it is monitored that the design under test accesses an external device and if the design under test outputs data through the first transceiver, until the first transceiver is idle, and then restore the data output of the second transceiver.

[0125] Optionally, the device further comprises:

[0126] The third interrupt module is used to interrupt the operation of the software simulator when it is detected that the software buffer corresponding to the software simulator is full.

[0127] Optionally, the device further comprises:

[0128] The interrupt control module is used to control the shortest time limit of the interruption of the design under test due to the fullness of the hardware buffer through the interrupt timer, and the interrupt timer is a forward timer or a countdown timer.

[0129] Optionally, the interrupt submodule includes:

[0130] An interrupt unit is used to send an interrupt signal to the design to be tested and the software simulator when it is determined by the checker that the first execution result of the design to be tested does not match the second execution result of the software simulator, and transmit the interrupt signal to the controller through the checker so that the controller can create a snapshot after both the design to be tested and the software simulator are safely paused.

[0131] Optionally, the priority of the interrupt condition that the first execution result does not match the second execution result is greater than the priority of the interrupt condition that the hardware buffer corresponding to the design under test is full;

[0132] The priority of the interrupt condition that the hardware buffer corresponding to the design under test is full is greater than the priority of the interrupt condition that the software buffer corresponding to the software simulator is empty.

[0133] Optionally, the device further comprises:

[0134] The synchronization recovery module is used to transfer the data read by the design under test from the external device to the software simulator to restore the synchronization operation between the external device and the software simulator.

[0135] In summary, the embodiment of the present application provides an interrupt control device. During the process of hardware verification of the design to be tested, it can determine when to stop the design to be tested based on whether the first execution result of the benchmark test program of the design to be tested matches the second execution result of the benchmark test program of the software simulator, and the data storage status of the hardware buffer and the software buffer. There is no need for the tester to manually set checkpoints or breakpoints. Compared with the traditional FPGA prototype based on the set checkpoints or snapshot points, which only captures a valid number of signals, the FPGA chip using the interrupt control method provided by the embodiment of the present application can automatically compare and check the execution results of the design to be tested and the software simulator during hardware verification, and automatically trigger an interrupt, and has better debugging capabilities.

[0136] The various component embodiments of the present application can be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof. It will be appreciated by those skilled in the art that a microprocessor or a digital signal processor (DSP) can be used in practice to implement some or all of the functions of some or all of the components in the computing processing equipment according to the embodiment of the present application. The application can also be implemented as a device or apparatus program (for example, a computer program and a computer program product) for performing a part or all of the methods described herein. Such a program implementing the present application can be stored on a computer-readable medium, or can have the form of one or more signals. Such a signal can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

[0137] For example, FIG4 illustrates a computing device that can implement the methods according to the present application. The computing device typically includes a processor 1010 and a computer program product or computer-readable medium in the form of a memory 1020. Memory 1020 can be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, a hard disk, or ROM. Memory 1020 has storage space 1030 for program code 1031 for executing any of the method steps described above. For example, storage space 1030 for program code can include individual program codes 1031 for implementing various steps in the method described above. These program codes can be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, compact disks (CDs), memory cards, or floppy disks. Such computer program products are typically portable or fixed storage units, as described with reference to FIG5 . This storage unit can have storage segments, storage space, and the like arranged similarly to memory 1020 in the computing device of FIG4 . The program code can, for example, be compressed in a suitable form. Typically, the storage unit includes computer-readable codes 1031 ′, ie, codes that can be read by a processor such as 1010 , which, when executed by a computing device, cause the computing device to perform the steps of the method described above.

[0138] Referring to Figure 6 , there is shown a block diagram of an electronic device according to an embodiment of the present invention. As shown in Figure 6 , the electronic device includes a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other via the communication bus. The memory stores executable instructions that cause the processor to execute the interrupt control method according to the aforementioned embodiment.

[0139] The processor may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable devices, transistor logic devices, hardware components, or any combination thereof. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0140] The communication bus may include a path for transmitting information between the memory and the communication interface. The communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, for example. The communication bus may be categorized as an address bus, a data bus, a control bus, etc. For ease of illustration, FIG6 shows only one line, but this does not imply that there is only one bus or only one type of bus.

[0141] The memory may be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only), a CD-ROM (Compact Disa Read Only), a magnetic tape, a floppy disk, and an optical data storage device, etc.

[0142] An embodiment of the present application also provides a computer program product, including a computer program, and an interrupt control method implemented when the computer program is executed by a processor.

[0143] References herein to "one embodiment," "an embodiment," or "one or more embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Furthermore, please note that instances of the phrase "in one embodiment" do not necessarily all refer to the same embodiment.

[0144] In the description provided herein, a large number of specific details are described. However, it is understood that the embodiments of the present application can be practiced without these specific details. In some instances, well-known methods, structures, and techniques are not shown in detail so as not to obscure the understanding of this description.

[0145] In the claims, any reference signs placed between brackets shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in the claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present application may be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The use of the words first, second, and third etc. does not indicate any order. These words may be interpreted as names.

[0146] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

[0147] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0148] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

[0149] The above are only preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application.

[0150] The above is a detailed introduction to the interrupt control method, device, electronic device computer program and computer-readable storage medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. At the same time, for those skilled in the art, according to the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting the present application.

Claims

1. An interrupt control method, wherein: The method comprises: Obtaining a first execution result of a design under test on a benchmark test program and a second execution result of a software simulator on the benchmark test program; the design under test runs in a programmable logic area of ​​a programmable logic chip, and the software simulator runs in a processing system of the programmable logic chip; When the interruption condition is met, interrupting the operation of the design under test; The interruption condition includes at least one of the following: The first execution result does not match the second execution result; The hardware buffer corresponding to the design to be tested is full; the hardware buffer is used to record the operation data of the design to be tested; The software buffer corresponding to the software simulator is empty; the software buffer is used to record the running data of the software simulator.

2. The method according to claim 1, wherein: When the interruption condition is met, interrupting the operation of the design to be tested includes: When the hardware buffer corresponding to the design to be tested is full, interrupting the operation of the design to be tested, waiting for the hardware buffer to release data, and starting an interrupt timer; When the value of the interrupt timer is greater than or equal to a preset value, checking whether there is a free area in the hardware buffer; When there is a free area in the hardware buffer, resuming the operation of the design to be tested; When there is no free area in the hardware buffer, the operation of the design to be tested continues to be interrupted and the hardware buffer is waited for releasing data.

3. The method according to claim 1, wherein: When the interruption condition is met, interrupting the operation of the design to be tested includes: When the first execution result does not match the second execution result, interrupting the operation of the design under test and the software simulator; Triggering a hardware snapshot mechanism to save state information of the programmable logic chip; The state information is imported into simulation software for simulation, so as to debug and repair the design to be tested.

4. The method according to claim 1, wherein: When the interruption condition is met, interrupting the operation of the design to be tested includes: When at least two of the interruption conditions are met, determining a target interruption condition according to the priorities of the respective interruption conditions; The interruption management mechanism corresponding to the target interruption condition is used to control the interruption of the design under test.

5. The method according to claim 1, wherein: Before obtaining the first execution result of the benchmark test program on the design under test and the second execution result of the benchmark test program on the software simulator, the method further includes: When it is detected that the execution result of the first instruction in the benchmark test program by the design under test is written into the hardware buffer, an interrupt signal is sent to the design under test to suspend the operation of the design under test; When it is detected that the software simulator writes the execution result of the first instruction into the software buffer, an interrupt release signal is sent to the design under test to trigger the design under test to continue executing the instructions in the benchmark test program.

6. The method according to claim 1, wherein: The method further comprises: When it is detected that the design under test accesses an external device, interrupting the operation of the software simulator; When it is detected that the access to the design under test is completed, the operation of the software simulator is resumed.

7. The method according to claim 6, wherein: When it is detected that the design under test accesses an external device, interrupting the operation of the software simulator comprises: When it is monitored that the design under test accesses an external device, if the design under test outputs data through the first transceiver, the operation of the software simulator is interrupted, and the data output of the second transceiver of the software simulator is interrupted until the first transceiver is idle, and then the data output of the second transceiver is restored.

8. The method according to claim 1, wherein: The method further comprises: When it is detected that the software buffer corresponding to the software simulator is full, the operation of the software simulator is interrupted.

9. The method according to claim 2, wherein: The method further comprises: The shortest time limit for interrupting the design under test due to the hardware buffer being full is controlled by the interrupt timer, and the interrupt timer is a forward timer or a countdown timer.

10. The method according to claim 3, wherein: When the first execution result does not match the second execution result, interrupting the operation of the design under test and the software simulator includes: When the checker determines that the first execution result of the design under test does not match the second execution result of the software simulator, an interrupt signal is sent to the design under test and the software simulator, and the interrupt signal is passed to the controller through the checker, so that the controller can create a snapshot after both the design under test and the software simulator are safely paused.

11. The method according to claim 1, wherein: The priority of the interrupt condition that the first execution result does not match the second execution result is greater than the priority of the interrupt condition that the hardware buffer corresponding to the design under test is full; The priority of the interrupt condition that the hardware buffer corresponding to the design under test is full is greater than the priority of the interrupt condition that the software buffer corresponding to the software simulator is empty.

12. The method according to claim 6, wherein: The method further comprises: The data read by the design under test from the external device is transferred to the software simulator to restore the synchronous operation between the external device and the software simulator.

13. An interruption control device, wherein: The device comprises: an acquisition module, configured to acquire a first execution result of a design under test on a benchmark test program and a second execution result of a software simulator on the benchmark test program; the design under test runs in a programmable logic area of ​​a programmable logic chip, and the software simulator runs in a processing system of the programmable logic chip; A first interrupt module, used for interrupting the operation of the design under test when an interrupt condition is met; The interruption condition includes at least one of the following: The first execution result does not match the second execution result; The hardware buffer corresponding to the design to be tested is full; the hardware buffer is used to record the operation data of the design to be tested; The software buffer corresponding to the software simulator is empty; the software buffer is used to record the running data of the software simulator.

14. The device according to claim 13, wherein: The first interrupt module includes: A first control submodule, configured to interrupt the operation of the design to be tested, wait for the hardware buffer to release data, and start an interrupt timer when the hardware buffer corresponding to the design to be tested is full; A checking submodule, used for checking whether there is a free area in the hardware buffer when the value of the interrupt timer is greater than or equal to a preset value; A second control submodule, used for resuming the operation of the design to be tested when there is a free area in the hardware buffer; The third control submodule is used for, when there is no free area in the hardware buffer, continuing to interrupt the operation of the design to be tested and waiting for the hardware buffer to release data.

15. The device according to claim 13, wherein: The first interrupt module includes: An interrupt submodule, used for interrupting the operation of the design under test and the software simulator when the first execution result does not match the second execution result; A snapshot submodule, used to trigger a hardware snapshot mechanism to save the state information of the programmable logic chip; The information import submodule is used to import the state information into the simulation software for simulation, so as to debug and repair the design to be tested.

16. The device according to claim 13, wherein: The first interrupt module includes: A determination submodule, configured to determine a target interruption condition according to the priority of each interruption condition when at least two of the interruption conditions are met; A management submodule is used to interrupt the device under test according to the interrupt management mechanism corresponding to the target interrupt condition. The device performs interrupt control.

17. The device according to claim 13, wherein: The device also includes: A first sending module is used to send an interrupt signal to the design under test to suspend the operation of the design under test when monitoring that the execution result of the first instruction in the benchmark test program by the design under test is written into the hardware buffer; The second sending module is used to send an interrupt release signal to the design under test when it is monitored that the software simulator writes the execution result of the first instruction into the software buffer, so as to trigger the design under test to continue executing the instructions in the benchmark test program.

18. An electronic device comprising: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method according to any one of claims 1 to 12.

19. A computer program comprising computer readable code which, when executed on a computing processing device, causes the computing processing device to execute the method according to any one of claims 1 to 12.

20. A computer-readable storage medium storing the computer program according to claim 19, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the method according to any one of claims 1 to 12.

Images