Joint simulation system and method for heterogeneous multi-core processor

Abstract

The invention relates to the technical field of embedded system development and verification, and discloses a joint simulation system and method for a heterogeneous multi-core processor. The simulation module is configured to execute processor multi-core architecture simulation, multi-core parallel simulation, memory system layered modeling, peripheral and interface simulation and debugging and performance analysis; the programmable logic subsystem simulation module is configured to provide a multi-precision modeling framework and a dynamic reconstruction mechanism, the multi-precision modeling framework comprises a behavior-level model, a register transfer-level model and a hardware-in-the-loop simulation model, and the dynamic reconstruction mechanism supports model hot plugging and parameter adjustment during operation; and the interaction module is configured to execute data interaction, synchronization and joint debugging of the processor subsystem simulation module and the programmable logic subsystem simulation module. The method is suitable for software and hardware collaborative development and verification of the heterogeneous computing platform.

Description

Technical Field

[0001] This invention relates to the field of embedded system development and verification technology, and in particular to a co-simulation system and method for heterogeneous multi-core processors. Background Technology

[0002] The Zynq-7000 series chips are embedded heterogeneous multi-core processors launched by Xilinx (now part of AMD). Their key feature is the integration of a dual-core ARM Cortex-A9 processor (PS part) and FPGA programmable logic (PL part) onto a single chip. The PS part is responsible for running the operating system and applications, while the PL part is used for high-speed parallel processing and hardware acceleration. The two communicate via the AXI (Advanced eXtensible Interface) bus, achieving a combination of high performance and flexibility.

[0003] In traditional Zynq system development processes, software development and hardware design are often separated. Software developers typically have to wait for the hardware design to be completed before they can perform system-level testing, which significantly extends the development cycle. While existing simulation technologies (such as FPGA prototyping and hardware simulators) can partially solve this problem, they usually suffer from high costs, slow speeds, and poor flexibility.

[0004] Existing simulation solutions also have the following obvious drawbacks: (1) In the software simulation scheme, Xilinx provides a customized QEMU version for its Zynq series to simulate the PS part of the Zynq platform and its common peripherals. Although this scheme can simulate the PS part well, it has limited support for the PL part and can only simulate fixed IP cores; SystemC / TLM simulation has a high level of abstraction, but lacks accurate timing simulation capabilities; virtual platform simulation modeling is complex and differs from the behavior of real hardware.

[0005] (2) In the hardware simulation scheme, FPGA prototype verification requires physical hardware support, which is costly and inflexible; hardware simulators are expensive and slow, making them unsuitable for large-scale deployment.

[0006] (3) In the hybrid simulation scheme, the existing collaborative simulation lacks a unified debugging environment, data synchronization is difficult, and performance overhead is large.

[0007] Therefore, there is an urgent need for a solution that can achieve joint simulation of PS and PL, enabling software developers and hardware designers to perform complete system-level verification and debugging before the hardware platform is available. Summary of the Invention

[0008] To address the aforementioned issues, this invention proposes a co-simulation system and method for heterogeneous multi-core processors. It achieves complete system-level simulation by independently simulating the corresponding functions of the programming logic (PL) and interfacing with the simulation system of the power processing system (PS), and provides an efficient PS-PL data exchange mechanism. This invention enables early collaborative development between the PS and PL, supports parallel hardware and software design, provides high-precision AXI bus protocol simulation to ensure simulation accuracy, establishes an efficient co-simulation architecture to reduce simulation performance overhead, constructs a unified debugging environment, and provides complete visualization and analysis capabilities. It also supports multiple PL modeling methods to meet different accuracy and speed requirements.

[0009] The technical solution adopted in this invention is as follows: A co-simulation system for heterogeneous multi-core processors includes: The processor subsystem simulation module is configured to perform processor multi-core architecture simulation, multi-core parallel simulation, memory system hierarchical modeling, peripheral and interface simulation, debugging and performance analysis. The programmable logic subsystem simulation module is configured to provide a multi-precision modeling framework and a dynamic reconfiguration mechanism. The multi-precision modeling framework includes a behavioral-level model, a register-transfer-level model, and a hardware-in-the-loop simulation model. The dynamic reconfiguration mechanism supports hot-swapping of models and adjustment of runtime parameters. The interaction module is configured to perform data interaction, synchronization, and joint debugging between the processor subsystem simulation module and the programmable logic subsystem simulation module.

[0010] Furthermore, in the processor subsystem simulation module: The processor multi-core architecture simulation includes: based on dynamic binary translation technology, converting the binary code of the processor's corresponding instruction set into an intermediate representation, which is then optimized by an optimizer and converted into host instructions by a back-end code generator, while maintaining the consistency of the processor architecture state; The multi-core parallel simulation includes: creating an independent execution context for each processor core, maintaining a synchronization clock between cores, and simultaneously simulating the inter-core interrupt controller and shared memory synchronization primitives.

[0011] Furthermore, in the processor subsystem simulation module: The memory system hierarchical modeling includes: performing multi-level cache architecture simulation to simulate the consistency maintenance and replacement strategies of L1 and L2 caches; simulating memory access timing and bandwidth characteristics through the DDR controller simulation unit; and executing memory mapping and address decoding logic through the address space management unit. The peripheral and interface simulation includes: performing interface simulation through a standard peripheral model, simulating the interrupt channel and priority handling mechanism of a general interrupt controller through an interrupt controller, and performing timing simulation of global timers and private timers through a timer system; The debugging and performance analysis includes: integrating a remote debugging interface to support breakpoint setting, single-step execution, and register viewing; using a performance counter simulation unit to statistically analyze CPU utilization, cache hit rate, and memory access latency; and displaying system status and performance indicators in real time through runtime monitoring.

