Hardware simulation system, control method, electronic equipment and storage medium

Abstract

The invention discloses a hardware simulation system, a control method, electronic equipment and a storage medium, and relates to the technical field of analogue simulation. An external process interface module, a synchronous core module and a hardware simulation process interface module are matched with one another, and the external process interface module writes simulation data into an external push queue of the synchronous core module; the synchronization core module carries the data to the local pull queue of the hardware simulation process interface module when the conditions are met, the hardware simulation process can obtain the data by accessing the local pull queue, and the access conflict of shared resources is reduced in the whole process. Therefore, the technical problem that the shared resource locking time between the hardware simulation process and the processes of other processor cores is long in the related technology is solved, and the technical effect of improving the hardware simulation efficiency of the integrated circuit is achieved.

Description

Technical Field

[0001] The present application relates to the field of simulation technology, and in particular to a hardware simulation system, a control method, an electronic device and a storage medium. Background Art

[0002] The hardware design of integrated circuits such as System on Chip (SoC) is relatively complex and involves the integration of many functional modules. Therefore, it is necessary to perform simulation before hardware implementation to confirm the rationality of the hardware architecture in advance and improve the development efficiency of SoC.

[0003] Among them, hardware simulation processes such as SystemC are important tools for electronic system level design (ESL), supporting transaction level modeling (TLM), and can describe the functions and architecture of the entire circuit system of SoC without being trapped in the complicated signal timing and gate circuits of hardware circuits.

[0004] However, in the scenario of multi-core processors, the hardware simulation process can only be applied to a single processor core. When the hardware simulation process is linked and simulated with processes of other processor cores, the shared resources between the hardware simulation process and the processes of other processor cores are often locked for a long time, thereby reducing the hardware simulation efficiency of the integrated circuit. Summary of the invention

[0005] The present application provides a hardware simulation system, a control method, an electronic device and a storage medium, so as to at least solve the problem in the related art that the shared resource locking time between the hardware simulation process and the processes of other processor cores is long, thereby reducing the hardware simulation efficiency of the integrated circuit.

[0006] The present application provides a hardware simulation system, comprising: an external process interface module, a synchronization core module and a hardware simulation process interface module; The external process interface module is used to receive simulation data sent by the external process and write the simulation data into the external push queue; The synchronization core module is used to move the simulation data in the external push queue to the local pull queue of the hardware simulation process interface module and send simulation events to the hardware simulation process interface module when the external push queue is not empty and the current state of the external push queue is idle; The hardware simulation process interface module is used to receive simulation events, and in response to the simulation events, trigger the hardware simulation process so that the hardware simulation process obtains simulation data sent by the external process by accessing the local pull queue.

[0007] The present application also provides a hardware simulation system control method, which is applied to any of the above-mentioned hardware simulation systems, and the method comprises: When the simulation data sent by the external process is obtained, the external process interface module is controlled to write the simulation data into the external push queue; When the external push queue is not empty and the current state of the external push queue is idle, the control synchronization core module moves the simulation data in the external push queue to the local pull queue of the hardware simulation process interface module; The hardware simulation process interface module is controlled to trigger the hardware simulation process, so that the hardware simulation process obtains the simulation data sent by the external process by accessing the local pull queue.

[0008] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing any of the above-mentioned hardware simulation system control steps when executing the computer program.

[0009] The present application also provides a computer-readable storage medium, in which a computer program is stored, wherein when the computer program is executed by a processor, any of the above-mentioned steps of hardware simulation system control is implemented.

[0010] The present application also provides a computer program product, including a computer program, which implements any of the above-mentioned steps of hardware simulation system control when executed by a processor.

[0011] Through this application, since the external process interface module, the synchronous core module and the hardware simulation process interface module cooperate with each other, the external process interface module writes the simulation data into the external push queue of the synchronous core module, and the synchronous core module moves the data to the local pull queue of the hardware simulation process interface module when the conditions are met. The hardware simulation process can obtain data by accessing the local pull queue, and the whole process reduces the shared resource access conflict. Therefore, the technical problem of the long shared resource locking time between the hardware simulation process and the processes of other processor cores in the related technology is solved, and the technical effect of improving the hardware simulation efficiency of the integrated circuit is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in 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 paying any creative work.

