Method for realizing accurate synchronization of time sequence in simulator based on shared memory

Abstract

The invention discloses a method for realizing accurate synchronization of a time sequence in a simulator based on a shared memory, which relates to the technical field of simulator development and cross-process communication, and comprises the following steps: constructing a standardized three-layer layout comprising a head control region, an annular data region and a compact storage unit, the annular data area circularly accesses, and the compact storage unit binds data and a time sequence; cross-platform zero-leakage resource management is realized through a global singleton handle manager, and interface multiplexing is provided or a shared memory is created and mapped; the sending end encodes data, binds a time sequence and atomically updates a write pointer, and the receiving end reads the data, calibrates the time sequence and atomically updates a read pointer; and executing time sequence precision, transmission delay, throughput and stability verification. According to the method, the lock competition overhead is eliminated, the cross-process data transmission efficiency is greatly improved, the time sequence synchronization accuracy is guaranteed, and the hardware bus refinement requirement is met.

Description

Technical Field

[0001] This invention relates to the fields of simulator development and cross-process communication technology, and in particular to a method for achieving precise timing synchronization in a simulator based on shared memory. Background Technology

[0002] In modern simulator development, to achieve modularity and flexible deployment, multifunctional modules are often split and run as independent processes. These processes require precise "data transmission-timing alignment" to accurately reproduce the real-world behavior of hardware devices. This includes timing matching for peripheral register reads and writes, and delay control for multi-module collaborative responses, directly determining the simulator's accuracy. However, current mainstream communication solutions struggle to meet the simulator's dual requirements for efficient transmission and strict timing. Network socket-based communication requires multiple layers of protocol stack encapsulation, resulting in latency generally exceeding 100μs. While pipe communication has slightly lower latency, it still reaches approximately 50μs, neither meeting the core requirement of nanosecond-level timing control for simulators, leading to deviations in hardware behavior simulation.

[0003] While traditional shared memory solutions reduce transmission latency through direct memory access, their reliance on mutexes or semaphores for inter-process coordination leads to severe lock contention. Lock wait times often exceed 30%, resulting in a data transfer throughput decrease of over 40% and potential timing disruptions due to lock contention, compromising the consistency of multi-process collaboration. Some lock-free shared memory solutions rely solely on simple pointer operations, failing to address the critical issues of "read / write pointer contention ambiguity" and "data visibility issues caused by CPU caching." In practical applications, this frequently leads to data loss or read errors, compromising transmission reliability. Furthermore, these solutions lack a unified handle management mechanism, resulting in low shared memory resource reuse rates and resource leak rates exceeding 20%, increasing system maintenance costs and stability risks.

[0004] Current technologies have not yet formed an integrated solution combining lock-free synchronization, timing binding, and cross-platform unified management, making it difficult to simultaneously meet the comprehensive requirements of simulators for transmission efficiency, timing accuracy, and system reliability. On the one hand, most solutions do not deeply bind data and timing information, failing to adapt to the fine-grained timing requirements of hardware buses such as IIC, SPI, and UART. On the other hand, cross-platform deployment support is insufficient; the resource creation and release mechanisms differ significantly across operating systems, resulting in high adaptation costs and poor compatibility. These problems collectively constrain the simulation accuracy and operational stability of simulators, becoming a critical technical bottleneck that urgently needs to be overcome in the field of simulator development. Summary of the Invention

[0005] This invention proposes a method for achieving precise timing synchronization in an emulator based on shared memory, in order to solve the problems mentioned in the prior art.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a method for achieving precise timing synchronization in an emulator based on shared memory, comprising the following steps: A standardized three-layer shared memory layout is constructed: the header control area uses RustAtomicUsize atomic types to encapsulate read_ptr, write_ptr, and buffer_size; the circular data area has the same capacity as buffer_size, and circular access is completed through index modulo; the compact storage unit is an EncodedEntry structure modified by #[repr(packed)], containing a 32-bit bit_value, an 8-bit status_flag, and a 24-bit timing_count, with a single structure occupying ≤8 bytes; Cross-platform zero-leakage resource management based on Rust: A global singleton SharedMemoryManager is defined using lazy_static!, internally using a mutex. <HashMap<String,Arc> > Stores shared memory handles; provides a get_or_create interface, which returns after verifying the capacity consistency. If inconsistent, it creates a new instance and initializes the header parameters, storing it in a HashMap. Relies on conditional compilation. Unix systems release resources through shm_unlink and munmap, while Windows systems use Droptrait to call munmap and rely on system mechanisms to reclaim handles. To achieve lock-free data transmission and timing synchronization across processes: The sending end encodes data in EncodedEntry format, writes it into a circular buffer and synchronizes timing_count, and atomically updates write_ptr using Release memory order; The receiving end reads the read and write pointers through Acquire memory order, calculates the amount of available data, reads the data into the read-side FIFO, calibrates the timing based on timing_count, and updates read_ptr using Release memory order. Performance verification: FPGA 1ns clock to verify timing accuracy, 1GS / s oscilloscope to acquire transmission delay; 72 hours of full load operation to verify stability, timing synchronization deviation ≤1ns, cross-process transmission delay ≤8μs, throughput ≥1.2GB / s, handle reuse rate 100%.

[0007] Furthermore, it also includes a dynamic timing deviation compensation step. The receiving end extracts the timing_count value from the EncodedEntry data as the transmitting end clock count, reads the local hardware clock count, and calculates the count difference as the local hardware clock count minus the transmitting end clock count, using the formula... Calculate the compensation delay amount, where To compensate for the delay, This is the clock cycle coefficient. The difference in counts, The basic compensation threshold is preset based on the simulator timing accuracy requirements.

[0008] Furthermore, it also includes a ring buffer state calculation step, whereby the sending end uses a formula... The receiver calculates the free space using a formula. Calculate the amount of available data, where Free space for the circular buffer. The total capacity of the buffer is buffer_size. The current value of write_ptr The current value of read_ptr This represents the amount of available data.

[0009] Furthermore, it also includes a multi-bus protocol adaptation step. The data to be transmitted is IIC, SPI, or UART bus protocol data. The status_flag field of the EncodedEntry structure defines different identifiers according to the bus type. In IIC bus protocol data, 0x01 represents the start condition, 0x02 represents the stop condition, 0x04 represents the ACK bit, and 0x08 represents the data bit. In SPI bus protocol data, 0x10 represents the chip select signal, 0x20 represents the clock signal, 0x40 represents the MOSI data, and 0x80 represents the MISO data. In UART bus protocol data, 0x01 represents the start bit, 0x02 represents the data bit, 0x04 represents the parity bit, and 0x08 represents the stop bit. It supports 5-8 data bits and 1-2 stop bits configuration.

