A hardware simulation system, control method, electronic device, and storage medium

Abstract

The present application discloses a hardware simulation system, a control method, an electronic device, and a storage medium, relating to the technical field of simulation. Since the external process interface module, the synchronization core module, and the hardware simulation process interface module cooperate with each other, the external process interface module writes simulation data into the external push queue of the synchronization core module. When the conditions are met, the synchronization core module transfers the data to the local pull queue of the hardware simulation process interface module. The hardware simulation process can obtain the data by accessing the local pull queue. The entire process reduces the access conflict of shared resources. Therefore, the technical problem of the long locking time of shared resources between the hardware simulation process and the processes of other processor cores in the related art is solved, and the technical effect of improving the hardware simulation efficiency of integrated circuits is achieved.

Description

Technical Field

[0001] This application relates to the field of simulation technologies, and particularly 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, involving the integration of numerous functional modules. Therefore, it is necessary to perform simulation before hardware implementation to confirm the rationality of its hardware architecture in advance, so as to improve the development efficiency of SoC.

[0003] Among them, hardware simulation processes such as SystemC are important tools for Electronic System Level (ESL) design, supporting Transaction Level Modeling (TLM), capable of describing the functions and architectures of the entire circuit system of SoC, without getting involved in the complex signal timings and gate circuits of the hardware circuit.

