A progressive event-driven synchronization control method

Abstract

The application discloses a kind of progressive event-driven synchronous control methods, comprising: parallel simulation, simultaneously enable multiple simulation processes, respectively simulate each core grain in multiple-core system, and the synchronization between simulation processes is managed by global manager;Synchronization on demand, when the core grain simulated by simulation process occurs inter-core communication, global manager synchronizes relevant process;Process synchronization, global manager ensures that other cross-process communication events earlier than the request have been completed simulation;If there is a simulation process has not reached the time point, the process that initiates request will be suspended by global manager until the request can be executed;Network simulation and timing simulation, when the request can be executed, global manager starts inter-chip network simulator, and simulates the communication event.The application significantly improves the accuracy and running efficiency of multi-core parallel simulation, and is suitable for large-scale complex multi-core chip function verification and performance analysis.

Description

Technical Field

[0001] This invention relates to the field of parallel simulation, and more particularly to a progressive event-driven synchronization control method. Background Technology

[0002] Currently, the mainstream CPU parallel emulators are Gem5 and Sniper. Gem5's main problem is that its use of a single-threaded DES kernel limits its performance and scalability for simulating multi-core systems. Sniper has a significant advantage in multi-core parallel simulation, but because it is based on trace simulation, its simulation accuracy is relatively low. The mainstream GPU emulator is GPGPU-Sim.

[0003] Besides these basic simulators, many studies have proposed simulators for multi-core parallelism, improving their parallel simulation capabilities and scalability compared to previous simulators. Daniel Sanchez and Christos Kozyrakis proposed the Zsim simulator, which improves its scalability for parallel simulation on multi-core hosts through bonded-weave parallelization. However, due to its staged clock synchronization—meaning that although the simulation of each core is parallel, all cores synchronize through a synchronization barrier after reaching a predetermined number of cycles—cores that finish early must wait for all other cores to complete their tasks in that stage before moving to the next, increasing simulation time overhead. JE Miller et al. proposed the Graphite simulator, which uses a loosely synchronized clock synchronization strategy. This strategy features clocks on each core running independently, synchronizing only at specific times. The drawback of this synchronization strategy is that Graphite does not strictly enforce the order of all events when processing events. In some cases, it ignores timestamps and determines operation delays based on the order in which events are executed locally, rather than their precise order in the simulation system. Rafael Ubal et al. proposed the Multi2Sim simulator, which simulates the interaction between the CPU and GPU through an exhaustive synchronization strategy. While this strategy improves simulation accuracy by using instruction-level synchronization, it also significantly increases simulation overhead.

[0004] Accurate and rapid synchronization of multiple processes or threads is a major challenge in parallel simulation. Quantum-based barrier synchronization is a global synchronization algorithm. Compared to cycle-by-cycle synchronization, this method reduces synchronization overhead. Compared to complete synchronization, it offers advantages in accuracy. However, it still requires setting barriers to synchronize all cores.

[0005] Two typical clock synchronization algorithms for parallel simulations are LBTS and FNM. The LBTS algorithm is used in parallel and distributed simulations to manage and control the progression of simulation time. It ensures that events are processed in a causally consistent order, i.e., in non-decreasing timestamp order, which is crucial for maintaining the integrity and correctness of the simulation. The Forecast Null-Message (FNM) algorithm is an event scheduling and time management algorithm used in parallel discrete event simulations. It avoids timestamp reversal and inconsistency problems between different processors by sending null messages, thus ensuring the correctness of the simulation. The drawback of this method is that it requires prediction of on-chip network transmission delays, and the timing model has some error.

[0006] In multi-chip parallel simulation, each chip corresponds to an independent simulation process, responsible for simulating the functional model of its respective chip. Chips communicate with each other through an inter-chip network, and this communication process includes both transmission delay and data transfer delay. Transmission delay refers to the time required from the start of data packet transmission to its complete completion, while data transfer delay refers to the time it takes for the data packet to travel through the inter-chip network. Accurately simulating these delays is crucial for reflecting the communication timing and network congestion status of the real system. However, traditional global synchronization algorithms and staged clock synchronization strategies, while ensuring the correctness of the simulation, often lead to a significant reduction in simulation efficiency due to frequent synchronization, especially in computationally intensive tasks, where the performance bottleneck is particularly prominent.

[0007] Consider the realities of multi-chip architectures: each chip independently runs its own task. When one chip needs to transmit a data packet to another chip via the on-chip network, there is a transmission delay that must be waited for—specifically, the delay from when the data packet is sent from the chip until it completely leaves that chip. Similarly, when the receiving chip needs to receive a data packet, it must first wait for the time it took for the data packet to be sent from the sending chip, plus the transmission delay within the on-chip network.

