Event simulation method and device, computer device and storage medium

Abstract

The application provides an event simulation method and device, computer equipment and a storage medium, and belongs to the technical field of computers. The method comprises the following steps: in the i th simulation period, at least one event with the i th simulation period as the execution period is taken out from a main event queue corresponding to a main thread; for any event in the at least one event, the event is distributed to a first simulation queue of a slave thread corresponding to the event; for any slave thread running in the i th simulation period, based on a newly generated event of the slave thread in the i th simulation period, the first simulation queue and a second simulation queue of the slave thread are updated; after each slave thread running in the i th simulation period completes the event in the first simulation queue of the slave thread, the event in the second simulation queue of each slave thread is transferred to the main event queue to execute a simulation process of the i+1 th simulation period. This improves the simulation running efficiency and simulation reliability.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an event simulation method, apparatus, computer equipment, and storage medium. Background Technology

[0002] With the development of chip technology, the complexity of system-on-a-chip (SoC) is constantly increasing. Chip simulation plays a crucial role in chip design by evaluating chip functionality and performance. Currently, it mainly involves constructing an abstract model of the chip, abstracting the chip's instruction execution, data interaction, and other operational processes into discrete events, reproducing the chip's operation, and outputting simulation results. However, the continuous increase in chip system complexity has led to a surge in the number of discrete events generated within the chip. Traditional serial simulation typically processes discrete events sequentially on a single core, resulting in low simulation efficiency and making it difficult to meet the demands of large-scale chip simulation. Summary of the Invention

[0003] This application provides an event simulation method, apparatus, computer equipment, and storage medium, ensuring the orderly progress of the simulation process and improving simulation efficiency. The technical solution is as follows: On the one hand, an event simulation method is provided, the method comprising: In the i-th simulation cycle, at least one event with the i-th simulation cycle is retrieved from the main event queue corresponding to the main thread. The main event queue is used to temporarily store events, and the main thread is used to manage the main event queue and multiple slave threads. i is a positive integer. For any one of the at least one events, the event is distributed to the first simulation queue of the slave thread corresponding to the event. The slave thread corresponding to each event is used to execute the event. The first simulation queue of each slave thread is used to store the first simulation event. The first simulation event is the event to be executed by the slave thread in the i-th simulation cycle. For any slave thread running in the i-th simulation cycle, based on the events newly generated by the slave thread in the i-th simulation cycle, update the first simulation queue and the second simulation queue of the slave thread. The second simulation queue is used to store the second simulation events. The second simulation events include the events to be executed outside the i-th simulation cycle among the newly generated events and the events to be executed by other slave threads outside the slave thread. After each slave thread in the i-th simulation cycle completes the events in its respective first simulation queue, the events in the second simulation queue of each slave thread are transferred to the main event queue to execute the simulation process of the (i+1)-th simulation cycle.

[0004] On the other hand, an event simulation device is provided, the device comprising: The acquisition module is used to retrieve at least one event with an execution cycle of the i-th simulation cycle from the main event queue corresponding to the main thread in the i-th simulation cycle. The main event queue is used to temporarily store events, and the main thread is used to manage the main event queue and multiple slave threads, where i is a positive integer. The distribution module is used to distribute the event to the first simulation queue of the slave thread corresponding to the event for any one of the at least one events. The slave thread corresponding to each event is used to execute the event. The first simulation queue of each slave thread is used to store the first simulation event, which is the event to be executed by the slave thread in the i-th simulation cycle. An update module is used to update the first simulation queue and the second simulation queue of any slave thread running in the i-th simulation cycle based on the events newly generated by the slave thread in the i-th simulation cycle. The second simulation queue is used to store second simulation events, which include events to be executed outside the i-th simulation cycle and events to be executed by other slave threads outside the slave thread. The transfer module is used to transfer the events in the second simulation queue of each slave thread to the main event queue after each slave thread has completed the events in its first simulation queue in the i-th simulation cycle, so as to execute the simulation process of the (i+1)-th simulation cycle.

[0005] In some embodiments, the update module is configured to: In response to any newly generated event in the slave thread, the execution period of the event and the slave thread corresponding to the event are determined; if the execution period of the event is the i-th simulation period and the slave thread corresponding to the event is the current slave thread, the first simulation queue of the slave thread is updated; if the execution period of the event is not the i-th simulation period or the slave thread corresponding to the event is not the current slave thread, the second simulation queue of the slave thread is updated.

[0006] In some embodiments, the update module is configured to: When updating the first simulation queue, newly generated events are inserted into the tail of the first simulation queue in the order of their generation.

[0007] In some embodiments, the distribution module is configured to: Based on the functional module corresponding to the event, determine the logical process to which the functional module belongs. The functional module is used to execute the corresponding event, and the logical process is used to manage the corresponding functional module and slave thread. Determine the slave thread corresponding to the logical process. The logical process and the slave thread are in one-to-one correspondence. Distribute the event to the first simulation queue of the slave thread corresponding to the logical process.

[0008] In some embodiments, the distribution module is configured to: Based on the functional module corresponding to the event, a preset mapping table is queried to obtain the logical process to which the functional module belongs. The preset mapping table is used to pre-store the association mapping relationship between each functional module and its corresponding logical process.

[0009] In some embodiments, the distribution module is further configured to: Based on the logical process, the corresponding slave thread is queried in the thread pool, which is used to manage slave threads corresponding to multiple logical processes; if no corresponding slave thread is found, a slave thread is created based on the logical process and added to the thread pool.

[0010] In some embodiments, the apparatus further includes: The control module is used to update the barrier pointer based on the running state of each slave thread during the operation of each slave thread. The running state includes a running state and a completed state. The barrier pointer is used to control the progress of multiple slave threads. If the barrier pointer does not reach a preset threshold, the main thread and the slave threads in the completed state are blocked. If the barrier pointer reaches the preset threshold, the blocking state of the main thread and each slave thread is released to execute the simulation process of the (i+1)th simulation cycle.

[0011] In some embodiments, the control module is further configured to: Before each slave thread starts running, a barrier pointer is initialized based on the number of threads in each slave thread. The initial value of the barrier pointer is the sum of the number of threads and 1, and the preset threshold is 0.

[0012] In some embodiments, the control module is further configured to: The main thread sends a wake-up signal to each of the slave threads to be run, and the wake-up signal is used to wake up the slave threads.

[0013] In some embodiments, the transfer module is further configured to: After the main event queue receives events from the second simulation queues of each slave thread, the events in the main event queue are reordered based on the execution cycle of each event.

[0014] On the other hand, a computer device is provided, the computer device including a processor and a memory, the memory being used to store at least one computer program, the at least one computer program being loaded and executed by the processor to implement the event simulation method in the embodiments of this application.

[0015] On the other hand, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor to implement the event simulation method in the embodiments of this application.

[0016] On the other hand, a computer program product is provided, including a computer program that is executed by a processor to implement the event simulation method in the embodiments of this application.

