A method for timing synchronization in a software HDL co-simulation system

Abstract

The application provides a timing synchronization method in a software HDL co-simulation system, comprising a clock management module and a DPI mutex module on the software side, a DUT model on the hardware side, and a DPI interface for instruction interaction between the software side and the hardware side; the method comprises the following steps: S1: the clock management module accesses the DPI mutex module to obtain the state of the DPI interface; S2: when the state of the DPI interface is idle, the clock management module obtains the time point of the previous call of the DPI interface and the current CPU time point, and calculates the time interval of the software side; S3: the number of simulation loop cycles of the DUT model is determined based on the time interval; S4: the clock management module calls the DPI interface to advance the number of simulation loop cycles of the DUT model, and steps S1 to S4 are repeated until the co-simulation ends, so as to realize the timing synchronization between the simulation time domain and the software side.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of simulation testing, in particular to a timing synchronization method in a software HDL co-simulation system. BACKGROUND

[0002] Advanced verification language (such as System Verilog) provides a Direct Programming Interface (hereinafter referred to as DPI) interface mechanism to support interaction with C / C++, based on which C++ software and Verilog hardware model co-simulation can be realized. This co-simulation technology has various application scenarios, such as the most common one is to use C++ language to implement a simulation excitation generation program, and then through DPI to pour the generated excitation into the Verilog circuit model, so as to verify whether the behavior of the Device under test (hereinafter referred to as DUT) under this excitation meets the expectation.

[0003] Hardware Description Language (HDL, Hardware Description Language) co-simulation system can enable designers to see the behavior of real user applications running on the chip at an early stage of chip design, which will bring many benefits. For example, from the perspective of chip function verification, this system enables designers to run real complex applications in simulation at an early stage of chip design. These complex applications often contain corner cases that are difficult for verification personnel to write or randomly constrain, thus improving the coverage rate of the chip function verification stage. From the perspective of chip architecture design, by analyzing the behavior of real applications running on the chip, designers can identify performance bottlenecks in chip design at an earlier stage, and then optimize the chip architecture to improve performance. From the perspective of chip driver software personnel, this system also enables driver designers to start driving software design and optimization at an earlier project cycle, thereby shortening the software development cycle.

[0004] Compared with lightweight co-simulation software programs, when the software side needs to execute a large and complex program, there will be a large number of DPI interface call instructions between the behaviors that do not access DPI, and a large amount of CPU time is consumed, so the problem of time domain asynchronization between the GPU driver side and the simulation side needs to be solved. SUMMARY

[0005] The present application provides a timing synchronization method in a software HDL co-simulation system, including a clock management module and a DPI mutex module on the software side; a DUT model on the hardware side; and a DPI interface for instruction interaction between the software side and the hardware side; the method comprises:

[0006] Step S1: the clock management module accesses the DPI mutex module to obtain the DPI interface state;

[0007] Step S2: when the DPI interface state is the DPI interface idle, the clock management module obtains the time point of the previous call of the DPI interface and the current CPU time point, and calculates the time interval on the software side;

[0008] Step S3: the simulation loop number of the DUT model is determined based on the time interval;

[0009] Step S4: the clock management module calls the DPI interface to advance the simulation loop number of the DUT model, so as to realize the timing synchronization between the simulation time domain and the software side;

[0010] Steps S1 to S4 are repeated until the co-simulation ends.

[0011] In the preferred embodiment of the application, any thread on the software side needs to access the DPI mutex module to obtain the DPI interface state before calling the DPI interface.

[0012] The DPI interface state includes the DPI interface idle and the DPI interface occupied.

[0013] When the DPI interface state is the DPI interface occupied, the clock management module waits for a cycle period and then queries the DPI interface state again until the DPI interface state becomes the DPI interface idle.

[0014] When the DPI interface state is obtained as the DPI interface idle, the clock management module sets the DPI interface state as the DPI interface occupied and starts to call the DPI interface.

[0015] The clock management module applies to call the DPI interface at a set time cycle interval.

[0016] The clock management module obtains the time point of the last call of the DPI interface through a storage variable and obtains the current CPU time point through a system function.