[0008] To accurately reflect the two delays to the sender and receiver chips mentioned above, and to address the efficiency issues of traditional synchronization methods, this invention proposes a progressive event-driven synchronization control method. This method improves simulation efficiency by dynamically controlling the synchronization operations of the simulation process, reducing unnecessary synchronization overhead. Summary of the Invention

[0009] The purpose of this invention is to address the shortcomings of existing technologies by providing a progressive event-driven synchronization control method.

[0010] To achieve the above objectives, the present invention provides a progressive event-driven synchronization control method, comprising the following steps: (1) Parallel simulation: Multiple simulation processes are started simultaneously to simulate each core in the multi-core system, and the synchronization between simulation processes is managed by the global manager; (2) Synchronization on demand: When the cores simulated by the simulation process communicate with each other, that is, when the simulation process initiates a cross-process communication request, the global manager synchronizes the relevant processes. (3) Process synchronization: When a simulation process has a cross-process communication requirement, it submits a corresponding request to the global manager; the global manager ensures that other cross-process communication events earlier than the request have been simulated; if a simulation process has not yet reached the time point, the process that initiated the request will be suspended by the global manager until the request can be executed. (4) Network simulation and timing simulation: When the request in step (2) can be executed, in order to accurately simulate the communication delay through the chip's on-chip network, the global manager will start the inter-chip network simulator and simulate the communication event; at the same time, in order to ensure that the simulation results of the inter-chip network simulator can accurately reflect each simulation process, when the inter-chip network simulator simulates an interactive event, the simulation time of all simulation processes that do not participate in the interaction is faster than the current simulation time of the inter-chip network simulator; after the inter-chip network simulator completes the simulation of an interactive event, the global manager will advance the simulation time of the relevant processes according to the simulation results.

[0011] Furthermore, when a simulation process issues a communication request, the global manager records the position of the request based on the current simulation system time and the local time of the process from which the request originated. A clock line is introduced to represent all simulation tasks that the simulation system has completed up to the time indicated by the line. The clock line is maintained by the global manager to ensure that the time progress of all parallel simulation processes is strictly synchronized and follows a causal order. The clock line is defined as the minimum simulation time of all currently unsuspended simulation processes, representing the global time boundary that the simulation system has completed. The clock line can only advance after all cross-process events before the clock line have been simulated, thereby preventing any process's simulation time from exceeding that of the slowest global process and ensuring that the causal relationship of events is not disrupted.

[0012] Furthermore, the communication request includes a send request and a receive request; during the simulation, each simulation process notifies the global manager of the request when initiating an inter-process communication request; the global manager will process the request accordingly based on its type. If the request type is "send", the simulation process that initiated the request will be suspended, and communication requests that have not completed the simulation will be placed in an event processing priority queue. If the request type is "receive", the global manager first determines whether the corresponding message has completed network transmission simulation. If the message has not yet been transmitted, the receiving process is temporarily suspended, waiting for the transmission to complete. If it has been completed, the manager determines whether to advance the simulation time of the receiving process based on the relationship between the sending time plus the transmission delay and the receiving request time.

[0013] Furthermore, whenever the clock line maintained by the global manager is updated, the global manager checks whether the clock period of the request at the top of the event processing priority queue is less than or equal to the clock line. If so, the request is removed from the queue and the inter-chip network emulator is started to obtain the relevant send and transmit delays.

[0014] Furthermore, if the data sender's sending time T send Plus transmission delay D trans Greater than the receiver's request sending time T recv If so, the receiving process does not need to advance its simulation clock; otherwise, the process must wait until time T. send +D trans When the data transmission is complete, the receiver sends a receive request, T recv ≥ T send + D trans The receiving process does not need to wait and can directly receive data; when the data has not been completely transmitted but the receiver has already sent a receive request, T recv < T send +D trans The receiving process needs to wait until time T. recv + D trans Only then can the data be accepted.

[0015] Furthermore, the global manager continuously monitors the real-time latency simulation results output of the inter-chip network simulator. When a latency result is read, the global manager records the latency and resumes the corresponding simulation process, informing it of the time delay information. The simulation process will automatically wait for the corresponding delay. The global manager controls the simulation clock of the inter-chip network simulator to ensure that its simulation time is less than or equal to the clock line, so as to ensure that all events can be simulated at the correct time.

[0016] Furthermore, when the sending process has completed sending the message and the inter-chip network simulator reports that the data packet has arrived in the receiving process's buffer, even if the receiving process has not yet initiated a receiving request, the message can still be completely saved. Once the receiving request is sent, the message can be read directly, avoiding message loss and ensuring timing correctness. The two communicating parties exchange data through pre-allocated shared memory, ensuring efficient and isolated data transmission.

