Design under test verification method, apparatus, device, and medium

Abstract

This invention relates to the field of chip verification technology, and provides a method, apparatus, device, and medium for verifying a design under test (DUT). The method includes: determining a target execution function from at least two execution functions in the verification environment based on the management and arbitration logic of a DPI-C processor model with a direct programming interface in C language; calling a corresponding function with the same name from a program library to execute the program based on the target execution function; and verifying the DUT based on the program executed by the function with the same name. This invention uses a DPI-C processor model instead of a real processor, directly calling the execution program according to the management and arbitration logic of the DPI-C processor model to verify the DUT, avoiding adherence to processor execution program specifications, and improving simulation speed and iterative verification efficiency.

Description

Technical Field

[0001] This invention relates to the field of chip verification technology, and in particular to a method, apparatus, equipment and medium for verifying designs under test. Background Technology

[0002] In chip verification, for chip systems with processors, a real processor is typically used to load firmware and send instructions to the Design Under Test (DUT) via a bus to execute programs. This covers the interaction logic between the processor and the intellectual property core (IP) and helps verify the correctness of the IP.

[0003] However, existing technologies require strict adherence to processor execution program specifications, which typically results in slow simulation speeds and reduces the efficiency of iterative verification. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and medium for verifying a design under test, which addresses the shortcomings of existing technologies that require strict adherence to processor execution program specifications, resulting in slow simulation speeds and reduced efficiency of iterative verification. The invention utilizes a DPI-C processor model instead of a real processor, directly calling the execution program based on the management and arbitration logic of the DPI-C processor model to verify the design under test. This avoids adhering to processor execution program specifications, thereby improving simulation speed and iterative verification efficiency.

[0005] This invention provides a method for verifying a design under test, comprising the following steps:

[0006] Based on the management and arbitration logic in the DPI-C processor model with the C language direct programming interface, the target execution function is determined from at least two execution functions in the verification environment;

[0007] Based on the target execution function, the program is executed by calling the corresponding function with the same name from the program library;

[0008] The program is executed based on the function with the same name to verify the design under test.

[0009] According to a design-to-test verification method provided by the present invention, the determination of the target execution function based on the management logic and arbitration logic in the DPI-C processor model of the C language direct programming interface includes: determining the execution level corresponding to each execution function; and determining the target execution function based on the management logic, the arbitration logic, and the execution level corresponding to each execution function.

[0010] According to a design-under-test (DUT) verification method provided by the present invention, the execution function includes a main function and an interrupt service function, wherein the execution level of the main function is lower than that of the interrupt service function. The step of determining the target execution function based on the management logic, the arbitration logic, and the execution levels corresponding to each execution function includes: determining the main function as the target execution function based on the management logic, the arbitration logic, and the execution levels corresponding to each execution function when no DUT interruption signal is received; and determining the interrupt service function as the target execution function based on the management logic, the arbitration logic, and the execution levels corresponding to each execution function when the DUT interruption signal is received.

[0011] According to the present invention, a method for verifying a design under test includes verifying the design under test based on the execution program of the function with the same name, comprising: performing callback processing on the execution program of the function with the same name based on the callback mechanism in the verification environment to obtain an adaptation object; and verifying the design under test based on the adaptation object.

[0012] According to the present invention, a method for verifying a design under test includes an adapter object comprising a register model or an interface verification IP. The method for verifying the design under test based on the adapter object includes: when the verification content is configuration, sending stimuli to the design under test based on the register model for verification; and when the verification content is an interface, sending stimuli to the design under test based on the interface verification IP for verification.

[0013] According to a design-to-test verification method provided by the present invention, determining the DPI-C processor model includes: determining the management logic and arbitration logic in the DPI-C processor model based on events and semaphores in the system hardware programming language; and determining the DPI-C processor model based on the management logic and the arbitration logic.

[0014] According to the present invention, a method for verifying a design under test (DUT) is provided, wherein the verification of the DUT based on the execution program of the function with the same name includes: in the event of an interrupt during the verification of the DUT, calling an interrupt routine from the program library through the DPI-C processor model; and after the interrupt routine is executed, continuing to execute the execution program of the function with the same name to verify the DUT.