[0017] The clock management module stores the time point of the current call of the DPI interface, which is used to determine the time interval when the DPI interface is called next time.

[0018] When the DPI interface call ends, the DPI interface state is modified as the DPI interface idle to release the DPI interface resource.

[0019] The clock management module enters a background sleep state after the DPI interface call ends.

[0020] The loop number of the simulation time domain is obtained based on the conversion rate between the CPU time and the simulation loop.

[0021] In another aspect of the present application, a computer readable storage medium is provided, which stores computer instructions for causing a processor to implement the method according to any one of the preceding aspects when executed.

[0022] In another aspect of the present application, an electronic device is provided, which comprises one or more processors, a memory for storing executable instructions, and the one or more processors are configured to implement the method according to any one of the preceding aspects via the executable instructions.

[0023] The present application is directed to a time domain synchronization problem of a software HDL co-simulation system, and a time sequence synchronization mechanism is used to synchronize the time domain of the software side and the hardware side, so that the software and the hardware model are driven to advance at the same speed, thereby making the entire co-simulation platform make correct simulation behaviors, and the entire software / hardware co-simulation system can truly reproduce the real behaviors of the user application running on the hardware platform. BRIEF DESCRIPTION OF DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0025] Figure 1 A structural diagram of a software HDL co-simulation system according to an embodiment of the present application is shown;

[0026] Figure 2 An instruction time sequence diagram of a co-simulation system lacking a time domain synchronization mechanism is shown;

[0027] Figure 3 An instruction time sequence diagram of another co-simulation system lacking a time domain synchronization mechanism is shown;

[0028] Figure 4 A structural diagram of a software HDL co-simulation system according to an embodiment of the present application is shown;

[0029] Figure 5 A flowchart of calling a DPI interface by a DPI mutual exclusion lock module according to an embodiment of the present application is shown;

[0030] Figure 6 A flowchart of time sequence synchronization by a clock management module according to an embodiment of the present application is shown;

[0031] Figure 7A command timing diagram of a co-simulation system with time domain synchronization mechanism is shown.

[0032] Figure 8 A structure block diagram of an electronic device is shown. DETAILED DESCRIPTION

[0033] Exemplary embodiments of the present application are described herein with reference to the accompanying drawings, in which various details are set forth to assist in an understanding of the embodiments of the present application. It will be apparent to those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the spirit and scope of the present application. Thus, the present application is not intended to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. Further, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. It is also to be understood that the features recited in the claims can be combined in any manner deemed appropriate by those skilled in the art.

[0034] Figure 1 A structure diagram of a software HDL co-simulation system is shown.

[0035] As Figure 1 shown, the present embodiment is a co-simulation system of GPU driving software (based on C / C++) and GPU hardware model (based on Verilog language), and a DPI interface technology is used to build the co-simulation system of the software and the DUT.

[0036] After the co-simulation system starts running, the GPU driver continuously sends the read / write access of the user's application (including rendering games / AI models / general computing programs, etc.) to the verilog simulation program simulating the DUT of the GPU through the DPI interface. The read / write access of the user's application includes the read / write access of the GPU memory and the GPU register.

[0037] The GPU performs calculations according to these stimuli, and then the driver reads the operation results in the HDL model back through the DPI interface.

[0038] In the above-described co-simulation system of the GPU driver and the hardware DUT, there is a problem of time domain asynchronization, because there are two time domains in the entire system: the time seen on the GPU driver side is the CPU time domain, that is, the real time, while the hardware DUT sees the simulation time domain, that is, the number of simulation cycles of the test platform (testbench).

[0039] Figure 2 A command timing diagram of a co-simulation system lacking a time domain synchronization mechanism is shown.

[0040] As Figure 2As shown, in the case of a lack of time domain synchronization mechanism in the co-simulation system, there is a driver on the software side, and the program content is to print a sentence on the terminal every 1 s in the CPU time domain. On the verilog side (hardware DUT side), the program is called through the DPI interface at the 10th cycle, and the simulation clock is pushed forward at a period of 1 ns. When the simulation is started, the expected system behavior is that the DUT starts from the 10th cycle, and the printing behavior in the software program is executed every 1 second in the CPU time, and at the same time, the simulation cycle will continue to advance.

