Joint simulation method, system, electronic device and storage medium

Abstract

The application provides a joint simulation method and system, an electronic device and a storage medium. The method comprises the following steps: in a system-level simulation environment, an embedded program is executed by an instruction core to generate a simulation time advancement amount, and an event scheduler of the system-level simulation environment is driven to advance operation according to the simulation time advancement amount; and in the process of the event scheduler operation, a single-step advancement interface is called through a synchronous coroutine according to a preset physical simulation step length period, so as to drive the physical simulation environment to run one step. The advancement of the physical simulation environment is based on a synchronous mechanism triggered by the system-level simulation environment at a fixed step length period, so that the integral step length of the physical engine is strictly aligned with the virtual time elapse of the system-level simulation environment, the cumulative time sequence deviation caused by independent running of the two is avoided, and the time axis out of step in the joint simulation is prevented.

Description

Technical Field

[0001] This application relates to the technical field of co-simulation methods, and more particularly to a co-simulation method, system, electronic device, and storage medium. Background Technology

[0002] Embedded systems typically consist of a core processor, on-chip integrated devices, externally connected device components, various sensors, actuators, and the physical environment in which they are embedded. In real-world operation, the control software of such systems not only directly reads and writes the processor's on-chip registers to configure hardware states, but also accesses and operates various external interfaces connected to the processor. More importantly, the software needs to interact with external physical objects in real time, receiving feedback data from sensors and driving actuators to perform corresponding actions based on this information, thus forming a complete, dynamic, closed-loop control interaction to ensure the system can accurately and reliably respond to changes and demands in the actual environment. Traditional system-level simulation environments (such as simulation platforms based on SystemC or instruction set simulators) can perform periodic-level precise simulations of processor core instruction execution, on-chip bus, and peripheral register state changes.

[0003] When performing joint simulations in a system-level simulation environment and a physical simulation environment, the timing deviations in simulations are caused by the different mechanisms of discrete event scheduling and continuous physical time stepping, as well as the logical disconnect between the execution of embedded programs by the instruction core and the time progression of the system-level simulation environment. This makes it impossible to accurately control the time alignment of the two simulation environments. Summary of the Invention

[0004] This application provides a co-simulation method, system, electronic device, and storage medium to solve the problems existing in related technologies. The technical solution is as follows:

[0005] In a first aspect, embodiments of this application provide a co-simulation method, including:

[0006] Based on the device binding relationship between the system-level simulation environment and the physical simulation environment, a bidirectional data interaction path is constructed between physical devices in the physical simulation environment and off-chip devices in the system-level simulation environment. The system-level simulation environment includes instruction cores, on-chip devices, and off-chip devices.

[0007] In the system-level simulation environment, the embedded program is executed through the instruction core to generate the simulation time advance amount and drive the event scheduler of the system-level simulation environment to advance the operation according to the simulation time advance amount;

[0008] Obtain the simulation step size of the physical simulation environment, create a synchronous coroutine in the system-level simulation environment, and use the synchronous coroutine to call the single-step advancement interface according to the simulation step size cycle to drive the physical simulation environment to run a simulation step size;

[0009] When the physical simulation environment is in operation, the physical simulation data generated by the physical device in the physical simulation environment is synchronized to the external device through a two-way data interaction channel. This allows the instruction core to read the physical simulation data through the on-chip device. The control data written by the instruction core to the on-chip device is synchronized to the physical device through the external device and the two-way data interaction channel, so that the physical device can update its status according to the control data in the physical simulation environment.

[0010] Secondly, embodiments of this application provide a simulation system, including:

[0011] The first construction module is used to build a bidirectional data interaction path between physical devices in the physical simulation environment and off-chip devices in the system-level simulation environment, based on the device binding relationship between the system-level simulation environment and the physical simulation environment. The system-level simulation environment includes instruction cores, on-chip devices and off-chip devices.

[0012] The first generation module is used to execute embedded programs through the instruction core in the system-level simulation environment, generate simulation time advance, and drive the event scheduler of the system-level simulation environment to advance the operation according to the simulation time advance.

[0013] The first acquisition module is used to acquire the simulation step size of the physical simulation environment and create a synchronous coroutine in the system-level simulation environment. The synchronous coroutine is used to call the single-step advancement interface according to the simulation step size cycle to drive the physical simulation environment to run one simulation step size.

[0014] The first synchronization module is used to synchronize the physical simulation data generated by the physical device in the physical simulation environment to the external device through a two-way data interaction channel when the physical simulation environment is running. This allows the instruction core to read the physical simulation data through the on-chip device and synchronize the control data written by the instruction core to the on-chip device to the physical device through the external device and the two-way data interaction channel, so that the physical device can update its status in the physical simulation environment according to the control data.

[0015] Thirdly, embodiments of this application provide an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to execute the aforementioned co-simulation method.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium that stores computer instructions, wherein when the computer instructions are executed on a computer, the methods in any of the above-described embodiments are performed.

[0017] The advantages or beneficial effects of the above technical solutions include at least the following:

[0018] The co-simulation method in this embodiment, within a system-level simulation environment, executes an embedded program through an instruction core to generate simulation time advance increments. These increments drive the event scheduler of the system-level simulation environment. During the event scheduler's operation, a single-step advancement interface is called via a synchronous coroutine according to a preset physical simulation step size cycle to drive the physical simulation environment to run one step. The advancement of the physical simulation environment is based on a synchronization mechanism triggered by the system-level simulation environment at a fixed step size cycle. This ensures strict alignment between the physical engine's integral step size and the virtual time elapsed in the system-level simulation environment, avoiding cumulative timing deviations caused by their independent operation and preventing timeline synchronization issues in the co-simulation. Furthermore, a bidirectional data interaction path is established between the physical device and external devices. After the physical simulation environment advances, this path synchronizes physical simulation data to external devices for the instruction core to read through the on-chip device. Simultaneously, control data written by the instruction core to the on-chip device is synchronized to the physical device for execution status updates. The embedded program on the instruction core can obtain physical simulation data and send control data by reading and writing regular on-chip device registers. The entire closed-loop interaction path conforms to the signal flow of real hardware, so that the test process does not require modification of the embedded program source code, making the joint simulation test realistic and reliable at the register and pin levels.

[0019] The above overview is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features of this application will become readily apparent from the accompanying drawings and the following detailed description. Attached Figure Description

[0020] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in this application and should not be construed as limiting the scope of this application.

[0021] Figure 1 This is a flowchart of a co-simulation method according to an embodiment of this application.

[0022] Figure 2 This is a block diagram of an electronic device according to an embodiment of the present application.

[0023] Figure 3 A schematic diagram of the overall architecture of the co-simulation system provided in this embodiment is shown.

[0024] Figure 4 This diagram illustrates the binding relationship between on-chip and off-chip devices on the system-level simulation side in this embodiment.

[0025] Figure 5 A schematic diagram of the timing synchronization logic of the embedded co-simulation system in this embodiment is shown.

[0026] Figure 6 This diagram illustrates the data binding and interaction mechanism between the system-level simulation side and the physical simulation side in this embodiment. Detailed Implementation

[0027] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0028] Embedded systems typically consist of a processor, on-chip devices, off-chip devices, sensors, actuators, and the external physical environment. During the operation of a real system, the embedded control software not only needs to access on-chip registers and off-chip interfaces, but also needs to form a closed-loop interaction with external physical objects, sensor data, and actuator actions. However, in the early stages of system design, relying solely on actual physical hardware for testing and debugging often faces practical limitations such as high hardware environment setup costs, difficulty in reproducing faults, difficulty in safely constructing hazardous test scenarios, and long overall testing cycles.

[0029] To overcome the limitations of relying on real hardware for early testing, a co-simulation scheme combining an embedded emulation instruction core with a system-level simulation environment (such as SystemC) is typically employed. This type of scheme can load and run embedded executable programs and utilize the system-level simulation environment to establish relationships between on-chip devices, off-chip devices, pin bindings, and event scheduling. In practical implementation, instruction synchronization functions (such as `inst_sync_fun`) are typically used to convert the number of CPU instructions counted by the embedded emulation instruction core into simulation time increments for the system-level simulation environment. Simultaneously, memory read / write functions (such as `memory_read_fun` and `memory_write_fun`) are used to perform read / write operations on on-chip device registers.

[0030] However, the existing co-simulation solutions mainly focus on solving the problems of instruction execution, register access, and device timing synchronization between the embedded simulation instruction core and the system-level simulation device model. They are difficult to directly handle and simulate complex behaviors in three-dimensional physical scenes, such as the motion trajectory of physical objects, collision detection, sensor physical environment sampling, actuator mechanical response, and dynamic interaction with the external environment.

[0031] On the other hand, existing physical simulation environments (such as the GZSIM device simulation environment) can provide 3D physics engines, sensor models, and actuator models, which can be used to construct physical simulation objects such as robots, vehicles, mechanical equipment, and environmental scenes. However, if one attempts to directly integrate such physical simulation environments into the aforementioned co-simulation system of "embedded simulation instruction core and system-level simulation environment," several technical obstacles will be encountered, mainly including: how to effectively advance the operation of the physical simulation environment while maintaining the progress of the system-level simulation environment; how to establish binding relationships between devices in the physical simulation environment and off-chip devices in the system-level simulation environment; how to accurately write back the data generated by the physics engine to the devices in the system-level simulation environment; and how to distribute the control data generated by the system-level simulation environment to the actuators in the physical simulation environment.