[0010] Furthermore, it also includes a free space verification step at the sending end. Before writing data, the sending end reads the values ​​of write_ptr and read_ptr through atomic operations, calculates the free space as buffer_size minus the difference between the values ​​of write_ptr and read_ptr, and performs the data writing operation when the free space is not less than the number of bytes occupied by a single EncodedEntry structure. After writing is completed, the write pointer is atomically updated by writing_ptr.fetch_add the number of bytes occupied by a single EncodedEntry structure and Ordering::Release.

[0011] Furthermore, it also includes the receiving end decoding and data distribution steps. After reading the EncodedEntry data, the receiving end first extracts the status_flag value to identify the data type, and then decodes the bit_value data to obtain the original transmission information. If it is IIC bus data, it performs protocol parsing according to the start condition, stop condition, ACK bit, and data bit identifiers. If it is SPI bus data, it reassembles the data frame according to the chip select signal, clock signal, MOSI data, and MISO data identifiers. If it is UART bus data, it restores the byte stream according to the start bit, data bit, parity bit, and stop bit identifiers.

[0012] Furthermore, it includes detailed steps for creating cross-platform shared memory. In Unix and Unix-like operating systems, the `shm_open` function is called to create a named shared memory object, specifying the object name, access permissions, and creation mode. Then, the `mmap` function is called to map the shared memory object to the current process's address space. In Windows operating systems, the `CreateFileMapping` function is called to create a file mapping object, specifying the mapped file handle, security attributes, high and low bits of the file size, and the mapping name. Then, the `MapViewOfFile` function is called to map the file mapping object to the current process's address space, setting the mapping access permissions to allow both reading and writing of the file mapping.

[0013] Furthermore, the performance verification details include: timing accuracy verification uses an FPGA to generate a 1ns periodic standard clock signal to synchronously trigger the transmitting end's timing_count counting and the receiving end's verification logic, collecting 10,000 sets of differences between the transmitting end's timing_count values ​​and the receiving end's local clock count; transmission delay verification uses a 1GS / s sampling rate high-precision oscilloscope to collect the time difference between the transmitting end's data write completion signal and the receiving end's data parsing completion signal; throughput verification uses a fixed data volume of 10GB as the test benchmark to statistically analyze the effective data volume transmitted across processes per unit time; and stability verification involves continuous full-load operation for 72 hours, with a cumulative data transmission volume of no less than 100GB, and a statistical data transmission error rate not exceeding 10%. -6 After the process is restarted 1000 times, the handle reuse success rate is 100%.

[0014] Furthermore, it also includes a handle reuse consistency verification step. When the get_or_create interface queries the cache handle, in addition to verifying the consistency between buffer_size and the received capacity parameter, it also verifies three key parameters: the shared memory layout structure version, the EncodedEntry structure format, and the atomic operation memory order configuration. If all three are consistent, the cache handle is returned. If any one of them is inconsistent, it is considered an invalid handle and deleted, and a new shared memory instance that meets the current parameter requirements is created.

[0015] Furthermore, it also includes simulation scene extension adaptation steps. Based on the extensible characteristics of the EncodedEntry structure, an extended field reserved is added to store custom extended information; the get_or_create interface parameters are extended, and layout configuration parameters and timing precision parameters are added. The layout configuration parameters support adjusting the bit allocation of each field in the EncodedEntry structure, and the timing precision parameters support setting the mapping ratio between timing_count and the hardware clock cycle, adapting to simulator scenarios with different precision requirements from ns to μs, while maintaining the core lock-free synchronization mechanism and cross-platform management features unchanged.

[0016] Compared with existing technologies, the beneficial effects of this invention are: The present invention provides a method for achieving precise timing synchronization in simulators based on shared memory, which specifically addresses multiple pain points of traditional solutions. It significantly improves transmission efficiency, timing accuracy, system reliability, cross-platform compatibility, and scalability, providing efficient and reliable core technology support for simulator development.

[0017] Transmission efficiency is fundamentally optimized. By constructing a lock-free synchronization architecture, the performance loss caused by lock contention in traditional solutions is completely eliminated. Combined with the direct access characteristics of shared memory, the intermediate steps in data transmission are significantly reduced, making cross-process data transmission more efficient. The tight binding design of data and timing information avoids additional timing synchronization overhead, further improving transmission efficiency and meeting the high-frequency data interaction needs of simulators. It is significantly superior to network sockets, pipe communication, and traditional shared memory solutions.

[0018] A qualitative leap has been achieved in timing synchronization accuracy. Data bit values, status flags, and timing counters are integrated into a compact storage unit, ensuring that each data unit carries precise timing information. The receiving end performs targeted calibration based on the timing counters, effectively compensating for clock skew and making inter-process timing synchronization more accurate. This perfectly adapts to the fine-grained timing requirements of hardware buses such as IIC, SPI, and UART, providing a crucial guarantee for simulators to reproduce real hardware behavior.

[0019] The system reliability has been significantly enhanced. The global singleton handle manager enables efficient reuse of shared memory resources. Combined with Arc reference counting and cross-platform automatic resource release mechanisms, resource leaks are eliminated. Rust's memory safety features prevent common errors such as dangling pointers and data races from the underlying layer. After long-term full-load operation verification, the system's operational stability has been significantly improved, the failure rate has been greatly reduced, and maintenance costs and potential risks have been reduced.

[0020] Its cross-platform compatibility is outstanding. Leveraging the conditional compilation features of the Rust language, it customizes the creation, mapping, and resource release mechanisms of shared memory for mainstream operating systems such as Unix and Unix-like systems, and Windows, ensuring stable operation across different operating systems. The unified interface design reduces cross-platform adaptation costs, freeing developers from concern themselves with underlying system differences, significantly improving the solution's usability and deployment efficiency.

[0021] It exhibits excellent scalability; the standardized shared memory layout and get_or_create interface simplify the integration process, facilitating rapid integration into various simulator development scenarios. The compact storage unit supports custom extensions of status flags and data formats, flexibly adapting to the transmission requirements of different hardware bus protocols. It also supports flexible configuration of timing precision parameters, meeting simulator scenarios with varying precision requirements from nanoseconds to microseconds, and reserving ample space for future feature expansion and scenario adaptation. Attached Figure Description

[0022] Figure 1 This is a schematic block diagram of a method for achieving precise timing synchronization in an simulator based on shared memory, as proposed in this invention. Figure 2 Flowchart for a three-tier shared memory layout; Figure 3 This is a timing flowchart for lock-free data transfer across processes. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," and "counterclockwise," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0025] 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 indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified. Furthermore, the terms "installed," "connected," and "linked" should be interpreted broadly; for example, they may refer to a fixed connection, a detachable connection, or an integral connection; they may refer to a mechanical connection or an electrical connection; they may refer to a direct connection or an indirect connection through an intermediate medium; and they may refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances. The invention will now be described in further detail with reference to the accompanying drawings.