[0017] To achieve the above objectives, the present invention also provides a progressive event-driven synchronization control device, including one or more processors, for implementing the progressive event-driven synchronization control method described above.

[0018] To achieve the above objectives, the present invention also provides an electronic device, including a memory and a processor, wherein the memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the above-described progressive event-driven synchronization control method.

[0019] To achieve the above objectives, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described progressive event-driven synchronization control method.

[0020] The beneficial effects of this invention are as follows: It achieves efficient collaboration and synchronization between simulation processes in a multi-core system, ensuring the causal relationship of cross-process events while avoiding the performance overhead caused by frequent global synchronization. Simulation processes can run freely when there is no communication requirement, without passively waiting, maximizing the utilization of parallel simulation. The introduction of a "busy wait" mechanism not only more realistically simulates the core's operating state but also provides an accurate basis for power consumption estimation. Overall, this invention significantly improves the accuracy and operating efficiency of multi-core parallel simulation and is suitable for functional verification and performance analysis of large-scale complex multi-core chips. Attached Figure Description

[0021] Figure 1 This is the overall simulation architecture diagram of the present invention; Figure 2 This is a conceptual diagram of the progressive event-driven synchronization control method of the present invention; wherein, Figure 2 In (a), the clock line represents the simulation time of the simulation system, and the vertical axis represents the running time of the actual system; Figure 2 In (b), the advancement of the vertical axis represents the advancement of the runtime of the simulated actual system; Figure 2 In (c), the clock line advance represents the simulation time advancement of the simulation system; Figure 3 This is a flowchart illustrating an example of the distributed parallel simulation synchronization algorithm of the present invention; wherein, Figure 3 (a) shows the simulation processes A, B, and C at their respective local clock t i、 t i+1、 t i+2 The state of initiating a send request (send D, send C) and a receive request (receive D), and being suspended by the global manager; Figure 3 (b) shows the simulation process D at the local clock t i+3Initiate a send request (send C), the global manager confirms that all processes are suspended, and after the clock line changes, "S" AD "The status after processing begins and is completed;" Figure 3 (c) shows the clock line at "S" AD "After completion, make further changes, "S" BC "The status after the request has been processed and completed;" Figure 3 (d) shows the clock line at "S" BC "After completion, make further changes, "S" DC "The status after the request has been processed and completed;" Figure 3 (e) Shows “S DC "Request to complete the transmission delay simulation. Simulation process D is unsuspended and busy waiting for the updated clock line. At the same time, the inter-chip network simulator is suspended and waiting for the clock line to be adjusted." Figure 3 (f) Figure 3 (g) and Figure 3 (h) shows the process where simulation process C and simulation process D initiate a receive request one after another, and because both requests have delayed data, they can proceed directly after waiting for the corresponding delay. Figure 4 This is a schematic diagram of the structure of the device of the present invention; Figure 5 This is a schematic diagram of an electronic device according to the present invention. Detailed Implementation

[0022] This section will describe exemplary embodiments in detail, the contents of which are illustrated in the accompanying drawings. In the following description, unless otherwise stated, the same numbers in different drawings denote the same or similar elements. The described embodiments do not represent all possible embodiments of the invention, but are merely examples of apparatuses and methods consistent with some aspects of the invention, as specifically set forth in the appended claims.

[0023] This invention provides a progressive event-driven synchronization control method. This method improves simulation efficiency by dynamically controlling the synchronization operations of the simulation process, reducing unnecessary synchronization overhead.

[0024] When a core needs to send data to another core, the simulation process to which that core belongs must simulate this communication behavior. Specifically, when a core sends a communication request, its simulation process initiates a communication request, indicating its intention to transmit a data packet to the target core. This behavior is called a "cross-core (process) communication event." In multi-core parallel simulation, to ensure the accurate order of cross-core events, this invention designs a simulation synchronization framework centrally coordinated by a Global Manager (GM). Within this framework, this invention also proposes a two-dimensional coordinate graph to represent the simulation process. Figure 2 As shown in (a), the vertical axis in the figure represents the "simulation time that each simulation process has completed", and the horizontal axis represents the "actual time that the simulation system has actually spent".

[0025] When a simulation process issues a communication request, the global manager records the position of the request based on the current simulation system time and the local time of the process from which the request originated. Furthermore, this invention introduces the concept of a "clock level" on this coordinate axis, representing all simulation tasks completed up to the time indicated by that level. The clock level is maintained by the global manager, ensuring that the time progress of all parallel simulation processes is strictly synchronized and follows a causal order. The clock level is defined as the minimum simulation time of all currently unsuspended simulation processes, representing the global time boundary that the simulation system has completed. The clock level only advances after all cross-process events prior to it have been simulated, thus preventing any process's simulation time from exceeding that of the slowest global process and ensuring that the causal relationships of events are not disrupted.