[0017] This application provides an event simulation method that sets up two simulation queues for each slave thread, thereby ensuring the efficient execution of multi-threaded simulation. Each slave thread is configured with its own first and second simulation queues, used to store events to be executed by the current thread in the current simulation cycle, as well as other events such as those spanning cycles or threads. After each simulation cycle, each slave thread sends the events from its second queue back to the main thread's main event queue for scheduling in the next simulation cycle. In this architecture, when a slave thread dynamically generates new events during execution, it does not need to communicate with the main thread or other slave threads in real time; it can simply add these events to its corresponding simulation queue for sequential processing or subsequent unified transfer. This avoids the problems of logical errors, mutual waiting, and lock contention caused by real-time multi-threaded communication, improving simulation efficiency and reliability. Furthermore, this method does not require significant modifications to the original serial simulation framework; multi-threaded parallel simulation can be achieved simply by adding queues and scheduling logic, reducing the complexity of parallelization and further improving overall simulation efficiency. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of an implementation environment provided in an embodiment of this application; Figure 2 This is a flowchart of an event simulation method provided in an embodiment of this application; Figure 3 This is a flowchart of another event simulation method provided in the embodiments of this application; Figure 4 This is a schematic diagram of a hierarchical organization of an integrated circuit system provided in an embodiment of this application; Figure 5 This is a schematic diagram of a synchronization process provided in an embodiment of this application; Figure 6This is a schematic diagram of a conventional serial simulation framework provided in an embodiment of this application; Figure 7 This is a schematic diagram of a traditional event queue organization provided in an embodiment of this application; Figure 8 This is a schematic diagram of an overall process provided in an embodiment of this application; Figure 9 This is a block diagram of an event simulation device provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0021] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor is there any limitation on the quantity or execution order. For example, without departing from the scope of this application, the first simulation queue can be referred to as the second simulation queue, and similarly, the second simulation queue can be referred to as the first simulation queue.

[0022] In this application, the term "at least one" means one or more, "multiple" means two or more, and "each" means each of the at least one.

[0023] It should be noted that the information, data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application have all been fully authorized by the parties, and the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0024] For ease of understanding, the terms used in the embodiments of this application will be explained below.

[0025] Discrete Event Simulation (DES) is a computer simulation technique focused on the dynamic behavior of systems. It is driven by discrete events, which occur only at specific points in time and change the system state. It is used to model, analyze, and simulate the evolution of a system over discrete time. In essence, the core of DES is to progressively advance the system according to the sequence of events. In computer systems, DES can evaluate the performance and behavior of modules such as processors, memory systems, and buses by simulating discrete event interactions between hardware components. Hardware components (CPU cores, caches, buses) are modeled as different event-handling modules, communicating with each other through events.

[0026] Parallel Discrete Event Simulation (PDES) is a parallel acceleration technology developed based on Discrete Event Simulation (DES). It utilizes multiple computing cores (such as multiple CPU cores, GPUs, multi-core processors, or distributed computing nodes) to execute simulation tasks in parallel, decomposing and co-computing the simulation process in parallel, thereby significantly shortening simulation runtime and improving simulation efficiency.

[0027] Logical Processes (LPs) are the core scheduling units in Parallel Discrete Event Simulation (PDES). PDES divides the simulated system into several relatively independent subsystems based on function or structure. Each subsystem is modeled and simulated by a corresponding logical process. Each logical process can be independently mapped to a processor core or computing node for execution, responsible for maintaining its own local state, handling relevant events, and interacting with other logical processes. Logical processes communicate with each other through events to simulate the interactions of the actual subsystems.

[0028] In parallel discrete event simulation, the core requirement is to ensure that events within each logical process are executed in an ordered manner according to timestamps. That is, the event that is processed later cannot occur earlier than the event that was processed earlier, so as to avoid problems such as system state disorder and simulation result distortion, and to ensure the correct timing of events and the reliability of simulation results.

[0029] Currently, with the continuous increase in the complexity of chip systems, traditional serial simulation is no longer able to meet the needs of large-scale chip simulation, so parallel discrete event simulation is usually adopted.

[0030] However, traditional parallel discrete event simulation schemes, in order to ensure the correctness of the event sequence under parallel processing, all introduce complex synchronization mechanisms (such as empty messages, rollback, etc.), which brings significant runtime overhead and implementation complexity, resulting in low simulation efficiency. Furthermore, in order to convert the original serial simulation framework into a parallel discrete event simulation framework, it is usually necessary to rewrite the original framework code on a large scale and in depth to embed parallel synchronization logic. This process is complex to implement, has a high error rate, and is highly invasive and has poor versatility.

[0031] Based on this, this application provides an event simulation method that achieves multi-threaded parallel simulation without significantly modifying the original serial simulation framework. By adding queues and scheduling logic, it improves simulation efficiency while reducing the complexity of parallelization. In other words, this efficient serial simulation framework parallelization conversion scheme can fully utilize the original serial simulation framework and adapt it to multi-core and other parallel hardware environments in a low-intrusive manner. By optimizing simulation task scheduling and inter-module communication mechanisms, simulation efficiency is improved while ensuring that the simulation results are completely consistent with the original serial version, and the complexity and implementation difficulty of parallelization are reduced.

[0032] The system architecture of the technical solution provided in the embodiments of this application is described below.

[0033] Figure 1 This is a schematic diagram of an implementation environment provided in an embodiment of this application. See also... Figure 1 The implementation environment includes terminal 101 and server 102. Terminal 101 and server 102 can be connected directly or indirectly via wired or wireless communication, which is not limited herein.

[0034] Among them, terminal 101 can be various types of terminals such as mobile phones, desktop computers, laptops, and tablets. Server 102 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0035] Optionally, the event simulation method provided in this application embodiment can be executed by terminal 101 alone, by server 102 alone, or by terminal 101 and server 102 interacting.

[0036] In some embodiments, when the method is executed independently by terminal 101 or server 102, terminal 101 or server 102 can run the application offline. Based on this application, the main thread and various slave threads are run, and parallel simulation of discrete events is achieved.

[0037] In some embodiments, when the terminal 101 and server 102 interactively execute the method, the terminal 101 and server 102 are associated, and the server 102 provides background services to the terminal 101. Optionally, the server 102 undertakes the main computational work, and the terminal 101 undertakes the secondary computational work; or, the server 102 undertakes the secondary computational work, and the terminal 101 undertakes the main computational work; or, the server 102 and the terminal 101 collaborate on computation using a distributed computing architecture. That is, some steps in the method are executed by the terminal 101, and other steps are executed by the server 102.

[0038] After introducing the implementation environment of the embodiments of this application, the event simulation method provided by the embodiments of this application will be described below. It should be noted that the following description of the technical solution provided by this application uses a server as the execution subject as an example. In other possible implementations, the technical solution provided by this application can also be executed jointly by a terminal and a server; the embodiments of this application do not limit the type of execution subject.

[0039] Figure 2 This is a flowchart of an event simulation method provided in an embodiment of this application. The method is executed by a computer device. See also... Figure 2 The method includes the following steps: 201. In the i-th simulation cycle, the computer device retrieves at least one event with the i-th simulation cycle from the main event queue corresponding to the main thread. The main event queue is used to temporarily store events, and the main thread is used to manage the main event queue and multiple slave threads. i is a positive integer.