[0026] Reference Figures 1 to 3 A method for achieving precise timing synchronization in an emulator based on shared memory includes the following steps: A standardized three-layer layout for shared memory is constructed. The header control area uses the Rust language's AtomicUsize atomic type to encapsulate three control parameters: read_ptr (read pointer), write_ptr (write pointer), and buffer_size (buffer capacity), ensuring the visibility of the state during concurrent access by multiple processes. The circular data area is configured with a storage capacity consistent with the buffer_size value. Circular access is achieved through a wraparound calculation method that modulo the buffer_size with the index value, maximizing memory utilization. The compact storage unit is an EncodedEntry structure marked with the #[repr(packed)] attribute, containing a 32-bit bit_value data value, an 8-bit status_flag status flag, and a 24-bit timing_count timing counter. The number of bytes occupied by a single structure is controlled within 8 bytes, achieving a tight binding between data and timing. To achieve cross-platform, zero-leakage resource management, a global singleton `SharedMemoryManager` is defined using the `lazy_static!` macro in the Rust language, which internally sets a mutex. <HashMap<String,Arc> The structure stores shared memory handles. The keys of the HashMap are the shared memory name string, and the values ​​are SharedMemory handles with Arc reference counting. It provides a get_or_create interface, which accepts the shared memory name parameter and the capacity parameter. It first queries the cached handle in the HashMap. If it exists, it checks whether the buffer_size is consistent with the received capacity parameter. If they are consistent, it returns the handle. If it does not exist or the capacity is inconsistent, it creates a new instance and maps it to the current process address space. After initializing the header control section parameters, it stores it in the HashMap and returns the new handle. Based on Rust's conditional compilation features, in Unix and Unix-like operating systems, the shared memory object is deleted through the shm_unlink system call and the munmap function is called to unmap it. In the Windows operating system, the munmap function is called through Droptrait to unmap it, relying on the operating system's handle reclamation mechanism to release resources. To perform lock-free cross-process data transmission and timing synchronization, the sending end stores the data to be transmitted into the write-side FIFO buffer, iterates through the buffer data and encodes it according to the EncodedEntry structure format, synchronously writes the timing_count value corresponding to the hardware clock cycle in a 1:1 ratio, and updates the write pointer by calling the fetch_add atomic operation of write_ptr in Ordering::Release memory order to complete the data writing. The receiving end reads the values ​​of read_ptr and write_ptr respectively in Ordering::Acquire memory order, calculates the available data volume as the write_ptr value minus the read_ptr value, and when the available data volume is greater than 0, it reads the EncodedEntry data from the position pointed to by read_ptr and stores it into the read-side FIFO buffer, performs timing calibration based on the timing_count value and the local clock, and calls the fetch_add atomic operation of read_ptr to update the read pointer in Ordering::Release memory order. Performance verification was performed by generating a 1ns period standard clock signal using the FPGA for timing accuracy verification, acquiring the transmission delay using an oscilloscope with a 1GS / s sampling rate, and performing 72 hours of full-load operation for stability verification. The timing synchronization deviation was controlled within 1ns, the cross-process transmission delay was controlled within 8μs, the data transmission throughput was maintained above 1.2GB / s, the lock wait time ratio was 0%, the handle reuse rate was 100%, and the resource leakage rate was 0%.

[0027] This invention also includes a dynamic timing deviation compensation step. The receiving end extracts the timing_count value from the EncodedEntry data as the transmitting end clock count, reads the local hardware clock count, and calculates the count difference as the local hardware clock count minus the transmitting end clock count, using the formula... Calculate the compensation delay amount, where To compensate for the delay, This is the clock cycle coefficient, which has a fixed proportional relationship with the hardware clock cycle. The difference in counts, Based on the basic compensation threshold, the timing accuracy requirements of the simulator are preset, and the data output timing of the receiving end is adjusted based on the compensation delay, so that the deviation between the output timing and the sending timing is always controlled within 1ns, which adapts to the fine timing requirements of hardware peripherals.

[0028] This invention also includes a ring buffer state calculation step, whereby the sending end uses a formula... The receiver calculates the free space using a formula. Calculate the amount of available data, where Free space for the circular buffer. The total capacity of the buffer is buffer_size. The current value of write_ptr The current value of read_ptr To determine the available data volume, precise calculations are used to achieve non-blocking writing at the sending end and conflict-free reading at the receiving end, avoiding data overflow or reading empty data.

[0029] This invention also includes a multi-bus protocol adaptation step. The data to be transmitted is IIC, SPI, or UART bus protocol data. The status_flag field of the EncodedEntry structure defines different identifiers according to the bus type. In the IIC bus protocol data, 0x01 represents the start condition, 0x02 represents the stop condition, 0x04 represents the ACK bit, and 0x08 represents the data bit, supporting switching between 100Kbps standard mode and 400Kbps fast mode. In the SPI bus protocol data, 0x10 represents the chip select signal, 0x20 represents the clock signal, 0x40 represents the MOSI data, and 0x80 represents the MISO data, supporting rate adjustment from 1Mbps to 10Mbps. In the UART bus protocol data, 0x01 represents the start bit, 0x02 represents the data bit, 0x04 represents the parity bit, and 0x08 represents the stop bit, supporting 5-8 data bits and 1-2 stop bits configuration.

[0030] This invention also includes a sender-end free space verification step. Before writing data, the sender reads the values ​​of write_ptr and read_ptr through atomic operations, calculates the free space as buffer_size minus the difference between the values ​​of write_ptr and read_ptr, and performs the data writing operation when the free space is not less than the number of bytes occupied by a single EncodedEntry structure. After writing, the sender uses write_ptr.fetch_add to calculate the number of bytes occupied by a single EncodedEntry structure and Ordering::Release to perform an atomic update of the write pointer. When the value of write_ptr is not less than buffer_size, the sender resets the buffer_size to the starting position by taking the modulo of the write_ptr value, thus ensuring the security and continuity of the write operation.

[0031] This invention also includes a receiving end decoding and data distribution step. After reading the EncodedEntry data, the receiving end first extracts the status_flag value to identify the data type, and then decodes the bit_value data to obtain the original transmission information. If it is IIC bus data, it performs protocol parsing according to the identifiers of start condition, stop condition, ACK bit, and data bit. If it is SPI bus data, it reassembles the data frame according to the identifiers of chip select signal, clock signal, MOSI data, and MISO data. If it is UART bus data, it restores the byte stream according to the identifiers of start bit, data bit, parity bit, and stop bit. Finally, the decoded original data is distributed to the corresponding simulator hardware peripheral module.