[0041] The simulation cycle of the hardware DUT side stays at the 10th simulation cycle and no longer advances, and the software printing statement is repeatedly executed continuously.

[0042] In the case of a lack of time domain synchronization mechanism in the co-simulation system, 1 second of the software program is not equivalent to 1 second in the simulation time domain. In this example, 1 second on the software side is equal to 0 cycles on the hardware side, so the simulation is in an infinite loop of printing at the 10th cycle, and the cycle number no longer advances, resulting in the inability of the co-simulation to reproduce the real application scenario.

[0043] Figure 3 An instruction timing diagram of another co-simulation system lacking a time domain synchronization mechanism is shown.

[0044] As shown, Figure 3 In the GPU driver co-simulation system lacking a time domain synchronization mechanism of the embodiment, when the user's rendering application and the driver program are running, they will successively send DPI interface instructions to the DUT side.

[0045] The software side of the embodiment executes a large and complex program (user application + GPU driver), and a large number of DPI interface calling instructions are separated by a large number of behaviors that do not access DPI and consume a large amount of CPU time.

[0046] The DPI interface instructions can include a series of read and write instructions of the video memory / register, and can also include other DPI interface instructions.

[0047] The read and write instructions of the DPI interface can include DPI instruction 1 "write GPU video memory", DPI instruction 2 "write GPU register and start rendering", DPI instruction 3 "read GPU video memory and query rendering status", and DPI instruction 4 "query rendering status again".

[0048] The time point when the software issues the DPI instruction and the simulation cycle number when the hardware side receives the DPI instruction. When there is no effective timing synchronization mechanism in the collaborative simulation system, although these instructions are issued at a certain time interval in the software, they will be received at consecutive cycles on the simulation side. This timing difference between the software and hardware sides will cause the hardware to malfunction. For example, the software expects "DPI instruction 2" to start the GPU, and one frame in the game should take 10ms to render. Therefore, the software sends "DPI instruction 3" to query the rendering state of the GPU after 10ms. However, on the simulation side, the GPU is just started in the previous simulation cycle, and the next simulation cycle immediately receives the query state operation sent by the software. Therefore, the GPU state returned to the driver is not as expected, which causes the entire collaborative simulation system to malfunction.

[0049] Figure 4 A structural diagram of a software HDL collaborative simulation system according to an embodiment of the present application is shown.

[0050] As shown in Figure 4 A software HDL collaborative simulation system according to an embodiment of the present application includes a clock management module and a DPI mutex module on the software side, a DUT model on the hardware side, and a DPI interface for instruction interaction between the software side and the hardware side.

[0051] The timing synchronization method of the collaborative simulation system includes the following steps:

[0052] Step S1: The clock management module accesses the DPI mutex module to obtain the DPI interface state.

[0053] Step S2: When the DPI interface state is idle, the clock management module obtains the time point of the previous call to the DPI interface and the current CPU time point, and calculates the time interval on the software side.

[0054] Step S3: Based on the time interval, the simulation loop number of the DUT model is determined.

[0055] Step S4: The clock management module calls the DPI interface to advance the simulation loop number of the DUT model to achieve timing synchronization between the simulation time domain and the software side.

[0056] Steps S1 to S4 are repeated until the collaborative simulation ends.

[0057] The timing synchronization method of the collaborative simulation system according to the embodiment can ensure that the timing of the software side and the hardware DUT side can be synchronized and advanced, so that the timing of the DUT receiving instructions is closer to the real situation.

[0058] The time sequence synchronization mechanism of the cooperative simulation system comprises a clock management module in addition to the original application program and GPU driver for synchronizing the clock of the DUT.

[0059] The clock management module and the original driver run in two independent threads, avoiding mutual interference between the threads.