[0040] In this embodiment, a simulation cycle is a pre-defined time advance unit in the parallel discrete event simulation process, used to synchronize the execution progress of the main thread and each slave thread, ensuring the timing consistency of the parallel simulation. The simulation process proceeds step by step according to the simulation cycle. The main thread is the control thread used for overall scheduling, event distribution, and cycle synchronization. The main event queue is a global event cache queue maintained by the main thread, used to centrally store all events to be scheduled. An event (i.e., a discrete event) refers to a discrete behavior that triggers a state change in the simulation system. Each event includes an execution cycle and an execution subject (i.e., the corresponding slave thread). Since discrete events are usually various running functions in chip simulation scenarios, the execution subject of the event is also called the triggering subject of the event. At the beginning of each simulation cycle, the main thread selects and retrieves the events that need to be executed in the current simulation cycle from the main event queue for subsequent distribution processing.

[0041] 202. For any one of the at least one events, the computer device distributes the event to the first simulation queue of the slave thread corresponding to the event. Each slave thread is used to execute the event, and the first simulation queue of each slave thread is used to store the first simulation event. The first simulation event is the event to be executed by the slave thread in the i-th simulation cycle.

[0042] In this embodiment, a slave thread is a worker thread used to handle event execution tasks. Multiple slave threads work in parallel to improve simulation efficiency, and the number of slave threads is not limited in this embodiment. The first simulation queue is a local execution queue independently maintained by each slave thread, used to store events to be executed by that thread within the current simulation cycle, i.e., the first simulation event. The first simulation queue ensures that events in the current simulation cycle can be executed sequentially within the thread. The main thread distributes the retrieved events of the current simulation cycle to the corresponding slave thread's first simulation queue, enabling each slave thread to obtain the tasks to be executed in the current simulation cycle, thereby ensuring that events are executed in an orderly manner on the correct execution entity.

[0043] The above description uses the two steps of retrieving and distributing events as an example, and is merely illustrative and not intended to be limiting. In practice, the operations of retrieving and distributing events can be combined into a single execution step, completing event filtering and thread allocation in a single scheduling action; alternatively, they can be further broken down into more steps, such as event priority sorting and thread matching verification, depending on actual needs. This application's embodiments do not limit these steps, as long as the function of retrieving events for the current simulation cycle from the main event queue and allocating them to the corresponding slave threads is achieved.

[0044] 203. For any slave thread running in the i-th simulation cycle, the computer device updates the first simulation queue and the second simulation queue of the slave thread based on the events newly generated by the slave thread in the i-th simulation cycle. The second simulation queue is used to store second simulation events. The second simulation events include events to be executed outside the i-th simulation cycle from the newly generated events and events to be executed by other slave threads outside the slave thread.

[0045] In this embodiment, new events are dynamically generated by the slave thread during event execution. The second simulation queue is a temporary cache queue maintained independently by each slave thread, used to store events that do not belong to the current simulation cycle or are not executed by the current thread; that is, the second simulation events include cross-cycle events and cross-thread events. The slave thread does not need to immediately send newly generated events to the main thread or other slave threads, but updates them to its own first or second simulation queue, realizing local temporary storage and delayed scheduling of events, thereby reducing the overhead of real-time communication between threads.

[0046] 204. After each slave thread in the i-th simulation cycle has completed the events in its respective first simulation queue, the computer device transfers the events in each slave thread's respective second simulation queue to the main event queue to execute the simulation process of the (i+1)-th simulation cycle.

[0047] In this embodiment, once all slave threads have completed the events in their respective first simulation queues for the current simulation cycle, the local execution tasks for the current simulation cycle are considered complete. In this case, the second simulation events temporarily stored in the second simulation queues of each slave thread are uniformly recycled to the main event queue of the main thread, so that the main thread can uniformly schedule and distribute them in the next simulation cycle. This achieves centralized management and periodic advancement of global events, ensuring the timing correctness and process controllability of parallel simulation with low complexity.

[0048] The above description uses the example of transferring events to the second simulation queue after each slave thread completes its event as an illustration. This is merely an example and does not constitute a limitation. In fact, the embodiments of this application do not limit the timing of event transfer; they can transfer events uniformly after all slave threads in the current simulation cycle have completed their events, or they can transfer events separately after a single slave thread has completed its event.

[0049] This application provides an event simulation method that sets up two simulation queues for each slave thread, thereby ensuring the efficient execution of multi-threaded simulation. Each slave thread is configured with its own first simulation queue and second simulation queue, which are used to store the events to be executed by the current simulation cycle and other events such as those spanning cycles or threads. After each simulation cycle, each slave thread sends the events from the second queue back to the main event queue of the main thread for scheduling in the next simulation cycle. In this architecture, when a new event is dynamically generated during the execution of a slave thread, there is no need to communicate with the main thread or other slave threads in real time; it can be added to the corresponding simulation queue of its own thread for sequential processing or subsequent unified transfer. This avoids the problems of logical confusion, mutual waiting, and lock contention caused by real-time communication in multi-threaded systems, improving simulation efficiency and reliability. At the same time, this method does not require significant modification to the original serial simulation framework; multi-threaded parallel simulation can be achieved by adding queues and scheduling logic, reducing the complexity of parallelization and further improving overall simulation efficiency.

[0050] The above embodiments are merely a brief description of the event simulation method. For a detailed implementation process of this event simulation method, please refer to the following... Figure 3 Examples of implementations. Figure 3 This is a flowchart of another event simulation method provided in an embodiment of this application. The method is executed by a computer device and includes the following steps: 301. In the i-th simulation cycle, the computer device retrieves at least one event with the i-th simulation cycle from the main event queue corresponding to the main thread. The main event queue is used to temporarily store events, and the main thread is used to manage the main event queue and multiple slave threads. i is a positive integer.

[0051] In this embodiment of the application, the process of step 301 is the same as that of step 201 described above, and will not be repeated here.

[0052] 302. For any one of the at least one events, the computer device distributes the event to the first simulation queue of the slave thread corresponding to the event. Each slave thread corresponding to the event is used to execute the event. The first simulation queue of each slave thread is used to store the first simulation event. The first simulation event is the event to be executed by the slave thread in the i-th simulation cycle.

[0053] In this embodiment of the application, the process of step 302 is the same as that of step 202 described above, and will not be repeated here.

[0054] In some embodiments, a logical process is bound to the functional module corresponding to an event, and then the corresponding simulation thread is matched to complete the event distribution. Accordingly, the computer device determines the logical process to which the functional module belongs based on the functional module corresponding to the event. The functional module is used to execute the corresponding event, and the logical process is used to manage the corresponding functional module and slave threads. The slave threads corresponding to the logical process are determined, with a one-to-one correspondence between logical processes and slave threads. The event is then distributed to the first simulation queue of the slave thread corresponding to the logical process. Each logical process can manage at least one functional module, but only manages a single slave thread, which implements the simulation process under the corresponding logical process. This achieves precise matching between events and execution vehicles, ensuring that events of the corresponding functional module are handled by a dedicated slave thread, improving the accuracy of event distribution and execution efficiency.

[0055] For easier description of functional modules, see [link / reference]. Figure 4 As shown, Figure 4 This is a schematic diagram illustrating a hierarchical organization of an integrated circuit system according to an embodiment of this application. Exemplarily, the integrated circuit system is organized hierarchically according to a top-level node, slot node, die node, parent module, and child module. The child module is the aforementioned functional module. Here, a slot (Socket) refers to the physical socket of a central processing unit (CPU). A motherboard can have multiple CPU slots, corresponding to multiple physical CPUs. A die (DIE) refers to the chip core within a physical CPU package; a multi-chip packaged CPU will contain multiple dies.