[0032] This invention also includes detailed steps for creating cross-platform shared memory. In Unix and Unix-like operating systems, the `shm_open` function is called to create a named shared memory object, specifying the object name, access permissions, and creation mode. Then, the `mmap` function is called to map the shared memory object to the current process's address space, setting the mapping permissions to read and write. In the Windows operating system, the `CreateFileMapping` function is called to create a file mapping object, specifying the mapped file handle, security attributes, high and low bits of the file size, and the mapping name. Then, the `MapViewOfFile` function is called to map the file mapping object to the current process's address space, setting the mapping access permissions to read and write, ensuring consistency in shared memory creation and mapping across different operating systems.

[0033] This invention also includes detailed performance verification steps. Timing accuracy verification uses an FPGA to generate a 1ns periodic standard clock signal, synchronously triggering the transmitting end's timing_count and the receiving end's verification logic. It collects 10,000 sets of differences between the transmitting end's timing_count value and the receiving end's local clock count, ensuring that the percentage of samples with a deviation within 1ns is no less than 99.9%. Transmission delay verification uses a 1GS / s sampling rate high-precision oscilloscope to collect the time difference between the transmitting end's data write completion signal and the receiving end's data parsing completion signal, repeating the test 10,000 times and averaging the result to within 8μs. Throughput verification uses a fixed data volume of 10GB as the test benchmark, statistically analyzing the effective data volume transmitted across processes per unit time, calculating a net throughput maintained above 1.2GB / s. Stability verification involves continuous full-load operation for 72 hours, with a cumulative data transmission volume of no less than 100GB, and statistically analyzing a transmission error rate not exceeding 10%. -6 After 1000 process restarts, the handle reuse success rate was 100%, with no resource leaks or memory anomalies.

[0034] This invention also includes a handle reuse consistency verification step. When the get_or_create interface queries the cache handle, in addition to verifying the consistency between buffer_size and the received capacity parameter, it also verifies three key parameters: the shared memory layout structure version, the EncodedEntry structure format, and the atomic operation memory order configuration. If all three parameters are consistent, the cache handle is returned. If any one parameter is inconsistent, the handle is considered invalid and deleted. A new shared memory instance that meets the current parameter requirements is then created to ensure that the reused shared memory can meet the current simulator timing synchronization requirements and avoid data transmission errors or timing deviations caused by parameter mismatch.

[0035] This invention also includes a simulation scenario extension adaptation step. Based on the extensible characteristics of the EncodedEntry structure, a new extended field, reserved, is added to store custom extended information. This supports adding custom attributes such as data verification bits, module identifiers, and transmission priorities according to the needs of different simulator scenarios. The get_or_create interface parameters are extended, and layout configuration parameters and timing precision parameters are added. The layout configuration parameters support adjusting the bit allocation of each field in the EncodedEntry structure, and the timing precision parameters support setting the mapping ratio between timing_count and the hardware clock cycle. This adapts to simulator scenarios with different precision requirements from the ns level to the μs level, while maintaining the core lock-free synchronization mechanism and cross-platform management characteristics unchanged.

[0036] The following two examples further illustrate the specific implementation of this system: Example 1 IIC bus peripheral simulator cross-process timing synchronization This embodiment is applied to the development scenario of IIC bus peripheral simulator, aiming to realize cross-process communication timing synchronization between the main control chip and the peripheral chip, adapt to the standard mode and fast mode of IIC bus, deploy on the Unix operating system, accurately replicate the peripheral register read and write timing, and fully implement the technical solution of this invention.

[0037] Constructing a standardized three-layer shared memory layout is the foundation for the solution implementation. The header control area uses the `AtomicUsize` atomic type in Rust to encapsulate three core control parameters: read pointer, write pointer, and buffer capacity. This ensures state visibility during concurrent access by multiple processes and avoids data visibility issues caused by CPU caching. The storage capacity of the circular data area is consistent with the buffer capacity. Circular access is achieved through a wraparound calculation method that modulo the buffer capacity using the index value, maximizing memory utilization and avoiding address overflow issues. The compact storage unit uses an `EncodedEntry` structure marked with the `#[repr(packed)]` attribute. It contains 32 data bits, 8 status flags, and timing counters. The number of bytes occupied by a single structure is strictly controlled within 8 bytes, achieving tight binding between data and timing information and providing a foundation for accurate timing synchronization. The status flag field is identified according to the IIC bus protocol definition. The start condition, stop condition, ACK bit, and data bits each correspond to specific flags, ensuring the accuracy of protocol parsing.

[0038] This implements cross-platform, zero-leakage resource management based on Rust, using the `lazy_static!` macro to define a global singleton `SharedMemoryManager`, which internally sets a mutex. <HashMap<String, Arc> The shared memory object is stored in a HashMap. The key is the shared memory name string, and the value is a SharedMemory handle with Arc reference counting, enabling centralized management and secure access to the handles. It provides a `get_or_create` interface, which receives the shared memory name and capacity parameters. First, it queries the HashMap for cached handles. If a cached handle exists, it verifies the buffer capacity against the received capacity parameter. It also verifies three key parameters: the shared memory layout version, the `EncodedEntry` structure format, and the atomic operation memory order configuration. Only if all four parameters match is the cached handle returned; otherwise, it is considered invalid and deleted. If the cached handle does not exist or has been deleted, a new shared memory instance is created. In Unix operating systems, a named shared memory object is created using the `shm_open` function, specifying the object name, read / write access permissions, and a suitable creation mode. Then, the `mmap` function is called to map the shared memory object to the current process's address space, initialize the header control parameters, store it in the HashMap, and return a new handle. During the resource release phase, relying on Rust's conditional compilation features, the shared memory object is deleted through the shm_unlink system call, and the memory mapping is released by calling the munmap function. With the help of the Arc reference counting mechanism, it is ensured that resources are completely released after all processes exit, achieving zero-leakage resource management.

[0039] The core steps involve performing lock-free cross-process data transmission and timing synchronization. The sending end first stores the IIC bus protocol data to be transmitted into a write-side FIFO buffer. Then, it iterates through the buffer data, encodes it according to the EncodedEntry structure format, and synchronously writes timing counters corresponding one-to-one with the hardware clock cycle, ensuring that each data unit carries accurate timing information. Before writing data, the sending end atomically reads the values ​​of the write and read pointers to calculate the free space in the circular buffer. Data writing is only performed when the free space is not less than the number of bytes occupied by a single EncodedEntry structure, preventing data overflow. After writing, the write pointer is updated using the Ordering::Release memory ordering method with the fetch_add atomic operation. When the write pointer value is not less than the buffer capacity, it is reset to the starting position using a modulo operation, ensuring the safety and continuity of the write operation. The receiving end reads the values ​​of the read and write pointers using the Ordering::Acquire memory ordering to calculate the available data volume. When the available data volume is greater than 0, it reads the EncodedEntry data from the position pointed to by the read pointer and stores it into the read-side FIFO buffer. Timing calibration is performed based on the timing count carried in the data and the local hardware clock count. The timing count is extracted as the transmitting end clock count, the local hardware clock count is read, and the difference between the two counts is calculated. According to the preset clock cycle coefficient and the basic compensation threshold, the compensation delay is calculated, and the receiving end data output timing is adjusted according to this compensation delay to ensure that the timing synchronization deviation is controlled within the required range. After calibration, the fetch_add atomic operation of the read pointer is called to update the read pointer in Ordering::Release memory order, realizing lock-free synchronization across processes.