[0015] The present invention also provides a design-to-test verification device, comprising the following modules:

[0016] The determination module is used to determine the target execution function from at least two execution functions in the verification environment, based on the management logic and arbitration logic in the DPI-C processor model with the C language direct programming interface.

[0017] The calling module is used to call the corresponding function with the same name from the program library to execute the program based on the target execution function;

[0018] The verification module is used to execute a program based on the function with the same name to verify the design under test.

[0019] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the design-to-test verification method as described above.

[0020] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the design-to-test verification method as described above.

[0021] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the design-to-test verification method as described above.

[0022] The present invention provides a method, apparatus, device, and medium for verifying designs under test (DUTs). By utilizing the management and arbitration logic within a DPI-C processor model (based on a direct programming interface in C), a target execution function is determined from at least two execution functions in the verification environment. Based on the target execution function, a corresponding function with the same name is called from a program library to execute the program. The DUT is then verified using this program. In this way, by using a DPI-C processor model instead of a real processor, and directly calling the execution program based on the management and arbitration logic of the DPI-C processor model, the verification of the DUT is achieved. This avoids adhering to processor execution program specifications, improving simulation speed and the efficiency of iterative verification. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating the design-to-test verification method provided by the present invention.

[0025] Figure 2This is a schematic diagram of the first system structure of the design-to-test verification method provided by the present invention.

[0026] Figure 3 This is a schematic diagram of the second system structure of the design under test verification method provided by the present invention.

[0027] Figure 4 A schematic diagram of the structure of the design under test verification device provided by the present invention.

[0028] Figure 5 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0030] In existing technologies, using a real processor to verify the design under test not only reduces simulation speed and the efficiency of iterative verification, but also has the following problems:

[0031] (1) The real processor interface is limited by the bus protocol and has poor scalability; (2) The real processor is strongly bound to the hardware environment during operation, such as memory mapping, peripheral addresses, etc. If the chip architecture is adjusted, the firmware needs to be rewritten.

[0032] To address the aforementioned problems, this invention provides a method for verifying a design under test. By using a DPI-C processor model instead of a real processor, the method directly calls the execution program based on the management and arbitration logic of the DPI-C processor model to verify the design under test. This avoids following the processor execution program specifications and improves simulation speed and iterative verification efficiency.

[0033] The following is combined with Figures 1-3 The present invention describes a design-to-test (DUT) verification method applicable to the verification of any DUT. The execution subject of this method can be an electronic device or a DUT verification device installed in the electronic device. The DUT verification device can be implemented by software, hardware, or a combination of both.

[0034] Figure 1 This is a flowchart illustrating the design-to-test verification method provided by the present invention, as shown below. Figure 1 As shown, the method includes the following:

[0035] Step 101: Based on the management logic and arbitration logic in the DPI-C processor model with the C language direct programming interface, determine the target execution function from at least two execution functions in the verification environment.

[0036] The Direct Programming Interface for C (DPI-C) is an interface for interaction between Hardware Description and Verification Language (HDVL) and C / C++. SystemVerilog is a Hardware Description and Verification Language (HDVL). DPI-C allows SystemVerilog to call external C code to implement functionalities and extend interfaces.

[0037] Here, the DPI-C processor model is used to simulate the processor's management of processor execution state, program execution, and interrupt handling.

[0038] Here, the management logic manages requests from upper layers (such as C / C++ programs), parsing and preprocessing the requests. The arbitration logic arbitrates the priority of multiple concurrent requests; for example, when high-priority test and low-priority test requests are received simultaneously, it determines the execution order.

[0039] Here, the target execution function refers to the function that is executed first.

[0040] Here, the execution function can be understood as a request, which may include the main function main() and the interrupt service function isr().

[0041] Here, the verification environment can be the verification environment of Universal Verification Methodology (UVM), which is an open-source standardized verification framework built on the SystemVerilog language.

[0042] For example, determining the target execution function based on the management logic and arbitration logic in the DPI-C processor model with the C language direct programming interface includes: determining the execution level corresponding to each execution function; and determining the target execution function based on the management logic, the arbitration logic, and the execution level corresponding to each execution function.