[0056] In a serial simulation framework, the simulation model is usually organized in the above-mentioned hierarchical multi-branch tree architecture. In order to achieve parallelization, each functional module (as shown in the figure) is divided into multiple logical processes, and each logical process is executed in an independent thread.

[0057] In some embodiments, to complete this mapping, the computer device maintains a preset mapping table, which is used to pre-store and dynamically update the association mapping relationship between each functional module and its corresponding logical process. Accordingly, based on the functional module corresponding to the event, the computer device queries the preset mapping table to obtain the logical process to which the functional module belongs. By replacing real-time calculation and determination with a table lookup method, the matching time between events and logical processes is shortened, the overhead of event distribution is reduced, and the event distribution efficiency is improved.

[0058] For example, the preset mapping table is preferably a hash table data structure. In this preset mapping table, the mapping relationship between module identifiers and process identifiers is recorded, representing the mapping relationship between the functional module (or module instance) indicated by the module identifier and the logical process indicated by the process identifier. Furthermore, during simulation, if the correspondence between functional modules and logical processes changes (such as adding or deleting functional modules, or reallocating logical processes), the computer device can modify the correspondence in the preset mapping table in real time, achieving dynamic updates of the mapping relationship and enabling the mapping table to adapt to the dynamic changes in modules and processes during the simulation. It should be noted that this preset mapping table is not needed in a serial simulation framework; it is a data structure used for parallel simulation.

[0059] The following describes an exemplary method for dividing functional modules into multiple logical processes, namely, determining a preset mapping table. This method is divided into an analysis and statistics phase and an optimization and operation phase.

[0060] In the analysis and statistics phase, each functional module is initially divided, and performance profiling data is collected based on the simulation process. This performance profiling data records the values ​​of preset performance indicators for each functional module during the simulation, including but not limited to execution time and event trigger frequency. For example, after the initial division of functional modules is completed, the computer device performs a simulation and automatically generates a performance profiling configuration file containing this performance profiling data after the simulation ends. In this phase, automatic division, manual division, or a combination of both can be used; this application embodiment does not impose any limitations on these methods. For example, in the automatic division method, the computer device automatically completes the division operation using a default grouping strategy. For instance, to maximize parallel granularity and accurately collect performance data, the default grouping strategy initializes each functional module as an independent logical process. In the manual division method or the combination of automatic and manual division, users can explicitly and manually group functional modules based on prior knowledge using predefined configuration files or code. Manual grouping rules have higher priority than automatic grouping rules, improving the flexibility of module division.

[0061] Following the analysis and statistics phase, the process enters the optimization and execution phase. Based on the aforementioned performance profiling data and the hardware resource data of the current simulation environment, the computer equipment generates optimized module partitioning results using a pre-set optimization algorithm. The hardware resource data of the current simulation environment includes, but is not limited to, the number of available processor cores and memory transfer bandwidth. This pre-set optimization algorithm aims to minimize communication overhead between logical processes and achieve load balancing, distributing computationally heavy functional modules across different logical processes while aggregating frequently communicating functional modules within the same logical process, thereby achieving efficient parallel execution in subsequent simulations. For example, the optimization algorithm may employ the Kernighan-Lin algorithm or the METIS algorithm, which will not be elaborated further here. For example, the computer equipment loads the aforementioned performance profiling configuration file, and the group optimizer completes the optimization based on the performance profiling data and the hardware resource data of the current simulation environment.

[0062] In some embodiments, slave threads are managed through a thread pool. Accordingly, the computer device queries the thread pool for the corresponding slave thread based on the logical process. The thread pool manages slave threads corresponding to multiple logical processes. If no corresponding slave thread is found, a slave thread is created based on the logical process and added to the thread pool. If a corresponding slave thread is found, step 302 above is executed. The thread pool is used to implement thread reuse and dynamic creation. By retrieving the slave thread corresponding to the logical process from the thread pool, and creating a new thread and adding it to the pool if no match is found, not only is redundant thread resource waste avoided, but simulation interruption is also prevented due to a lack of available threads. This achieves dynamic configuration of thread resources and optimizes thread resource utilization.

[0063] The above description uses the real-time creation of slave threads corresponding to logical processes as an example, but it does not constitute a limitation. In other embodiments, after determining the preset mapping table, slave threads can be created for each logical process in the preset mapping table, and the created slave threads can be added to the thread pool. This saves real-time processing time and improves efficiency.

[0064] 303. In response to any newly generated event in a slave thread, the computer device determines the execution period of the event and the slave thread corresponding to the event.

[0065] In this embodiment, the slave thread corresponding to the event is also the execution body of the event. Events newly generated by the slave thread during event processing can be classified according to two dimensions: time and thread. In the time dimension, events can be divided into current-cycle events and cross-cycle events. Current-cycle events are those whose execution cycle is the current simulation cycle, while cross-cycle events are those whose execution cycle is not the current simulation cycle (e.g., the execution cycle of a cross-cycle event is after the current simulation cycle). In the thread dimension, events can be divided into local-thread events and cross-thread events. Local-thread events are those processed by the current slave thread, while cross-thread events are those processed by slave threads other than the current slave thread. For newly generated events by slave threads, quickly identifying their execution cycle and execution body provides a basis for subsequent queue writing, ensuring the accuracy of event classification and processing.

[0066] For events newly generated from a thread, adding them to the main event queue corresponding to the main thread would incur significant lock overhead. Therefore, this application proposes a two-layer event queue communication architecture to solve the efficiency and synchronization problems of event transmission in parallel simulations, as shown in steps 304 and 305 below. This mechanism reduces inter-thread communication overhead by classifying events according to execution time and execution subject, while ensuring the correct timing of event processing.

[0067] 304. If the execution cycle of the event is the i-th simulation cycle and the slave thread corresponding to the event is the current slave thread, the computer device updates the first simulation queue of the slave thread.

[0068] In this embodiment of the application, if the event is a current cycle event and a current thread event, the event is stored in the first simulation queue, which ensures the continuity of event processing within the same cycle.

[0069] In some embodiments, when updating the first simulation queue, newly generated events are inserted into the tail of the first simulation queue in the order of their generation. This ensures that events within the same period are executed serially in the order of occurrence, conforming to the actual event occurrence logic, avoiding simulation result distortion caused by disordered execution, and improving the reliability of event processing.

[0070] 305. If the execution cycle of an event is not the i-th simulation cycle or the slave thread corresponding to the event is not the current slave thread, the computer device updates the second simulation queue of the slave thread. The second simulation events include newly generated events that are to be executed outside the i-th simulation cycle and events that are to be executed by other slave threads outside the current slave thread.

[0071] In this embodiment, cross-cycle events or cross-thread events are stored in a second simulation queue. In other words, if the event is any of the following types, it is stored in the second simulation queue: a cross-thread current cycle event, a cross-cycle current thread event, or a cross-cycle and cross-thread event.

[0072] In one embodiment, since events in the second simulation queue are reordered when transferred to the main event queue, the timing of events in the second simulation queue is not required. Accordingly, when updating the second simulation queue, newly generated events can be inserted into the queue in the order of generation, ordered according to execution cycle, or inserted at any position; there are no restrictions on this.