[0012] Furthermore, in the programmable logic subsystem simulation module: The behavioral-level model is based on the algorithm-level or architecture-level description of the programmable logic subsystem functions written in a high-level programming language, and interacts with the processor subsystem simulation module through a standardized model interface. The register transfer level model integrates an RTL simulation core and interacts with the processor subsystem simulation module through a transaction-level interface or a signal-level co-simulation interface. The hardware-in-the-loop simulation model connects the processor subsystem simulation module to the real programmable logic board via a PCIe or Ethernet interface, and performs the conversion of scalable interface transactions and physical level signals through a hardware proxy unit.

[0013] Furthermore, the interaction module includes: The AXI bus emulation interface is configured to execute the complete AXI protocol stack, simulate the channel handshake mechanism and various burst transmission modes, and perform memory attribute transfer. The collaborative simulation communication layer is configured to use a shared memory communication mechanism, perform data exchange through zero-copy technology, and support network interfaces based on Transmission Control Protocol or User Datagram Protocol for cross-network collaborative simulation. It ensures transaction-level synchronization and timing consistency through a data synchronization mechanism and implements flow control based on a credit mechanism to prevent data loss and overflow. The debugging and tracing system is configured to provide transaction-level debugging capabilities, record and analyze all transactions on the AXI bus, collect and display system performance indicators in real time through the performance monitoring unit, and perform signal-level debugging through the waveform viewer.

[0014] A co-simulation method for heterogeneous multi-core processors includes the following steps: Preparation phase: Construct the processor subsystem simulation module and interaction module, and generate the simulation model corresponding to the programmable logic subsystem and the proxy program required for hardware-in-the-loop interaction; Configuration phase: Configure the processor model startup parameters and the loading path and initialization parameters of the programmable logic subsystem simulation model, and configure the association information of the programmable logic subsystem peripherals in the device tree; Operation phase: Load the processor subsystem model and the programmable logic subsystem simulation model and complete the initialization; intercept the processor's access to the address range of the programmable logic subsystem, convert it into a bus transaction and forward it to the programmable logic subsystem model for processing; and then receive the response data back. Debugging and Analysis Phase: Debug the processor subsystem software, analyze bus transaction data through a transaction tracer, and monitor the system's operating status using a performance analyzer.

[0015] Furthermore, during the preparation phase, if the simulation model of the programmable logic subsystem is a behavioral-level model, it is compiled into a dynamic shared library and a standardized model interface is implemented; if it is a register-transfer-level model, the hardware description language code is compiled into a C++ model using a tool, and then encapsulated into a dynamic library by a standardized model interface wrapper.

[0016] Furthermore, during the configuration phase, the associated information configured in the device tree includes peripheral compatibility identifiers, register address ranges, and interrupt numbers. After configuration, the operating system kernel automatically loads the matching peripheral drivers when it starts up, enabling interaction between the processor subsystem software and the programmable logic subsystem model.

[0017] Furthermore, during the operation phase, the programmable logic subsystem model processes bus transactions through read or write functions of the standardized model interface, and the forwarding, processing, and response processes of bus transactions are transparent to the operating system and application programs on the processor subsystem side.

[0018] Furthermore, during the debugging and analysis phase, the register transfer level model can generate VCD waveform files and analyze the timing details of the signals using a waveform viewer; the system operating status monitored by the performance analyzer includes processor utilization, cache hit rate, and memory bandwidth, as well as the communication throughput between the processor subsystem simulation module and the programmable logic subsystem simulation module.

[0019] The beneficial effects of this invention are as follows: 1) This invention proposes a highly integrated PS-PL co-simulation framework that deeply integrates the hardware simulation model into the software simulator, achieving a seamless hardware and software interaction experience.

[0020] 2) This invention realizes transaction-level AXI bus simulation, which not only simulates the protocol itself, but also optimizes the simulation speed, and reduces the overhead of cross-process communication through mechanisms such as caching and batch processing.

[0021] 3) This invention supports dynamic configuration of PL models through the device tree, allowing different hardware accelerator models to be loaded without modifying the QEMU core code, thus improving the system's flexibility and scalability.

[0022] 4) This invention allows for parallel development and debugging of software and hardware, bringing system integration testing forward; it provides a unified debugging view, enabling developers to quickly locate problems in the PS software, PL logic, or the interaction interface between the two; this invention reduces reliance on physical hardware prototypes, saving hardware costs and laboratory space. Attached Figure Description

[0023] Figure 1 This is a co-simulation system architecture diagram of a heterogeneous multi-core processor according to Embodiment 3 of the present invention.

[0024] Figure 2 This is a schematic diagram of the working principle of the AXI bus interface in Embodiment 3 of the present invention.

[0025] Figure 3 This is a flowchart of a co-simulation method for a heterogeneous multi-core processor according to Embodiment 4 of the present invention. Detailed Implementation