[0032] In summary, when extending the physics engine for co-simulation on the existing framework based on instruction kernel and system-level simulation, the following technical problems exist:

[0033] Lack of a unified timing mechanism: There is a lack of a coordinated advancement mechanism triggered by the system-level simulation environment event scheduler between the operation of the system-level simulation environment and the operation of the physical simulation environment, which can easily lead to timing discrepancies during the simulation process.

[0034] Lack of standard data binding interface: There is a lack of unified and decoupled data binding path between off-chip devices in the system-level simulation environment and sensor and actuator models in the physical simulation environment;

[0035] Difficulty in writing physical feedback data: Physical data such as position, velocity, collision state, and sensor sampling values ​​generated by the physics engine are difficult to write into the off-chip device of the system-level simulation environment through a deterministic interface closed loop;

[0036] Difficulty in issuing control commands: Control quantities, configuration parameters, and externally dynamically modified data generated by external devices in the system-level simulation environment are difficult to issue to the devices in the physical simulation environment through deterministic interfaces;

[0037] The system extension has a high degree of coupling: When introducing new physical co-simulation capabilities, the existing co-simulation process of "instruction core and system-level simulation environment" is inevitably subject to significant modifications, lacking a loosely coupled extension mechanism.

[0038] Figure 1 A flowchart illustrating a co-simulation method according to an embodiment of this application is shown. Figure 1 and Figures 3-6 As shown, a co-simulation method may include:

[0039] S110: Based on the device binding relationship between the system-level simulation environment and the physical simulation environment, construct a bidirectional data interaction path between physical devices in the physical simulation environment and off-chip devices in the system-level simulation environment. The system-level simulation environment includes instruction cores, on-chip devices, and off-chip devices.

[0040] S120: In the system-level simulation environment, the embedded program is executed through the instruction core to generate the simulation time advance amount and drive the event scheduler of the system-level simulation environment to advance the operation according to the simulation time advance amount;

[0041] S130: Obtain the pre-configured simulation step size of the physical simulation environment, create a synchronous coroutine in the system-level simulation environment, and attach the synchronous coroutine to the event scheduler. The synchronous coroutine is used to call the single-step advancement interface to drive the physical simulation environment to run one simulation step size when the event scheduler advances to the trigger time corresponding to the simulation step size.

[0042] S140: When the physical simulation environment is running, the physical simulation data generated by the physical device in the physical simulation environment is synchronized to the external device through the two-way data interaction channel, so that the instruction core can read the physical simulation data through the internal device and synchronize the control data written by the instruction core to the internal device through the external device and the two-way data interaction channel to the physical device, so that the physical device can perform status updates according to the control data in the physical simulation environment.

[0043] The co-simulation method in this embodiment, within a system-level simulation environment, executes an embedded program through an instruction core to generate simulation time advance increments. These increments drive the event scheduler of the system-level simulation environment. During the event scheduler's operation, a single-step advancement interface is called via a synchronous coroutine according to a preset physical simulation step size cycle to drive the physical simulation environment to run one step. The advancement of the physical simulation environment is based on a synchronization mechanism triggered by the system-level simulation environment at a fixed step size cycle. This ensures strict alignment between the physical engine's integral step size and the virtual time elapsed in the system-level simulation environment, avoiding cumulative timing deviations caused by their independent operation and preventing timeline synchronization issues in the co-simulation. Furthermore, a bidirectional data interaction path is established between the physical device and external devices. After the physical simulation environment advances, this path synchronizes physical simulation data to external devices for the instruction core to read through the on-chip device. Simultaneously, control data written by the instruction core to the on-chip device is synchronized to the physical device for execution status updates. The embedded program on the instruction core can obtain physical simulation data and send control data by reading and writing regular on-chip device registers. The entire closed-loop interaction path conforms to the signal flow of real hardware, so that the test process does not require modification of the embedded program source code, making the joint simulation test realistic and reliable at the register and pin levels.

[0044] The co-simulation method in this embodiment is applied to a basic co-simulation system that already has an embedded simulation instruction core, a system-level device simulation environment (SystemC), an instruction synchronization function (inst_sync_fun), a memory read function (memory_read_fun), a memory write function (memory_write_fun), and a pin binding function (pin_bind_fun).

[0045] In the aforementioned basic co-simulation system, the embedded simulation instruction core is used to load the embedded executable program and execute the target central processing unit (CPU) instructions. Specifically, the memory read function (memory_read_fun) is configured to read the on-chip device registers implemented by the System-level Device Simulation Environment (SystemC); the memory write function (memory_write_fun) is configured to write to the on-chip device registers implemented by the System-level Device Simulation Environment (SystemC); and the instruction synchronization advance function (inst_sync_fun) is used to count the number of instructions executed by the CPU and convert this count into a simulation time increment for the System-level Device Simulation Environment (SystemC), thereby advancing the simulation operation of the System-level Device Simulation Environment (SystemC) through the execution of the embedded simulation instruction core.

[0046] The System-Level Device Simulation Environment (SystemC) in the basic co-simulation system is used to develop on-chip and off-chip devices in embedded simulation. Specifically, on-chip devices may include general-purpose input / output (GPIO), universal asynchronous transmitter (UART), serial peripheral interface (SPI), internal integrated circuit bus (I2C), controller area network (CAN), timers, pulse width modulation (PWM), analog-to-digital converter (ADC), direct memory access (DMA), interrupt controller, and memory controller, etc., in a system-on-a-chip (SoC); off-chip devices may include sensor interfaces, actuator interfaces, motor drivers, buttons, external memory, or other external functional devices.

[0047] In addition, the pin binding function (pin_bind_fun) is used to bind on-chip devices and off-chip devices according to their pin names. For example, it can bind a pin (Pin1) of an on-chip device to the input terminal of an off-chip device, and bind the feedback terminal of an off-chip device to a pin (Pin2) of an on-chip device. By executing the pin binding function (pin_bind_fun), a signal transmission path can be established between on-chip devices and off-chip devices in a System-on-a-Chip (SoC).

[0048] Building upon the aforementioned basic system, this embodiment adds a physical device simulation environment (GZSIM), a physical simulation loading and initialization module, a physical simulation synchronization coroutine (gzsim_sync_fun), and a global data interaction interface (map).<string, sc_gz_data> ).

[0049] Specifically, the Physical Device Simulation Environment (GZSIM) is used to develop devices within a 3D physical simulation environment. The main program creates the runtime environment of GZSIM through dynamic library loading, plugin loading, or initialization interfaces, and within this environment, creates the physics engine, engine thrusters, sensor models, and actuator models. The sensor models are configured to generate physical data such as position, velocity, distance, collision, force, images, or point clouds; the actuator models are configured to receive target velocity, target position, control force, on / off states, or other control commands.

[0050] The physical simulation synchronization coroutine (gzsim_sync_fun) is created within the system-level device simulation environment (SystemC) and is used to cascade and advance the simulation execution of the physical device simulation environment (GZSIM) during the simulation run of the system-level device simulation environment (SystemC). Its operational logic is as follows: After the system-level simulation environment starts, it obtains the simulation step size of the physical simulation environment and attaches the synchronization coroutine to the event scheduler of the system-level simulation environment according to the simulation step size cycle; when the event scheduler advances and the currently accumulated simulation time reaches an integer multiple of the simulation step size, the synchronization coroutine is triggered to call the engine booster of the physical simulation environment, driving the physical simulation environment to run a complete simulation step size, so that the physical simulation environment follows the simulation progress of the system-level simulation environment.

[0051] Global data interaction interface (map)<string, sc_gz_data> This interface is used to establish a connection path between system-level external devices (SystemC external devices) and physical simulation devices (GZSIM devices). It stores simulation interaction data structure (sc_gz_data) objects using the device name or device identifier as a string as the key. The simulation interaction data structure (sc_gz_data) contains three members: physical name (phy_name), physical data write interface (gz_write_func), and system-level data write interface (sc_write_func).

[0052] The physical name (phy_name) is used to identify the name of the device that needs to be bound between the physical device simulation environment (GZSIM) and the system-level device simulation environment (SystemC);

[0053] The physical data write interface (gz_write_func) is used to synchronize the simulation result data of the physical device simulation environment (GZSIM) to the system-level external device (SystemC external device).

[0054] The system-level data write interface (sc_write_func) is used to synchronize data from system-level off-chip devices (SystemC off-chip devices) to physical simulation devices (GZSIM devices).

[0055] Without altering the existing main simulation process of the embedded simulation instruction core and the system-level device simulation environment (SystemC), a new physical simulation synchronization coroutine (gzsim_sync_fun) is added, organically integrating the physical device simulation environment (GZSIM) into the event scheduler (SystemC event scheduler) of the system-level simulation environment, thereby improving the convenience of simulation system expansion.