[0073] Steps 303 to 305 above are an exemplary method for a computer device to update the first and second simulation queues of a slave thread based on events newly generated by the slave thread in the i-th simulation cycle, but this method does not constitute a limitation. In this method, the newly generated events are categorized into the first and second simulation queues based on the dual criteria of the execution cycle and the executing entity, according to whether the execution cycle is current and whether the executing thread is the current thread. This avoids the mixing of currently processable events with events spanning cycles or threads, achieving event classification management and reducing performance overhead in scenarios where events are dynamically generated during simulation.

[0074] The following is a further summary of the first and second simulation queues, explaining them from two aspects: event reception source and processing flow. Regarding the first simulation queue: In terms of event reception source, the events in the first simulation queue (i.e., the first simulation events) are either distributed by the main thread or generated locally. Events distributed by the main thread refer to events assigned by the main thread based on a preset mapping table, with the execution cycle being the current cycle and the execution subject being the current thread. Locally generated events refer to events newly generated during processing, with the execution subject being the current cycle and the execution subject being the current thread. In terms of processing flow, the thread will sequentially retrieve events from the first simulation queue for execution. Regarding the second simulation queue: In terms of event reception source, the events in the second simulation queue (i.e., the second simulation events) are cross-thread events within the current cycle or cross-cycle events (regardless of the corresponding thread). In terms of processing flow, events in the second simulation queue do not require processing within the current simulation cycle.

[0075] The above description uses the example of each slave thread corresponding to its own second simulation queue, but this is not intended to be limiting. In other embodiments, an independent storage area is created in the main thread for each slave thread (i.e., for each logical process), and each slave thread writes newly generated cross-cycle / cross-thread events into the corresponding independent storage area in the main thread. Alternatively, a specific shared storage area is set in the main thread, and each slave thread writes newly generated cross-cycle / cross-thread events into this shared storage area for subsequent aggregation and scheduling by the main event queue. These methods can also achieve centralized temporary storage and subsequent scheduling of cross-cycle / cross-thread events, achieving the same effect as the second simulation queue described above, and the subsequent processing flow is also the same, so it will not be elaborated here. In other words, as long as cross-cycle / cross-thread events can be stored separately to achieve isolation from the current-cycle events of each slave thread, this application does not limit how the storage is implemented.

[0076] After the events of the current simulation cycle are distributed to the first simulation queue of the corresponding slave threads, these slave threads will begin running. At this time, the main thread needs to wait for each slave thread running in the current simulation cycle to finish executing before proceeding to the next simulation cycle. To achieve synchronization between threads, this application proposes a master-slave synchronization architecture based on a condition variable-barrier hybrid mechanism, realizing precise coordination between the main thread and multiple slave threads. This synchronization mechanism ensures the consistency of time progression of each slave thread in discrete event simulation while also taking into account execution efficiency. A detailed description follows.

[0077] In some embodiments, a barrier pointer is used to regulate the progress of each thread. Accordingly, during the execution of each slave thread, the computer device updates the barrier pointer based on the running state of each slave thread, including running and completed states. The barrier pointer is used to regulate the progress of multiple slave threads. If the barrier pointer does not reach a preset threshold, the main thread and slave threads in the completed state are blocked. If the barrier pointer reaches the preset threshold, the blocking state of the main thread and all slave threads is released to execute the simulation process of the (i+1)th simulation cycle. Here, the barrier pointer is a synchronization marker used to regulate the progress of multiple threads. Its numerical change controls the blocking and release of threads, and the preset threshold is the judgment value for triggering the release of the barrier pointer. By dynamically synchronizing thread progress using the barrier pointer, each slave thread running in the current simulation cycle is forced to complete its event processing for that cycle before synchronously entering the next simulation cycle. This eliminates data interaction errors caused by inconsistent thread progress and ensures the consistency of parallel simulation results.

[0078] In some embodiments, before each slave thread starts running, a barrier pointer is initialized based on the number of threads in each slave thread. The initial value of the barrier pointer is the sum of the number of threads and 1, with a preset threshold of 0. By initializing the barrier pointer according to the number of threads, the synchronization benchmark is unified, the synchronization logic is simplified, and a standardized basis is provided for verifying thread progress. For example, the value of the barrier pointer can represent the state of each slave thread and the main thread running in the current simulation cycle. Whenever a slave thread completes its own event in the current simulation cycle (i.e., the event in the first simulation queue of that slave thread), the value of the barrier pointer is decremented by 1; after the main thread completes event dispatch, the value of the barrier pointer is decremented by 1; or, when the main thread completes the preparation work for entering the next simulation cycle (i.e., has completed step 307 below), the value of the barrier pointer is decremented by 1.

[0079] In some embodiments, slave threads are selectively woken up in each simulation cycle. Accordingly, the main thread sends wake-up signals to each slave thread scheduled to run in the current simulation cycle. These wake-up signals are used to wake up the slave threads. Slave threads with no events pending in the current simulation cycle do not need to be woken up, ensuring on-demand scheduling of thread resources, avoiding system overhead caused by invalid wake-ups, reducing resource consumption during simulation, and improving overall operating efficiency.

[0080] For a clearer description of the above process, see [link to documentation]. Figure 5 As shown, Figure 5 This is a schematic diagram of a synchronization process provided in an embodiment of this application. This synchronization process is based on the coordinated operation of three synchronization primitives: condition variable, barrier pointer, and mutex. The condition variable is used to simulate thread sleep and wake-up control, the barrier pointer is used for progress synchronization points of all threads, and the mutex is used to protect concurrent access to shared state variables.

[0081] In this multi-threaded simulation cycle synchronization process based on a main thread-slave thread architecture, a barrier pointer is used to achieve coordinated advancement of each thread. After the simulation cycle begins, the main thread first traverses the slave threads, determines the slave threads to be executed, and initializes the barrier pointer to the number of slave threads to be executed plus 1 (including the main thread itself), that is, creating a synchronization barrier that includes the main thread and the slave threads to be executed in the current simulation cycle. Subsequently, according to the selective wake-up mechanism, the main thread uses the alt branch to determine whether there are events and sends a wake-up signal to the slave threads that have events, while the slave threads without events remain in a dormant state. For example, a wake-up signal is sent after determining the slave threads to be executed; or, after the event is distributed, the first simulation queue of each slave thread is traversed, and a wake-up signal is sent according to whether there are events in the queue. This application embodiment does not limit this. After the main thread completes the wake-up distribution, it reaches the synchronization barrier point, and the barrier pointer is decremented by 1 accordingly. Entering the parallel execution phase, the awakened slave thread 1, slave thread 2, etc., execute the events in their respective first simulation queues in parallel. After completion, they reach the synchronization barrier point respectively, and the barrier pointer is decremented by 1 accordingly. Once all active threads (including the main thread, slave thread 1, and slave thread 2) reach the barrier point and the barrier pointer is zero, the main thread releases all threads and continues subsequent operations. Each slave thread enters a waiting state for the next simulation cycle. The main thread releases barrier resources, resets the barrier pointer, and prepares to enter the next simulation cycle, thereby achieving the orderly progress of each simulation cycle.

[0082] The event handling process of the simulation thread includes the following aspects: conditional waiting, where the simulation thread waits for the main thread's wake-up signal or termination instruction; event handling and performance monitoring, where the thread executes events in the first simulation queue and tracks the execution time; and barrier synchronization, where the thread waits for other threads at a barrier point to ensure periodic synchronization. These have all been described above and will not be repeated here.