[0026] To provide a clearer understanding of the technical features, objectives, and effects of the present invention, specific embodiments are now described. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention; that is, the described embodiments are only a part of the embodiments of the invention, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0027] Example 1 This embodiment provides a co-simulation system for heterogeneous multi-core processors, characterized in that it includes: The processor subsystem simulation module is configured to perform processor multi-core architecture simulation, multi-core parallel simulation, memory system hierarchical modeling, peripheral and interface simulation, debugging and performance analysis. The programmable logic subsystem simulation module is configured to provide a multi-precision modeling framework and a dynamic reconfiguration mechanism. The multi-precision modeling framework includes a behavioral-level model, a register-transfer-level model, and a hardware-in-the-loop simulation model. The dynamic reconfiguration mechanism supports hot-swapping of models and adjustment of runtime parameters. The interaction module is configured to perform data interaction, synchronization, and joint debugging between the processor subsystem simulation module and the programmable logic subsystem simulation module.

[0028] It should be noted that this co-simulation system, through modular design, covers the core requirements of heterogeneous multi-core processor subsystem simulation. The multi-precision modeling framework can adapt to different simulation precision scenarios, the dynamic reconfiguration mechanism improves the system's flexibility, and the interaction module ensures the synergy between the two subsystems. Overall, it achieves comprehensive, efficient, and flexible co-simulation functions.

[0029] Preferably, in the processor subsystem simulation module: The processor multi-core architecture simulation includes: based on dynamic binary translation technology, converting the binary code of the processor's corresponding instruction set into an intermediate representation, which is then optimized by an optimizer and converted into host instructions by a back-end code generator, while maintaining the consistency of the processor architecture state; Multi-core parallel simulation includes: creating an independent execution context for each processor core, maintaining a synchronous clock between cores, and simulating the inter-core interrupt controller and shared memory synchronization primitives.

[0030] Specifically, during the multi-core processor architecture simulation, a dynamic binary translation engine is first activated to capture the binary code of the target processor's instruction set. This code is then converted into a general intermediate representation format according to preset rules. An optimizer then performs logic and efficiency optimizations on the intermediate representation. Finally, a backend code generator converts the optimized intermediate representation into instructions executable by the current host. Throughout this process, a dedicated state management module synchronizes various state information of the processor architecture in real time to ensure consistency before and after the conversion. During multi-core parallel simulation, each processor core is allocated an independent resource space to create its own execution context. A global clock synchronization module maintains clock consistency across all cores. Simultaneously, an interrupt controller simulation unit and a shared memory synchronization primitive simulation unit are built to simulate inter-core interrupt propagation logic and shared memory access synchronization mechanisms, respectively.

[0031] It should be noted that the architecture simulation based on dynamic binary translation technology can accurately reproduce the instruction execution logic of the target processor, ensuring the accuracy of the architecture simulation; the design of independent execution context and synchronous clock realizes the realistic simulation of multi-core parallel operation, while the simulation of inter-core interrupts and shared memory synchronization ensures the realism of multi-core collaboration scenarios and improves the reliability of multi-core parallel simulation.

[0032] Preferably, in the processor subsystem simulation module: The hierarchical modeling of the memory system includes: performing multi-level cache architecture simulation, implementing consistency maintenance and replacement strategies for L1 and L2 caches; simulating memory access timing and bandwidth characteristics through the DDR controller simulation unit, and executing memory mapping and address decoding logic through the address space management unit; Peripheral and interface simulation includes: performing interface simulation through standard peripheral models, simulating the interrupt channels and priority handling mechanisms of a general interrupt controller through an interrupt controller, and performing timing simulation of global and private timers through a timer system; Debugging and performance analysis include: integrating a remote debugging interface that supports breakpoint setting, single-step execution, and register viewing; using performance counters to simulate CPU utilization, cache hit rate, and memory access latency; and displaying system status and performance metrics in real time through runtime monitoring.

[0033] Specifically, when modeling the memory system in layers, L1 and L2 cache simulation sub-modules are first constructed, embedding the simulation logic of cache coherency protocols and various cache replacement strategies to simulate the cache data consistency maintenance and replacement process; then, a DDR controller simulation unit is deployed to simulate the timing rules and bandwidth limitations of memory access, and an address space management unit is designed to process memory access requests according to preset memory mapping rules and address decoding logic.

[0034] In terms of peripheral and interface simulation, a standard peripheral model library is loaded, and the interface interaction simulation of various peripherals is realized through the built-in interface of the model; a general interrupt controller simulation module is built to simulate the allocation of interrupt channels and the judgment and processing of interrupt priorities; a timer simulation subsystem is constructed to realize the timing generation and triggering simulation of global timers and each core private timer.

[0035] In the debugging and performance analysis section, a standardized remote debugging interface is integrated, and the underlying logic for breakpoint setting, single-step execution, and register viewing is developed; a performance counter simulation unit is designed to collect and statistically analyze key performance parameters such as CPU utilization and cache hit rate in real time; and a runtime monitoring interface is developed to display the system's running status and various performance index data in real time.

[0036] It should be noted that the layered modeling of the memory system can accurately reproduce the real characteristics of multi-level caching and memory access, providing a memory environment that closely resembles actual hardware for simulation; the peripheral and interface simulation covers the core peripheral functions, meeting the simulation requirements for peripheral interaction in heterogeneous systems; and the debugging and performance analysis functions provide users with convenient problem localization methods and comprehensive performance evaluation basis, improving the practicality and operability of the simulation.

[0037] Preferably, in the programmable logic subsystem simulation module: Behavioral-level models are based on algorithm-level or architecture-level descriptions of programmable logic subsystem functions written in high-level programming languages, and interact with processor subsystem simulation modules through standardized model interfaces. The register-transfer-level model integrates an RTL simulation core and interacts with the processor subsystem simulation module through a transaction-level interface or a signal-level co-simulation interface. The hardware-in-the-loop simulation model connects the processor subsystem simulation module to the real programmable logic board via a PCIe or Ethernet interface, and performs the conversion of scalable interface transactions and physical level signals through a hardware proxy unit.