[0026] Furthermore, the "simulation time completed by each simulation process" represented by the vertical axis needs to take into account the potential differences in simulation speed and chip frequency among different emulators. This difference can lead to inconsistencies between the simulation time of different simulation processes and the actual system time. Specifically, if some simulation processes operate at higher frequencies, the time represented by each clock cycle will be shorter than that of processes with lower frequencies, resulting in asynchrony between simulation time and actual time. Therefore, this invention uses the actual system runtime as a benchmark to achieve time alignment of the behaviors of various emulators, ensuring that the simulation is not interfered with by hardware and software factors. The translation process of the vertical axis is as follows: Figure 2 As shown in (b), it represents the passage of time in the real simulation system, that is, the progress of time in the entire simulation process.

[0027] Furthermore, the significance of the "clock line" concept lies in the fact that the clock line can only be advanced when all events under the clock line have been executed and the simulation is complete. This mechanism ensures that in a real multi-chip system, communications occurring at the same time can be synchronously simulated in the inter-chip network simulator, thereby obtaining latency data that conforms to reality. Through this mechanism, the causal relationships between cross-process events can be ensured to be correct, thus not affecting the causal relationships of local events in each simulation process, achieving efficient simulation of the overall system. The translation of the clock line is as follows: Figure 2 As shown in (c), all simulation processes have reached the time progress indicated by the clock line.

[0028] This invention categorizes communication requests into two types: Send requests and Receive requests. During simulation, each simulation process notifies the global manager of any inter-process communication request it initiates. The global manager will then process the request accordingly based on its type. (1) If the request type is “send”: the simulation process that initiated the request will be suspended, and communication requests that have not completed the simulation will be placed in an “event processing priority queue” (maintained by the global manager).

[0029] (2) If the request type is "receive": The global manager first determines whether the corresponding message has completed network transmission simulation. If the message has not yet been transmitted, the receiving process is temporarily suspended and waits for the transmission to complete; if it has been completed, the simulation time of the receiving process is advanced based on the relationship between the sending time plus the transmission delay and the receiving request time.

[0030] In addition, in (1), whenever the “clock line” maintained by the global manager is updated, the global manager checks whether the clock cycle of the request at the top of the “event processing priority queue” is less than or equal to the clock line. If so, the request is removed from the queue and the inter-chip network emulator is started to obtain the relevant send and transmit delays.

[0031] In (2), if the data sender's sending time (T) send ) plus transmission delay (D trans The time taken to send the request is greater than the time taken to send the request from the receiver (T). recv If the receiving process does not advance its simulation clock, then the receiving process does not need to advance its simulation clock; otherwise, the process must wait until time T. send + D trans Considering the realities of multi-core systems, data transmission can begin to reach the target location without waiting for the receiver, while the receiver must wait for data transmission to complete. Therefore, two possibilities need to be discussed: "After data transmission is complete, the receiver issues a receive request" (T...). recv ≥ T send + D trans"Data transmission has not yet been completed, but the receiver has already sent a reception request" (T) recv < T send + D trans In the first scenario, the receiving process can directly receive data without waiting; however, in the second scenario, the receiving process must wait until time T. recv + D trans Only then can the data be accepted.

[0032] Furthermore, the global manager continuously monitors the real-time latency simulation results output of the "inter-chip network emulator". When the latency result is read, the global manager records the latency and resumes the corresponding simulation process, informing it of the time latency information. The simulation process will automatically "busy wait" for the corresponding latency.

[0033] Furthermore, the global manager will also strictly control the simulation clock of the "inter-chip network emulator" to ensure that its simulation time is less than or equal to the "clock line" so that all events can be simulated at the correct time.

[0034] This invention also introduces a message buffering mechanism to solve the problem of messages potentially arriving early and being received late. That is, when the sending process has completed message transmission and the inter-chip network emulator reports that the data packet has arrived in the receiving process's buffer, even if the receiving process has not yet initiated a receive request, the message is guaranteed to be completely saved. It can be directly read after the receive request is sent, avoiding message loss and ensuring timing correctness. The communicating parties exchange data through pre-allocated shared memory, ensuring efficient and isolated data transmission.