[0083] 306. After each slave thread running in the i-th simulation cycle has completed the events in its respective first simulation queue, the computer device transfers the events in each slave thread's respective second simulation queue to the main event queue.

[0084] In this embodiment of the application, the process of step 306 is the same as that of step 204 described above, and will not be repeated here.

[0085] 307. After the main event queue receives events from the second simulation queue of each slave thread, the computer device reorders the events in the main event queue based on the execution cycle of each event in order to execute the simulation process of the (i+1)th simulation cycle.

[0086] In this embodiment, the main thread iterates through the second simulation queues of each slave thread, transferring events in batches to the main event queue. The main event queue is reordered based on the newly collected events to ensure timing correctness and prepare for the next simulation cycle. This provides the main thread with an ordered data source, ensuring the orderly connection and continuous stable operation of multiple simulation cycles.

[0087] The above description assumes that the main thread performs a summary operation after all slave threads have completed their execution in the current simulation cycle, but this does not constitute a limitation. In other embodiments, after a single slave thread completes the events in its first simulation queue, the slave thread actively sends the events in its second simulation queue to the main event queue without waiting for all other slave threads in the current simulation cycle to complete their processing.

[0088] The above explanation uses the example of summarizing and then reordering as an example, but it does not constitute a limitation. In other embodiments, during the process of receiving events sent from threads, events are inserted into the corresponding positions in the main event queue according to their execution cycles, without waiting for all events to be received before unified sorting. This also ensures the temporal order of events in the main event queue and reduces the centralized computational overhead of the main thread.

[0089] The above description illustrates the isolation of cross-cycle / cross-thread events (events in the second simulation queue) from current-cycle, thread-specific events (events in the first simulation queue) as an example, but it does not constitute a limitation. In other embodiments, each slave thread can use a single event queue to store all events, executing the current simulation cycle's thread-specific events within the current simulation cycle, while temporarily refraining from executing newly generated cross-cycle / cross-thread events; after the current simulation cycle's thread-specific events have been executed, the cross-cycle / cross-thread events in the queue are then transferred to the main event queue. To achieve the above operation, the number of newly generated cross-cycle / cross-thread events in the slave thread can be recorded, and the number of events can be verified during subsequent transfers to ensure complete event transfer. The core of this application is to ensure that when a slave thread executes events in the current simulation cycle, it does not need to communicate with the main thread or other slave threads in real time. This objective can be achieved through various queue storage and processing methods, such as the aforementioned isolated storage scheme and single-queue processing scheme, which this application does not limit.

[0090] To facilitate the description of how this application parallelizes the serial simulation framework, a traditional serial simulation framework will be introduced first. See [link to relevant documentation]. Figure 6 , Figure 6This is a schematic diagram of a traditional serial simulation framework provided in an embodiment of this application. The traditional serial simulation framework includes the following steps: setting the initial system state; generating initial events and adding them to the simulation event queue; determining whether the simulation event queue is empty. If empty, the process ends; if not empty, the earliest event is retrieved, the simulation cycle is advanced to the event's execution cycle, the current event is processed, a new event is generated and added to the simulation event queue, and the step of determining whether the simulation event queue is empty continues. In the traditional serial simulation framework, events are typically organized according to simulation cycles, and events within the same cycle are centrally managed. See also... Figure 7 As shown, Figure 7 This is a schematic diagram of a traditional event queue organization provided by an embodiment of this application. Events are arranged in ascending order of simulation cycles, such as simulation cycles 1 to 4, but the simulation cycles themselves are not required to be consecutive. The workflow of a traditional serial simulation framework includes: sequentially retrieving and executing events from the event queue of the most recent simulation cycle, such as sequentially retrieving and executing events 11, 12, and 13 from the event queue of simulation cycle 1; when the event queue is empty, it automatically switches to the event queue of the next most recent simulation cycle with events, and continues the above steps, such as switching to the event queue of simulation cycle 2, and sequentially retrieving and executing events 21 and 22. The embodiment of this application parallelizes the above serial process, improving simulation efficiency.

[0091] The event simulation method in this application embodiment enables the parallelization of a serial simulation framework. See [link to relevant documentation]. Figure 8 As shown, Figure 8 This is a schematic diagram of an overall process provided in an embodiment of this application. This parallel simulation execution process adds parallel logic to the original serial simulation framework. The overall process is as follows: After the simulation starts, the initialization of the original serial simulation framework and the parallel simulation framework is completed first. If it is the first run, a default grouping strategy or a user-defined grouping strategy can be used to group modules. If it is not the first run, an optimized grouping strategy or a user-defined grouping strategy can be used based on the configuration file. Then, initial events are generated and added to the main event queue, entering the main loop: if the main event queue is empty, the simulation ends; otherwise, the current period event is retrieved from the main event queue, and it is determined whether the slave thread corresponding to the logical process to which the event belongs exists. If not, the corresponding slave thread is dynamically created, and the event is then distributed to the corresponding slave thread and awakened for execution. After each slave thread executes the event in parallel, all threads (including the main thread and slave threads) are synchronized through a barrier. Then, the events in the second simulation queue of each slave thread are collected and merged back into the main event queue, advancing the simulation cycle. This cycle repeats until the main event queue is empty.

[0092] This application provides an event simulation method that sets up two simulation queues for each slave thread, thereby ensuring the efficient execution of multi-threaded simulation. Each slave thread is configured with its own first simulation queue and second simulation queue, which are used to store the events to be executed by the current simulation cycle and other events such as those spanning cycles or threads. After each simulation cycle, each slave thread sends the events from the second queue back to the main event queue of the main thread for scheduling in the next simulation cycle. In this architecture, when a new event is dynamically generated during the execution of a slave thread, there is no need to communicate with the main thread or other slave threads in real time; it can be added to the corresponding simulation queue of its own thread for sequential processing or subsequent unified transfer. This avoids the problems of logical confusion, mutual waiting, and lock contention caused by real-time communication in multi-threaded systems, improving simulation efficiency and reliability. At the same time, this method does not require significant modification to the original serial simulation framework; multi-threaded parallel simulation can be achieved by adding queues and scheduling logic, reducing the complexity of parallelization and further improving overall simulation efficiency.

[0093] In detail, this event simulation method has the following advantages.

[0094] (1) Improved simulation performance and solved the computational efficiency bottleneck: This solves the problem that traditional serial simulation frameworks cannot fully utilize multi-core computing resources and face serious performance bottlenecks. The embodiments of this application distribute the computational load to multiple computing cores, achieving a near-linear speedup. In typical integrated circuit simulation scenarios, a 6-7 times performance improvement can be achieved in an 8-core environment.

[0095] (2) It lowers the barrier to parallelization and solves the problem of high technology migration costs: Traditional parallel simulation requires a complete rewrite of the code, which has a high learning cost and cannot reuse existing simulation resources. In the embodiments of this application, the code of the original serial simulation framework can be integrated into the parallel framework with almost no modification, and there is no need to modify the user's original business logic, only the simulation framework itself needs to be modified.

[0096] (3) It ensures the correctness of the simulation and solves the timing error problem introduced by parallelization: Traditional parallelization may destroy the original event timing relationship and lead to incorrect simulation results. However, the embodiments of this application ensure that the parallel simulation results are completely consistent with the original serial simulation through barrier synchronization and event sorting mechanism.