[0038] Specifically, when developing the behavioral-level model, a high-level programming language is used to abstract and describe the core functions of the programmable logic subsystem at the algorithm or architecture level. After writing the code, it is encapsulated according to the standardized model interface specification to ensure that it can interact with the processor subsystem simulation module for data and instruction transmission. When building the register transfer-level model, a mature RTL simulation core is integrated. Based on the interaction requirements, a transaction-level interface or a signal-level co-simulation interface is selected to complete interface adaptation and communication logic development, achieving precise interaction with the processor subsystem simulation module. When building the hardware-in-the-loop simulation model, a physical connection is established between the processor subsystem simulation module and the real programmable logic board through a PCIe or Ethernet interface. Hardware proxy units are deployed, and the conversion logic between interface transactions and physical level signals is developed to ensure effective data transmission between the virtual simulation module and the real hardware.

[0039] It should be noted that the multi-precision modeling framework provides users with simulation options for different precision requirements. Behavioral-level models are suitable for rapid verification, register-transfer-level models ensure simulation accuracy, and hardware-in-the-loop models realize the combination of virtual and real hardware. The design of standardized and adaptable interfaces ensures smooth interaction between various models and processor subsystem simulation modules, improving the system's compatibility and scalability.

[0040] Preferably, the interaction module includes: The AXI bus emulation interface is configured to execute the complete AXI protocol stack, simulate the channel handshake mechanism and various burst transmission modes, and perform memory attribute transfer. The collaborative simulation communication layer is configured to use a shared memory communication mechanism, perform data exchange through zero-copy technology, and support network interfaces based on Transmission Control Protocol or User Datagram Protocol for cross-network collaborative simulation. It ensures transaction-level synchronization and timing consistency through a data synchronization mechanism and implements flow control based on a credit mechanism to prevent data loss and overflow. The debugging and tracing system is configured to provide transaction-level debugging capabilities, record and analyze all transactions on the AXI bus, collect and display system performance indicators in real time through the performance monitoring unit, and perform signal-level debugging through the waveform viewer.

[0041] Specifically, during the development of the AXI bus simulation interface, a complete AXI protocol stack logic is embedded to simulate the implementation process of the AXI bus channel handshake mechanism and various burst transmission modes. Simultaneously, memory attribute transfer logic is designed to ensure the accurate transmission of memory attribute information during bus transmission. In the construction of the co-simulation communication layer, shared memory is used as the core communication carrier, integrating zero-copy technology to reduce data copy overhead and improve data exchange efficiency. It also adapts to network interfaces of Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), developing cross-network communication logic. A data synchronization mechanism is designed, ensuring transaction-level synchronization and timing consistency through timing calibration and transaction alignment. A credit mechanism is introduced to dynamically adjust the transmission rate based on the data transmission status, achieving flow control. During the development of the debugging and tracing system, a transaction recording module is deployed to capture and store all transaction data on the AXI bus, providing transaction analysis tools. A performance monitoring unit is built to collect and visualize various performance indicators of the system in real time. A waveform viewer is integrated, supporting signal-level data parsing and debugging operations.

[0042] It should be noted that the AXI bus simulation interface ensures the standardization and compatibility of bus transmission, providing a standard channel for data interaction between the two subsystems; the co-simulation communication layer achieves fast and stable data transmission through efficient communication technology and synchronization and flow control mechanisms, supports cross-network deployment, and improves system flexibility; the debugging and tracing system provides comprehensive debugging capabilities from the transaction level to the signal level, making it easier for users to locate problems and ensuring the smooth progress of simulation.

[0043] Example 2 This embodiment is based on embodiment 1: This embodiment provides a co-simulation method for heterogeneous multi-core processors, including: Preparation phase: Construct the processor subsystem simulation module and interaction module, and generate the simulation model corresponding to the programmable logic subsystem and the proxy program required for hardware-in-the-loop interaction; Configuration phase: Configure the processor model startup parameters and the loading path and initialization parameters of the programmable logic subsystem simulation model, and configure the association information of the programmable logic subsystem peripherals in the device tree; Operation phase: Load the processor subsystem model and the programmable logic subsystem simulation model and complete the initialization; intercept the processor's access to the address range of the programmable logic subsystem, convert it into a bus transaction and forward it to the programmable logic subsystem model for processing; and then receive the response data back. Debugging and Analysis Phase: Debug the processor subsystem software, analyze bus transaction data through a transaction tracer, and monitor the system's operating status using a performance analyzer.

[0044] It should be noted that this co-simulation method, through phased process design, makes the co-simulation process logically clear and the steps well-defined, facilitating operation and control. The core operations of each phase revolve around the collaborative work of the two subsystems, ensuring the continuity and effectiveness of the simulation. The design of the debugging and analysis phase provides strong support for the verification of simulation results and system optimization, improving the reliability and practicality of the simulation.

[0045] Preferably, during the preparation phase, if the simulation model of the programmable logic subsystem is a behavioral-level model, it is compiled into a dynamic shared library and a standardized model interface is implemented; if it is a register-transfer-level model, the hardware description language code is compiled into a C++ model using a tool, and then encapsulated into a dynamic library by a standardized model interface wrapper.