[0035] Throughout the simulation process, the simulation clock of the inter-chip network simulator is constrained by the clock line, preventing premature simulation of events and ensuring synchronization between delayed data and global causal relationships. The global manager continuously schedules the inter-chip network simulator based on the event queue and clock line, acquiring delay results in real time and waking up the corresponding simulation processes. It is particularly noteworthy that the clock line's progression is unaffected by receiving processes suspended while waiting for communication. Even if a receiving process is suspended, its time progression is delayed until the communication is completed, ensuring that it does not hinder the advancement of the global time boundary, thereby improving simulation efficiency.

[0036] Through the aforementioned mechanism, this invention achieves efficient collaboration and synchronization between simulation processes in a multi-core system, ensuring the causal relationship of cross-process events while avoiding the performance overhead caused by frequent global synchronization. Simulation processes can run freely when there is no communication requirement, without passively waiting, maximizing the utilization of parallel simulation. The introduction of a "busy wait" mechanism not only more realistically simulates the core's operating state but also provides an accurate basis for power consumption estimation. Overall, this invention significantly improves the accuracy and efficiency of multi-core parallel simulation, making it suitable for functional verification and performance analysis of large-scale complex multi-core chips.

[0037] Next, we will combine Figure 1 and Figure 2 The embodiments of the present invention will be described in detail below. To clearly illustrate the implementation process, the diagrams and steps mentioned in the following description will help to better understand the working principle and implementation of the present invention.

[0038] 1. Simulation System Architecture like Figure 1 As shown, the progressive event-driven synchronization control method of the present invention mainly consists of the following components: (1.1) Global Manager (GM): Responsible for managing and coordinating the interaction and synchronization of all simulation processes, ensuring the timing consistency between various simulation processes, and monitoring the communication requests and event queues of simulation processes.

[0039] (1.2) Inter-chip network simulator (NoI): simulates the transmission delay of communication between chips within a multi-chip chip via on-chip network, and is responsible for calculating message sending delay and transmission delay, and feeding back the delay results.

[0040] (1.3) Core particle simulator: It corresponds to the independent simulation process of each core particle and is responsible for the simulation calculation of core particle functions and timing models, as well as initiating communication requests with other core particles.

[0041] 2. Progressive event-driven synchronization mechanism The core of this invention lies in a progressive event-driven synchronization method based on a "clock line" mechanism. This mechanism greatly reduces unnecessary synchronization waiting and improves simulation efficiency by dynamically controlling the synchronization operation of the simulation process.

[0042] Definition and function of the clock line: The clock line serves as a marker of global simulation time, maintained by the global manager, and is defined as the minimum simulation time among all currently unsuspended simulation processes. The clock line represents the global time boundary that the simulation system has completed. The clock line only advances after all cross-process communication events preceding it have been simulated, thus ensuring the accuracy of event causality and preventing any simulation process from leading the slowest global process.

[0043] (2.1) Communication Request Processing: When the chip simulator initiates an inter-process communication request (send or receive), the request is submitted to the global manager. The global manager dynamically decides whether to suspend the simulation process and wait for the clock line to advance, or to immediately execute the corresponding communication simulation, based on the request type and clock line status.

[0044] Inter-process communication specifically involves using shared memory or files as a medium, allowing one simulated process to "write" (i.e. send) to it, while another simulated process "reads" (i.e. receives) from it, thereby simulating communication and data transmission between cores in a multi-core system.

[0045] (2.2) Send Request Processing: For a send request, if the clock line has reached the requested time, the global manager starts the inter-chip network simulator to perform communication simulation and calculate the sending and transmission delays. The simulation process that initiated the send request enters a "busy wait" state and continues execution after the delay is completed. If the clock line has not yet reached the requested time, the send process is suspended and waits.

[0046] (2.3) "Receive" Request Processing: For a receive request, the global manager determines whether the corresponding data packet has completed the transmission simulation. If not, the receiving process suspends and waits; if it has completed, it determines whether the receiving process needs to advance the simulation time or directly receive the data based on the sending time and transmission delay. The receiving process may also enter a "busy waiting" state to simulate actual waiting.

[0047] 3. Scheduling and Synchronization of Simulation Processes (3.1) Event Priority Queue Management: The global manager maintains a priority queue based on the event time to store all unprocessed communication requests. Whenever the clock line advances, the manager checks whether the event at the head of the queue has met the execution conditions. If the conditions are met, the inter-chip network simulator simulation delay is triggered.

[0048] (3.2) Simulation clock difference handling: Since the simulation speed and chip operating frequency of different simulation processes may be different, the present invention uses the real system running time as a unified benchmark to realize time alignment between each simulator, ensure the synchronization of simulation time and real time, and avoid timing errors caused by the timing difference of each process.

[0049] (3.3) Message Buffering Mechanism: To solve the problem of "early arrival and late reception" of messages, this invention introduces a message buffer. When the sending process completes the message sending and the network simulator reports that the message has arrived, the message is stored in the receiver's buffer. Regardless of when the receiving process initiates a reception request, the message can be read correctly, ensuring data integrity and accurate timing.