[0097] (4) Reduced communication overhead and solved the bottleneck problem of parallel efficiency: In the traditional way, the communication overhead between threads may offset the performance gains brought by parallelization. However, the embodiments of this application reduce lock contention and context switching overhead by batch aggregating and transmitting cross-cycle / cross-thread events, compared with the real-time communication method.

[0098] Figure 9This is a block diagram of an event simulation device provided in an embodiment of this application. The device is used to execute the steps of the event simulation method described above, see below. Figure 9 The event simulation device includes: an acquisition module 901, a distribution module 902, an update module 903, and a transfer module 904.

[0099] The acquisition module 901 is used to retrieve at least one event with an execution cycle of the i-th simulation cycle from the main event queue corresponding to the main thread in the i-th simulation cycle. The main event queue is used to temporarily store events, and the main thread is used to manage the main event queue and multiple slave threads. i is a positive integer. The distribution module 902 is used to distribute the event to the first simulation queue of the slave thread corresponding to the event for any one of the at least one events. The slave thread corresponding to each event is used to execute the event, and the first simulation queue of each slave thread is used to store the first simulation event. The first simulation event is the event to be executed by the slave thread in the i-th simulation cycle. The update module 903 is used to update the first simulation queue and the second simulation queue of any slave thread running in the i-th simulation cycle based on the events newly generated by the slave thread in the i-th simulation cycle. The second simulation queue is used to store the second simulation events, which include the events to be executed outside the i-th simulation cycle and the events to be executed by other slave threads other than the slave thread. The transfer module 904 is used to transfer the events in the second simulation queue of each slave thread to the main event queue after each slave thread has completed the events in its first simulation queue in the i-th simulation cycle, so as to execute the simulation process of the (i+1)-th simulation cycle.

[0100] In some embodiments, the update module 903 is used for: In response to any newly generated event in a slave thread, determine the execution period of the event and the slave thread corresponding to the event; if the execution period of the event is the i-th simulation period and the slave thread corresponding to the event is the current slave thread, update the first simulation queue of the slave thread; if the execution period of the event is not the i-th simulation period or the slave thread corresponding to the event is not the current slave thread, update the second simulation queue of the slave thread.

[0101] In some embodiments, the update module 903 is used for: When updating the first simulation queue, newly generated events are inserted into the tail of the first simulation queue in the order of their generation.

[0102] In some embodiments, the distribution module 902 is configured to: Based on the functional module corresponding to the event, determine the logical process to which the functional module belongs. The functional module is used to execute the corresponding event, and the logical process is used to manage the corresponding functional module and slave thread. Determine the slave thread corresponding to the logical process. There is a one-to-one correspondence between logical processes and slave threads. Distribute the event to the first simulation queue of the slave thread corresponding to the logical process.

[0103] In some embodiments, the distribution module 902 is configured to: Based on the functional module corresponding to the event, a preset mapping table is queried to obtain the logical process to which the functional module belongs. The preset mapping table is used to store the association mapping relationship between each functional module and its corresponding logical process in advance.

[0104] In some embodiments, the distribution module 902 is further configured to: Based on the logical process, the corresponding slave thread is queried in the thread pool. The thread pool is used to manage slave threads corresponding to multiple logical processes. If no corresponding slave thread is found, a slave thread is created based on the logical process and added to the thread pool.

[0105] In some embodiments, the apparatus further includes: The control module is used to update the barrier pointer based on the running state of each slave thread during the operation of each slave thread. The running state includes the running state and the finished state. The barrier pointer is used to control the progress of multiple slave threads. If the barrier pointer does not reach the preset threshold, the main thread and the slave threads in the finished state are blocked. If the barrier pointer reaches the preset threshold, the blocking state of the main thread and each slave thread is released to execute the simulation process of the (i+1)th simulation cycle.

[0106] In some embodiments, the control module is further configured to: Before each slave thread starts running, a barrier pointer is initialized based on the number of threads in each slave thread. The initial value of the barrier pointer is the sum of the number of threads and 1, and the preset threshold is 0.

[0107] In some embodiments, the control module is further configured to: The main thread sends a wake-up signal to each of the slave threads to be run. The wake-up signal is used to wake up the slave threads.

[0108] In some embodiments, the transfer module 904 is further configured to: After the main event queue receives events from the second simulation queues of each slave thread, the events in the main event queue are reordered based on the execution cycle of each event.

[0109] This application provides an event simulation device that sets up two simulation queues for each slave thread, thereby ensuring the efficient execution of multi-threaded simulation. Each slave thread is configured with its own first simulation queue and second simulation queue, used to store events to be executed by the current thread in the current simulation cycle, as well as other events such as those spanning cycles or threads. After each simulation cycle, each slave thread sends the events from its second queue back to the main event queue of the main thread for scheduling in the next simulation cycle. In this architecture, when a slave thread dynamically generates new events during execution, it does not need to communicate with the main thread or other slave threads in real time; it can simply add these events to its corresponding simulation queue for sequential processing or subsequent unified transfer. This avoids the problems of logical errors, mutual waiting, and lock contention caused by real-time multi-threaded communication, improving simulation efficiency and reliability. Furthermore, this approach does not require significant modifications to the original serial simulation framework; multi-threaded parallel simulation can be achieved simply by adding queues and scheduling logic, reducing the complexity of parallelization modifications and further improving overall simulation efficiency.

[0110] It should be noted that the event simulation device provided in the above embodiments is only illustrated by the division of the above functional modules when running the application. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the event simulation device and the event simulation method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0111] This application also provides a computer device, which includes a processor and a memory. The memory stores at least one computer program, which is loaded and executed by the processor to perform the operations performed in the event simulation method of the above embodiments.

[0112] Optionally, the computer device is provided as a terminal. Figure 10 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. The terminal 1000 includes a processor 1001 and a memory 1002.

[0113] Processor 1001 may include one or more processing cores, such as a quad-core processor, a deca-core processor, etc. Processor 1001 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1001 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1001 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1001 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0114] The memory 1002 may include one or more computer-readable storage media, which may be non-transitory. The memory 1002 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1002 are used to store at least one computer program, which is executed by the processor 1001 to implement the event simulation method provided in the method embodiments of this application.

[0115] In some embodiments, the terminal 1000 may optionally include a peripheral device interface 1003 and at least one peripheral device. The processor 1001, memory 1002, and peripheral device interface 1003 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 1003 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 1004, a display screen 1005, a camera assembly 1006, an audio circuit 1007, and a power supply 10010.

[0116] Peripheral device interface 1003 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 1001 and memory 1002. In some embodiments, processor 1001, memory 1002 and peripheral device interface 1003 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 1001, memory 1002 and peripheral device interface 1003 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0117] The radio frequency (RF) circuit 1004 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 1004 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 1004 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. In some embodiments, the RF circuit 1004 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 1004 can communicate with other terminals via at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 1004 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0118] Display screen 1005 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 1005 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 1001 for processing. In this case, display screen 1005 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 1005, disposed on the front panel of terminal 1000; in other embodiments, there may be at least two display screens, disposed on different surfaces of terminal 1000 or in a folded design; in still other embodiments, display screen 1005 may be a flexible display screen, disposed on a curved or folded surface of terminal 1000. Furthermore, display screen 1005 may be configured as a non-rectangular, irregular shape, i.e., a non-rectangular screen. The display screen 1005 can be made of materials such as LCD (Liquid Crystal Display) and OLED (Organic Light-Emitting Diode).