[0046] Specifically, during the preparation phase of processing the simulation model of the programmable logic subsystem, the model type is first determined: if it is a behavioral-level model, the corresponding compiler is used to compile the model source code into a dynamic shared library format. At the same time, interface functions and data interaction logic are developed according to the standardized model interface specifications to ensure that the dynamic shared library can interact with other modules of the system. If it is a register-transfer level model, a special tool is first used to convert the model code written in the hardware description language into a C++ model file. Then, the C++ model is encapsulated through a standardized model interface wrapper to finally generate a dynamic library file that meets the system requirements.

[0047] It should be noted that by standardizing the simulation models of different types of programmable logic subsystems, the interface format and file type of the models have been unified, ensuring that various models can be seamlessly integrated into the joint simulation system, improving the compatibility of the models and the scalability of the system, while simplifying the loading and calling process of the models.

[0048] Preferably, during the configuration phase, the associated information of the device tree configuration includes peripheral compatibility identifiers, register address ranges, and interrupt numbers. After configuration, the operating system kernel automatically loads the matching peripheral drivers when it starts up, enabling interaction between the processor subsystem software and the programmable logic subsystem model.

[0049] Specifically, during the device tree configuration phase, the compatibility identifiers of the programmable logic subsystem peripherals are entered into the device tree file according to the system's agreed format and specifications. This is used by the operating system to identify the peripheral types. The register address range corresponding to the peripheral is specified, and the memory access area of ​​the peripheral is defined. A unique interrupt number is assigned, and the association between the peripheral and the interrupt controller is established. After the configuration is completed, when the operating system kernel starts, it will scan the association information in the device tree, match the corresponding peripheral driver according to the compatibility identifier, and load it automatically, thereby establishing a communication link between the processor subsystem software and the programmable logic subsystem model.

[0050] It should be noted that configuring peripheral association information through the device tree enables automatic loading of peripheral drivers without manual intervention, simplifying the system configuration process. At the same time, it ensures that the processor subsystem software can accurately identify and access the peripheral model of the programmable logic subsystem, guaranteeing the smoothness and accuracy of software and hardware interaction.

[0051] Preferably, during the runtime phase, the programmable logic subsystem model processes bus transactions through read or write functions of the standardized model interface, and the forwarding, processing, and response processes of bus transactions are transparent to the operating system and application programs on the processor subsystem side.

[0052] Specifically, during the runtime phase, after a bus transaction is forwarded to the programmable logic subsystem model, the model calls the corresponding read or write function in the standardized model interface according to the transaction type (read transaction or write transaction) to process the transaction data and perform corresponding logical operations or data storage operations. Throughout the entire process of bus transaction forwarding, model processing, and response data return, the encapsulation and isolation design of the underlying logic prevents the operating system and application on the processor subsystem from being aware of the specific implementation details of the process. They only need to initiate requests and receive results according to normal hardware access logic.

[0053] It should be noted that the use of standardized interface read and write functions to handle bus transactions ensures the standardization and consistency of transaction processing; the transparent design of the transaction process means that the software on the processor subsystem side does not need to be specially adapted for the simulation environment, reducing software development and debugging costs, while improving the realism and versatility of the simulation environment.

[0054] Preferably, during the debugging and analysis phase, the register transfer level model can generate VCD waveform files and analyze the timing details of the signals using a waveform viewer; the system operating status monitored by the performance analyzer includes processor utilization, cache hit rate and memory bandwidth, as well as the communication throughput between the processor subsystem simulation module and the programmable logic subsystem simulation module.

[0055] Specifically, during the debugging and analysis phase, if a register-transfer level model is used for simulation, the model will generate a VCD waveform file containing signal timing information according to preset logging rules during operation. Users can open this file through the system-integrated waveform viewer to view the timing details of various signals and analyze the accuracy of signal interactions. Simultaneously, a performance analyzer is activated. This instrument collects core performance parameters such as processor utilization, cache hit rate, and memory bandwidth in real time through interfaces with various system modules, as well as communication throughput data between the two subsystem simulation modules. After organizing and statistically analyzing the data, it is presented to the user in a visual manner.

[0056] It should be noted that the combination of VCD waveform files and waveform viewers provides refined timing analysis tools for register transfer level simulation, making it easier for users to discover signal timing issues; the multi-dimensional performance parameters monitored by the performance analyzer comprehensively reflect the system's operating status and interaction efficiency, providing comprehensive data support for users to evaluate system performance and locate performance bottlenecks, thus assisting in the optimization and improvement of the simulation system.

[0057] Example 3 like Figure 1 As shown, this embodiment provides a co-simulation system for heterogeneous multi-core processors, which adopts a layered architecture design and mainly includes the following core components: 1.1 PS Simulation Subsystem The PS simulation subsystem is implemented as a full-system CPU simulator based on software, specifically including: 1) Accurate Simulation of ARM Multi-core Architecture: This technology employs dynamic binary translation to achieve accurate functional simulation of a dual-core ARM Cortex-A9 processor. The technology uses a front-end decoder to convert the binary code of the ARMv7-A instruction set into an intermediate representation. After basic block optimization by the optimizer, the back-end code generator converts it into host instructions, while maintaining the consistency of the ARM architecture state.

[0058] 2) Multi-core parallel simulation: True parallel execution is achieved by creating an independent execution context for each CPU core. The system maintains inter-core synchronization clocks to ensure timing consistency, while also achieving accurate simulation of inter-core interrupt controllers and shared memory synchronization primitives.

[0059] 3) Layered modeling of the memory system: Includes simulation of a multi-level cache architecture, simulating consistency maintenance and replacement strategies for L1 and L2 caches. The DDR controller simulation module accurately simulates memory access timing and bandwidth characteristics, and the address space management module fully implements the memory mapping and address decoding logic of the Zynq-7045.