[0040] The receiving end's decoding and data distribution steps ensure the accurate restoration and transmission of the original data. After reading the EncodedEntry data, the receiving end first extracts the status flag value to identify the data type. After confirming that it is IIC bus protocol data, it decodes the data bits to obtain the original transmission information. Then, it performs protocol parsing according to the start condition, stop condition, ACK bit, and data bit identifiers. Finally, it distributes the decoded original data to the corresponding simulator hardware peripheral modules to ensure that the peripheral modules can accurately respond to the operating instructions of the main control chip.

[0041] The simulation scenario extension and adaptation steps enhance the flexibility of the solution. Based on the scalability of the EncodedEntry structure, a new extended field is added to store custom extended information. Custom attributes such as data check bits and module identifiers can be added according to the requirements of this IIC bus simulator scenario, enhancing the reliability and traceability of data transmission. The get_or_create interface parameters are extended, adding layout configuration parameters and timing precision parameters. The layout configuration parameters support adjusting the bit allocation of each field in the EncodedEntry structure, and the timing precision parameters support setting the mapping ratio between timing counts and hardware clock cycles, adapting to different precision requirements in this scenario while maintaining the core lock-free synchronization mechanism and cross-platform management characteristics.

[0042] The performance verification phase comprehensively examines the reliability and effectiveness of the solution. Timing accuracy verification uses specialized equipment to generate a standard clock signal, synchronously triggering the timing counter at the transmitting end and the verification logic at the receiving end. Multiple sets of differences between the transmitting end's timing count and the receiving end's local clock count are collected to ensure that timing synchronization deviations meet requirements. Transmission delay verification uses a high-precision oscilloscope to collect the time difference between the transmitting end's data write completion signal and the receiving end's data parsing completion signal, ensuring that cross-process transmission delay is controlled within the specified range. Throughput verification uses a fixed data volume as the test benchmark, statistically analyzing the effective data volume transmitted across processes per unit time to ensure that data transmission efficiency meets requirements. Stability verification involves continuous full-load operation for a long period, accumulating large amounts of data transmission, statistically analyzing the transmission error rate, and performing multiple process restart tests to verify handle reuse success rate and resource leakage, ensuring the long-term stability and reliability of the system.

[0043] Table 1 Comparison of Analog Timing Synchronization Performance of IIC Bus Peripherals Table 1 clearly demonstrates the core advantages of this invention's solution in IIC bus simulation scenarios. Traditional shared memory solutions rely on mutex locks to coordinate process access, resulting in significant lock waiting time. This not only leads to high inter-process transmission latency but also severely impacts data transmission throughput, causing large timing synchronization deviations that fail to meet the fine-grained timing requirements of the IIC bus. Furthermore, the high resource leakage rate affects the long-term stability of the system. Network socket solutions, affected by multi-layered protocol stack encapsulation, suffer from extremely high inter-process transmission latency, extremely low data transmission throughput, and timing synchronization deviations far exceeding hardware bus requirements, making them unsuitable for simulator scenarios. This invention's solution completely eliminates lock contention overhead through a lock-free synchronization architecture. Combined with tight data and timing binding and a dynamic compensation mechanism, it achieves extremely low inter-process transmission latency and minimal timing synchronization deviations, significantly improving data transmission throughput. Simultaneously, through a global singleton handle manager and a cross-platform automatic resource release mechanism, it achieves zero resource leakage and 100% handle reuse, perfectly meeting the core requirements of IIC bus peripheral simulators for efficiency, accuracy, and stability.

[0044] Example 2 SPI bus multi-module collaborative simulation timing synchronization This embodiment is applied to a multi-module collaborative simulation scenario of the SPI bus, simulating cross-process timing synchronization between the main control module and multiple peripheral modules, adapting to the multi-rate adjustment requirements of the SPI bus, deployed on the Windows operating system, supporting concurrent data interaction of multiple modules, and fully implementing the technical solution of this invention.

[0045] When constructing a standardized three-layer shared memory layout, the header control area also adopts the Rust language's AtomicUsize atomic type, encapsulating three control parameters: read pointer, write pointer, and buffer capacity. This ensures the visibility of state access during concurrent multi-process access and provides a foundation for collaborative access by multiple modules. The storage capacity of the circular data area is consistent with the buffer capacity. Circular access is achieved through a wraparound calculation method that modulo the buffer capacity with the index value, maximizing memory utilization and meeting the data storage needs of concurrent multi-modules. The compact storage unit is an EncodedEntry structure marked with the #[repr(packed)] attribute, containing 32-bit data bits, 8-bit status flags, and 24-bit timing counters. A single structure occupies no more than 8 bytes, achieving tight binding between data and timing. The status flag field defines specific identifiers according to the SPI bus protocol. Chip select signal, clock signal, MOSI data, and MISO data each correspond to a unique identifier, ensuring accurate identification during multi-module data interaction.

[0046] Cross-platform, zero-leakage resource management is achieved through features of the Rust language. This is achieved by using the `lazy_static!` macro to define a global singleton `SharedMemoryManager`, which internally sets a mutex. <HashMap<String, Arc> The shared memory handle is stored in a HashMap. The key is the shared memory name string, and the value is a SharedMemory handle with Arc reference counting, enabling efficient handle management. When calling the `get_or_create` interface, the shared memory name and capacity parameters are passed in. The interface first queries the cached handle in the HashMap. If a cached handle exists, it verifies four key parameters: buffer capacity, shared memory layout structure version, `EncodedEntry` structure format, and atomic operation memory order configuration. If all four match, the handle is returned; otherwise, it is considered invalid and deleted. If the cached handle does not exist or has been deleted, a new shared memory instance is created. In Windows operating systems, the `CreateFileMapping` function is called to create a file mapping object, specifying the mapped file handle, security attributes, high and low bits of the file size, and the mapping name. Then, the `MapViewOfFile` function is called to map the file mapping object to the current process's address space, setting the mapping access permissions to read and write, initializing the header control parameters, storing it in the HashMap, and returning a new handle. During the resource release phase, the memory mapping is released by calling the munmap function through Droptrait. The shared memory resources are released by relying on the handle reclamation mechanism of the Windows operating system. When the Arc reference count drops to 0, the cleanup logic is automatically triggered to achieve cross-platform zero-leakage resource management.