[0056] The simulation operation of the System-level Device Simulation Environment (SystemC) calls the engine booster to advance the operation of the Physical Device Simulation Environment (GZSIM), forming an embedded simulation instruction core that advances the System-level Device Simulation Environment (SystemC). The System-level Device Simulation Environment (SystemC) further advances the Physical Device Simulation Environment (GZSIM) in a chain-like timing progression relationship, avoiding the risk of timing out-of-sync during the joint operation of heterogeneous simulation engines.

[0057] By introducing a global data interaction interface (map)<string, sc_gz_data> The system establishes a bidirectional synchronization mechanism between the system-level external device (SystemC external device) and the physical simulation device (GZSIM device) by defining its internal physical name (phy_name), physical data write interface (gz_write_func), and system-level data write interface (sc_write_func), thereby avoiding high coupling of the underlying code.

[0058] Based on the above data synchronization mechanism, the physical data generated by the sensor model can be synchronously read into the system-level external device (SystemC external device), and further fed back to the on-chip device of the system-on-chip (SOC) in the form of electrical signals by the original pin binding function (pin_bind_fun), thus realizing the closed-loop transmission of environmental feedback data.

[0059] The control quantities generated by the system-level off-chip device (SystemC off-chip device) can be accurately written into the actuator model by calling the system-level data write interface (sc_write_func), thereby enabling the embedded software to implement real closed-loop control of the three-dimensional physical device.

[0060] Compared to the co-simulation basic scheme that only has an embedded simulation instruction core and a system-level device simulation environment (SystemC), this embodiment introduces capabilities such as three-dimensional physical scene calculation, dynamic feedback of physical state, and verification of actuator physical response, providing a verification basis with higher engineering confidence for the logical correctness of embedded control software in real physical interaction scenarios.

[0061] Figure 3 A schematic diagram of the overall architecture of the co-simulation system provided in this embodiment is shown. Figure 3 As shown, this application extends the existing embedded simulation instruction core and system-level device simulation environment (SystemC).

[0062] Existing embedded simulation instruction cores include a Read interface, a Write interface, and a Sync interface. Existing system-level device simulation environments (SystemC) include a system-on-a-chip (SOC), external devices, an event scheduler, and Read, Write, and Sync interfaces for interacting with the embedded simulation instruction core.

[0063] In this embodiment, the co-simulation system has added the Physical Device Simulation Environment (GZSIM). The Physical Device Simulation Environment (GZSIM) includes an Engine Propeller, a Sensor Model, and an Actuator Model.

[0064] Specifically, the embedded emulation instruction core reads on-chip device registers from the System-on-Chip (SoC) via its Read interface, writes to on-chip device registers via its Write interface, and advances the simulation execution of the System-level Device Emulation Environment (SystemC) via its Sync interface. In this interaction, the Read interface in the System-level Device Emulation Environment (SystemC) corresponds to the memory read function (memory_read_fun), the Write interface corresponds to the memory write function (memory_write_fun), and the Sync interface corresponds to the instruction synchronization function (inst_sync_fun).

[0065] Within the System-on-Chip (SystemC) emulation environment, the System-on-Chip (SoC) establishes pin-level bindings with external devices using the pin-bind function (pin_bind_fun). Signal connection paths are established between the on-chip and external devices of the SoC according to pin names (e.g., Pin1, Pin2, etc.) to enable signal transmission and scheduling under the control of the Event Scheduler.

[0066] The newly added connection path between the System-level Device Simulation Environment (SystemC) and the Physical Device Simulation Environment (GZSIM) includes timing advancement lines and data transmission lines:

[0067] Timing Propeller: Used during the simulation of the system-level device simulation environment (SystemC), the synchronous coroutine calls the Engine Propeller according to the simulation step size cycle of the physical simulation environment to drive the physical device simulation environment to run a complete simulation step.

[0068] Data transmission line: Used to establish a bidirectional data synchronization channel between off-chip devices in the System-level Device Simulation Environment (SystemC) and sensor models and actuator models in the Physical Device Simulation Environment (GZSIM).

[0069] Figure 4 This diagram illustrates the binding relationship between on-chip and off-chip devices on the system-level simulation side in this embodiment. For example... Figure 4 As shown, existing on-chip devices and off-chip devices establish a connection by calling the pin binding function (pin_bind_fun).

[0070] The pin binding function (pin_bind_fun) establishes low-level pin-level connections based on the input pin name, pin number, signal direction, and binding configuration. This embodiment utilizes the existing connections between on-chip and off-chip devices, enabling physical feedback data generated in the Physical Device Simulation Environment (GZSIM) to be further transmitted to the on-chip devices of the System-on-Chip (SoC) via off-chip devices.

[0071] In one specific embodiment, the on-chip device of the system-on-a-chip (SOC) has a first pin (Pin1) and a second pin (Pin2). The first pin (Pin1) is used to transmit the output signal of the SOC to the external device, and the second pin (Pin2) is used to transmit the feedback signal of the external device to the SOC.

[0072] By calling the pin binding function (pin_bind_fun), the first pin (Pin1) is bound to the input pin of the external device, and the second pin (Pin2) is bound to the output pin of the external device. After the pin binding relationship is established, changes in the state of the registers within the System-on-Chip (SOC), changes in pin levels, and changes in the state of the external device are all scheduled uniformly by the Event Scheduler of the System-on-C environment.

[0073] Figure 5 A timing synchronization logic diagram of the embedded co-simulation system in this embodiment is shown. Figure 5 As shown, the execution logic of the timing synchronization mechanism is as follows:

[0074] First, during the process of the embedded emulated instruction core executing the embedded executable program, the number of instructions executed by the central processing unit (CPU) is counted in real time.

[0075] When the number of instructions counted reaches the preset synchronization threshold, or when the embedded simulation instruction core executes a specific synchronization condition (such as read / write access operation to on-chip device, interrupt check operation, timer event trigger operation, etc.), the embedded simulation instruction core calls the instruction synchronization advance function (inst_sync_fun).

[0076] The instruction synchronization advance function (inst_sync_fun) calculates the simulation time increment for the System-level Device Simulation Environment (SystemC) based on the currently counted number of instructions, the target CPU frequency parameters, and the instruction cycle parameters. After calculation, the embedded simulation instruction core uses the instruction synchronization advance function (inst_sync_fun) to pass the simulation time increment to the System-level Simulation Environment's event scheduler (SystemC event scheduler) to advance the corresponding simulation time for the System-level Device Simulation Environment (SystemC).

[0077] During the operation of the event scheduler (SystemC event scheduler) in the system-level simulation environment, it is responsible for scheduling on-chip device events, off-chip device events, and physical simulation synchronization coroutines (gzsim_sync_fun) deployed on the system-level simulation side.

[0078] The system obtains the simulation step size of the physical simulation environment. The physical simulation synchronization coroutine (gzsim_sync_fun) is triggered and executed according to this simulation step size cycle in the event scheduler of the system-level device simulation environment (SystemC). When the physical simulation synchronization coroutine is triggered, it calls the engine propeller in the physical device simulation environment, driving the physical engine in the physical device simulation environment to advance a complete simulation step size. Thus, the system constructs a cascading chain of timing synchronization relationships, in which the embedded simulation instruction core runs to drive the system-level simulation, and the system-level simulation further drives the physical simulation.

[0079] Figure 6 This diagram illustrates the data binding and interaction mechanism between the system-level simulation side and the physical simulation side in this embodiment. For example... Figure 6 As shown, the system has constructed a global data interaction interface (map).<string, sc_gz_data> This is used to manage the data binding and synchronization between system-level off-chip devices (SystemC off-chip devices) and physical simulation devices (GZSIM devices).

[0080] Global data interaction interface (map)<string, sc_gz_data> This uses a string containing the device name as the key and a simulation interaction data structure (sc_gz_data) as the actual value. The simulation interaction data structure (sc_gz_data) has the following three members:

[0081] Physical name (phy_name): Used to identify the target device name that needs to be bound between the physical simulation side and the system-level simulation side;

[0082] Physical data write callback (gz_write_func): This is a callback function pointer from the physical simulation side to the system-level simulation side to synchronize data. It points to the physical data write function (gz_write_fun) corresponding to the physical device in the physical device simulation environment (GZSIM), which is used to synchronously write the physical state data generated by the physical engine to the corresponding system-level off-chip device (SystemC off-chip device).

[0083] System-level data write callback (sc_write_func): This is a callback function pointer from the system-level simulation side to the physical simulation side to synchronize data. It points to the system-level data write function (sc_write_fun) corresponding to the device in the system-level device simulation environment (SystemC), which is used to synchronously write the control or configuration data generated by the system-level off-chip device (SystemC off-chip device) to the corresponding physical simulation device (GZSIM device).

[0084] Based on the above interface binding relationship, the implementation process of bidirectional closed-loop data interaction is as follows:

[0085] In the physical device simulation environment (GZSIM), the sensor model generates sensor physical data after completing the physical calculations for the current simulation step. At this point, the system calls the physical data write callback (gz_write_func) registered in the simulation interaction data structure (sc_gz_data) to synchronously write the sensor physical data to the receiving area of ​​the corresponding system-level off-chip device (SystemC off-chip device). After receiving the data, the system-level off-chip device (SystemC off-chip device) converts the data into pin signals using the bound pin binding function (pin_bind_fun) and passes them to the on-chip device of the system-on-chip (SoC). Finally, the embedded simulation instruction core reads the registers of the on-chip device by calling the memory read function (memory_read_fun) to obtain the sensor physical data.