[0050] (3.4) "Busy wait" mechanism: The simulation process performs "busy wait" during the waiting period for sending or receiving delay, which truly simulates the activity state of the chip, improves the simulation accuracy, and provides an accurate basis for subsequent power consumption estimation.

[0051] 4. Global Manager and Simulation Process Interaction Protocol To ensure the accuracy and synchronization of the simulation process, this invention defines an interaction protocol between the global manager and the simulation process. This mainly includes the following functional and timing protocols, as shown in Table 1.

[0052] In Table 1, the RECEIVE (receive data), SEND (send data), and RESULT (permit read / write permission) commands are used for function synchronization. Each command includes the source address. <source address> and destination address <destinationaddress>This is to distinguish different cores, thereby enabling read / write matching within the global manager. The RECEIVE and SEND commands are sent from the core emulator to the global manager, corresponding to read and write operations respectively. The RESULT command is sent from the global manager to the core emulator as a response from the core to the global manager's request.

[0053] In the "Timing Protocol," the READ and WRITE commands are sent from the core emulator to the global manager, corresponding to the RECEIVE and SEND commands. However, the difference is that the READ and WRITE commands include the simulation process time information at the time the request was issued. Additionally, the SYNC response command is sent from the global manager to the core emulator as a reply from the core to the global manager's request, informing the simulation process that the local time needs to be adjusted.

[0054] Table 1: Definitions of Functional Protocols and Timing Protocols

[0055] Example description See Figure 3(a) to Figure 3 (h) Hereinafter, the invention will be described in detail by way of examples.

[0056] Assuming the current simulation system has four simulation processes, A, B, C, and D, the global manager receives the following communication requests sequentially from xi to xi+5:

[0057] Here, "send" and "receive" refer to sending and receiving requests, respectively. The "send" request sends data from the source process to memory shared by both the source and destination processes; the "receive" request reads data from memory shared by both processes.

[0058] It's important to emphasize that in this example, it's not guaranteed that `ti` is less than `ti+1`. Furthermore, this example first assumes that all requests before `xi` have been processed. Additionally, it makes the following assumptions about each simulation process: each simulation process has the same frequency; that is, in this example, the "local clock" of each simulation process is equivalent to the "local real time" in the aforementioned principle. See [link to relevant documentation] Figure 3 The following is a detailed explanation of this example: 1. The simulation system reaches time x. i Simulation process A is running locally t i The clock cycle initiates send D. Based on the aforementioned principle, the global manager cannot confirm whether all running processes have reached t. i Therefore, simulation process A must be suspended first. Similarly, the simulation system time is x i+1 At that time, simulation process B is running at local clock t. i+1 When the send C request is initiated, the global manager can only suspend the simulation process B first.

[0059] "S AD "" indicates a "send request, with process A as the initiating process and process D as the destination process", and the vertical axis time represents the local clock of the process that initiated the request.

[0060] 2. See Figure 3 (a) Simulation system time to x i+2 At that time, simulation process C is running locally t i+2 Clock cycle initiates receive D(R) CD At this point, because the global manager does not have information about R... CD The delayed data. The global manager suspends the simulation process C.

[0061] R CD "This means "receive request, initiated by C, destination D".

[0062] 3. See Figure 3 (b) Simulation system time to x i+3 At that time, the simulation process D is running locally t i+3 Clock cycle initiates send C(S) DC At this point, the global manager can see the clock cycles of all running simulation processes, and all simulation processes are suspended. The "clock line" is now pushed to infinity. At this point, "S..." AD "、"S BC "and "S DC "It will be simulated by an inter-chip network emulator. Here, we assume 'S'..." AD The communication request for "" first completed the "send delay (D)" send Simulation of "(assuming D)" send_A At this point, simulation process A will be unsuspended and busy-wait until t. i + D send_A At this point, the "clock line" is adjusted to t. i + D send_A .

[0063] Furthermore, because the clock line has been adjusted at this time, the inter-chip network emulator must be temporarily suspended and wait.