[0060] The clock management module can advance the simulation cycle number of the DUT model side through the DPI interface function, and the simulation cycle of the DUT model can be uniformly advanced forward along with the CPU time by uniformly and circularly calling the DPI interface function.

[0061] The DPI mutex module can implement the DPI mutex mechanism. Since the threads on the software side run independently, different threads may simultaneously call the DPI interface function, which will cause simulation errors due to the limitation of the simulation language, and thus the mutex mechanism is needed to avoid the simultaneous calling of the DPI interface function by different threads.

[0062] The clock management module can call the DPI interface through the DPI mutex module.

[0063] Any thread on the software side, such as the GPU driver thread or the time management thread, needs to execute the DPI mutex process before starting a DPI interface call to ensure that only one thread uses the DPI interface resource at the same time.

[0064] Figure 5 A flowchart of calling the DPI interface through the DPI mutex module according to the embodiment of the application is shown.

[0065] The mutex flag is defined in the DPI mutex module, and the mutex flag comprises two states, a free state representing that the DPI interface is idle and a thread can start calling the DPI interface, and a lock state representing that the DPI interface is occupied and the current application thread needs to wait.

[0066] As shown in FIG. 4, the flow steps of the software side thread for acquiring the DPI interface state and calling the DPI interface through the DPI mutex module are as follows. Figure 5

[0067] Step S10: Before starting the DPI call, a thread first queries the mutex flag state in the software to acquire the DPI interface state.

[0068] ​Step Sll: If the mutex flag is in the lock state, the thread needs to wait for a cycle period and then query the mutex flag again. This cycle continues until the mutex flag is in the free state, i.e., the DPI interface is idle.

[0069] Step S12: Once the mutex flag is in the free state, the thread can set the mutex flag to the lock state and then start the current DPI interface function call.

[0070] Step S13: When the DPI interface function call ends, the thread sets the mutex flag to the free state to release the DPI resource.

[0071] The clock management module drives the DUT model to advance the clock frequency at a uniform speed by calling the DPI interface function, thereby keeping consistent with the software side time.

[0072] Figure 6 A flowchart of the clock management module advancing the timing synchronization according to an embodiment of the present application is shown.

[0073] As shown in Figure 6 , the flow steps of the clock management module advancing the timing synchronization are as follows:

[0074] Step S20: The clock management module applies to access the DPI mutex module to obtain the DPI interface state. Once the DPI interface is idle, the clock management module is ready to call the DPI interface function.

[0075] Step S21: The clock management module calculates the time interval between the current CPU time point and the last time point of calling the DPI interface. The last time point of calling the DPI interface is saved in the variable t_old. The clock management module obtains the current CPU time t_new through a system function, and then the time interval of the CPU time advancement t_progress = t_new - t_old.

[0076] Step S22: The clock management module calculates the simulation cycle number (cycle_progress) of the simulation time domain that should be advanced in the current DPI call. The simulation cycle and the CPU time on the hardware side follow a fixed conversion rate K.

[0077] Therefore, the simulation cycle number cycle_progress = K * t_progress.

[0078] Step S23: The clock management module backs up the start time point t_new of the current DPI call to t_old for use in the next DPI interface call.

[0079] Step S24: invoke the DPI interface function to advance the cycle of the DUT model in the simulation time domain.

[0080] Step S25: invoke the DPI interface function to end, and invoke the sleep system function to make the time management thread enter background sleep for 10 ms.

[0081] Repeat steps S20 to S25 until the co-simulation ends.

[0082] The clock management module can cyclically invoke the DPI interface function at a time interval of approximately 10 ms, and each time of invocation advances the simulation cycle through software instructions, ensuring that the timing of the software side and the hardware DUT side can be synchronously advanced.

[0083] Figure 7 An instruction timing diagram of a co-simulation system with a time domain synchronization mechanism according to an embodiment of the present application is shown.

[0084] As shown in Figure 7 , after the time domain synchronization mechanism proposed in the present application is added, the time point of the original GPU driver accessing the hardware memory / register is substantially consistent with the time point of the clock management module invoking the DPI interface function to advance the simulation cycle.