[0043] Here, in the UVM main phase, the required functions are simultaneously started (fork-joined) and their corresponding execution levels are set. The execution level of each function represents its priority; functions with higher priority are executed first. For example, between the main function and the isr function, the main function is executed first when there is no interrupt signal. When an interrupt signal is received, the execution of the main function is interrupted, and the isr function is executed. After the isr function finishes executing, the main function continues to execute.

[0044] It should be noted that different ISR functions also have priority levels. When there are two interrupt signals, the interrupt signal with the higher priority should be executed first. Furthermore, a higher priority interrupt function can interrupt a lower priority interrupt function, but a lower priority interrupt function cannot interrupt a higher priority interrupt function.

[0045] Optionally, the target execution function can be determined by comparing the execution level of the execution function through management logic and arbitration signals, or it can be determined based on management logic, arbitration logic, execution level, and interrupt signals.

[0046] In this embodiment of the invention, the target execution function is determined by management logic, arbitration logic, and the execution level corresponding to each execution function, supporting the execution of programs with different priorities and closely approximating the actual processor execution process.

[0047] For example, the execution function includes a main function and an interrupt service function, wherein the execution level of the main function is lower than that of the interrupt service function. Determining the target execution function based on the management logic, the arbitration logic, and the execution levels of each execution function includes: determining the main function as the target execution function when no interruption signal is received from the design under test, based on the management logic, the arbitration logic, and the execution levels of each execution function; and determining the interrupt service function as the target execution function when an interruption signal is received from the design under test, based on the management logic, the arbitration logic, and the execution levels of each execution function.

[0048] Here, the design under test may include chips, processor cores, interface modules, etc.

[0049] Here, interrupt signals can originate from external hardware of the DUT, internal modules of the DUT, or virtual triggers in the simulation / test environment. Examples include button presses, low-voltage warnings from external power monitoring chips, threshold trigger signals from sensors, and virtual interrupt signals.

[0050] Specifically, after receiving the main function and interrupt service function, the DPI-C processor model executes the normal process in the main function according to the management logic and arbitration logic if no interrupt signal is received from the design under test. When an interrupt signal is received from the design under test, the high-priority interrupt service function is executed according to the management logic, arbitration logic, and the level of the interrupt signal's corresponding function.

[0051] In this embodiment of the invention, the main function or interrupt service function is determined as the target execution function based on whether the device under test has an interrupt signal, according to the management logic, arbitration logic and the execution level corresponding to each execution function, so as to support the execution of programs with different priorities and closely approximate the actual processor execution process.

[0052] Step 102: Based on the target execution function, call the corresponding function with the same name from the program library to execute the program.

[0053] Here, the library can be a C / C++ program.

[0054] Specifically, after determining the target execution function, the program is executed by calling the function with the same name from the C / C++ program through the DPI-C interface, and the design under test is verified based on the execution of the function with the same name.

[0055] Step 103: Execute the program based on the function with the same name to verify the design under test.

[0056] Optionally, after executing the program by calling the function with the same name, the DPI-C processor model can send stimulus signals to the design under test to verify the design under test.

[0057] Optionally, the DPI-C processor model can generate excitation signals via a bus or callback function.

[0058] Figure 2 This is a schematic diagram of the first system structure of the design-to-test verification method provided by the present invention, as shown below. Figure 2As shown, the first system 200 includes a UVM testbench (TB) 210, a design under test (DUT) 220, and a C / C++ program 230. The UVM testbench 210 includes a DPI-C processor model 211 and a callback unit 212. The DPI-C processor model 211 includes a request manager and a request arbitrator. Specifically, the verification process of the DUT includes: the DPI-C processor model uses the request manager and request arbitrator to determine the function to be executed first from multiple requests, then calls the program corresponding to the function to be executed first from the C / C++ program, and then uses the callback unit to send stimuli to the DUT to verify the DUT. When the DUT generates an interrupt (INT), the interrupt program is called from the C / C++ program by the DPI-C processor model.

[0059] Furthermore, the step of verifying the design under test based on the function execution program with the same name includes: performing callback processing on the function execution program with the same name based on the callback mechanism in the verification environment to obtain an adaptation object; and verifying the design under test based on the adaptation object.

[0060] Here, the callback mechanism refers to the function being called in reverse when a specific event occurs or a condition is met.