[0064] 4. See Figure 3 (c), here we assume t i+1 Less than t i+2 Furthermore, simulation process A has far exceeded t after several cycles. i+1 At this point, the clock line will rise, the inter-chip network emulator will resume operation, and the "S" will be completed. BC "Requested" transmission delay (D send Simulation of "(assuming D)" send_B At this point, simulation process B will be unsuspended and busy-wait until t. i+1 +D send_B .

[0065] 5. See Figure 3 (d) Here it is assumed that simulation process A and simulation process B have far exceeded t after a certain number of cycles. i+3 At this point, the clock line will rise, the inter-chip network emulator will resume operation, and the "S" will be completed. DC "Requested" transmission delay (D send Simulation of "(assuming D)" send_D At this point, simulation process D will be unsuspended and busy-wait until t. i+3 +D send_D .

[0066] 6. As simulation processes A, B, and C are unsuspended and proceed independently, the clock line rises accordingly. Assume that at this point, the inter-chip network simulator has completed the simulation of "S" first. DC "Request" transmission delay (D trans Simulation of "(assuming D)" recv_DC At this point, simulation process C will be unsuspended and busy-wait until max(t) is reached. i+2 , t i+3 + D recv_CD ).

[0067] like Figure 3 As shown in (e). In this figure, assume t i+2 < t i+3 + D recv_CD At this point, simulation process C needs to advance the clock cycle to t. i+3 + D recv_CD .

[0068] 7. Simulation processes C and D proceed independently, each at t i+5 and t i+4 Because R was initiated CB and R DA Hang up. As shown in Figure 3(f).

[0069] As simulation processes A and B continue to advance, assuming the inter-chip network simulator first completes the simulation of "S"... AD "Request" transmission delay (D trans Simulation of "(assuming D)" recv_AD At this point, simulation process D will be unsuspended and busy-wait until max(t) is reached. i+4 , t i + D recv_AD ).

[0070] like Figure 3 As shown in (g). In this figure, assume t i+4 ≥ t i + D recv_AD At this point, the simulation process D does not need to change the local clock.

[0071] 8. As simulation processes A, B, and D are unsuspended and proceed independently, the clock line rises accordingly. Assume that at this point, the inter-chip network simulator has first completed the simulation of "S". BC "Request" transmission delay (D trans Simulation of "(assuming D)" recv_BC At this point, simulation process C will be unsuspended and busy-wait until max(t) is reached. i+5 , t i+1 + D recv_BC ).

[0072] like Figure 3 As shown in (h). In this figure, it is also assumed that t i+5 ≥ t i+1 + D recv_BC At this point, simulation process C does not need to change the local clock.

[0073] Corresponding to the aforementioned embodiments of the progressive event-driven synchronization control method, the present invention also provides embodiments of a progressive event-driven synchronization control device.

[0074] See Figure 4 The progressive event-driven synchronization control device provided in this embodiment of the invention includes one or more processors for implementing the progressive event-driven synchronization control method in the above embodiments.

[0075] The embodiments of the progressive event-driven synchronization control device of the present invention can be applied to any device with data processing capabilities, such as a computer. The device embodiments can be implemented in software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of any data-processing device loading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 4 The diagram shown is a hardware structure diagram of any device with data processing capabilities where the progressive event-driven synchronization control device of the present invention is located, except... Figure 4 In addition to the processor, memory, network interface, and non-volatile memory shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0076] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0077] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the present invention according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0078] Corresponding to the aforementioned embodiments of the progressive event-driven synchronization control method, this application also provides an electronic device, including: one or more processors; a memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the progressive event-driven synchronization control method as described above. Figure 5 The diagram shown is a hardware structure diagram of any device with data processing capabilities where the progressive event-driven synchronization control method provided in this application embodiment is implemented. Except for... Figure 5 In addition to the processor, memory, DMA controller, disk, and non-volatile memory shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0079] Corresponding to the aforementioned embodiments of the progressive event-driven synchronization control method, this embodiment of the invention also provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the progressive event-driven synchronization control method described in the above embodiments.

[0080] The computer-readable storage medium can be an internal storage unit of any data processing device described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be any data processing device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units of any data processing device and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the data processing device, and can also be used to temporarily store data that has been output or will be output.

[0081] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0082] The above embodiments are only used to illustrate the design concept and features of the present invention, and their purpose is to enable those skilled in the art to understand the content of the present invention and implement it accordingly. The protection scope of the present invention is not limited to the above embodiments. Therefore, all equivalent changes or modifications made based on the principles and design ideas disclosed in the present invention are within the protection scope of the present invention.< / destinationaddress>

Claims