[0013] Figure 1 A schematic diagram of the interaction process of the hardware simulation system provided in the embodiment of the present application; Figure 2 A schematic diagram of the structure of a hardware simulation system provided in an embodiment of the present application; Figure 3 A schematic diagram of an execution flow of a hardware simulation system provided in an embodiment of the present application; Figure 4 A schematic diagram of the execution flow of another hardware simulation system provided in an embodiment of the present application; Figure 5 A schematic diagram of an execution flow of another hardware simulation system provided in an embodiment of the present application; Figure 6 A schematic diagram of the network structure of the hardware simulation system provided in the embodiment of the present application; Figure 7 A schematic diagram of the execution flow of the simulation maintenance unit provided in the embodiment of the present application; Figure 8 It is a structural diagram of the traditional system; Fig. 9 This is a schematic diagram of the shared resource access delay of the traditional system; Fig.10 A schematic diagram of the structure of an exemplary hardware simulation system provided in an embodiment of the present application; Fig.11 A schematic diagram of shared resource access delay of a hardware simulation system provided in an embodiment of the present application; Fig.12 A flowchart of a hardware simulation system control method provided in an embodiment of the present application; Fig.13 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0015] It should be noted that, in the description of this application, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in this application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0016] The difficulty of SoC design stems from its complexity. Complexity gave rise to SystemC and electronic system level design (ESL) methodology. Transaction processing level modeling is the key to electronic system level design. For complex SoCs, in-depth system level simulation is required before RTL design to confirm whether the designed architecture is appropriate, whether the bus can meet the throughput and real-time requirements, and whether the memory is wasted. In order to shorten the design cycle of SoC key IP and assist the design process, and to shorten the gap between system architecture design and hardware RTL circuit implementation, a modeling methodology is needed to describe the function and architecture of the entire circuit system without falling into the complicated signal timing and gate circuits of the hardware circuit. Therefore, ESL electronic system level design came into being. The ESL design methodology is used to describe the system at an appropriate level of abstraction, construct a virtual hardware prototype platform, explore the hardware architecture and develop software programs, and achieve rapid system modeling and simulation analysis. The core of ESL is TLM, that is, transaction level modeling method.

[0017] In the related art, the mainstream modeling method for chip circuit systems is to develop models based on the SystemC standard. However, since the SystemC simulation kernel (SystemC kernal) is single-threaded, that is, although it can simulate hardware concurrent behavior, it cannot simulate software concurrent behavior. The entire SystemC kernal can only run on a single host core. When the host is a multi-core CPU, it cannot effectively improve the utilization rate. Therefore, it is necessary to communicate between the SystemC process and the process of the external operating system. Since the SystemC process and the process of the external operating system are completely asynchronous, it is necessary to consider the synchronization between different processes.

[0018] Problems with the traditional communication method between operating system processes and SystemC processes: (1) SystemC itself is not thread-safe, and random injections from the outside may destroy the simulation. Therefore, in order to avoid losing external events and not destroying the simulation of SystemC itself, it is necessary to use a shared thread-safe container defined in the middle to receive and transfer them. The traditional SystemC model process needs to use polling to obtain event notifications from external processes from the shared thread-safe container, which reduces the execution efficiency of SystemC; (2) When it comes to asynchronous communication programming, it is necessary to ensure that the shared resources used in the two parallel threads are protected. The traditional method locks the shared resources (such as thread-safe containers) of the operating system process and the SystemC model process for a long time. The external operating system process and the SystemC model process can only access the shared thread-safe container completely and mutually exclusively, which is not conducive to exerting the maximum performance of the system.

[0019] In order to solve the above technical problems, the embodiment of the present application provides a hardware simulation system, a control method, an electronic device and a storage medium, the system comprising: an external process interface module, a synchronization core module and a hardware simulation process interface module; the external process interface module is used to receive the simulation data sent by the external process and write the simulation data into the external push queue; the synchronization core module is used to move the simulation data in the external push queue to the local pull queue of the hardware simulation process interface module when the external push queue is not empty and the current state of the external push queue is idle, and send a simulation event to the hardware simulation process interface module; the hardware simulation process interface module is used to receive the simulation event, and in response to the simulation event, trigger the hardware simulation process, so that the hardware simulation process obtains the simulation data sent by the external process by accessing the local pull queue. In the system provided by the above scheme, the hardware simulation process can obtain data by accessing the local pull queue, and the whole process reduces the shared resource access conflict between the hardware simulation process and the external process, and improves the hardware simulation efficiency of the integrated circuit.