[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 performs joint simulation with the processes of other processor cores, there is often a long locking time for shared resources between the hardware simulation process and the processes of other processor cores, reducing the hardware simulation efficiency of integrated circuits. Summary of the Invention

[0005] This application provides a hardware simulation system, a control method, an electronic device, and a storage medium to at least solve the problem in related technologies that the locking time of shared resources between the hardware simulation process and the processes of other processor cores is relatively long, reducing the hardware simulation efficiency of integrated circuits.

[0006] This application provides a hardware simulation system, including: an external process interface module, a synchronization core module, and a hardware simulation process interface module;

[0007] The external process interface module is used to receive simulation data sent by an external process and write the simulation data into an external push queue;

[0008] 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 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;

[0009] The hardware simulation process interface module is used to receive simulation events and, in response to the simulation events, trigger a hardware simulation process so that the hardware simulation process can obtain simulation data sent by an external process by accessing a local pull queue.

[0010] This application also provides a method for controlling a hardware simulation system, which is applied to any of the above hardware simulation systems. The method includes:

[0011] When obtaining simulation data sent by an external process, control the external process interface module to write the simulation data into an external push queue;

[0012] 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 transfer the simulation data in the external push queue to the local pull queue of the hardware simulation process interface module;

[0013] Control the hardware simulation process interface module to trigger a hardware simulation process so that the hardware simulation process can obtain simulation data sent by an external process by accessing the local pull queue.

[0014] This application also provides an electronic device, including: a memory for storing a computer program; a processor for implementing the steps of controlling any of the above hardware simulation systems when executing the computer program.

[0015] This application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of controlling any of the above hardware simulation systems are implemented.

[0016] This application also provides a computer program product, including a computer program. When the computer program is executed by a processor, the steps of controlling any of the above hardware simulation systems are implemented.

[0017] Through this application, since the external process interface module, the synchronization 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 synchronization core module. The synchronization core module transfers 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 entire process reduces the access conflicts of shared resources. Therefore, the technical problem of the long locking time of shared resources 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 integrated circuits is achieved. Description of the Drawings

[0018] To more clearly illustrate the embodiments of the present application, the following will briefly introduce the accompanying drawings required in the embodiments. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.

[0019] Figure 1 Schematic diagram of the interaction process of the hardware simulation system provided by the embodiment of the present application;

[0020] Figure 2 Schematic diagram of the structure of the hardware simulation system provided by the embodiment of the present application;

[0021] Figure 3 Schematic diagram of the execution process of a hardware simulation system provided by the embodiment of the present application;

[0022] Figure 4 Schematic diagram of the execution process of another hardware simulation system provided by the embodiment of the present application;

[0023] Figure 5 Schematic diagram of the execution process of yet another hardware simulation system provided by the embodiment of the present application;

[0024] Figure 6 Schematic diagram of the network structure of the hardware simulation system provided by the embodiment of the present application;

[0025] Figure 7 Schematic diagram of the execution process of the simulation maintenance unit provided by the embodiment of the present application;

[0026] Figure 8 Schematic diagram of the structure of the traditional system;

[0027] Figure 9 Schematic diagram of the access delay of shared resources in the traditional system;

[0028] Figure 10 Schematic diagram of the structure of an exemplary hardware simulation system provided by the embodiment of the present application;

[0029] Figure 11 Schematic diagram of the access delay of shared resources in the hardware simulation system provided by the embodiment of the present application;

[0030] Figure 12 Schematic diagram of the process of the hardware simulation system control method provided by the embodiment of the present application;

[0031] Figure 13 Schematic diagram of the structure of the electronic device provided by the embodiment of the present application. Detailed implementation manners

[0032] The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present application.

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

[0034] The difficulty in the design of SoC stems from its complexity. The complexity has given rise to SystemC and the electronic system level (ESL) design methodology. Transaction-level modeling is the key to ESL 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 the key IP of SoC and assist the design process, and at the same time to shorten the gap between system architecture design and hardware RTL circuit implementation, a modeling methodology is needed to describe the functions and architecture of the entire circuit system without getting involved in the complex signal timing and gate circuits of the hardware circuit. Therefore, ESL electronic system-level design has emerged. Using the ESL design methodology to describe the system at an appropriate abstraction level, construct a virtual hardware prototype platform, explore the hardware architecture and develop software programs to achieve rapid system modeling and simulation analysis. The core of ESL is TLM, that is, the transaction-level modeling method.

[0035] 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 is single-threaded, that is, although it can simulate the concurrent behavior of hardware, it cannot simulate the concurrent behavior of software, and the entire SystemC kernel can only run on a single host kernel. When the host is a multi-core CPU, the utilization rate cannot be effectively improved. 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.

[0036] Problems existing in the traditional communication methods between operating system processes and SystemC processes:

[0037] (1) SystemC itself is not thread-safe, and random injection from the outside may disrupt the simulation. Therefore, in order to avoid losing external events and not disrupting the simulation of SystemC itself, it is necessary to receive and transfer through an intermediate defined shared thread-safe container. The SystemC model process of the traditional method needs to use a polling method to obtain event notifications from external processes from the shared thread-safe container, thus reducing the execution efficiency of SystemC;

[0038] (2) When it comes to asynchronous communication programming, it is necessary to ensure that the shared resources used in two parallel threads are protected. The traditional method has a long locking time for the shared resources (such as thread-safe containers) of the operating system process and the SystemC model process. The external operating system process and the SystemC model process can only access the shared thread-safe container in a completely mutually exclusive manner, so it is not conducive to maximizing the performance of the system.

[0039] In order to solve the above technical problems, the embodiments of the present application provide a hardware simulation system, a control method, an electronic device, and a storage medium. The system includes: 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 an 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 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 can obtain 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, and the entire process reduces the access conflict of shared resources between the hardware simulation process and the external process, improving the hardware simulation efficiency of the integrated circuit.

[0040] In order to enable those skilled in the art of the present technology to better understand the solution of the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0041] The embodiments of the present application provide a hardware simulation system for hardware simulation of integrated circuits in a multi-core processor scenario.

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

[0043] Among them, the external process interface module is used to receive simulation data sent by an external process and write the simulation data into an 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 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 can obtain the simulation data sent by the external process by accessing the local pull queue. Internally, data storage and fast pull are performed by defining two-level cache queues (external push queue and local pull queue), keeping the locking time of shared resources accessed by SystemC (hardware simulation process) and external processes to a minimum, minimizing the mutual influence between the SystemC process side and the external process side, and effectively improving the simulation efficiency of the system.

[0044] 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, and the external process includes an operating system process of a multi-core processor, a hardware simulation process running on other processor cores, or a hardware simulation process running on other host sides, etc. 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, and the external process and the hardware simulation process can jointly implement the hardware simulation of integrated circuits such as SoC.

[0045] Among them, the simulation data at least includes hardware simulation events and simulation key data of hardware simulation events. The hardware simulation events include data read / write events, clock signal change events, and interrupt request events, etc. Taking the data read / write event as an example, the corresponding simulation key data includes data read / write addresses, data read / write lengths, and written data contents (data values), etc.