[0060] 4) Virtual Implementation of Peripherals and Interfaces: This includes a standard peripheral model, an interrupt controller, and a timer system. The standard peripheral model implements accurate simulation of interfaces such as UART, GPIO, SPI, and I2C; the interrupt controller simulates the 128 interrupt channels and priority handling mechanism of a general interrupt controller; and the timer system implements accurate timing simulation of global and private timers.

[0061] 5) Debugging and Performance Analysis Module: Integrates the GDB remote debugging interface, supporting breakpoint setting, single-step execution, and register viewing. The performance counter simulation unit tracks CPU utilization, cache hit rate, and memory access latency, while runtime monitoring displays system status and performance metrics in real time.

[0062] 1.2 PL Simulation Subsystem The PL simulation subsystem implements an innovative architecture that includes a multi-precision modeling framework, a dynamic reconstruction mechanism, and intelligent resource allocation management, solving the problems of difficult modeling of the PL part and the difficulty of seamless integration with the PS simulation environment in the traditional simulation process.

[0063] 1.2.1 Multi-Fidelity Modeling Framework The PL simulation subsystem designed in this embodiment does not employ a single modeling approach, but rather provides a flexible and scalable multi-precision modeling framework to adapt to the entire development process from algorithm verification to gate-level timing analysis. Specifically, it includes three core modeling methods: a) Behavioral Model Implementation: High-level programming languages ​​(such as C / C++ / SystemC / TLM-2.0) are used to describe the hardware functions of the PL section at the algorithm or architecture level. This model interacts with the PS simulation subsystem through the standardized model interface defined in this invention.

[0064] Technical advantages: This model focuses entirely on functional correctness, abstracting away specific timing and circuit details, thus achieving extremely high simulation execution speed. It is particularly suitable for software developers in the early stages of driver development and application testing, or for hardware designers for algorithm exploration and architecture verification.

[0065] b) RTL Model Implementation: This method allows users to directly integrate existing RTL code (Verilog / VHDL) into the simulation environment. This is achieved by integrating a high-performance RTL simulation core (such as Verilator, VCS®'s PLI interface, or ICARUS Verilog). This simulation core, as a standalone compilation module, enables efficient and accurate data exchange with QEMU through the transaction-level interface or signal-level co-simulation interface implemented in this invention.

[0066] Technical advantages: This model provides cycle-accurate or signal-accurate simulation capabilities, accurately reflecting the timing behavior, state machine transitions, and internal register states of the hardware design. It is ideal for hardware designers to perform functional verification, performance evaluation, and deep debugging, ensuring a high degree of consistency between the simulation results and the behavior of the final bitstream burned onto the actual FPGA.

[0067] c) Hardware-in-the-Loop Simulation Implementation: This is the highest precision simulation mode supported by this system. The system connects the PS (Physical Signal Processor) portion of the simulation environment to the PL (Physical Platform) portion of the actual physical FPGA board simulation via high-speed interfaces such as PCIe or Ethernet. AXI transactions generated by the PS simulation subsystem (QEMU) are converted into actual physical level signals through a dedicated hardware proxy module and sent to the FPGA development board; conversely, the FPGA's response signals are also captured and transmitted back to the simulation environment.

[0068] Technical advantages: This mode fully incorporates unpredictable physical effects and the timing of real interfaces into the simulation loop, providing unparalleled simulation accuracy and realism. It is particularly suitable for verifying interfaces with extreme timing requirements (such as high-speed ADC / DAC, SDRAM controllers) and for the final system performance calibration.

[0069] 1.2.2 Dynamic Reconfiguration Mechanism This embodiment introduces the concept of Dynamic Partial Reconfiguration in the simulation environment, enabling flexible switching and adjustment of the PL model and greatly improving debugging efficiency.

[0070] Hot-swapping of models: Users can dynamically load, unload, or replace different PL models at runtime (e.g., switching from a behavioral-level model to an RTL-level model, or changing different algorithm IP cores) without stopping the entire simulation. This is achieved by maintaining a model registry and utilizing the dynamic linking capabilities of the operating system (such as the dynamic library loading mechanism of the Linux kernel).

[0071] Runtime Parameter Adjustment: Supports real-time modification of internal parameters of the PL model (such as filter coefficients, FIFO depth, clock division ratio, etc.) during runtime through the debugging interface of the simulation environment, and immediately observes the changes in system behavior, which greatly facilitates parameter optimization.

[0072] 1.3 PS and PL subsystem interaction design The PS-PL subsystem interaction design includes three key components: 1) AXI Bus Emulation Interface: Implements the complete AXI4 protocol stack, supporting AXI4-Lite, AXI4-Stream, and AXI4-Full protocols. This interface accurately simulates the channel handshake mechanism, supports multiple burst transmission modes, and implements memory attribute passing functionality. For example... Figure 2 The diagram illustrates the working principle of the AXI bus interface, detailing the timing and signal processing flow for read and write operations.

[0073] 2) Cooperative Simulation Communication Layer: Employs a shared memory communication mechanism, achieving high-speed data exchange through zero-copy technology. The Socket interface supports TCP / UDP protocols for cross-network cooperative simulation, a data synchronization mechanism ensures transaction-level synchronization and timing consistency, and flow control based on a credit mechanism prevents data loss and overflow.

[0074] 3) Debugging and Tracing System: Provides transaction-level debugging capabilities, recording and analyzing all transactions on the AXI bus. The performance monitoring unit collects and displays system performance indicators in real time, the waveform viewer integrates support for signal-level debugging, and the cross-triggered mechanism supports synchronous debugging between PS and PL.