[0020] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0021] An embodiment of the present application provides a hardware simulation system for integrated circuit hardware simulation in a multi-core processor scenario.

[0022] like Figure 1 As shown, it is a schematic diagram of the interaction process of the hardware simulation system provided in an embodiment of the present application. The system includes: an external process interface module, a synchronization core module and a hardware simulation process interface module.

[0023] Among them, the external process interface module is used to receive the simulation data sent by the external process and write the simulation data into the external push queue; the synchronous core module is used to move the simulation data in the external push queue to the local pull queue of the hardware simulation process interface module when the external push queue is not empty and the current state of the external push queue is idle, and send simulation events to the hardware simulation process interface module; the hardware simulation process interface module is used to receive simulation events, and in response to simulation events, trigger the hardware simulation process so that the hardware simulation process obtains the simulation data sent by the external process by accessing the local pull queue. Internally, by defining two-level cache queues (external push queues and local pull queues) for data storage and fast pulling, the locking time of shared resources accessed by SystemC (hardware simulation process) and external processes is kept to a minimum, and the mutual influence between the SystemC process end and the external process end is minimized, which effectively improves the simulation efficiency of the system.

[0024] It should be noted that the external process and the hardware simulation process run on different processor cores. The external process can be a C++ process. The external process includes the operating system process of a multi-core processor, the hardware simulation process running on other processor cores, or the hardware simulation process running on other host terminals. The external process is at least the source of data required by the hardware simulation process. The external process is used to generate simulation data. The external process and the hardware simulation process can jointly realize the hardware simulation of integrated circuits such as SoC.

[0025] Among them, the simulation data at least includes hardware simulation events and simulation key data of hardware simulation events. Hardware simulation events include data read and write events, clock signal change events, and interrupt request events. Taking data read and write events as an example, the corresponding simulation key data include data read and write addresses, data read and write lengths, and write data content (data values).

[0026] Based on the above embodiments, Figure 2 The schematic diagram of the structure of the hardware simulation system provided in the embodiment of the present application is as an implementable manner. In one embodiment, the system further includes: The shared resource management module is used to record the current status of the external push queue. The current status of the external push queue is divided into two types: busy and idle.

[0027] The shared resource management module is provided with a critical section state mark, and the shared resource management module distinguishes and indicates the current state of the external push queue based on the critical section state mark. The shared resource management module is mutually exclusive accessed by the external process interface module and the synchronous core module.

[0028] Among them, the shared resources in the embodiment of the present application include an external push queue (push_deque) and a local pull queue (pop_deque). When the external process interface module is executing the operation of writing events to the push_deque, the synchronization core module cannot pull tasks from the push_deque to the pop_deque. When the synchronization core module is pulling tasks from the push_deque to the pop_deque, the external process interface module cannot execute the operation of writing events to the push_deque. Through the management of the shared resource management module, it is ensured that the locking time of the shared resource is only the time when the event task is written to the push_deque, or the time when the event task is moved from the push_deque to the pop_deque. The locking time of this method is not interfered by the external process and the hardware simulation process itself, which can minimize the locking time of the shared resource and maximize the execution efficiency of the SystemC end.

[0029] Specifically, in one embodiment, the external process interface module is used to read the current state of the external push queue from the shared resource management module after obtaining the simulation data sent by the external process; when it is determined that the current state of the external push queue is idle, the current state of the external push queue is set to busy, and the simulation data is written to the external push queue; after completing the writing of the simulation data, a synchronization event is sent to the synchronization core module, and the current state of the external push queue is set to idle.

[0030] Specifically, after the external process interface module receives the simulation data sent by the external process, it first reads the current state of the external push queue from the shared resource management module to determine whether the current external push queue can receive new data, so as to avoid forcibly writing data when the queue is being used, thereby causing data conflict or overwriting. If the current state of the external push queue is idle, the external process interface module will set its state to busy to lock the shared resource (external push queue), indicating to other modules that the queue is being used, preventing other processes or modules from operating it at the same time, and ensuring the security and integrity of data writing. The external process interface module writes the received simulation data into the external push queue. After completing the writing of the simulation data, the external process interface module sends a synchronization event to the synchronization core module to inform the synchronization core module that there is new data in the external push queue that can be processed. At the same time, the external process interface module resets the state of the external push queue to idle to release the shared resource.