[0086] When executing control outputs, the embedded program running on the embedded simulation instruction core writes control data to the on-chip device registers of the System-on-Chip (SoC) by calling the memory write function (memory_write_fun). Based on the register state changes, the on-chip device drives the corresponding system-level off-chip device (SystemC off-chip device) to run via the pin binding function (pin_bind_fun). The system-level off-chip device (SystemC off-chip device) responds and generates control signals. By calling the system-level data write callback (sc_write_func) registered in the simulation interaction data structure (sc_gz_data), it synchronously writes the control data to the corresponding actuator model in the physical device simulation environment (GZSIM), thereby driving the actuator model to execute the corresponding physical output actions in the next physical simulation iteration.

[0087] In step S110, based on the device binding relationship between the system-level simulation environment and the physical simulation environment, a bidirectional data interaction path is constructed between the physical devices in the physical simulation environment and the off-chip devices in the system-level simulation environment. The system-level simulation environment includes an instruction core, on-chip devices, and off-chip devices.

[0088] In traditional standalone simulation architectures, the system-level simulation environment (SystemC) and the physical simulation environment (GZSIM) are two isolated simulation domains with fundamentally different data structures and addressing methods. This embodiment breaks down these barriers by constructing a cross-domain bidirectional data interaction path.

[0089] Specifically, the System-on-Chip (SoC) simulation environment contains an instruction core, on-chip devices, and off-chip devices. The instruction core, as the core computing unit, is used to load and execute embedded executable programs. On-chip devices are typically peripheral controllers within the System-on-Chip (SoC) (such as general-purpose input / output interfaces, serial peripheral interfaces, etc.), which have specific register addresses for the instruction core to access via memory-mapped read / write operations. Off-chip devices serve as interfaces or functional modules outside the SoC. In the SoC simulation environment, off-chip devices and on-chip devices typically establish level logic communication within the SoC environment based on pin-bonding relationships (e.g., configuring signal direction and connection paths through pin-bonding functions). The Physical Simulation Environment (GZSIM) is mainly used to simulate the dynamic changes of the three-dimensional physical world. Its internal physical devices mainly include sensor models for sensing physical states and actuator models for executing physical responses.

[0090] To establish connectivity between the two simulation domains, this embodiment constructs a cross-domain bidirectional data interaction path based on pre-defined device binding relationships. Device binding relationships refer to the logical one-to-one mapping and association between specific physical devices in the physical simulation environment (GZSIM) and corresponding target off-chip devices in the system-level simulation environment (SystemC) through device names, device identifiers, or a unified string mapping mechanism.

[0091] The bidirectional data interaction path built upon the aforementioned device binding relationship carries closed-loop data transmission in two directions, including:

[0092] The first direction (feedback data uplink): from physical devices to external devices. During the operation of the physical simulation environment (GZSIM), physical devices (such as sensor models) continuously generate physical feedback data (such as position, velocity, collision state, and other physical quantities) based on the calculations of the 3D physics engine. Through a two-way data exchange path, the aforementioned physical feedback data can be synchronized across domains and written to the external devices with which it has established a binding relationship. Furthermore, this data can be transmitted from the external devices to the on-chip devices via pin-level connections, and finally read by the embedded program on the instruction core. This process enables the embedded program to obtain real-time state feedback of the 3D physical environment.

[0093] The second direction (control data downlink): from external device to physical device. The embedded program running on the instruction core generates control instructions after computation. These instructions are written to the registers of the on-chip device and converted into pin signals to drive the corresponding external device. After the external device generates system-level control data (such as target position, control force, switch status, etc.), it synchronizes this control data across domains to the physical device (such as the actuator model) with which it has established a binding relationship through a bidirectional data exchange path. This process drives the actuators in the physical environment to make corresponding mechanical or physical responses in subsequent physical simulation time steps.

[0094] In summary, the bidirectional data interaction path constructed through this embodiment establishes a complete data transmission chain connecting the instruction core, on-chip devices, off-chip devices, and physical devices without requiring intrusive modifications to the internal processing logic of the embedded simulation instruction core. This not only avoids data communication barriers between heterogeneous simulation environments but also provides embedded control software with a closed-loop verification path that includes real physical responses, thereby improving the technical effectiveness and verification confidence of the co-simulation system in the early testing phase.

[0095] In step S120, in the system-level simulation environment, the embedded program is executed through the instruction core to generate the simulation time advance amount and drive the event scheduler of the system-level simulation environment to advance the operation according to the simulation time advance amount.

[0096] In real-world embedded systems, the execution of machine instructions by the microprocessor and the state transitions of on-chip peripherals occur synchronously with the natural passage of real physical time. However, in a system-level simulation environment (SystemC) based on software simulation, the passage of time does not depend on a real physical clock, but is explicitly managed by an internal virtual clock. To ensure that the virtual clock in the system-level simulation environment accurately reflects the progress of the instruction core, a unidirectional timing-driven relationship needs to be established between the instruction execution side and the system scheduling side.

[0097] First, in the system-level simulation environment (SystemC), the instruction core acts as a virtual central processing unit, responsible for loading, parsing, and executing the embedded program line by line. Each execution of a target processor instruction or batch of instructions by the instruction core is equivalent to a certain number of clock cycles consumed by a real physical microprocessor.

[0098] During the continuous execution of the embedded program, the system monitors and tracks the execution progress of the instruction core. When preset synchronization trigger conditions are met (for example, the cumulative number of instructions executed continuously by the instruction core reaches a set synchronization threshold, or the embedded program triggers timing-sensitive hardware interaction events such as read / write access to on-chip device registers or interrupt checks), the system generates a simulation time advance based on the computational workload currently executed by the instruction core. This simulation time advance physically represents the virtual physical time span corresponding to the current batch of instructions executed by the instruction core since the last timing synchronization.

[0099] Subsequently, the system-level simulation environment uses the generated simulation time advance to drive the event scheduler of the system-level simulation environment. As the core scheduling engine of the system-level simulation environment, the event scheduler is responsible for maintaining the global simulation timeline and all hardware events attached to that timeline.

[0100] When the event scheduler receives the simulation time advance, it will perform the following advance operations: step forward the current global virtual simulation time of the system-level simulation environment, and the specific increase is the simulation time advance; at the same time, during this window period when the time axis slides forward, the event scheduler will automatically trigger and evaluate all registered system-level events (including timer overflow of on-chip devices, state toggling of pin levels, completion of bus transmission, etc.).

[0101] The co-simulation method in this embodiment enables on-chip and off-chip devices within the system-level simulation environment (SystemC) to evolve their states strictly according to the processing rhythm of the embedded simulation instruction core. This achieves precise alignment of the hardware and software operation process on the virtual time axis within a single simulation domain and provides a coherent and reliable system-level time reference for further driving the external physical simulation environment (GZSIM).

[0102] In step S130, the pre-configured simulation step size of the physical simulation environment is obtained, a synchronous coroutine is created in the system-level simulation environment, and the synchronous coroutine is attached to the event scheduler. The synchronous coroutine is used to call the single-step advancement interface to drive the physical simulation environment to run one simulation step size when the event scheduler advances to the trigger time corresponding to the simulation step size.

[0103] As the system-level simulation environment (SystemC) is driven and advanced, its internal event scheduler is responsible not only for scheduling hardware events of on-chip and off-chip devices, but also for synchronously maintaining the system-level global virtual simulation time. Because the computational overhead of the physical simulation environment (GZSIM) in solving three-dimensional physical space states (such as collisions, forces, motion trajectories, etc.) is large, the system usually does not perform cross-domain synchronization at the microscopic system clock cycle level, but is configured with a macroscopic simulation step size.

[0104] To establish an objective mapping between the microscopic clock of the underlying instruction execution and the macroscopic clock of the evolution of the three-dimensional physical world, the simulation step size configured by the physical simulation environment (e.g., the three-dimensional physics engine GZSIM) is first obtained. This simulation step size is usually determined by the integration accuracy required by the physics engine for dynamic solution.

[0105] After obtaining the aforementioned simulation step size, during the initialization or scheduling configuration phase of the system-level simulation environment (e.g., a SystemC-based simulation platform), a synchronous coroutine specifically for cross-domain timeline alignment is instantiated. At the computer operating system level, this synchronous coroutine, as a lightweight user-mode thread, is orchestrated into the event scheduler of the system-level simulation environment.

[0106] During the continuous operation of the system-level simulation environment, the event scheduler accumulates the elapsed virtual time. When the event scheduler determines that the currently accumulated system-level virtual time has reached a cycle node of the aforementioned simulation step size, it wakes up and triggers the synchronization coroutine.

[0107] Once the synchronous coroutine is triggered, it sends a stepping command to the physical simulation environment by calling the Single-step Advance Interface exposed by the physical simulation environment. In response to this interface call, the physical simulation environment performs a time span calculation for one of the aforementioned simulation step sizes within its internal three-dimensional physical space.

[0108] The co-simulation method in this embodiment decouples the execution flow of the instruction core execution logic from the physics and dynamics solution logic at the software architecture level. This eliminates the need for the system-level simulation environment to forcibly poll the physics simulation environment at every micro-processor clock cycle; instead, timing alignment is performed based on the step size of the physics simulation engine. This process avoids the timing fragmentation problem caused by the independent operation of two heterogeneous simulation systems.