[0061] Optionally, the adapter can be a register model or an interface verification IP.

[0062] Specifically, after using a callback mechanism to execute the callback process of the function with the same name to obtain the adapter object, the adapter object is used to generate an excitation signal, which is then sent to the design under test for verification.

[0063] In this embodiment of the invention, the interface is extended by using the callback mechanism in UVM, which enhances the robustness of the verification environment, facilitates rapid switching and adaptation between adaptable objects, improves the efficiency of verifying the design under test, facilitates migration from the module level to the system level verification environment, and DPI-C is bound to different bus interfaces. The use of callbacks achieves rapid compatibility with the UVM environment.

[0064] Furthermore, the adaptation object includes a register model or an interface verification IP. The verification of the design under test based on the adaptation object includes: when the verification content is configuration, sending stimuli to the design under test for verification based on the register model; when the verification content is an interface, sending stimuli to the design under test for verification based on the interface verification IP.

[0065] Here, when the verification content is configuration, it is necessary to obtain the register model pointer in the UVM environment and then use the register model to generate an incentive signal; when the verification content is interface verification, an incentive signal is generated by issuing a transaction (trans) through the write-read call sequence (axi vip sequence).

[0066] In this embodiment of the invention, the interface is extended by using the UVM callback mechanism to enhance the robustness of the verification environment, facilitate adaptation to various protocol startup sequences and quick switching between register models, and facilitate migration from the module level to the system level verification environment.

[0067] Further, determining the DPI-C processor model includes: determining the management logic and arbitration logic in the DPI-C processor model based on events and semaphores in the system hardware programming language; and determining the DPI-C processor model based on the management logic and the arbitration logic.

[0068] It should be noted that in system hardware programming languages ​​(such as SystemVerilog, which is often used for hardware design and verification), events and semaphores are two core process synchronization and cooperation mechanisms used to simulate the interaction behavior of multiple concurrent modules (such as processors, peripherals, and buses) in a hardware system, ensuring that they work together in accordance with the expected timing and logic.

[0069] An event is a tool for notification and waiting synchronization between processes. It enables sequential coordination between multiple concurrent processes (such as the behavior model of a hardware module). When a process completes an operation, it notifies other processes waiting for that operation through an event, allowing them to continue execution.

[0070] A semaphore is a mechanism used to control access to limited shared resources by multiple processes. It limits the number of processes that can access a resource simultaneously through get and put operations, thus avoiding conflicts. Specifically, a process requests n resources using get(n), blocking if there are insufficient resources, and releases n resources using put(n), waking up waiting processes.

[0071] For example, events and semaphores in the system hardware programming language can be set according to the actual situation to determine the management logic and arbitration logic in the processor model in order to simulate the DPI-C processor model.

[0072] It should be noted that multiple DPI-C processor models can be designed to meet the multiple verification requirements of the design under test.

[0073] In this embodiment of the invention, events and semaphores in the system hardware programming language are used to simulate simple processor process management, supporting program execution with different priorities, closely resembling the real processor execution process, and decoupling from the hardware by simulating the DPI-C processor model. Modifications can be seamlessly migrated at each stage of verification (from module level to system level) and in later software development, saving development costs.

[0074] Furthermore, the step of verifying the design under test based on the function with the same name includes: in the event of an interrupt during the verification of the design under test, calling an interrupt routine from the program library through the DPI-C processor model; and after the interrupt routine is executed, continuing to execute the function with the same name to verify the design under test.

[0075] If an interrupt signal is generated during the verification of the design under test, the main program needs to be interrupted, and the ISR program needs to be called and executed in the C / C++ program through the DPI-C interface. After the ISR program is executed, if there are no other interrupt signals, the main program will continue to execute.

[0076] In this embodiment of the invention, when an interrupt occurs, the interrupt routine is executed first, supporting the priority execution of high-priority programs, and closely approximating the actual processor execution process.