[0075] Example 4 This embodiment is based on embodiment 3: like Figure 3 As shown, this embodiment provides a co-simulation method for heterogeneous multi-core processors, specifically including the following steps: 1) Preparation stage: This stage aims to prepare all the software and model components required for the simulation environment: Compile the corresponding software simulation subsystem for PS, and integrate and compile the AXI bus simulation interface, co-simulation communication layer, and debug tracing module to build a complete enhanced simulation platform.

[0076] PL Model Preparation (Multi-Precision Model Generation): Based on the development stage and precision requirements, select one or more of the following methods to generate a simulation model for the user-defined PL logic: Behavioral-level model: Write the algorithmic model for the PL functionality using C / C++ or SystemC / TLM-2.0, and compile it into a dynamic shared library (.so file). This library must implement the Standardized Model Interface (SMI) defined in this invention.

[0077] RTL-level model: Use tools such as Verilator to compile the user-provided Verilog / VHDL RTL code into a C++ model, and also use an SMI wrapper to encapsulate it into a dynamic library that conforms to the SMI standard.

[0078] Hardware-in-the-loop interface: Compiles the agent program (Client) and its corresponding SMI dynamic library for communication with the actual FPGA board. This library is responsible for forwarding transactions to the physical hardware via the network or PCIe.

[0079] 2) Configuration phase: This stage uses configuration files and command-line parameters to assemble the prepared components into a complete virtual target system.

[0080] CPU model startup parameter configuration: Start the Zynq-7045 platform using the basic configuration, and use custom command line parameters to dynamically specify the PL model library path and initialization parameters to be loaded.

[0081] Device tree configuration: In the device tree (.dts file), corresponding nodes are created for virtual PL peripherals, containing information such as the compatibility string (compatible), register address range (reg), and interrupt number (interrupts). During Linux kernel startup, the matching driver is automatically loaded based on the device tree description, allowing the PS-side software to interact with the PL model in the simulation environment through standard address mapping and interrupt mechanisms, just like operating real hardware.

[0082] 3) Operation phase: At this stage, joint simulation is initiated, and system operation is observed.

[0083] System startup: Based on the configuration, first load the PS model (ARM CPU, memory, etc.), then dynamically load (dlopen) the specified PL model library, and call its initialization entry function for initialization.

[0084] Cooperative simulation operation: The AXI bus monitoring module inside the PS emulation subsystem begins operation. When the simulated CPU accesses the PL address range defined in the device tree, the AXI bus emulation interface intercepts the access.

[0085] The interface converts memory access into AXI transactions and forwards them to the PL model end through the co-simulation communication layer (shared memory or Socket).

[0086] The SMI interface on the PL model side receives transactions, calls the internal smi_read or smi_write function for processing, and returns the response data to the PS subsystem along the same path. The entire process is transparent to the operating system and applications running on the PS subsystem.

[0087] 4) Debugging and Analysis Phase: This stage utilizes an integrated, unified debugging environment for problem localization and performance analysis.

[0088] Software debugging: Developers can use GDB to connect to the debugging port of the PS subsystem to perform source code-level debugging of Linux applications, kernel modules, and even the kernel itself running on the PS side, including setting breakpoints, single-stepping, and viewing variables and memory.

[0089] Hardware Behavior Analysis: Developers can enable the built-in transaction tracker to capture and display all read and write transactions via the AXI bus in real time, analyzing access patterns, latency, and potential errors. For RTL-level models, VCD waveform files can be generated, and the timing details of the signals can be analyzed in waveform viewers such as GTKWave.

[0090] System-level performance profiling: Utilize performance analyzers to monitor the overall system operation status, including CPU utilization, cache hit rate, memory bandwidth, and communication throughput between PS and PL, thereby accurately locating performance bottlenecks.

[0091] Preferably, the dynamic model loading mechanism defines a standard model operation interface, including initialization, read / write, and interrupt callback functions. The shared library loader uses a dynamic link library mechanism to load the PL model, symbol resolution ensures the correct acquisition of model operation function pointers, and error handling provides detailed error information and recovery mechanisms.

[0092] Preferably, AXI transaction processing optimization employs a batch processing mechanism, aggregating multiple transactions into a single transmission to reduce communication overhead. Cache optimization uses a prefetch mechanism to predictively read potentially accessed data, and consistency maintenance ensures cache consistency in the simulation environment.

[0093] Preferably, the timing synchronization algorithm implements multiple synchronization modes: lockstep synchronization ensures that PS and PL are executed in strict synchronization; event-driven synchronization synchronizes when a specific event occurs; optimistic synchronization allows for a certain degree of desynchronization and performs rollback and resynchronization when needed.

[0094] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

[0095] It should be noted that, for the sake of simplicity, the foregoing method embodiments are described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

Claims

1. A co-simulation system for heterogeneous multi-core processors, characterized in that, include: The processor subsystem simulation module is configured to perform processor multi-core architecture simulation, multi-core parallel simulation, memory system hierarchical modeling, peripheral and interface simulation, debugging and performance analysis. The programmable logic subsystem simulation module is configured to provide a multi-precision modeling framework and a dynamic reconfiguration mechanism. The multi-precision modeling framework includes a behavioral-level model, a register-transfer-level model, and a hardware-in-the-loop simulation model. The dynamic reconfiguration mechanism supports hot-swapping of models and adjustment of runtime parameters. The interaction module is configured to perform data interaction, synchronization, and joint debugging between the processor subsystem simulation module and the programmable logic subsystem simulation module.