[0031] Among them, Figure 3 As shown, it is a schematic diagram of the execution flow of a hardware simulation system provided by an embodiment of the present application. The external process interface module is provided with an asynchronous request call interface, and the external process sends simulation data by calling the asynchronous request call interface. The external process first queries the critical section state (the current state of the external push queue) inside the shared resource management module through the asynchronous request call interface. If it is busy, it blocks and waits; if it is idle, it locks the critical section, that is, sets the critical section state to busy (sets the current state of the external push queue to busy); stores the event (simulation data) in the external push queue (push_deque), calls the internal notification method (remembered as notify method), notifies the process synchronization core module to start processing, that is, sends a synchronization event to the synchronization core module; finally releases the critical section, that is, sets the critical section state to idle (sets the current state of the external push queue to idle).

[0032] Accordingly, in one embodiment, the synchronization core module is used to receive a synchronization event sent by the external process interface module; when a synchronization event is obtained, it is determined that the external push queue is not empty.

[0033] On the basis of the above embodiments, as an implementable method, in one embodiment, the synchronization core module is also used to determine whether the local pull queue meets the simulation data transfer conditions; when it is determined that the local pull queue meets the simulation data transfer conditions, the simulation data in the external push queue is transferred to the local pull queue of the hardware simulation process interface module when the external push queue is not empty and the current state of the external push queue is idle.

[0034] Specifically, the synchronization core module evaluates the status and data status of the local pull queue to determine whether the conditions for moving simulation data are met. The local pull queue has data capacity limitations or specific data processing rules. Only when these conditions are met will subsequent data moving operations be performed to ensure the normal operation of the data moving operation.

[0035] Specifically, in one embodiment, the synchronization core module is also used to obtain data cache information of the local pull queue; when the data cache information of the local pull queue indicates that the local pull queue is an empty queue, it is determined that the local pull queue meets the simulation data transfer condition.

[0036] The data cache information at least includes the data cache amount of the current queue.

[0037] Specifically, in one embodiment, the synchronization core module is used to set the current state of the external push queue to busy when the external push queue is not empty and the current state of the external push queue is idle; transfer the simulation data in the external push queue to the local pull queue; after completing the transfer of the simulation data, send a simulation event to the hardware simulation process interface module, and set the current state of the external push queue to idle.

[0038] Specifically, Figure 4As shown, it is a schematic diagram of the execution flow of another hardware simulation system provided by an embodiment of the present application. The process synchronization core module includes an event triggering unit and a simulation maintenance unit, wherein the event triggering unit is triggered by the synchronization event of the external process interface module, and calls the internal update function (referred to as Update_function) to realize the event (simulation data) from the external push queue to the local pull queue (the local queue is defined in the SystemC process interface module (hardware simulation process interface module), referred to as pop_deque). First, the event triggering unit responds to the synchronization event, checks whether the local pull queue is an empty queue, if not empty, blocks and waits, otherwise further queries the critical section status inside the shared resource management module, if it is busy, blocks and waits; if it is idle (the current state of the external push queue is idle), locks the critical section, that is, sets the critical section status to busy; moves the event task (simulation data) of the external push queue to the local pull queue, and after completing the simulation data movement, releases the critical section, that is, sets the critical section status to idle, and calls the event notification method of the SystemC process interface module, that is, sends the simulation event to the hardware simulation process interface module.

[0039] Accordingly, in one embodiment, if Figure 5 As shown, it is a schematic diagram of the execution flow of another hardware simulation system provided in an embodiment of the present application. After obtaining the simulation event, the hardware simulation process interface module initiates a corresponding event notification to the hardware simulation process (SystemC model process) through the event notification method. The hardware simulation process responds to the event notification based on the event processing process to obtain simulation data from the local pull queue in the hardware simulation process interface module.

[0040] Based on the above embodiment, as an implementable manner, in one embodiment, the synchronization core module includes: a simulation maintenance unit; The simulation maintaining unit is used to perform cyclic detection on the current simulation state of the hardware simulation process so as to keep the hardware simulation system in a running state.

[0041] It should be noted that the system provided in the embodiment of the present application is applied to the SystemC simulation core, and the role of the simulation maintenance unit is mainly to keep the SystemC simulation core in a running state and not to exit midway. The simulation maintenance unit continuously checks the current simulation state of the hardware simulation process, and the checking process is performed in a cyclic manner. During the whole process, no matter what state the hardware simulation process is in, the simulation maintenance unit will not stop the cyclic detection, so as to maintain the continuous operation of the SystemC simulation core.