[0046] Based on the above embodiments, as Figure 2 is a schematic structural diagram of the hardware simulation system provided by the embodiment of the present application. As an implementable manner, in one embodiment, the system further includes:

[0047] A shared resource management module, which is used to record the current state of the external push queue. The current state of the external push queue is divided into two types: busy and idle.

[0048] Among them, a critical section state flag is set in the shared resource management module, and the shared resource management module distinguishes and represents the current state of the external push queue based on the critical section state flag. The shared resource management module is mutually exclusive accessed by the external process interface module and the synchronization core module.

[0049] Among them, the shared resources in the embodiments 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 writing events to the push_deque, the synchronization core module cannot perform the operation of pulling 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 perform 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 writes to the push_deque, or the time when the event task transports from the push_deque to the pop_deque. The locking time in this way is not interfered by the external process and the hardware simulation process itself, and the locking time of the shared resource can be minimized, and the execution efficiency of the SystemC side can be maximized.

[0050] 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; in the case where the current state of the external push queue is determined to be idle, set the current state of the external push queue to busy, and write the simulation data into the external push queue; after completing the writing of the simulation data, send a synchronization event to the synchronization core module, and set the current state of the external push queue to idle.

[0051] 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, avoiding forcibly writing data when the queue is being used, which may cause data conflicts or overwrites. 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 and preventing other processes or modules from operating on it simultaneously, 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.

[0052] Among them, such as Figure 3As shown in the figure, it is a schematic diagram of the execution process 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. First, the external process queries the critical section status (the current status 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 status to busy (sets the current status of the external push queue to busy); stores the event (simulation data) in the external push queue (push_deque), calls the internal notification method (denoted as the notify method), and 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 status to idle (sets the current status of the external push queue to idle).

[0053] Correspondingly, in one embodiment, the synchronization core module is used to receive 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.

[0054] Based on the above embodiment, as an implementable manner, in one embodiment, the synchronization core module is further used to determine whether the local pull queue meets the simulation data transfer condition; in the case where it is determined that the local pull queue meets the simulation data transfer condition, 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 status of the external push queue is idle.

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

[0056] Specifically, in one embodiment, the synchronization core module is further used to obtain the data cache information of the local pull queue; in the case where 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.

[0057] Among them, the data cache information at least includes the data cache volume of the current queue.

[0058] 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.

[0059] Specifically, Figure 4 As 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.

[0060] 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.

[0061] Based on the above embodiment, as an implementable manner, in one embodiment, the synchronization core module includes: a simulation maintenance unit;

[0062] 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.

[0063] It should be noted that the system provided by the embodiments of the present application is applied to the SystemC simulation core. The main function of the simulation maintenance unit is to keep the SystemC simulation core in a running state and not exit midway. The simulation maintenance unit continuously checks the current simulation state of the hardware simulation process, and its checking process is carried out in a loop manner. Throughout the process, regardless of the state of the hardware simulation process, the simulation maintenance unit will not stop the loop detection, so as to maintain the continuous operation of the SystemC simulation core.

[0064] Among them, as Figure 6 shown, it is a schematic diagram of the network structure of the hardware simulation system provided by the embodiments 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 are different, that is, the hardware simulation core and the external process belong to two different host processes (such as Figure 6 host process 1 and host process 2 in the figure). The hardware simulation system provided by the embodiments of the present application enables processes running on different host processes to communicate, and the hardware simulation process can receive external events from the external operating system process.

[0065] 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 period, it returns 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 an interval of a preset sleep period, it returns to execute the process of querying the current simulation state of the hardware simulation process.

[0066] Among them, the preset sleep period is greater than the preset basic period. Through the above method, it can not only ensure that the simulation is always in a running state and does not exit midway, but also avoid the problem of quickly reaching a very large time stamp caused by directly waiting in a wireless loop.

[0067] Specifically, as Figure 7As shown, it is a schematic diagram of the execution process of the simulation maintenance unit provided by 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 indicates that the process is processing data or performing related simulation tasks. At this time, the simulation maintenance unit will query the status of the hardware simulation process again after an interval of a preset basic period, continuously monitoring its progress; when it detects that the hardware simulation process is in an idle state, the simulation maintenance unit will re-check the status after an interval of a preset sleep period, that is, the simulation maintenance unit first enters the sleep state and waits for the wake-up cycle time (preset sleep period), and then the simulation maintenance unit is awakened. After being awakened, it obtains the working state flag of the hardware simulation process. The system provided by the embodiment of the present application avoids wasting system resources by frequently querying when the process is idle, realizes the reasonable allocation and efficient utilization of system resources, and at the same time avoids the rapid growth of timestamps, ensures the rationality of the advancement of simulation time, and improves the simulation efficiency.

[0068] 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.

[0069] Exemplarily, when the hardware simulation process is processing a critical task and the system load is low, the preset basic period is automatically shortened to query the status more frequently to ensure 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. It improves the adaptability of the system to complex environments and further optimizes resource utilization and simulation efficiency.

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

[0071] Among them, as Figure 9As shown in the figure, 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 processes two tasks, the time is discontinuous.

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

[0073] Among them, as Figure 11 shown, it is a schematic diagram of the access delay of shared resources in the hardware simulation system provided by an 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 synchronous controller to transfer the tasks in the external push queue to the local pull queue internally. This time is not affected by any external process, so the execution speed is much higher than the time t1 and the time t2 (Δt < t1 < t2); when the system is running, the time that must be executed sequentially is , and this part of the time does not include t2, that is, within this 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 has been improved, and the SystemC process can reach the maximum execution efficiency, that is, after the SystemC process finishes processing the first task, it can immediately process the second task without waiting in the middle.

[0074] 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 an 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 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 a hardware simulation process in response to the simulation event, so that the hardware simulation process can obtain 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++), nor does it 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.

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