[0109] The co-simulation method in this embodiment effectively avoids the risk of timing out-of-sync during joint operation of heterogeneous simulation engines by utilizing a time difference compensation mechanism without disrupting the original scheduling main process of the system-level simulation environment.

[0110] In step S140, as the physical simulation environment is running, the physical simulation data generated by the physical device in the physical simulation environment is synchronized to the external device through a two-way data interaction channel, so that the instruction core can read the physical simulation data through the internal device and synchronize the control data written by the instruction core to the internal device to the physical device through the external device and the two-way data interaction channel, so that the physical device can perform state updates according to the control data in the physical simulation environment.

[0111] Once the physical simulation environment (GZSIM) is triggered and runs according to the simulation time increment, its internal three-dimensional physical space state will evolve accordingly. During this dynamic evolution, the system performs cross-domain data synchronization strictly according to the uplink and downlink physical directions based on a two-way data interaction path. The specific transmission process is as follows:

[0112] First, in the uplink feedback direction (physical state perception link): As the physical simulation environment (GZSIM) progresses, the physical devices configured within it (specifically manifested as various sensor models, such as position, velocity, collision, or vision sensors) calculate the current state of the virtual physical world, thereby generating physical simulation data characterizing physical attributes. At this point, the system extracts this physical simulation data through the feedback link of the bidirectional data interaction path and maps and synchronously writes it across domains to the corresponding external devices with established binding relationships within the system-level simulation environment (SystemC). When the external device receives this data, its internal state changes, and under the control of the event scheduler of the system-level simulation environment, it converts the data into underlying electrical signal logic and transmits it to the corresponding on-chip device (i.e., the register of the on-chip system peripheral controller). Finally, the instruction core executing the embedded program successfully obtains the physical simulation data by reading the on-chip device registers. Thus, the software program running on the chip core receives perceptual input from the realistic simulation of the 3D physics engine.

[0113] Second, in the downlink control direction (control decision transmission link): after reading the feedback data from the physical side, the embedded control algorithm loaded by the instruction core performs calculations and decisions based on the feedback, generating corresponding control data (such as target speed, control torque, switching actions, etc.). Subsequently, the instruction core writes this control data into a specific on-chip device register. The flipping of the register state drives the corresponding off-chip device connected to it to operate. Immediately afterwards, the system captures the control logic output by the off-chip device through the control link side of the bidirectional data interaction path, and synchronously transmits it across domains to the corresponding physical device bound to it in the Physical Simulation Environment (GZSIM) (specifically manifested as an actuator model, such as a motor drive, robotic arm joint, etc.). When the Physical Simulation Environment (GZSIM) is run again in a subsequent time cycle, the physical device that receives the control data will follow the instructions of the control data and execute the corresponding mechanical response or kinematic state update in the virtual three-dimensional space.

[0114] This embodiment integrates discrete chip instruction-level execution, system-level hardware logic evolution, and macroscopic 3D physics engine computation into a unified data flow closed loop. Without altering the underlying architecture of each simulation engine, it enables embedded software on the chip side to perform closed-loop control and interaction with virtual controlled objects possessing real physical properties, thus laying the foundation for the effectiveness of co-simulation system engineering applications.

[0115] In some embodiments of this application, based on the device binding relationship between the system-level simulation environment and the physical simulation environment, constructing a bidirectional data interaction path between physical devices in the physical simulation environment and off-chip devices in the system-level simulation environment includes:

[0116] Construct a mapping interface with device name as key and simulation interaction data structure as real value;

[0117] Based on the configuration file, create physical devices in the physical simulation environment;

[0118] Create the corresponding off-chip device in the system-level simulation environment;

[0119] The first data write interface of the physical device and the second data write interface of the external device are registered as callback function pointers in the simulation interaction data structure. The first data write interface and the second data write interface are associated by the device name to form a bidirectional data interaction path.

[0120] At the underlying code and memory management level, data penetration between heterogeneous simulation environments is difficult to achieve through direct variable sharing. Therefore, this embodiment employs a global mapping mechanism based on callback function pointers to establish a cross-domain data interaction path. Specifically:

[0121] In a unified co-simulation management layer, a mapping interface is constructed, using device names as keys and simulation interaction data structures as values. Specifically, this mapping interface is represented as a globally managed key-value pair mapping table (Map). In this mapping table, the key is the device name in string form with a unique identifier (e.g., the sensor's identifier); while the corresponding value is a specially defined simulation interaction data structure (sc_gz_data). This structure serves as a dedicated memory container for storing cross-domain communication callback addresses.

[0122] Subsequently, during the initialization phase of the co-simulation, the system instantiates devices within the environment. Based on the configuration file, the system creates physical devices in the physical simulation environment. The configuration file records the physical structure topology and attributes of the objects to be simulated. After parsing this file, the physical simulation environment (GZSIM) instantiates the corresponding physical devices (such as sensor models, actuator models, etc.) in the three-dimensional virtual space and assigns them corresponding device names. Simultaneously, the system creates corresponding off-chip devices in the system-level simulation environment (SystemC). These off-chip devices are also instantiated according to a preset architecture and inherit device names that are consistent with or logically mapped from the physical devices, thus establishing simulation entity pairs with the same name binding relationship within two independent simulation domains.

[0123] After the physical devices are created and allocated their respective independent memory spaces, the system performs the final assembly of the cross-domain path, registering the first data write interface of the physical device and the second data write interface of the external device as callback function pointers into the simulation interaction data structure. Specifically, in the physical-side data feedback direction, the system extracts the memory address of the function used to write physical feedback data from the physical device as the first data write interface (i.e., the physical data write callback function, gz_write_func); in the system-side control sending direction, the system extracts the memory address of the function used to write system-level control commands from the external device as the second data write interface (i.e., the system-level data write callback function, sc_write_func). The system converts the memory addresses of the above two interfaces into callback function pointers and uniformly writes and registers them into the previously allocated simulation interaction data structure (sc_gz_data).

[0124] After registration, the system associates the first and second data write interfaces using the device name to form a bidirectional data interaction path. Based on the unique device name as the retrieval key, the system-level simulation environment can directly find the corresponding simulation interaction data structure through this mapping interface when data transmission is triggered, and then directly call the first data write interface on the physical side through a pointer; similarly, the physical simulation environment can also call the second data write interface on the system side across domains through a pointer.

[0125] Based on the key-value mapping and pointer registration construction mechanism, without requiring significant modifications to the underlying code structure of the heterogeneous simulation environments at both ends, the efficient callback attribute of the underlying memory address reliably binds the independent off-chip device logic and physical device logic at the memory level, thereby opening up a low-latency bidirectional data interaction path that meets the requirements of joint simulation.

[0126] In some embodiments of this application, executing an embedded program through an instruction core to generate simulation time advance quantities and driving the event scheduler of the system-level simulation environment to advance its operation based on the simulation time advance quantities includes:

[0127] The instruction core performs statistics during the execution of the embedded program to obtain the number of instructions executed;

[0128] The instruction synchronization function is invoked to obtain the target propagation duration based on the number of instructions and the preset main frequency parameters;

[0129] The target advancement time is used as the simulation time advancement amount;

[0130] Configure the target execution duration to the event scheduler to drive the event scheduler to execute the corresponding duration.

[0131] In the system-level simulation environment (SystemC), the passage of time must be consistent with the actual physical operating laws of the microprocessor. The quantization and driving of this time are as follows:

[0132] First, during the loading and execution of the embedded program, the instruction core continuously monitors and tracks its underlying processing progress. Through this internal tracking, the system can obtain the number of instructions executed by the instruction core within the current execution window in real time. This number of instructions represents the actual computational workload expended by the instruction core in completing specific control logic within the virtual environment.

[0133] Subsequently, to transform the aforementioned abstract computational workload into a time span recognizable by the macroscopic simulation system, the system invokes a specially configured instruction synchronization advance function (inst_sync_fun). This function encapsulates the computational logic for cross-domain time conversion. Specifically, the instruction synchronization advance function obtains the number of instructions obtained from the aforementioned statistics and performs calculations in conjunction with the clock frequency parameters pre-configured for the instruction core. In the underlying computer architecture, the clock frequency parameter represents the processing cycle frequency or running speed of the instruction core per unit time. Therefore, by comprehensively considering the total workload actually executed by the instruction core (i.e., the number of instructions) and its inherent processing speed (i.e., the clock frequency parameter), the instruction synchronization advance function can logically deduce and calculate the absolute physical time span that the instruction core must consume to execute this batch of specific instructions, thus obtaining the target advance duration.

[0134] After completing the above quantitative calculations, the system performs a conceptual-level parameter transformation, using the obtained target advancement time as the simulation time advancement amount. This establishes an equivalent mapping relationship between the workload of the instruction core and the time increment of the entire system-level simulation environment.

[0135] Finally, the system configures the target execution duration to the event scheduler within the system-level simulation environment. As the engine for maintaining global virtual time, the event scheduler, upon receiving this configuration parameter, uses this target execution duration as the time step benchmark and slides forward the corresponding increments on the system-level global virtual timeline. This drives the event scheduler to advance the execution duration according to the actual time scale consumed by the microprocessor.

[0136] The co-simulation method in this embodiment, without introducing an external complex clock generator, only relies on the amount of software code execution and the basic hardware attributes of the processor to clarify the causal relationship between the embedded program execution and the system-level virtual clock advancement at the underlying architecture, thus ensuring the accuracy of timing-driven operation.

[0137] In some embodiments of this application, obtaining the simulation step size of the physical simulation environment and creating a synchronous coroutine in the system-level simulation environment, wherein the synchronous coroutine is used to call the single-step advancement interface according to the simulation step size cycle to drive the physical simulation environment to run one simulation step size includes:

[0138] Obtain the simulation step size of the physical simulation environment;

[0139] The created synchronous coroutine is attached to the event scheduler of the system-level simulation environment;

[0140] When the event scheduler of the system-level simulation environment advances and reaches the trigger time of the synchronous coroutine, the synchronous coroutine is woken up to perform a suspension operation. The suspension operation is used to interrupt the normal hardware event evolution inside the system-level simulation environment to freeze the current register state and pin level logic of the on-chip device and the off-chip device.

[0141] When the system-level simulation environment is in a suspended state, the synchronous coroutine calls the pre-encapsulated single-step advancement interface to start the cross-domain driving process. The single-step advancement interface internally calls the engine thruster of the physical simulation environment to drive the physical simulation environment to run a complete simulation step.

[0142] During co-simulation, to prevent clock drift or data synchronization issues between the faster system-level simulation environment (SystemC) and the computationally expensive 3D physical simulation environment (GZSIM), the following measures are taken:

[0143] As the Event Scheduler advances the virtual clock according to the execution of the embedded program, the system continuously monitors the current progress. The system obtains its inherent simulation step size from the configuration information of the physical simulation environment or the parameters of the physics engine. This simulation step size is the physical time span corresponding to a single forward calculation by the physics engine.

[0144] Subsequently, a synchronous coroutine is created within the system-level simulation environment. This coroutine is attached to the event scheduler of the system-level simulation environment and is triggered for execution according to the simulation step size cycle obtained above. During the continuous operation of the system-level simulation environment, the instruction core executes the embedded program and continuously accumulates simulation time. When the event scheduler of the system-level simulation environment advances and reaches the trigger time of the synchronous coroutine, the synchronous coroutine is awakened and immediately takes over control. The first action of the synchronous coroutine after being awakened is to send a suspend instruction to the kernel of the system-level simulation environment. This suspend operation interrupts the normal hardware event evolution within the system-level simulation environment and freezes the current register states and pin level logic of the on-chip and off-chip devices. This provides a static and stable system-level time slice for subsequent cross-domain data interaction and clock alignment, avoiding the data race risk that is easily generated when heterogeneous engines are asynchronously concurrent. If the register and pin states are not frozen, the system-level simulation environment will continue to execute instructions during the time-consuming cross-process solution deduction of the physical simulation, causing time to advance and thus destroying the consistency and causal relationship of the software and hardware states.

[0145] After the system-level simulation environment is in a safe suspension state, the system initiates the cross-domain driving process. When the event scheduler of the system-level simulation environment advances and reaches the trigger time of the synchronous coroutine, the awakened synchronous coroutine calls the pre-encapsulated Single-step Advance Interface. This Single-step Advance Interface internally calls the engine advancer of the physical simulation environment, driving the physical simulation environment to run a complete simulation step. After the physics engine completes the rigid body state and collision matrix calculation for this fixed step, the system-level simulation environment releases the aforementioned suspension state, resumes the normal event evolution of the instruction core and peripherals, and thus enters the synchronization cycle of the next simulation step.

[0146] Through the co-simulation method in this embodiment, the physical simulation environment is actively and deterministically driven by the system-level simulation environment according to the inherent simulation step size cycle of the physical engine. This ensures that the physical simulation environment can obtain a precise clock step size every time it starts a simulation, providing accurate timing for the joint closed-loop test of embedded system software and hardware.

[0147] In some embodiments of this application, data interaction between the physical device and the off-chip device is implemented based on the execution of a callback function pointer. Wherein:

[0148] Synchronizing physical simulation data generated by physical devices during operation in a physical simulation environment with external devices includes:

[0149] Call the first callback function pointer registered in the simulation interaction data structure to write the physical simulation data generated by the physical device to the receiving buffer of the external device;

[0150] The control data written to the on-chip device by the instruction core is synchronized to the physical device through external devices and a two-way data exchange path, including:

[0151] The second callback function pointer registered in the simulation interaction data structure is invoked to write the control data received by the external device into the control input interface of the physical device.

[0152] In this embodiment, within the underlying computer memory scheduling architecture, data interaction between physical devices and off-chip devices is achieved through the execution of callback function pointers. Since the system-level emulation environment (SystemC) and the physical emulation environment (GZSIM) typically run in independent memory address spaces, direct variable access can lead to out-of-bounds access or data conflicts. By executing pre-registered callback function pointers, the system can cross-domain call the secure data interfaces exposed by the other without compromising their respective memory isolation. The specific bidirectional synchronous execution process is as follows:

[0153] On the one hand, in the link of physical state feedback to the chip (i.e., uplink data synchronization): as the physical simulation environment progresses, its internal physical devices (such as sensor models) complete the physical state calculation of the current three-dimensional space and generate physical simulation data that characterizes the latest physical properties.

[0154] Synchronizing physical simulation data generated by physical devices during operation in a physical simulation environment with external devices includes:

[0155] The system addresses the current physical device's name within the global simulation interaction data structure and invokes the first callback function pointer registered in that structure. This first callback function pointer points to a specific memory operation function exposed by the system-level simulation environment. With this pointer's invocation and execution, the system triggers a cross-domain data transmission mechanism, writing the physical simulation data generated by the physical device into the external device's receive buffer. The receive buffer is a pre-defined register-mapped area within the system-level simulation environment's memory specifically for receiving external physical signals. Through this low-level write operation, the real physical feedback signal successfully crosses the simulation engine's boundary and is transformed into a low-level level or register logic state that can be directly read by the system-level hardware device.

[0156] On the other hand, in the link where chip control instructions are sent to the physical environment (i.e., downlink data synchronization): after the instruction core runs the embedded control program based on the feedback data it reads and writes the calculated control data into the on-chip device, the control data will be transmitted to the off-chip device according to the hardware logic. At this time, it is necessary to feed the digital control instructions back to the physical world.

[0157] The control data written to the on-chip device by the instruction core is synchronized to the physical device through external devices and a two-way data exchange path, including:

[0158] The system also uses the device name as an index to call the second callback function pointer registered in the simulation interaction data structure. This second callback function pointer points to the starting address of a specific function on the physical simulation environment side used to receive external drive commands. By triggering the execution of this second callback function pointer, the system performs cross-domain delivery of the load data carrying the control commands, writing the control data received from the external device into the physical device's control input interface. The control input interface is a standardized data receiving point in the 3D physics engine used by physical devices (such as actuator models) to receive external stimuli such as driving torque, target rotation angle, or switching quantities. When control data is written to this interface, the state machine or dynamic equations inside the physical device are refreshed, ensuring that the physics engine can calculate and present corresponding physical changes based on the control data as the next physical simulation time step progresses.

[0159] This embodiment, based on the specific calling and writing mechanism of the first and second callback function pointers, establishes an efficient memory-level data flow path at the underlying hardware and software level, connecting the physical engine (data generation) to the system-on-a-chip (data receiving buffer), and then from the system-on-a-chip (control distribution) back to the physical engine (control input interface). This avoids complex network communication overhead, resulting in low latency and high reliability of data interaction in the co-simulation closed-loop test.

[0160] In some embodiments of this application, on-chip devices in the system-level simulation environment transmit signals to off-chip devices via pin-binding functions; the data feedback path from the physical device to the instruction core includes:

[0161] The physical equipment writes the physical simulation data generated during operation into the two-way data interaction channel;

[0162] A two-way data exchange path outputs physical simulation data to external devices;

[0163] External devices convert physical simulation data into pin signals and transmit them to internal devices by calling pin bonding functions;

[0164] The on-chip device updates the corresponding register state according to the pin signal, so that the instruction core can read the physical simulation data from the register by executing the memory read instruction.

[0165] In the underlying architecture of the SystemC simulation environment, to highly replicate the hardware topology of a real chip, on-chip devices in the systemC simulation environment transmit signals to off-chip devices through pin binding functions. The pin binding function simulates the physical traces on a real printed circuit board (PCB), establishing clock-driven hardware-level port connections within the systemC simulation engine.

[0166] Based on the aforementioned hardware connectivity architecture, the system constructs an uplink data synchronization chain. Specifically, the data feedback path from the physical device to the command core includes the following data flow steps:

[0167] First, on the physical simulation environment (GZSIM) side, when the state of the controlled object in three-dimensional space changes, the physical device writes the physical simulation data generated during operation into the two-way data interaction path. Physical simulation data is typically represented as high-level abstract data with specific physical dimensions (such as the angular velocity and distance values ​​of sensors).

[0168] Subsequently, the data enters the cross-domain transmission stage. The bidirectional data interaction path outputs the physical simulation data to the external device. Relying on the callback function pointer mechanism, the physical simulation data is directed to the external device's receive buffer in the system-level simulation environment, completing cross-environment data penetration.

[0169] Once the external device receives the abstract physical simulation data, it performs crucial hardware signal reduction and transformation operations. The external device converts the physical simulation data into pin signals by calling pin binding functions and transmits them to the internal device. Based on a preset communication protocol (such as SPI, I2C, or GPIO), the external device encodes the high-level floating-point or integer physical data into low-level serial bit streams or parallel high and low level logic signals, and transmits them to the chip's internal circuitry via virtual pins.

[0170] Next, on the data receiving side inside the chip, the on-chip device updates the corresponding register state based on the pin signal. Upon receiving the underlying pin signal, the on-chip device (such as a virtual analog-to-digital converter (ADC) or bus controller) triggers its internal hardware state machine, decoding the received signal and refreshing it to its corresponding memory-mapped register address space. This ensures that changes in the external physical world are reflected as changes in the state of binary bits at specific memory addresses within the chip.

[0171] Ultimately, this closed-loop data reaches the computation core, allowing the instruction core to read physical simulation data from the registers by executing memory read instructions. Since the register state has been refreshed by the underlying pin signals, the embedded program running on the instruction core does not need to be aware of the existence of the external co-simulation environment. It only needs to perform regular memory read operations (such as reading a specific memory address area through a pointer in C language) according to the driver logic written for real hardware to natively obtain the latest physical feedback status.

[0172] The data feedback path in this embodiment avoids the heterogeneity differences of the underlying simulation environment, enabling the embedded control software to achieve closed-loop perception and control of the complex three-dimensional physical environment by manipulating registers, just like on real physical hardware.

[0173] In some embodiments of this application, on-chip devices in the system-level simulation environment transmit signals to off-chip devices via pin-binding functions; the control delivery path from the instruction core to the physical device includes:

[0174] The instruction core modifies the state of the on-chip registers by executing memory write instructions and writing control signals into the on-chip registers.

[0175] The on-chip device drives the off-chip device to run through the pin binding function based on the modified state of the on-chip registers;

[0176] External devices respond to drive operation by generating control data and writing the control data into the bidirectional data interaction path;

[0177] The two-way data exchange path synchronizes control data to the physical device so that the physical device can update its physical state the next time it is pushed to run.

[0178] In the SystemC simulation environment, based on the connection relationships of the underlying hardware topology, on-chip devices in the systemC simulation environment also transmit signals to off-chip devices through pin binding functions. This mechanism ensures the hardware-level realism of bidirectional communication between the chip and the external environment.

[0179] Based on this architecture, when the embedded control program running on the instruction core calculates the control logic that needs to be output externally, the control transmission path from the instruction core to the physical device includes:

[0180] At the core execution level, the instruction core executes memory write instructions to write control signals to on-chip registers, thereby modifying the state of the on-chip registers. During this process, the embedded program does not need to call any special interfaces for external physical simulation environments; instead, it operates as if it were running on a real silicon chip, directly changing the binary bit values ​​of the memory-mapped registers corresponding to specific on-chip devices (such as PWM controllers and GPIO ports) through standard addressing and write operations.

[0181] At the internal hardware response level, on-chip devices drive external devices through pin-binding functions based on the modified state of on-chip registers. Once the logic value in the register toggles, the internal hardware state machine of the on-chip device is triggered, converting the digital control signals stored in the register into corresponding low-level pin level changes (such as high / low level toggles or serial bus timing). The pin-binding function then captures this level change and transmits these low-level hardware stimulus signals to the external device on the virtual printed circuit board.

[0182] At the external peripheral protocol conversion level, the external device responds to the driver operation by generating control data and writes the control data into the bidirectional data interaction path. After receiving the underlying pin level signal, the external device (such as a virtual motor driver model) decodes and restores the signal according to the corresponding hardware protocol, converting it from the underlying pulse or bit stream form into a higher-level abstract control quantity (e.g., converting the PWM duty cycle into a specific desired output voltage or target torque value), thereby generating control data. After generation, the external device submits the control data to the cross-domain bidirectional data interaction path (i.e., writes it to the underlying shared memory area through a callback function pointer mechanism).

[0183] At the level of cross-domain delivery and timing activation, the two-way data interaction channel will synchronize control data to the physical device so that the physical device can update its physical state the next time it is pushed to run.

[0184] When control data is delivered to the control input interface of a physical device (such as an actuator model) on the physical simulation environment (GZSIM) side, the control command will not immediately trigger a sudden change in physical form because the physical simulation within the current system time slice may be suspended or waiting for the system-level simulation environment to catch up. The physical device will temporarily store the received control data in its internal state input queue. Only when the physical simulation environment is given a new time increment and is driven by the event scheduler in the aforementioned embodiment, and then runs again, will the physical device extract the control data, substitute it into its own rigid body dynamics equations or kinematic model for solving, thereby realistically updating its own physical state (such as driving a virtual robotic arm to rotate a specific angle).

[0185] Through the control delivery path in this embodiment, the delivery of software instructions and the derivation steps of discrete physics simulation are strictly decoupled and aligned in the time flow, thereby providing a simulation base with engineering confidence for the control accuracy and response timing verification of embedded software.

[0186] In one specific embodiment, during the initialization phase of this closed-loop control simulation embodiment, the instruction core in the embedded simulation environment loads the target embedded executable program. The system-level simulation environment (SystemC) creates on-chip devices, off-chip sensor interface devices, and off-chip actuator interface devices based on a preset hardware topology. Simultaneously, the physical simulation environment (GZSIM) creates sensor models, actuator models, and a low-level physics engine corresponding to the aforementioned off-chip sensor interface devices and off-chip actuator interface devices.

[0187] During closed-loop simulation, when the target embedded executable program performs calculations and needs to write control data to the on-chip device control register, the control transmission link is triggered. Specifically, the embedded simulation instruction core calls the memory write function (memory_write_fun) to write the control quantity to the on-chip device in the system-level simulation environment. Subsequently, the on-chip device drives the off-chip actuator interface device in the system-level simulation environment to run in the form of hardware level signals through the underlying preset pin binding function (pin_bind_fun). After receiving the signal, the off-chip actuator interface device calls the downlink interaction function (i.e., the second callback function pointer, sc_write_func) to write the control quantity across domains into the actuator model on the physical simulation environment side through a bidirectional data interaction path.

[0188] During this system-level simulation, the system, based on a time synchronization mechanism, uses a synchronous scheduling coroutine function (gzsim_sync_fun) to call the engine actuator of the physical simulation environment according to the simulation step size cycle, driving the physical simulation environment to advance a complete simulation step on the virtual time axis. During the simulation, the actuator model on the physical side generates corresponding physical actions in three-dimensional space based on the received control quantities. Simultaneously, the sensor model on the physical side generates corresponding sensor data based on the latest physical state calculated by the current physics engine. Subsequently, the feedback link is triggered. The sensor data is written across domains to the receive buffer of the external sensor interface device in the system-level simulation environment via the uplink interaction function (i.e., the first callback function pointer, gz_write_func). This external sensor interface device then converts the data into low-level signals and transmits them to the on-chip devices of the system-on-a-chip (SoC) through the aforementioned pin binding function (pin_bind_fun), thereby updating the corresponding hardware register states. Finally, when the embedded program reads the sensor-related registers according to its software logic, the instruction core calls the memory read function (memory_read_fun) to directly read the updated sensor data from the on-chip device's registers.

[0189] Through data flow and timing scheduling steps, the system fully realizes high-fidelity closed-loop co-simulation with the participation of three-dimensional physical devices (GZSIM) based on the co-simulation of the existing embedded simulation instruction core and system-level simulation environment (SystemC).

[0190] This embodiment provides a timing synchronization system and a two-way data interaction method (i.e., a co-simulation method) that extends the co-simulation system of an existing embedded simulation instruction core and system-level simulation environment (SystemC) to integrate a physical simulation engine (GZSIM) for co-simulation. This method has the following technical effects:

[0191] At the underlying architecture level, the embedded simulation instruction core, consisting of the original instruction synchronization function (inst_sync_fun), memory read function (memory_read_fun), memory write function (memory_write_fun), and pin binding function (pin_bind_fun), is retained to enable joint operation with system-level simulation, ensuring compatibility with existing hardware verification systems.

[0192] By adding a new synchronous scheduling coroutine function (gzsim_sync_fun), a chain-like causal relationship was established, in which the physical simulation environment's operation is actively driven by the system-level simulation progress, thus resolving the clock alignment problem between heterogeneous simulation systems. Simultaneously, newly constructed simulation interaction data structures (such as a map based on string mapping) were used...<string, sc_gz_data> The system implements a tight data binding and bidirectional synchronization between the system-level off-chip device and the physical simulation device at the underlying memory level, along with the physical device name index (phy_name) and the corresponding uplink and downlink callback interaction functions (gz_write_func and sc_write_func).

[0193] In summary, this method enables the co-simulation system to expand the verification capabilities of the original pure digital circuit co-simulation system by including a three-dimensional physical space scene, realistic sensor physical feedback, and actuator physical dynamic response, while maintaining a low system coupling. It provides embedded control software with a virtual verification platform featuring realistic physical interaction, thereby improving the engineering verification efficiency, problem reproducibility, and framework scalability of the embedded R&D testing phase.

[0194] Secondly, embodiments of this application provide a simulation system, including:

[0195] The first construction module is used to build a bidirectional data interaction path between physical devices in the physical simulation environment and off-chip devices in the system-level simulation environment, based on the device binding relationship between the system-level simulation environment and the physical simulation environment. The system-level simulation environment includes instruction cores, on-chip devices and off-chip devices.

[0196] The first generation module is used to execute embedded programs through the instruction core in the system-level simulation environment, generate simulation time advance, and drive the event scheduler of the system-level simulation environment to advance the operation according to the simulation time advance.

[0197] The first acquisition module is used to acquire the simulation step size of the physical simulation environment and create a synchronous coroutine in the system-level simulation environment. The synchronous coroutine is used to call the single-step advancement interface according to the simulation step size cycle to drive the physical simulation environment to run one simulation step size.

[0198] The first synchronization module is used to synchronize the physical simulation data generated by the physical device in the physical simulation environment to the external device through a two-way data interaction channel when the physical simulation environment is running. This allows the instruction core to read the physical simulation data through the on-chip device and synchronize the control data written by the instruction core to the on-chip device to the physical device through the external device and the two-way data interaction channel, so that the physical device can update its status in the physical simulation environment according to the control data.

[0199] The functions of each module in each device in the embodiments of this application can be found in the corresponding descriptions in the above methods, and will not be repeated here.

[0200] Figure 2 A structural block diagram of an electronic device according to an embodiment of this application is shown. Figure 2 As shown, the electronic device includes a memory 410 and a processor 420, wherein the memory 410 stores instructions executable on the processor 420. When the processor 420 executes these instructions, it implements the co-simulation method described in the above embodiments. The number of memories 410 and processors 420 can be one or more. This electronic device is intended to represent various forms of digital computers, such as laptops, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present application described and / or claimed herein.

[0201] The electronic device may also include a communication interface 430 for communicating with external devices and exchanging data. The devices are interconnected using different buses and can be mounted on a common motherboard or otherwise as needed. The processor 420 can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). The bus can be divided into address buses, data buses, control buses, etc. For ease of illustration, Figure 2 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0202] Optionally, in a specific implementation, if the memory 410, processor 420 and communication interface 430 are integrated on a single chip, the memory 410, processor 420 and communication interface 430 can communicate with each other through an internal interface.