[0042] Among them, Figure 6As shown, it is a schematic diagram of the network structure of the hardware simulation system provided by the embodiment of the present application. The hardware simulation system is also called a synchronous control device. The hardware simulation system and the hardware simulation process are configured in the same hardware simulation core (SystemC simulation core). The hardware simulation core and the external process belong to different processors and processes, that is, the hardware simulation core and the external process belong to two different host processes (such as Figure 6 The hardware emulation system provided by the embodiment of the present application enables processes running on different host processes to communicate, and the hardware emulation process can receive external events from external operating system processes.

[0043] Specifically, in one embodiment, the simulation maintenance unit is used to query the current simulation state of the hardware simulation process; when the current simulation state of the hardware simulation process is a busy state, after an interval of a preset basic cycle, the process of querying the current simulation state of the hardware simulation process is returned; when the current simulation state of the hardware simulation process is an idle state, after an interval of a preset sleep cycle, the process of querying the current simulation state of the hardware simulation process is returned.

[0044] The preset sleep cycle is greater than the preset basic cycle. The above method can ensure that the simulation is always running and will not be exited midway, and can also avoid the problem of reaching a very large timestamp very quickly by directly waiting in an infinite loop.

[0045] Specifically, Figure 7 As shown, it is a schematic diagram of the execution flow of the simulation maintenance unit provided in the embodiment of the present application. The simulation maintenance unit enters the simulation state detection through an infinite loop. The simulation maintenance unit determines whether the current simulation state of the hardware simulation process is a busy state by obtaining the working state flag of the hardware simulation process (SystemC process). When the simulation maintenance unit detects that the hardware simulation process is in a busy state, it means that the process is processing data or executing related simulation tasks. At this time, the simulation maintenance unit will query the state of the hardware simulation process again after a preset basic cycle interval, and continuously monitor its progress; when it is detected that the hardware simulation process is in an idle state, the simulation maintenance unit will recheck the state after a preset sleep cycle interval, that is, the simulation maintenance unit first enters sleep, waits for the wake-up cycle time (preset sleep cycle), and then the simulation maintenance unit is awakened. After waking up, the working state flag of the hardware simulation process is obtained. The system provided by the embodiment of the present application avoids frequent queries and wastes system resources when the process is idle, realizes the reasonable allocation and efficient use of system resources, and at the same time avoids the rapid growth of timestamps, ensures the rationality of simulation time advancement, and improves simulation efficiency.

[0046] Specifically, in one embodiment, the simulation maintenance unit can adjust the query period in real time according to factors such as the historical operation data of the hardware simulation process, the current system load, and the priority of the simulation task. The query period includes a preset basic period and a preset sleep period.

[0047] Exemplarily, when the hardware simulation process is handling a critical task and the system load is low, the preset basic period is automatically shortened to query the status more frequently, ensuring the execution progress and accuracy of the critical task; when multiple simulation tasks are carried out simultaneously, resulting in a high system load, the preset sleep period is appropriately extended to reduce unnecessary query operations and avoid excessive consumption of system resources. This improves the system's adaptability to complex environments and further optimizes resource utilization and simulation efficiency.

[0048] To facilitate those skilled in the art to better understand the technical improvements and effects of the hardware simulation system provided in the embodiments of the present application compared with traditional systems, as Figure 8 shown, it is a schematic structural diagram of a traditional system. Generally, a traditional system has only one shared queue, and this shared queue is accessed mutually exclusively by the external operating (simply denoted as OS) system process and the SystemC model process.

[0049] Among them, as Fig. 9 shown, it is a schematic diagram of the access delay of shared resources in a traditional system. Among them, the time t1 refers to the delay of the external operating system process operating on the shared queue, and this part of the delay is affected by the execution time of the operating system process itself; the time t2 refers to the delay of the SystemC process operating on the shared queue, and this part of the delay is affected by the execution time of the SystemC process itself (generally, the execution speed of the SystemC process is slower than that of the external operating system process, so t1 < t2); when the system is running, the time that must be executed sequentially is t, that is, within the time t, only 1 task can be executed. At this time, the external operating system process and the SystemC process are executed alternately, and neither the external operating system process nor the SystemC process reaches the highest execution efficiency. Especially when the relatively slow SystemC process is processing two tasks, the time is discontinuous.

[0050] To form a comparison with the traditional system, as Fig.10 shown, it is a schematic structural diagram of an exemplary hardware simulation system provided in the embodiments of the present application. In the embodiments of the present application, the shared resources include an external push queue and a local pull queue.

[0051] Among them, as Fig.11As shown in the figure, it is a schematic diagram of the access delay of shared resources of the hardware simulation system provided by the embodiment of the present application. Among them, the time t1 refers to the delay of the external operating system operating on the shared queue, and this part of the delay is affected by the execution time of the operating system process itself; the time t2 refers to the delay of the SystemC process operating on the shared queue, and this part of the delay is affected by the execution time of the SystemC process itself (generally, the execution speed of the SystemC process is slower than that of the external operating system process, so t1 < t2); the time Δt refers to the delay time for the synchronization controller to transfer the tasks in the external push queue to the local pull queue internally, and this time is not affected by any external process, so the execution speed is much higher than the time t1 and t2 (Δt < t1 < t2); when the system is running, the time that must be executed sequentially is , this part of the time does not include t2, that is, within time, 1 task can be executed. At this time, although the external operating system process and the SystemC process are executed alternately, the execution efficiency of the external operating system process is improved, and the SystemC process can reach the maximum execution efficiency, that is, after the first task of the SystemC is processed, the second task can be processed immediately, without waiting idle time in the middle.

[0052] The embodiment of the present application provides a hardware simulation system, including: an external process interface module, a synchronization core module, and a hardware simulation process interface module; the external process interface module is used to receive simulation data sent by an external process and write the simulation data into the external push queue; the synchronization core module is used to transfer the simulation data in the external push queue to the local pull queue of the hardware simulation process interface module and send a simulation event to the hardware simulation process interface module when the external push queue is not empty and the current state of the external push queue is idle; the hardware simulation process interface module is used to receive the simulation event and trigger the hardware simulation process in response to the simulation event, so that the hardware simulation process obtains the simulation data sent by the external process by accessing the local pull queue. In the system provided by the above solution, the hardware simulation process can obtain data by accessing the local pull queue. The entire process reduces the access conflict of shared resources between the hardware simulation process and the external process, and improves the hardware simulation efficiency of the integrated circuit. Moreover, it has good encapsulation. Through this system, the isolation between the SystemC model process and the external operating system process can be realized. The SystemC model process part does not need to directly access the external process (such as pthread in C++), and does not need to change the semantics of SystemC itself. Moreover, the internal simulation process interface module realizes notifying the SystemC model process through events, which reduces the scheduling resources of the SystemC simulation kernel compared with the traditional method that the SystemC model process needs to periodically poll the external process security container.

[0053] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method.

[0054] An embodiment of the present application also provides a hardware simulation system control method, which is applied to the hardware simulation system provided by the above-mentioned implementation. The executor of the hardware simulation system control method provided by the embodiment of the present application is an electronic device, such as a server, a desktop computer, a laptop computer, a tablet computer and other electronic devices that can be used for integrated circuit hardware simulation.

[0055] like Fig.12 FIG. 1 is a flow chart of a hardware simulation system control method provided in an embodiment of the present application. The method includes: Step 1201, when the simulation data sent by the external process is obtained, the external process interface module is controlled to write the simulation data into the external push queue; Step 1202, when the external push queue is not empty and the current state of the external push queue is idle, control the synchronization core module to move the simulation data in the external push queue to the local pull queue of the hardware simulation process interface module; Step 1203, controlling the hardware simulation process interface module to trigger the hardware simulation process, so that the hardware simulation process obtains the simulation data sent by the external process by accessing the local pull queue.

[0056] For the description of the features in the embodiment corresponding to the hardware simulation system control method, reference can be made to the relevant description of the embodiment corresponding to the hardware simulation system, which will not be repeated here.

[0057] The embodiment of the present application also provides an electronic device, such as Fig.13 As shown, it is a structural schematic diagram of an electronic device provided in an embodiment of the present application, including a processor 10 and a memory 20, in which a computer program is stored, and the processor 10 is configured to run the computer program to execute the steps in any of the above-mentioned hardware simulation system control method embodiments.

[0058] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned hardware simulation system control method embodiments when running.

[0059] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0060] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned hardware simulation system control method embodiments are implemented.