[0119] The camera assembly 1006 is used to acquire images or videos. In some embodiments, the camera assembly 1006 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 1006 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash is a combination of a warm-light flash and a cool-light flash, which can be used for light compensation at different color temperatures.

[0120] The audio circuit 1007 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting the sound waves into electrical signals that are input to the processor 1001 for processing, or input to the radio frequency circuit 1004 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, each positioned at a different location on the terminal 1000. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert electrical signals from the processor 1001 or the radio frequency circuit 1004 into sound waves. The speaker may be a conventional diaphragm speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 1007 may also include a headphone jack.

[0121] Power supply 10010 is used to power the various components in terminal 1000. Power supply 10010 can be AC ​​power, DC power, a disposable battery, or a rechargeable battery. When power supply 10010 includes a rechargeable battery, the rechargeable battery can support wired charging or wireless charging. The rechargeable battery can also be used to support fast charging technology.

[0122] Those skilled in the art will understand that Figure 10 The structure shown does not constitute a limitation on terminal 1000 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0123] Optionally, the computer device is provided as a server. Figure 11 This is a schematic diagram of a server structure provided in an embodiment of this application. The server 1100 can vary considerably due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 1101 and one or more memories 1102. The memory 1102 stores at least one computer program, which is loaded and executed by the processor 1101 to implement the event simulation methods provided in the above-described method embodiments. Of course, the server may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The server may also include other components for implementing device functions, which will not be elaborated here.

[0124] This application also provides a computer-readable storage medium storing at least one computer program, which is loaded and executed by a processor to implement the event simulation method in the above embodiments. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0125] This application also provides a computer program product, including a computer program that is executed by a processor to implement the event simulation method in this application.

[0126] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0127] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. An event simulation method, characterized in that, The method includes: In the i-th simulation cycle, at least one event with the i-th simulation cycle is retrieved from the main event queue corresponding to the main thread. The main event queue is used to temporarily store events, and the main thread is used to manage the main event queue and multiple slave threads. i is a positive integer. For any one of the at least one events, the event is distributed to the first simulation queue of the slave thread corresponding to the event. The slave thread corresponding to each event is used to execute the event. The first simulation queue of each slave thread is used to store the first simulation event. The first simulation event is the event to be executed by the slave thread in the i-th simulation cycle. For any slave thread running in the i-th simulation cycle, based on the events newly generated by the slave thread in the i-th simulation cycle, update the first simulation queue and the second simulation queue of the slave thread. The second simulation queue is used to store the second simulation events. The second simulation events include the events to be executed outside the i-th simulation cycle among the newly generated events and the events to be executed by other slave threads outside the slave thread. After each slave thread in the i-th simulation cycle completes the events in its respective first simulation queue, the events in the second simulation queue of each slave thread are transferred to the main event queue to execute the simulation process of the (i+1)-th simulation cycle.

2. The method according to claim 1, characterized in that, The step of updating the first and second simulation queues of the slave thread based on the events newly generated by the slave thread in the i-th simulation cycle includes: In response to any newly generated event in the slave thread, determine the execution period of the event and the slave thread corresponding to the event; If the execution cycle of the event is the i-th simulation cycle and the slave thread corresponding to the event is the current slave thread, update the first simulation queue of the slave thread; If the execution cycle of the event is not the i-th simulation cycle or the slave thread corresponding to the event is not the current slave thread, update the second simulation queue of the slave thread.

3. The method according to claim 1 or 2, characterized in that, Updating the first simulation queue of the slave thread includes: When updating the first simulation queue, newly generated events are inserted into the tail of the first simulation queue in the order of their generation.

4. The method according to claim 1, characterized in that, The step of distributing the event to the first simulation queue of the slave thread corresponding to the event includes: Based on the functional module corresponding to the event, the logical process to which the functional module belongs is determined. The functional module is used to execute the corresponding event, and the logical process is used to manage the corresponding functional module and slave thread. Determine the slave thread corresponding to the logical process, with a one-to-one correspondence between logical processes and slave threads; The event is dispatched to the first simulation queue of the slave thread corresponding to the logical process.

5. The method according to claim 4, characterized in that, The step of determining the logical process to which the functional module belongs based on the functional module corresponding to the event includes: Based on the functional module corresponding to the event, a preset mapping table is queried to obtain the logical process to which the functional module belongs. The preset mapping table is used to pre-store the association mapping relationship between each functional module and its corresponding logical process.

6. The method according to claim 4, characterized in that, Determining the slave thread corresponding to the logical process includes: Based on the logical process, the corresponding slave thread is queried in the thread pool, which is used to manage the slave threads corresponding to multiple logical processes. If no corresponding slave thread is found, a slave thread is created based on the logical process, and the created slave thread is added to the thread pool.

7. The method according to claim 1, characterized in that, The method further includes: During the execution of each slave thread, the barrier pointer is updated based on the running state of each slave thread. The running state includes a running state and a completed state. The barrier pointer is used to regulate the progress of multiple slave threads. If the barrier pointer does not reach the preset threshold, the main thread and the slave thread that is in the terminated state will be blocked. When the barrier pointer reaches the preset threshold, the blocking state of the main thread and each slave thread is released to execute the simulation process of the (i+1)th simulation cycle.

8. The method according to claim 7, characterized in that, The method further includes: Before each slave thread starts running, a barrier pointer is initialized based on the number of threads in each slave thread. The initial value of the barrier pointer is the sum of the number of threads and 1, and the preset threshold is 0.

9. The method according to claim 8, characterized in that, The method further includes: The main thread sends a wake-up signal to each of the slave threads to be run, and the wake-up signal is used to wake up the slave threads.

10. The method according to claim 1, characterized in that, The method further includes: After the main event queue receives events from the second simulation queues of each slave thread, the events in the main event queue are reordered based on the execution cycle of each event.

11. An event simulation device, characterized in that, The device includes: The acquisition module is used to retrieve at least one event with an execution cycle of the i-th simulation cycle from the main event queue corresponding to the main thread in the i-th simulation cycle. The main event queue is used to temporarily store events, and the main thread is used to manage the main event queue and multiple slave threads, where i is a positive integer. The distribution module is used to distribute the event to the first simulation queue of the slave thread corresponding to the event for any one of the at least one events. The slave thread corresponding to each event is used to execute the event. The first simulation queue of each slave thread is used to store the first simulation event, which is the event to be executed by the slave thread in the i-th simulation cycle. An update module is used to update the first simulation queue and the second simulation queue of any slave thread running in the i-th simulation cycle based on the events newly generated by the slave thread in the i-th simulation cycle. The second simulation queue is used to store second simulation events, which include events to be executed outside the i-th simulation cycle and events to be executed by other slave threads outside the slave thread. The transfer module is used to transfer the events in the second simulation queue of each slave thread to the main event queue after each slave thread has completed the events in its first simulation queue in the i-th simulation cycle, so as to execute the simulation process of the (i+1)-th simulation cycle.

12. A computer device, characterized in that, The computer device includes a processor and a memory, the memory being used to store at least one computer program, the at least one computer program being loaded and executed by the processor to implement the event simulation method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store at least one computer program, which is loaded and executed by a processor to implement the event simulation method as described in any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the event simulation method as described in any one of claims 1 to 10.

Images