[0203] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0204] This application provides a computer-readable storage medium (such as the memory 410 described above) that stores computer instructions, which, when executed by a processor, implement the method provided in this application.

[0205] Optionally, memory 410 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device, etc. Furthermore, memory 410 may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory 410 may optionally include memory remotely located relative to processor 420, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0206] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0207] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0208] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more (two or more) executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0209] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0210] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0211] Furthermore, the functional devices in the various embodiments of this application can be integrated into a processing module, or each device can exist physically separately, or two or more devices can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0212] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A co-simulation method, characterized in that, include: Based on the device binding relationship between the system-level simulation environment and the physical simulation environment, a bidirectional data interaction path is constructed between physical devices in the physical simulation environment and off-chip devices in the system-level simulation environment. The system-level simulation environment includes an instruction core, on-chip devices, and off-chip devices. In the system-level simulation environment, the embedded program is executed through the instruction core to generate simulation time advance and drive the event scheduler of the system-level simulation environment to advance according to the simulation time advance. Obtain the simulation step size of the physical simulation environment, create a synchronous coroutine in the system-level simulation environment, and use the synchronous coroutine to call the single-step advancement interface according to the simulation step size period to drive the physical simulation environment to run one simulation step size. When the physical simulation environment is in operation, the physical simulation data generated by the physical device in the physical simulation environment is synchronized to the off-chip device through the bidirectional data interaction channel, so that the instruction core can read the physical simulation data through the on-chip device and synchronize the control data written by the instruction core to the on-chip device to the physical device through the off-chip device and the bidirectional data interaction channel, so that the physical device can perform status updates in the physical simulation environment according to the control data.