[0047] Cross-process lock-free data transmission and timing synchronization are adapted for multi-module collaborative scenarios. The transmitting end simulates the main control module's process, storing SPI bus protocol data frames into the write-side FIFO buffer and configuring timing parameters according to the currently set transmission rate. Data in the buffer is traversed and encoded according to the EncodedEntry structure format, synchronously writing timing counters corresponding one-to-one with the hardware clock cycle to ensure accurate timing information for each data unit. Before writing data, the transmitting end reads the values ​​of the write and read pointers through atomic operations, calculates the free space in the circular buffer, and performs the write operation when the free space is not less than the number of bytes occupied by a single EncodedEntry structure to avoid data overflow. After writing, the write pointer is updated by calling the fetch_add atomic operation of the write pointer through Ordering::Release memory order. When the write pointer value is not less than the buffer capacity, it is reset to the starting position through modulo operation to ensure continuous writing. Multiple receivers, simulating processes of different peripheral modules, read the values ​​of the read and write pointers using the Ordering::Acquire memory order to calculate the available data volume. When the available data volume is greater than 0, they read EncodedEntry data from the position pointed to by the read pointer and store it in their respective read-side FIFO buffers. Each receiver extracts the timing count from the data as the transmitter's clock count, reads the local hardware clock count and calculates the count difference. Combining this with a preset clock cycle coefficient and a basic compensation threshold, they calculate the compensation delay. Based on this compensation delay, they adjust the data output timing to ensure that the timing synchronization deviation meets the requirements. After calibration, each receiver updates its read pointer using the Ordering::Release memory order, achieving conflict-free access and lock-free synchronization across multiple processes.

[0048] The receiver's decoding and data distribution steps ensure accurate data interaction among multiple modules. After reading the EncodedEntry data, the receiver extracts the status flag values ​​to identify the data type. Once it confirms that the data is SPI bus protocol data, it decodes the data bits to obtain the original transmission information. The data frame is then reassembled according to the identifiers of the chip select signal, clock signal, MOSI data, and MISO data. Only peripheral modules with matching chip select signals respond to data interaction, ensuring the orderly progress of multi-module collaborative simulation. The reassembled original data is then distributed to the corresponding peripheral modules, achieving accurate collaboration between the main control module and multiple peripheral modules.

[0049] The simulation scenario extension and adaptation steps enhance the adaptability of the solution. Based on the scalability of the EncodedEntry structure, a new extended field is added to store custom extended information. For multi-module collaborative scenarios on the SPI bus, a transmission priority field can be added to ensure the priority transmission of critical data. The get_or_create interface parameters are extended, adding layout configuration parameters and timing precision parameters. The layout configuration parameters support adjusting the bit allocation of each field in the EncodedEntry structure, and the timing precision parameters support setting the mapping ratio between timing counts and hardware clock cycles, adapting to simulator scenarios with different precision requirements from nanoseconds to microseconds, while maintaining the core lock-free synchronization mechanism and cross-platform management characteristics, meeting the diverse needs of multi-module collaborative simulation.

[0050] The performance verification phase comprehensively examines the solution's performance in multi-module scenarios. Timing accuracy verification uses specialized equipment to generate a standard clock signal, synchronously triggering timing counters at the transmitting end and verification logic at each receiving end. Multiple sets of timing differences are collected to ensure timing synchronization deviations are controlled within specified ranges. Transmission delay verification uses a high-precision oscilloscope to collect the time difference between the data write completion signal at the transmitting end and the data parsing completion signal at each receiving end, ensuring cross-process transmission delays meet requirements. Throughput verification uses a fixed data volume as the test benchmark, statistically analyzing the effective data volume transmitted across processes per unit time to meet the efficiency requirements of concurrent data interaction across multiple modules. Stability verification involves continuous full-load operation for a long period, accumulating large amounts of data transmission, statistically analyzing transmission error rates, and performing multiple process restart tests to verify handle reuse success rate and resource leakage, ensuring the system's long-term stability and reliability under multi-module concurrent access scenarios.

[0051] Table 2 Comparison of SPI bus multi-module co-simulation performance Table 2 data visually demonstrates the significant advantages of the proposed solution in multi-module collaborative simulation scenarios on the SPI bus. Traditional shared memory solutions rely on mutex locks to coordinate multi-process access, resulting in high lock waiting time, high cross-process transmission latency, insufficient data transmission throughput to meet the concurrent requirements of multiple modules, significant timing synchronization deviations affecting the accuracy of multi-module collaboration, low handle reuse rate, high resource leakage rate, and insufficient system stability. Pipe communication solutions are limited by kernel buffers, resulting in high cross-process transmission latency, moderate to low data transmission throughput, and significant timing synchronization deviations, making it difficult to adapt to the fine-grained timing requirements of high-speed transmission and multi-module collaboration on the SPI bus. The proposed solution completely eliminates lock contention overhead through a lock-free synchronization architecture, maximizes memory utilization through circular reuse design of the circular data area, and ensures conflict-free concurrent access by multiple processes with atomic operations, achieving extremely low cross-process transmission latency and minimal timing synchronization deviations, significantly improving data transmission throughput. Furthermore, through a global singleton handle manager and a cross-platform automatic resource release mechanism, it achieves 100% handle reuse rate and zero resource leakage, providing efficient, accurate, and stable timing synchronization support for multi-module collaborative simulation on the SPI bus.

[0052] Example 3 UART bus multi-rate communication timing synchronization This embodiment is applied to the development scenario of a UART bus multi-rate communication simulator, simulating cross-process timing synchronization between serial port devices and the main control module. It adapts to different data bit and stop bit configurations of the UART bus, supports multi-rate adjustment, is deployed on a Unix-like operating system, and achieves accurate simulation of serial port data transmission timing, thus fully implementing the technical solution of this invention.

[0053] When constructing a standardized three-layer shared memory layout, the header control area uses the Rust language's AtomicUsize atomic type to encapsulate three core control parameters: read pointer, write pointer, and buffer capacity. This ensures state visibility during concurrent access by multiple processes and provides a foundation for cross-process data interaction. The storage capacity of the circular data area is consistent with the buffer capacity. Circular access is achieved through a wraparound calculation method using the index value modulo the buffer capacity, improving memory utilization and preventing address overflow. The compact storage unit is an EncodedEntry structure marked with the #[repr(packed)] attribute, containing 32 data bits, 8 status flags, and 24 timing counters. A single structure occupies no more than 8 bytes, achieving tight binding between data and timing. The status flag field is identified according to the UART bus protocol, with start, data, parity, and stop bits each corresponding to specific identifiers. Flexible configuration of 5-8 data bits and 1-2 stop bits is supported to meet multi-rate communication requirements.