[0085] The simulation cycle of the DUT model is advanced by the clock management module to ensure that the timing of the software side and the hardware side simulation time domain DPI instructions 1-4 is synchronized.

[0086] Since the clock management module is added on the software side, the hardware side can uniformly advance the simulation cycle, and the timing is synchronized with the software side, and the entire software / hardware co-simulation system can truly reproduce the real behavior of the user application running on the hardware platform.

[0087] Figure 8 A structural block diagram of an electronic device according to an embodiment of the present application is shown.

[0088] As shown in Figure 8 , an example configuration of the electronic device 300. The technical solutions of the present application can also be implemented by the electronic device 300 or similar devices / systems, in whole or at least in part. The electronic device 300 can be various different types of devices. Examples of the electronic device 300 include but are not limited to: a desktop computer, a server computer, a notebook computer or a netbook computer, a mobile device, a wearable device, an entertainment device, a television or other display device, a car computer, etc.

[0089] The electronic device 300 can include at least one processor 302, memory 304, communication interface(s) 309, display device 301, other input / output (I / O) devices 310, and one or more mass storage devices 303, which can be in communication with each other through a system bus 311 or other appropriate connection.

[0090] The processor 302 can be a single or multiple processing unit(s) comprising single or multiple computing unit(s) or core(s). The processor 302 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and / or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 302 can be configured to fetch and execute computer-readable instructions stored in the memory 304, the mass storage device 303, or any other computer-readable medium, such as program code of an operating system 305 or application programs 306 or other programs 307, etc.

[0091] The memory 304 and the mass storage device 303 are examples of computer-readable storage media for storing instructions which are executed by the processor 302 to implement the various functionalities described above. By way of example, the memory 304 can generally include both volatile memory and nonvolatile memory. Additionally, the mass storage device 303 can generally include hard disk drives, solid state drives, removable media, including external and removable drives, memory cards, flash memory, floppy disks, optical disks, storage arrays, network attached storage, storage area networks, etc. Both the memory 304 and the mass storage device 303 can be collectively referred to in this disclosure as memory or computer-readable storage media, and can be non-transitory media capable of storing computer-readable, processor-executable program instructions as computer program code that can be executed by the processor 302 as a particular machine configured to implement the operations and functionalities described in the examples of the present disclosure.

[0092] A number of program modules can be stored by the mass storage device 303. These programs include an operating system 305, one or more application programs 306, other programs 307, and program data 308, and they can be loaded into the memory 304 for execution. Examples of such application programs or program modules can include, for example, computer program logic (e.g., computer program code or instructions) for implementing the methods provided by the present disclosure (including any suitable steps of the methods) and / or additional embodiments described in the present disclosure.

[0093] Although the Figure 8The modular operating system 305, application programs 306, other programs 307, and program data 308, or portions thereof, are shown stored in the memory 304 of the electronic device 300, but can be implemented using any form of computer-readable media accessible by the electronic device 300. Herein, the computer-readable media can be any available media or communication media that can be accessed by a computer. By way of example, and not limitation, computer-readable media can comprise computer-readable storage media and communication media. Computer-readable storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer-readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information in a computer-readable format, and which can be accessed by the electronic device 300. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The foregoing examples of computer-readable storage media and communication media are not exhaustive of all possible types of computer-readable media.

[0094] For example, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. For example, computer-readable storage media includes, but is not limited to, random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information in a computer-readable format, and which can be accessed by the electronic device 300.

[0095] One or more communication interfaces 309 are used to exchange data with other devices, such as over a network, a direct connection, etc. This communication interface can be one or more of any type of network interface, wired or wireless (e.g., WLAN) interface, Wi-MAX interface, Ethernet interface, USB interface, cellular network interface, Bluetooth interface, NFC interface, etc. The communication interface 309 can facilitate communication over a variety of network and protocol types, including wired and wireless networks, the Internet, etc. The communication interface 309 can also provide communication with external storage devices (not shown) such as storage arrays, network attached storage, storage area networks, etc. Figure 8