[0077] Figure 3 This is a schematic diagram of the second system structure of the design-to-test verification method provided by the present invention, as shown below. Figure 3As shown, the second system 300 includes a UVM test platform 210 (Testbench, TB), a design under test 220, and a C / C++ program 230. The UVM test platform 210 includes a DPI-C processor model 211, a register model 301, and an interface verification IP 302. Specifically, the verification method for the design under test includes the following process: Multiple DPI-C processor models are instantiated in the UVM test platform. In the UVM main phase, the required functions (requests), such as the main function and the ISR function, are forked and joined. A corresponding execution level is set for each request. Multiple requests are initiated and input into the DPI-C processor model. The DPI-C processor model determines the execution level of the request based on management and arbitration logic, performs arbitration, and preempts the process after obtaining the arbitration result. When the request is completed, resources are released. The arbitration logic prioritizes the execution of higher-level requests. Then, the DPI-C processor model calls the corresponding function of the priority execution program from the C / C++ program. The IP is verified through the callback register model or interface, generating a stimulus signal and sending it to the DUT for verification. If an interrupt occurs, the TB detects the interrupt and again calls the ISR program in C / C++ through the DPI-C interface. After the ISR program completes execution, the main program continues execution.

[0078] The device for verifying a design under test provided by the present invention is described below. The device for verifying a design under test described below can be referred to in correspondence with the method for verifying a design under test described above.

[0079] Figure 4 This is a schematic diagram of the structure of the design-to-test verification device provided by the present invention, as shown below. Figure 4 As shown, the design-to-test verification device 400 includes the following:

[0080] The determination module 410 is used to determine the target execution function from at least two execution functions in the verification environment based on the management logic and arbitration logic in the DPI-C processor model based on the C language direct programming interface;

[0081] The calling module 420 is used to call the corresponding function with the same name from the program library to execute the program based on the target execution function;

[0082] Verification module 430 is used to execute a program based on the function with the same name to verify the design under test.

[0083] In another embodiment, the determining module 410 is specifically used to: determine the execution level corresponding to each of the execution functions; and determine the target execution function based on the management logic, the arbitration logic, and the execution level corresponding to each of the execution functions.

[0084] In another embodiment, the execution function includes a main function and an interrupt service function, wherein the execution level of the main function is lower than that of the interrupt service function. The determining module 410 is specifically configured to: determine the main function as the target execution function based on the management logic, the arbitration logic, and the execution levels corresponding to each of the execution functions when no interruption signal of the design under test is received; and determine the interrupt service function as the target execution function based on the management logic, the arbitration logic, and the execution levels corresponding to each of the execution functions when an interruption signal of the design under test is received.

[0085] In another embodiment, the verification module 430 is specifically used to: perform callback processing on the function execution program with the same name based on the callback mechanism in the verification environment to obtain an adaptation object; and verify the design under test based on the adaptation object.

[0086] In another embodiment, the adaptation object includes a register model or an interface verification IP. The verification module 430 is further specifically used to: when the verification content is configuration, send stimuli to the design under test for verification based on the register model; when the verification content is an interface, send stimuli to the design under test for verification based on the interface verification IP.

[0087] In another embodiment, the determining module 410 is further specifically configured to: determine the management logic and arbitration logic in the DPI-C processor model based on events and semaphores in the system hardware programming language; and determine the DPI-C processor model based on the management logic and the arbitration logic.

[0088] In another embodiment, the verification module 430 is further configured to: in the event of an interrupt during the verification of the design under test, call an interrupt routine from the program library through the DPI-C processor model; and after the interrupt routine has been executed, continue to execute the function execution program with the same name to verify the design under test.

[0089] Figure 5 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 5As shown, the electronic device may include a processor 810, a communications interface 820, a memory 830, and a communication bus 840, wherein the processor 810, communications interface 820, and memory 830 communicate with each other via the communication bus 840. The processor 810 can call logic instructions in the memory 830 to execute a design-under-test (DUT) verification method. This method includes: determining a target execution function from at least two execution functions in the verification environment based on management logic and arbitration logic in the DPI-C processor model (direct programming interface for C language); calling a corresponding function execution program from a program library based on the target execution function; and verifying the DUT based on the function execution program.

[0090] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0091] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the design-to-test verification method provided by the above methods. The method includes: determining a target execution function from at least two execution functions in the verification environment based on the management logic and arbitration logic in the DPI-C processor model of the C language direct programming interface; calling a function execution program with the same name corresponding to the target execution function from a program library based on the target execution function; and verifying the design-to-test based on the function execution program with the same name.