[0054] Cross-platform, zero-leakage resource management is achieved using Rust language features. A global singleton `SharedMemoryManager` is defined via the `lazy_static!` macro, internally configured with a mutex. <HashMap<String, Arc> The shared memory object is stored in a HashMap with the shared memory name string as the key and the SharedMemory handle with Arc reference counting as the value, enabling centralized management of handles. When the `get_or_create` interface is called, the shared memory name and capacity parameters are passed in. The interface first queries the HashMap for cached handles. If a cached handle exists, it verifies four key parameters: buffer capacity, shared memory layout structure version, `EncodedEntry` structure format, and atomic operation memory order configuration. If all four parameters match, the handle is returned; otherwise, it is considered invalid and deleted. If the cached handle does not exist or has been deleted, a new shared memory instance is created. In Unix-like operating systems, the `shm_open` function is called to create a named shared memory object, specifying the object name, read / write access permissions, and creation mode. Then, the `mmap` function is called to map the shared memory object to the current process's address space, initialize the header control parameters, store it in the HashMap, and return the new handle. During resource release, the shared memory object is deleted via the `shm_unlink` system call, and the `munmap` function is called to unmap the memory. Using Arc reference counting, this ensures that resources are completely released after all processes exit, achieving zero-leakage management.

[0055] Cross-process lock-free data transmission and timing synchronization ensure efficient and accurate serial port data transmission. The transmitting end stores the UART bus protocol data to be transmitted into the write-side FIFO buffer. Based on the currently configured rate, data bits, and stop bit parameters, it encodes the data according to the EncodedEntry structure format and synchronously writes it to a timing counter corresponding one-to-one with the hardware clock cycle. Before writing data, the transmitting end reads the values ​​of the write and read pointers through atomic operations to calculate the free space in the circular buffer. The write operation is performed when the free space is not less than the number of bytes occupied by a single EncodedEntry structure, preventing data overflow. After writing, the write pointer is updated using the Ordering::Release memory order to call the fetch_add atomic operation of the write pointer. When the write pointer value is not less than the buffer capacity, it is reset to the starting position using a modulo operation to ensure continuous writing. The receiving end reads the values ​​of the read and write pointers through the Ordering::Acquire memory order to calculate the available data volume. When the available data volume is greater than 0, it reads the EncodedEntry data and stores it into the read-side FIFO buffer. The timing count is extracted from the data and used as the transmitter clock count. The local hardware clock count is read and the count difference is calculated. Combined with the preset clock cycle coefficient and the basic compensation threshold, the compensation delay is calculated, and the data output timing is adjusted to ensure that the timing synchronization deviation meets the requirements. After calibration, the read pointer is updated via Ordering::Release memory ordering to achieve lock-free synchronization.

[0056] The receiving end decodes and distributes data to restore the original serial port data. After reading the EncodedEntry data, the receiving end extracts the status flag values ​​to identify the data type. After confirming that it is UART bus protocol data, it decodes the data bits to obtain the original transmission information. It restores the byte stream according to the start bit, data bits, parity bit, and stop bit identifiers. It performs verification according to the configured parity bit rules to ensure the accuracy of data transmission. Finally, it distributes the decoded original data to the corresponding serial port device simulation module to achieve accurate simulation of serial communication.

[0057] The simulation scenario extension and adaptation steps enhance the flexibility and compatibility of the solution. Based on the scalability of the EncodedEntry structure, new extended fields are added to store custom extended information. For multi-rate UART bus scenarios, a module identifier field can be added to facilitate differentiation of different serial port devices. The get_or_create interface parameters are extended, adding layout configuration parameters and timing precision parameters. The layout configuration parameters support adjusting the bit allocation of each field in the EncodedEntry structure, and the timing precision parameters support setting the mapping ratio between timing counts and hardware clock cycles, adapting to simulator scenarios with different precision requirements from nanoseconds to microseconds, while maintaining the core lock-free synchronization mechanism and cross-platform management features, meeting the diverse needs of multi-rate serial communication.

[0058] The performance verification phase comprehensively examines the reliability and adaptability of the solution. Timing accuracy verification uses specialized equipment to generate a standard clock signal, synchronously triggering the timing counting at the transmitting end and the verification logic at the receiving end. Multiple sets of timing differences are collected to ensure that timing synchronization deviations are controlled within the specified range. Transmission delay verification uses a high-precision oscilloscope to collect the time difference between the data write completion signal at the transmitting end and the data parsing completion signal at the receiving end, ensuring that cross-process transmission delay meets requirements. Throughput verification uses a fixed data volume as the test benchmark, statistically analyzing the effective data volume transmitted across processes per unit time to meet the efficiency requirements of multi-rate communication. Stability verification involves continuous full-load operation for a long period, accumulating the transmission of large amounts of data, statistically analyzing the transmission error rate, and simultaneously performing multiple process restart tests to verify handle reuse success rate and resource leakage, ensuring the long-term stability and reliability of the system under multi-rate communication scenarios.

[0059] Table 3 Comparison of Timing Synchronization Performance of UART Bus Multi-rate Communication Table 3 clearly demonstrates the core advantages of this invention's solution in UART bus multi-rate communication scenarios. Traditional shared memory solutions rely on mutex locks, resulting in high lock waiting time, high cross-process transmission latency, insufficient data transmission throughput, and significant timing synchronization deviations. This fails to meet the fine-grained timing requirements of UART bus multi-rate communication, and also suffers from low handle reuse and high resource leakage, impacting system stability. Pipe communication solutions are limited by their transmission mechanisms, resulting in high cross-process transmission latency, moderate to low data transmission throughput, and significant timing synchronization deviations, making them unsuitable for the high efficiency and precision requirements of multi-rate communication. This invention eliminates lock contention overhead through a lock-free synchronization architecture. Combined with tight data and timing binding and a dynamic compensation mechanism, it achieves extremely low cross-process transmission latency and minimal timing synchronization deviations, significantly improving data transmission throughput. Furthermore, through a global singleton handle manager and a cross-platform automatic resource release mechanism, it achieves 100% handle reuse and zero resource leakage, perfectly meeting the core requirements of UART bus multi-rate communication simulators and providing efficient, accurate, and stable timing synchronization support for serial device simulation.