2. The co-simulation system for heterogeneous multi-core processors according to claim 1, characterized in that, In the processor subsystem simulation module: The processor multi-core architecture simulation includes: based on dynamic binary translation technology, converting the binary code of the processor's corresponding instruction set into an intermediate representation, which is then optimized by an optimizer and converted into host instructions by a back-end code generator, while maintaining the consistency of the processor architecture state; The multi-core parallel simulation includes: creating an independent execution context for each processor core, maintaining a synchronization clock between cores, and simultaneously simulating the inter-core interrupt controller and shared memory synchronization primitives.

3. The co-simulation system for heterogeneous multi-core processors according to claim 1, characterized in that, In the processor subsystem simulation module: The memory system hierarchical modeling includes: performing multi-level cache architecture simulation to simulate the consistency maintenance and replacement strategies of L1 and L2 caches; simulating memory access timing and bandwidth characteristics through the DDR controller simulation unit; and executing memory mapping and address decoding logic through the address space management unit. The peripheral and interface simulation includes: performing interface simulation through a standard peripheral model, simulating the interrupt channel and priority handling mechanism of a general interrupt controller through an interrupt controller, and performing timing simulation of global timers and private timers through a timer system; The debugging and performance analysis includes: integrating a remote debugging interface to support breakpoint setting, single-step execution, and register viewing; using a performance counter simulation unit to statistically analyze CPU utilization, cache hit rate, and memory access latency; and displaying system status and performance indicators in real time through runtime monitoring.

4. The co-simulation system for heterogeneous multi-core processors according to claim 1, characterized in that, In the programmable logic subsystem simulation module: The behavioral-level model is based on the algorithm-level or architecture-level description of the programmable logic subsystem functions written in a high-level programming language, and interacts with the processor subsystem simulation module through a standardized model interface. The register transfer level model integrates an RTL simulation core and interacts with the processor subsystem simulation module through a transaction-level interface or a signal-level co-simulation interface. The hardware-in-the-loop simulation model connects the processor subsystem simulation module to the real programmable logic board via a PCIe or Ethernet interface, and performs the conversion of scalable interface transactions and physical level signals through a hardware proxy unit.

5. The co-simulation system for heterogeneous multi-core processors according to claim 1, characterized in that, The interaction module includes: The AXI bus emulation interface is configured to execute the complete AXI protocol stack, simulate the channel handshake mechanism and various burst transmission modes, and perform memory attribute transfer. The collaborative simulation communication layer is configured to use a shared memory communication mechanism, perform data exchange through zero-copy technology, and support network interfaces based on Transmission Control Protocol or User Datagram Protocol for cross-network collaborative simulation. It ensures transaction-level synchronization and timing consistency through a data synchronization mechanism and implements flow control based on a credit mechanism to prevent data loss and overflow. The debugging and tracing system is configured to provide transaction-level debugging capabilities, record and analyze all transactions on the AXI bus, collect and display system performance indicators in real time through the performance monitoring unit, and perform signal-level debugging through the waveform viewer.

6. A co-simulation method for heterogeneous multi-core processors, based on the co-simulation system as described in claim 1, characterized in that, The co-simulation method includes the following steps: Preparation phase: Construct the processor subsystem simulation module and interaction module, and generate the simulation model corresponding to the programmable logic subsystem and the proxy program required for hardware-in-the-loop interaction; Configuration phase: Configure the processor model startup parameters and the loading path and initialization parameters of the programmable logic subsystem simulation model, and configure the association information of the programmable logic subsystem peripherals in the device tree; Operation phase: Load the processor subsystem model and the programmable logic subsystem simulation model and complete the initialization; intercept the processor's access to the address range of the programmable logic subsystem, convert it into a bus transaction and forward it to the programmable logic subsystem model for processing; and then receive the response data back. Debugging and Analysis Phase: Debug the processor subsystem software, analyze bus transaction data through a transaction tracer, and monitor the system's operating status using a performance analyzer.

7. The co-simulation method for heterogeneous multi-core processors according to claim 6, characterized in that, During the preparation phase, if the simulation model of the programmable logic subsystem is a behavioral-level model, it is compiled into a dynamic shared library and a standardized model interface is implemented; if it is a register-transfer-level model, the hardware description language code is compiled into a C++ model using a tool, and then encapsulated into a dynamic library by a standardized model interface wrapper.

8. The co-simulation method for heterogeneous multi-core processors according to claim 6, characterized in that, During the configuration phase, the associated information configured in the device tree includes peripheral compatibility identifiers, register address ranges, and interrupt numbers. After configuration, the operating system kernel automatically loads the matching peripheral drivers when it starts up, enabling interaction between the processor subsystem software and the programmable logic subsystem model.

9. The co-simulation method for heterogeneous multi-core processors according to claim 6, characterized in that, During the runtime phase, the programmable logic subsystem model processes bus transactions through read or write functions of the standardized model interface, and the forwarding, processing, and response processes of bus transactions are transparent to the operating system and application programs on the processor subsystem side.

10. The co-simulation method for heterogeneous multi-core processors according to claim 6, characterized in that, During the debugging and analysis phase, the register-transfer level model can generate VCD waveform files and analyze the timing details of signals using a waveform viewer; the system operating status monitored by the performance analyzer includes processor utilization, cache hit rate, and memory bandwidth, as well as the communication throughput between the processor subsystem simulation module and the programmable logic subsystem simulation module.

Images