[0092] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program is implemented to perform the design-to-test verification method provided by the above methods. The method includes: determining a target execution function from at least two execution functions in a verification environment based on management logic and arbitration logic in a DPI-C processor model with a direct programming interface for C language; calling a function execution program with the same name corresponding to the target execution function from a program library based on the target execution function; and verifying the design-to-test based on the function execution program with the same name.

[0093] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0094] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0095] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A design-under-test verification method, comprising: include: Determine the execution level of each execution function; the execution functions include the main function and interrupt service functions in the verification environment; the execution level of the main function is lower than that of the interrupt service functions; In the absence of an interrupt signal from the design under test, the main function is determined as the target execution function based on the management logic and arbitration logic in the DPI-C processor model (direct programming interface for C language) and the execution level corresponding to each execution function. The DPI-C processor model is used to replace the real processor, the management logic is used to parse and preprocess requests from the upper layer, and the arbitration logic is used to arbitrate the priority of multiple parallel execution functions. Upon receiving the interruption signal of the design under test, the interrupt service function is determined as the target execution function based on the management logic, the arbitration logic, and the execution level corresponding to each execution function. Based on the target execution function, the program is executed by calling the corresponding function with the same name from the program library; The program is executed based on the function with the same name to verify the design under test.

2. The design-under-test verification method of claim 1, wherein, The process of executing a program based on the function with the same name to verify the design under test includes: Based on the callback mechanism in the verification environment, the execution program of the function with the same name is processed to obtain the adaptation object; The design under test is verified based on the adapted object.

3. The design-under-test verification method of claim 2, wherein, The adaptation object includes a register model or interface verification IP. The verification of the design under test based on the adaptation object includes: When the verification content is configured, the stimuli are sent to the design under test for verification based on the register model; When the verification content is an interface, the verification IP is based on the interface, and an incentive is sent to the design under test for verification.

4. The design-to-test verification method according to claim 1, characterized in that, Determining the DPI-C processor model includes: Based on events and semaphores in the system hardware programming language, the management logic and arbitration logic in the DPI-C processor model are determined. Based on the management logic and the arbitration logic, the DPI-C processor model is determined.

5. The design-to-test verification method according to claim 1, characterized in that, The process of executing a program based on the function with the same name to verify the design under test includes: In the event of an interruption during the verification of the design under test, the interrupt routine is called from the program library through the DPI-C processor model; After the interrupt procedure is completed, the execution procedure of the function with the same name continues to be executed to verify the design under test.

6. A design-under-test verification apparatus comprising: include: A determination module is used to determine the execution level of each execution function; the execution functions include the main function and interrupt service functions in the verification environment; the execution level of the main function is lower than that of the interrupt service functions; in the absence of an interrupt signal from the design under test, based on the management logic and arbitration logic in the DPI-C processor model (direct programming interface for C language) and the execution levels of each execution function, the main function is determined as the target execution function; the DPI-C processor model is used to replace the real processor, the management logic is used to parse and preprocess requests from the upper layer, and the arbitration logic is used to arbitrate the priority of multiple parallel execution functions; Upon receiving the interruption signal of the design under test, the interrupt service function is determined as the target execution function based on the management logic, the arbitration logic, and the execution level corresponding to each execution function. The calling module is used to call the corresponding function with the same name from the program library to execute the program based on the target execution function; The verification module is used to execute a program based on the function with the same name to verify the design under test.

7. The design-under-test verification apparatus of claim 6, wherein, include: The verification module is also used to perform callback processing on the function execution program with the same name based on the callback mechanism in the verification environment to obtain the adaptation object; The design under test is verified based on the adapted object.

8. The design-under-test verification apparatus of claim 7, wherein, include: The adaptation object includes a register model or an interface verification IP. The verification module is further configured to send stimuli to the design under test for verification based on the register model when the verification content is configuration; and to send stimuli to the design under test for verification based on the interface verification IP when the verification content is an interface.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the design-to-test verification method as described in any one of claims 1 to 5.

10. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by the processor, it implements the design-to-test verification method as described in any one of claims 1 to 5.

Images