1. A progressive event-driven synchronization control method, characterized in that, Includes the following steps: (1) Parallel simulation: Multiple simulation processes are started simultaneously to simulate each core in the multi-core system, and the synchronization between simulation processes is managed by the global manager; (2) Synchronization on demand: When the cores simulated by the simulation process communicate with each other, that is, when the simulation process initiates a cross-process communication request, the global manager synchronizes the relevant processes. (3) Process synchronization: When a simulation process has a cross-process communication requirement, it submits a corresponding request to the global manager. The global manager records the position of the request based on the current simulation system time and the local time of the process from which the request originates, and maintains a clock line. The clock line is defined as the minimum simulation time of all currently unsuspended simulation processes, representing the global time boundary that the simulation system has completed. The clock line advances only after all cross-process communication events before the clock line have been simulated. The global manager ensures that all other cross-process communication events earlier than the request have been simulated. If a simulation process has not yet reached that time point, the process that initiated the request will be suspended by the global manager until the request can be executed; (4) Network simulation and timing simulation: When the request in step (2) can be executed, in order to accurately simulate the communication delay through the chip on-chip network, the global manager will start the inter-chip network simulator and simulate the communication event; at the same time, in order to ensure that the simulation results of the inter-chip network simulator can accurately reflect each simulation process, when the inter-chip network simulator simulates the interaction event, the simulation time of all simulation processes that do not participate in the interaction is faster than the current simulation time of the inter-chip network simulator. Once the inter-chip network simulator completes the simulation of an interaction event, the global manager will advance the simulation time of the relevant processes based on the simulation results.

2. The progressive event-driven synchronization control method according to claim 1, characterized in that, When a simulation process issues a communication request, the global manager records the position of the request based on the current simulation system time and the local time of the process from which the request originated. A clock line is introduced to represent all simulation tasks that the simulation system has completed up to the time indicated by the line. The clock line is maintained by the global manager to ensure that the time progress of all parallel simulation processes is strictly synchronized and follows a causal order. The clock line is defined as the minimum simulation time of all currently unsuspended simulation processes, representing the global time boundary that the simulation system has completed. The clock line can only advance after all cross-process events before the clock line have been simulated, thereby preventing any process's simulation time from exceeding that of the slowest global process and ensuring that the causal relationship of events is not disrupted.

3. The progressive event-driven synchronization control method according to claim 2, characterized in that, The communication request includes a send request and a receive request; during the simulation, each simulation process notifies the global manager of the request when initiating an inter-process communication request; the global manager will process the request accordingly based on its type. If the request type is "send", the simulation process that initiated the request will be suspended, and communication requests that have not completed the simulation will be placed in an event processing priority queue. If the request type is "receive", the global manager first determines whether the corresponding message has completed network transmission simulation. If the message has not yet been transmitted, the receiving process is temporarily suspended, waiting for the transmission to complete. If it has been completed, the manager determines whether to advance the simulation time of the receiving process based on the relationship between the sending time plus the transmission delay and the receiving request time.

4. The progressive event-driven synchronization control method according to claim 3, characterized in that, Whenever the clock line maintained by the Global Manager is updated, the Global Manager checks whether the clock period of the request at the top of the event processing priority queue is less than or equal to the clock line. If so, the request is removed from the queue and the inter-chip network emulator is started to obtain the relevant send and transmit delays.

5. The progressive event-driven synchronization control method according to claim 3, characterized in that, If the data sender's sending time T send Plus transmission delay D trans Greater than the receiver's request sending time T recv If so, the receiving process does not need to advance its simulation clock; otherwise, the process must wait until time T. send + D trans When the data transmission is complete, the receiver sends a receive request, T recv ≥ T send + D trans The receiving process does not need to wait and can directly receive data; When the data transmission is not yet complete, and the receiver has already sent a receive request, T recv < T send + D trans The receiving process needs to wait until time T. recv +D trans Only then can the data be accepted.

6. The progressive event-driven synchronization control method according to claim 2, characterized in that, The global manager continuously monitors the real-time latency simulation results output of the inter-chip network emulator. When a latency result is read, the global manager records the latency and resumes the corresponding simulation process, informing it of the time delay information. The simulation process will automatically busy-wait for the corresponding delay. The global manager controls the simulation clock of the inter-chip network emulator to ensure that its simulation time is less than or equal to the clock line, so as to ensure that all events can be simulated at the correct time.

7. The progressive event-driven synchronization control method according to claim 1, characterized in that, When the sending process has completed sending the message and the inter-chip network simulator reports that the data packet has arrived in the receiving process's buffer, even if the receiving process has not yet initiated a receiving request, the message can be guaranteed to be completely saved. Once the receiving request is sent, the message can be read directly, avoiding message loss and ensuring timing correctness. The two communicating parties exchange data through pre-allocated shared memory, ensuring efficient and isolated data transmission.

8. A progressive event-driven synchronization control device, characterized in that, It includes one or more processors for implementing the progressive event-driven synchronization control method according to any one of claims 1-7.

9. An electronic device comprising a memory and a processor, characterized in that, The memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the progressive event-driven synchronization control method according to any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the progressive event-driven synchronization control method as described in any one of claims 1-7.

Images