[0060] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for timing accurate synchronization in a simulator based on shared memory, characterized in that, Comprising the following steps: Construct a standardized three-layer shared memory layout: the head control area encapsulates read_ptr, write_ptr, buffer_size with RustAtomicUsize atomic type; the ring data area has the same capacity as buffer_size, and circular access is achieved by index modulo operation; the compact storage unit is the EncodedEntry structure with #[repr(packed)] decoration, containing 32-bit bit_value, 8-bit status_flag, and 24-bit timing_count, and a single structure occupies ≤8 bytes; Implement cross-platform zero-leak resource management based on Rust: define a global singleton SharedMemoryManager using lazy_static!, which internally uses Mutex<HashMap<String, Arc>> to store shared memory handles; provide a get_or_create interface that returns after verifying capacity consistency, or creates a new instance and initializes the header parameters into the HashMap; rely on conditional compilation, release resources through shm_unlink and munmap on Unix systems, and call munmap using the Drop trait on Windows systems, and rely on system mechanisms to reclaim handles; Implement cross-process lock-free data transmission and timing synchronization: the sender encodes data into EncodedEntry format, writes it to the ring buffer and synchronizes timing_count, and updates write_ptr using Release memory order; the receiver reads read and write pointers using Acquire memory order, calculates the available data amount, reads data into the read-side FIFO, and adjusts timing based on timing_count, and updates read_ptr using Release memory order; Performance verification: FPGA 1ns clock verification timing accuracy, 1GS / s oscilloscope to collect transmission delay; 72-hour full-load running to verify stability, timing synchronization deviation ≤1ns, cross-process transmission delay ≤8μs, throughput ≥1.2GB / s, and handle reuse rate 100%.

2. The method for time-accurate synchronization in a shared memory based emulator according to claim 1, wherein, Also included is a timing offset dynamic compensation step, the receiving end extracts the timing_count value from the EncodedEntry data as the sending end clock count, reads the local hardware clock count to calculate the count difference as the local hardware clock count minus the sending end clock count, through the formula calculates the compensation delay amount, wherein is the final compensation delay amount, is the clock period coefficient, is the count difference, is the base compensation threshold, which is preset according to the timing accuracy requirement of the simulator.

3. The method for time-accurate synchronization in a shared memory based emulator according to claim 1, wherein, Also included is a ring buffer status calculation step, where the sender calculates the free space by the formula and the receiver calculates the available data by the formula where is the ring buffer free space, is the total buffer size, i.e. buffer_size, is the current value of write_ptr, is the current value of read_ptr, and is the available data.

4. The method for time-accurate synchronization in a shared memory based emulator according to claim 1, wherein, Also includes multi-bus protocol adaptation steps, the data to be transmitted is IIC, SPI, or UART bus protocol data, the status_flag field of the EncodedEntry structure defines different flags according to the bus type, 0x01 in IIC bus protocol data represents the start condition, 0x02 represents the stop condition, 0x04 represents the ACK bit, and 0x08 represents the data bit; 0x10 in SPI bus protocol data represents the chip select signal, 0x20 represents the clock signal, 0x40 represents the MOSI data, and 0x80 represents the MISO data; 0x01 in UART bus protocol data represents the start bit, 0x02 represents the data bit, 0x04 represents the check bit, and 0x08 represents the stop bit, supporting 5-8-bit data bits and 1-2-bit stop bit configuration.

5. The method for time-accurate synchronization in a shared memory based emulator according to claim 1, wherein, Also includes a sending end idle space checking step, the sending end reads the value of write_ptr and read_ptr respectively through atomic operation before data writing, calculates the idle space as buffer_size minus the difference between write_ptr value and read_ptr value, performs data writing operation when the idle space is not less than the number of bytes occupied by a single EncodedEntry structure, and after writing is completed, the number of bytes occupied by a single EncodedEntry structure is added to write_ptr through write_ptr.fetch_add, and Ordering::Release completes atomic update of the write pointer.

6. The method for time-accurate synchronization in a shared memory based emulator according to claim 1, wherein, Also includes a receiving end decoding and data distribution step, the receiving end reads EncodedEntry data, extracts the status_flag value to identify the data type first, then decodes the bit_value data to obtain the original transmission information, if it is IIC bus data, the protocol is parsed according to the identification of start condition, stop condition, ACK bit and data bit, if it is SPI bus data, the data frame is reorganized according to the identification of chip select signal, clock signal, MOSI data and MISO data, and if it is UART bus data, the byte stream is restored according to the identification of start bit, data bit, check bit and stop bit.

7. The method for time-accurate synchronization in a shared memory based emulator according to claim 1, wherein, Also includes a cross-platform shared memory creation refinement step, in Unix and Unix-like operating systems, the shm_open function is called to create a named shared memory object, the object name, access permission and creation mode are specified, and then the mmap function is called to map the shared memory object to the current process address space; in Windows operating system, the CreateFileMapping function is called to create a file mapping object, the mapping file handle, security attribute, file size high value and low value, mapping name are specified, then the MapViewOfFile function is called to map the file mapping object to the current process address space, and the mapping access permission is set to file mapping read and write.

8. The method for time-accurate synchronization in a shared memory based emulator according to claim 1, wherein, Also includes performance verification refinement steps, timing accuracy verification through FPGA to generate 1 ns period standard clock signal, synchronous trigger sending end timing_count count and receiving end check logic, collect 10000 group sending end timing_count value and receiving end local clock count difference; Transmission delay verification uses 1GS / s sampling rate high precision oscilloscope, collect sending end data write complete signal and receiving end data analysis complete signal time difference; Throughput verification uses 10GB fixed data volume as test benchmark, statistics unit time cross process transmission effective data volume; Stability verification full load continuous operation 72 hours, cumulative transmission data volume is not less than 100GB, statistics data transmission error rate is not more than 10 -6 , process restart 1000 times after handle reuse success rate is 100%.

9. The method for time-accurate synchronization in a shared memory based emulator according to claim 1, wherein, Also includes a handle reuse consistency checking step, when the get_or_create interface queries the cache handle, in addition to checking the consistency of buffer_size and the received capacity parameter, it also checks three key parameters: the layout structure version of the shared memory, the EncodedEntry structure format, and the memory order configuration of atomic operation, and returns the cache handle when they are consistent, if any of them is inconsistent, it is considered as an invalid handle and is deleted, and a shared memory instance that meets the current parameter requirements is created again.

10. The method of claim 1, wherein, Also includes an analog scenario expansion adaptation step, based on the extensible characteristics of EncodedEntry structure, an extension field reserved is added to store custom extension information; The extension get_or_create interface parameter is added with layout configuration parameters and timing accuracy parameters. The layout configuration parameters support adjusting the bit allocation of each field of the EncodedEntry structure. The timing accuracy parameters support setting the mapping ratio of timing_count and hardware clock period, adapting to different precision requirements of the simulator scene from ns level to μs level, while keeping the core lock-free synchronization mechanism and cross-platform management characteristics unchanged.

Images