[0061] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, the non-volatile computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned hardware simulation system control method embodiments are implemented.

[0062] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0063] The above is a detailed introduction to a hardware simulation system, control method, electronic device and storage medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application, and the description of the above embodiments is only used to help understand the method and core idea of ​​the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A hardware simulation system, characterized in that: include: External process interface module, synchronization core module and hardware simulation process interface module; The external process interface module is used to receive simulation data sent by the external process and write the simulation data into the external push queue; The synchronization core module is used for moving the simulation data in the external push queue to the local pull queue of the hardware simulation process interface module and sending simulation events to the hardware simulation process interface module when the external push queue is not empty and the current state of the external push queue is idle; The hardware simulation process interface module is used to receive the simulation event and trigger the hardware simulation process in response to the simulation event, so that the hardware simulation process obtains the simulation data sent by the external process by accessing the local pull queue.

2. The hardware simulation system according to claim 1, characterized in that: The system further comprises: The shared resource management module is used to record the current status of the external push queue, where the current status of the external push queue is divided into two types: busy and idle.

3. The hardware simulation system according to claim 2, characterized in that: The external process interface module is used to: After obtaining the simulation data sent by the external process, reading the current state of the external push queue from the shared resource management module; When determining that the current state of the external push queue is idle, setting the current state of the external push queue to busy, and writing the simulation data into the external push queue; After the writing of the simulation data is completed, a synchronization event is sent to the synchronization core module, and the current state of the external push queue is set to idle.