[0096] In some examples, a display device 301, such as a monitor, can be included for displaying information and images to a user. Other I / O devices 310 can be devices that receive user input and provide output to a user, and can include touch / gesture input devices, cameras, keyboards, remote controls, mice, audio input / output devices, etc.

[0097] ​The technical solutions described in the present application can be supported by these various configurations of the electronic device 300, and are not limited to the specific examples of the technical solutions described in the present application. The foregoing and the accompanying drawings in the present application are not restrictive, and it is obvious to those skilled in the art that the present application is not limited to the details of the above-mentioned exemplary embodiments, and the present application can be implemented in other specific forms without departing from the spirit or essential characteristics of the present application. Therefore, the scope of the present application claimed is defined by the claims, not the above description, and all changes falling within the meaning and scope of the equivalent elements of the claims are included in the scope of protection of the present application.

[0098] It should be noted that in this document, the terms "comprise", "comprising", or any other variant thereof are intended to cover non-exclusive inclusions, so that processes, methods, articles, or devices that include a series of elements not only include those elements, but also include other elements not explicitly listed, or inherent to such processes, methods, articles, or devices. Without more limitations, the element defined by the statement "comprises a" does not exclude the presence of additional identical elements in the process, method, article, or device that includes the element.

[0099] From the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be realized by means of software and a necessary general hardware platform, of course, they can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a computer readable storage medium (such as a ROM / RAM, a magnetic disk, or an optical disk) as described above, and includes a number of instructions for making a terminal device (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) execute the methods described in the various embodiments of the present application.

[0100] The above is only the preferred embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent structure or equivalent process transformation made by using the content of the present application specification and drawings, or directly or indirectly applied to other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for timing synchronization in a software HDL co-simulation system, comprising a clock management module and a DPI mutex module on the software side; a DUT model on the hardware side. and a DPI interface for software side and hardware side instruction interaction; characterized in that The method comprises: Step S1: The clock management module accesses a DPI mutex module to obtain a DPI interface state; Step S2: When the DPI interface state is a DPI interface idle, the clock management module obtains a time point of a previous call of the DPI interface and a current CPU time point, and calculates a time interval of the software side; Step S3: Based on the time interval, a simulation loop number of a DUT model is determined; Step S4: The clock management module calls the DPI interface to advance the simulation loop number of the DUT model, so as to realize timing synchronization between a simulation time domain and the software side; Steps S1 to S4 are repeated until the co-simulation ends.

2. The method of claim 1, wherein, Before any thread of the software side calls the DPI interface, the thread needs to access the DPI mutex module to obtain the DPI interface state.

3. The method of claim 1, wherein, The DPI interface state comprises a DPI interface idle and a DPI interface occupied.

4. The method of claim 3, wherein, When the DPI interface state is the DPI interface occupied, the clock management module waits for a loop period and then queries the DPI interface state again until the DPI interface state becomes the DPI interface idle.

5. The method of claim 3, wherein, When the DPI interface state is obtained as the DPI interface idle, the clock management module sets the DPI interface state as the DPI interface occupied and starts to call the DPI interface.

6. The method of claim 1, wherein, The clock management module applies to call the DPI interface at a set time loop interval.

7. The method of claim 1, wherein, The clock management module obtains a time point of a previous call of the DPI interface through a storage variable and obtains a current CPU time point through a system function.

8. The method of claim 1, wherein, The clock management module stores a time point of a current call of the DPI interface, which is used to determine the time interval when the DPI interface is called next time.

9. The method of claim 1, wherein, When the DPI interface call ends, the DPI interface state is modified as the DPI interface idle to release the DPI interface resource.

10. The method of claim 1, wherein, The clock management module enters a background sleep state after the DPI interface call ends.

11. The method of claim 1, wherein, Based on a conversion rate between the CPU time and the simulation loop, a loop number of the simulation time domain is obtained.

12. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions, and the computer instructions are used to make the processor execute the method in any one of claims 1 to 11.

13. An electronic device, comprising: The electronic device comprises: one or more processors; a memory for storing executable instructions; the one or more processors are configured to implement the method in any one of claims 1 to 11 via the executable instructions.

Images