[0076] The embodiment of the present application also provides a hardware simulation system control method, which is applied to the hardware simulation system provided in the above embodiment. The execution subject 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 notebook computer, a tablet computer, and other electronic devices that can be used for integrated circuit hardware simulation.

[0077] As Figure 12 shown, it is a schematic flowchart of the hardware simulation system control method provided by the embodiment of the present application. The method includes:

[0078] Step 1201, when obtaining the simulation data sent by the external process, control the external process interface module to write the simulation data into the external push queue;

[0079] Step 1202: When the external push queue is not empty and its current state 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.

[0080] Step 1203: Control the hardware simulation process interface module to trigger the hardware simulation process so that the hardware simulation process can obtain the simulation data sent by the external process by accessing the local pull queue.

[0081] For the description of the features in the corresponding embodiments of the hardware simulation system control method, reference can be made to the relevant descriptions of the corresponding embodiments of the hardware simulation system, which will not be elaborated here one by one.

[0082] An embodiment of the present application also provides an electronic device, as Figure 13 shown in the structural schematic diagram of the electronic device provided by the embodiment of the present application, including a processor 10 and a memory 20. The memory 20 stores a computer program, and the processor 10 is configured to run the computer program to execute the steps in any one of the above embodiments of the hardware simulation system control method.

[0083] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. The computer program is configured to execute the steps in any one of the above embodiments of the hardware simulation system control method when running.

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

[0085] An embodiment of the present application also provides a computer program product. The above computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps in any one of the above embodiments of the hardware simulation system control method.

[0086] 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 stores a computer program, and when the computer program is executed by a processor, it implements the steps in any one of the above embodiments of the hardware simulation system control method.

[0087] Those skilled in the art may further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0088] The above has introduced in detail a hardware simulation system, a control method, an electronic device, and a storage medium provided by this application. Specific examples have been used herein to elaborate on the principles and implementation manners of this application. The description of the above embodiments is only used to help understand the method and its core idea of this application. It should be noted that for those of ordinary skill in the art, without departing from the principle of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the protection scope of the claims of this 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 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; 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.

2. The hardware simulation system according to claim 1, 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.

3. The hardware simulation system according to claim 2, 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.

4. 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.

5. The hardware simulation system according to claim 4, 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.

6. 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.

7. 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 as to keep the hardware simulation system in a running state.

8. The hardware simulation system according to claim 7, 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.

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

10. 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.

11. A method for controlling a hardware simulation system, applied to the hardware simulation system according to any one of claims 1 to 10, 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; 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; The method further comprises: The current state of the external push queue is recorded. The current state of the external push queue is divided into two types: busy and idle.

12. 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 11 when executing the computer program.

13. 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 11.

14. 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 11 are implemented.

Images