2. The method according to claim 1, characterized in that, The construction of a bidirectional data interaction path between physical devices in the physical simulation environment and off-chip devices in the system-level simulation environment, based on the device binding relationship between the system-level simulation environment and the physical simulation environment, includes: Construct a mapping interface with device name as key and simulation interaction data structure as real value; According to the configuration file, create the physical device in the physical simulation environment; Create the corresponding off-chip device in the system-level simulation environment; The first data write interface of the physical device and the second data write interface of the off-chip device are registered as callback function pointers to the simulation interaction data structure. The first data write interface and the second data write interface are associated by the device name to form the bidirectional data interaction path.

3. The method according to claim 2, characterized in that, The step of executing the embedded program through the instruction core, generating simulation time advance measures, and driving the event scheduler of the system-level simulation environment to advance its operation according to the simulation time advance measures includes: The instruction core performs statistics during the execution of the embedded program to obtain the number of instructions executed; The instruction synchronization function is invoked to obtain the target propagation duration based on the number of instructions and the preset main frequency parameters; The target advancement time is used as the simulation time advancement amount; The target execution duration is configured to the event scheduler to drive the event scheduler to execute the corresponding duration.

4. The method according to claim 3, characterized in that, The step of obtaining the simulation step size of the physical simulation environment and creating a synchronous coroutine in the system-level simulation environment, wherein the synchronous coroutine is used to call the single-step advancement interface according to the simulation step size period to drive the physical simulation environment to run one simulation step size, includes: Obtain the simulation step size of the physical simulation environment; The created synchronous coroutine is attached to the event scheduler of the system-level simulation environment; When the event scheduler of the system-level simulation environment advances and reaches the trigger time of the synchronous coroutine, the synchronous coroutine is woken up to perform a suspension operation. The suspension operation is used to interrupt the normal hardware event evolution inside the system-level simulation environment to freeze the current register state and pin level logic of the on-chip device and the off-chip device. When the system-level simulation environment is in a suspended state, the synchronous coroutine calls the pre-encapsulated single-step advancement interface to start the cross-domain driving process. The single-step advancement interface internally calls the engine thruster of the physical simulation environment to drive the physical simulation environment to run a complete simulation step.

5. The method according to claim 4, characterized in that, The data interaction between the physical device and the off-chip device is implemented based on the execution of the callback function pointer, wherein: The step of synchronizing the physical simulation data generated by the physical device during operation in the physical simulation environment to the off-chip device includes: The first callback function pointer registered in the simulation interaction data structure is invoked to write the physical simulation data generated by the operation of the physical device into the receiving buffer of the off-chip device. The step of synchronizing the control data written by the instruction core into the on-chip device to the physical device through the off-chip device and the bidirectional data interaction path includes: The second callback function pointer registered in the simulation interaction data structure is invoked to write the control data received by the external device into the control input interface of the physical device.

6. The method according to claim 5, characterized in that, In the system-level simulation environment, the on-chip device transmits signals with the off-chip device through pin binding functions; the data feedback path from the physical device to the instruction core includes: The physical device writes the physical simulation data generated during operation into the bidirectional data interaction channel; The bidirectional data interaction path outputs the physical simulation data to the off-chip device; The external device converts the physical simulation data into pin signals and transmits them to the internal device by calling the pin binding function; The on-chip device updates the corresponding register state according to the pin signal, so that the instruction core can read the physical simulation data from the register by executing a memory read instruction.

7. The method according to claim 6, characterized in that, In the system-level simulation environment, the on-chip device transmits signals with the off-chip device through pin binding functions; the control delivery path from the instruction core to the physical device includes: The instruction core modifies the state of the on-chip register by executing memory write instructions to write control signals into the on-chip register. The on-chip device drives the off-chip device to operate through the pin binding function based on the modified state of the on-chip register. The off-chip device generates control data in response to the drive operation and writes the control data into the bidirectional data interaction path; The bidirectional data interaction path synchronizes the control data to the physical device so that the physical device can update its physical state the next time it is pushed and run.

8. A simulation system, characterized in that, include: The first construction module is used to construct a bidirectional data interaction path between physical devices in the physical simulation environment and off-chip devices in the system-level simulation environment based on the device binding relationship between the system-level simulation environment and the physical simulation environment. The system-level simulation environment includes an instruction core, on-chip devices, and off-chip devices. The first generation module is used to execute an embedded program through the instruction core in the system-level simulation environment, generate a simulation time advance amount, and drive the event scheduler of the system-level simulation environment to advance the operation according to the simulation time advance amount; The first acquisition module is used to acquire the simulation step size of the physical simulation environment and create a synchronous coroutine in the system-level simulation environment. The synchronous coroutine is used to call the single-step advancement interface according to the simulation step size period to drive the physical simulation environment to run one simulation step size. The first synchronization module is used to synchronize the physical simulation data generated by the physical device during the operation of the physical simulation environment to the off-chip device through the bidirectional data interaction path when the physical simulation environment is running. This allows the instruction core to read the physical simulation data through the on-chip device and synchronize the control data written by the instruction core to the on-chip device to the physical device through the off-chip device and the bidirectional data interaction path, so that the physical device can perform status updates in the physical simulation environment according to the control data.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-7.

Images