4. The hardware simulation system according to claim 3, characterized in that: The synchronous core module is used for: Receiving the synchronization event sent by the external process interface module; When the synchronization event is obtained, it is determined that the external push queue is not empty.

5. The hardware simulation system according to claim 1, characterized in that: The synchronous core module is also used for: Determine whether the local pull queue meets the simulation data handling condition; When it is determined that the local pull queue meets the simulation data transfer conditions, the process of transferring the simulation data in the external push queue to the local pull queue of the hardware simulation process interface module is executed when the external push queue is not empty and the current state of the external push queue is idle.

6. The hardware simulation system according to claim 5, characterized in that: The synchronous core module is also used for: Obtain data cache information of the local pull queue; When the data cache information of the local pull queue indicates that the local pull queue is an empty queue, it is determined that the local pull queue meets the simulation data transfer condition.

7. The hardware simulation system according to claim 1, characterized in that: The synchronous core module is used for: When the external push queue is not empty and the current state of the external push queue is idle, setting the current state of the external push queue to busy; Transferring the simulation data in the external push queue to the local pull queue; After completing the transfer of the simulation data, a simulation event is sent to the hardware simulation process interface module, and the current state of the external push queue is set to idle.

8. The hardware simulation system according to claim 1, characterized in that: The synchronous core module includes: a simulation maintenance unit; The simulation maintaining unit is used to perform cyclic detection on the current simulation state of the hardware simulation process, so that the hardware simulation system is always in a running state.

9. The hardware simulation system according to claim 8, characterized in that: The simulation maintaining unit is used for: Query the current simulation status of the hardware simulation process; When the current simulation state of the hardware simulation process is a busy state, after a preset basic period, returning to execute the process of querying the current simulation state of the hardware simulation process; When the current simulation state of the hardware simulation process is an idle state, after a preset sleep cycle, returning to execute the process of querying the current simulation state of the hardware simulation process; Wherein, the preset sleep period is greater than the preset basic period.

10. The hardware simulation system according to claim 1, characterized in that: The external process and the hardware simulation process run on different processor cores.

11. The hardware simulation system according to claim 1, characterized in that: The simulation data at least includes a hardware simulation event and simulation key data of the hardware simulation event.

12. A method for controlling a hardware simulation system, applied to the hardware simulation system according to any one of claims 1 to 11, characterized in that: The method comprises: When the simulation data sent by the external process is obtained, the external process interface module is controlled to write the simulation data into the external push queue; When the external push queue is not empty and the current state of the external push queue is idle, control the synchronization core module to move the simulation data in the external push queue to the local pull queue of the hardware simulation process interface module; The hardware simulation process interface module is controlled to trigger the hardware simulation process, so that the hardware simulation process obtains the simulation data sent by the external process by accessing the local pull queue.

13. An electronic device, characterized in that: include: Memory for storing computer programs; A processor is used to implement the steps of the hardware simulation system control method as claimed in claim 12 when executing the computer program.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the hardware simulation system control method as claimed in claim 12.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the hardware simulation system control method as claimed in claim 12 are implemented.

Images