A hardware-software co-simulation platform for processor chip architecture verification

Abstract

The application belongs to the technical field of integrated circuits, and particularly relates to a software and hardware joint simulation platform for processor chip architecture verification. The software and hardware joint simulation platform is an architecture crossing hardware and software; the software part comprises a scheduling module, a submission module, an acquisition module, an execution task table and four annular lock-free queues; the hardware part comprises a data packet preprocessing module, a signal conversion module and two queues. The simulation platform adopts a parallel simulation form of a software simulator and hardware FPGA, simplifies a traditional development process, and allows a hardware core module to directly and cooperatively simulate a software simulated processor chip. The software simulated processor chip can directly provide a real test environment for the hardware core and has rapid simulation capability, thereby improving the integration efficiency of a newly developed or iterated hardware core module in an existing large-scale processor chip.

Description

Technical Field

[0001] The present invention belongs to the technical field of integrated circuit design, and in particular relates to a software-hardware co-simulation platform for processor chip architecture verification. Background Art

[0002] With the rapid development and increasing diversity of upper-layer application workloads, processor chips, as the foundation for supporting the computing power requirements of these applications, also require timely updates to their chip architectures to match these demands. Simulation verification of advanced architecture design solutions is a key enabler for rapid iteration and updates of processor chip architectures. The traditional processor chip architecture development process encompasses several steps, including electronic-level system software simulation and hardware simulation. Specifically, engineers first build a software model on an electronic-level system software simulation platform for verification and architectural exploration. Then, the model is implemented in hardware and verified using test stimuli. Finally, the hardware model is embedded in a hardware-based processor chip architecture verification platform for debugging. Electronic-level system software simulation simulators provide high-level modeling, making them suitable for the early stages of architectural exploration. However, their simulation results may differ from actual hardware simulations, such as pipeline details and resource contention. The primary purpose of hardware simulation is to ensure the feasibility and reliability of the architecture. This process is lengthy and carries significant verification overhead. If verification results do not meet expectations, the design must be revised back to an earlier stage. Therefore, there is an urgent need to optimize the traditional processor chip architecture development and verification process, break through the barriers between software simulation and hardware simulation, and integrate and simplify the various stages of chip architecture development and verification to meet the actual needs of rapidly iterating processor chip architecture. Summary of the Invention

[0003] The purpose of the present invention is to provide a high-performance, highly flexible, and highly compatible software-hardware co-simulation platform for processor chip architecture verification.

[0004] The software and hardware joint simulation platform (referred to as simulation platform) for processor chip architecture verification proposed in the present invention can be directly applied to the design, development and verification process of high-performance processor architecture, simplify the design, development and verification process of the chip, and improve the research and development efficiency of the chip architecture. The basic implementation method of the software and hardware joint simulation platform of the present invention is that the software simulator simulates a complete processor chip, and the hardware FPGA simulates a newly developed or to-be-evaluated core module; the simulation platform is responsible for the seamless communication between the software simulator and the hardware FPGA, and is responsible for forwarding the access request of the processor chip simulated on the software simulator to the core module to the core module running on the FPGA, and also feeds back the request or response generated by the core module to the processor chip; each core module has a corresponding virtual module in the software simulator, and the simulated processor chip will interact with the virtual module normally. When the virtual module receives the request, it submits it to the simulation platform proposed in the present invention. Therefore, the software and hardware joint simulation platform proposed in the present invention is an architecture that spans hardware and software. The software part of the architecture includes a scheduling module, a submission module, an acquisition module, an execution task table and 4 circular lock-free queues, and the hardware part includes a data packet preprocessing module, a signal conversion module and 2 circular lock-free queues; wherein:

[0005] The execution task table records the detailed information of the requests received by the simulation platform;

[0006] The scheduling module is responsible for receiving access requests from the software emulator to the core module, applying for corresponding entries in the execution task table based on the type of request, and configuring the submission module and acquisition module to start responding. For requests that do not require a response, the scheduling module only needs to configure the submission module to execute the transfer of the request to the hardware FPGA. For requests that require a response, the scheduling module needs to configure both the submission module and the acquisition module. There are two options for configuring the acquisition module: one is the polling mode, which means that after the submission module transfers the request, the acquisition module needs to continuously send requests to the hardware FPGA to query the hardware execution results; the other mode is the interrupt mode, which means that when the hardware FPGA completes the execution, it will notify the acquisition module, and the acquisition module will initiate a request to obtain the execution results. The scheduling module interacts with the submission module and the acquisition module through two circular lock-free queues.

[0007] The submission module is responsible for transforming the requests prepared by the scheduling module into data packets that comply with the communication protocol standards for transmission. When modifying the data packets, the submission module supports merging multiple requests into a single transmission to offset significant communication costs. Specifically, if the submission module detects that there are more than one request waiting to be transmitted in the circular lock-free queue before executing the next submission, it can merge the multiple requests and add an additional data packet header to these requests, indicating the number and type of requests merged into the current data packet.

[0008] The acquisition module is responsible for obtaining the execution results of the hardware core module from the hardware FPGA. When the scheduling module informs the acquisition module that it needs to track the response to a request, the acquisition module will start to operate. The acquisition module supports two modes, namely polling mode and interrupt mode, which correspond to the way the acquisition module obtains the hardware execution results. The polling mode requires the acquisition module to continuously initiate requests to obtain the execution request results in order to finally obtain the data, while the interrupt result is responsible for informing the acquisition module by the hardware to retrieve the hardware execution results. The two modes are suitable for different scenarios, among which the polling mode is suitable for application scenarios that are sensitive to simulation time, and the interrupt mode is suitable for scenarios with high tolerance for simulation time.

[0009] The packet preprocessing module is responsible for receiving, reassembling, and parsing packets, as well as collecting, segmenting, and sending them. Due to bandwidth limitations of the communication protocol, communications between the software emulator and the hardware emulator may be split into several packets for transmission. The packet preprocessing module is responsible for receiving these fragmented packets. After collecting all the packets, it sorts and reassembles them. After restoring the original packets, it decodes the header and separates the requests within the packets based on the header information. Each separate request is queued to notify the signal conversion module for the next stage of processing. The packet preprocessing module is also responsible for sending packets. The results of the hardware core module's execution are continuously sent to the packet preprocessing module, which then collects and organizes these results. The packet preprocessing module performs different actions depending on the configuration of the acquisition module. When the acquisition module is in polling mode, the packet preprocessing module waits until the acquisition module initiates the next polling request, packages the currently collected core module execution results, modifies the packet header, and sends them. When the acquisition module is in interrupt mode, the data packet preprocessing module immediately notifies the acquisition module to retrieve the hardware execution result after collecting the execution result of the core module.

[0010] The signal conversion module is responsible for parsing the request from the software simulator, configuring the input signal of the core hardware module, collecting the output signal of the core hardware module, and assembling it into a response that is recognizable by the software simulator. When assembling the response, certain hardware execution information will be added, such as the number of execution clock cycles of the core module. The signal conversion module is one of the cores of the software and hardware joint simulation platform proposed in the present invention with extremely high compatibility. Any core module that requires hardware simulation is decoupled from the software and hardware joint simulation platform proposed in the present invention through the signal conversion module. The signal conversion module obtains requests and sends responses from two queues connected to the data packet preprocessing module respectively.

[0011] In this invention, the software-side architecture is responsible for transforming the software emulator's module requests into data packets that conform to the communication protocol and sending them to the hardware FPGA. The software-side framework consists of an execution task table, four circular lock-free queues, a scheduling module, a submission module, and a collection module. The execution task table records the detailed information of requests received by the platform, while the scheduling module is responsible for analyzing, modifying, and resolving the software emulator's requests. The submission module is responsible for sending the requests assembled by the scheduling module to the hardware FPGA. Similarly, the collection module is solely responsible for obtaining information from the hardware FPGA required for interaction with the processor chip. Once the software emulator initiates a request to the hardware core module, simulation can continue normally. The subsequent process is handled by the hardware-software co-simulation platform proposed in this invention. This platform first requests an entry from the execution task table to execute a fill request and then inserts the entry sequence number into the task queue. The scheduling module then accesses the execution task table based on the retrieved entry sequence number from the task queue and analyzes the characteristics of the request. For example, an inference request from the artificial intelligence engine must contain the information required for inference and also retrieve the inference results from the RTL module. After assembling the request and inserting it into the pre-submission queue, the scheduling module configures the collection module to initiate a request for a response. Upon receiving the response, the collection module populates the result with the corresponding entry in the execution task table and inserts the entry's sequence number into the post-collection queue. The scheduling module then modifies the ready entry into a response that meets the simulator's standards and inserts it into the results. After a certain delay, the simulator retrieves the response.

[0012] In the present invention, the hardware-side architecture is implemented in hardware and connected to the core hardware model before being deployed on the FPGA. The simulation platform first parses the data packets received by the FPGA. Because the data bit width of the software simulator's request or response to the hardware core module may exceed the upper limit of the bit width supported by the communication protocol, a data packet preprocessing module is required to collect and reassemble several data packets, parse them into the initial request or response initiated by the software simulator, and insert them into the task queue. Each entry in this queue consists of a task header and a payload. The former is essential information for maintaining the operation of the hardware-software co-simulation platform, such as the entry number of the request or response in the execution task table of the software-side architecture, and the latter is the actual request or response. The signal conversion module of the hardware-side framework is directly connected to the hardware core module. It receives tasks from the task queue and configures the hardware core module's input based on the task payload information. It also records the time when the hardware core module responds and the hardware core module's output, assembling the data packets into data packets before inserting them into the result queue. The data preprocessing module then splits the data packets into several packets based on the communication protocol configuration and transmits them to the software side of the co-simulation platform.

[0013] In the present invention, the simulation platform adopts an optimistic synchronization mechanism to solve the problem of large differences in simulation speed between software emulators and hardware emulators. When the software emulator initiates a request to the core hardware module, the software emulator will wait in place until the co-simulation platform obtains a response and the number of clock cycles executed from the hardware core module. The software emulator will then schedule an event after X clock cycles, which simulates the behavior of the hardware core module responding. At the same time, when receiving a request from the software emulator, the co-simulation platform will schedule an event after Y clock cycles. Y clock cycles is an estimate of the shortest execution time of the hardware core module, which means that the software emulator can continue to simulate Y clock cycles without risk after initiating the request. If the software and hardware co-simulation platform can return the response of the hardware core module within the time of the software emulator simulating these Y clock cycles, then the software emulator can simulate without interruption. Otherwise, the software emulator will wait in place after Y clock cycles until it obtains a response. After receiving the response, the software emulator reschedules the event to occur after (XY) cycles, thereby formally accepting the response. For hardware core modules capable of proactively initiating requests, the hardware-software co-simulation platform continuously inquires about the hardware core module's request status. When a hardware core module initiates a request to the processor chip, it optimistically continues executing for the expected number of clock cycles. At this point, the software simulator receives two time information points: the first time point at which it must process the hardware core module's request, and the second time point at which the hardware core model estimates the next proactive request under the worst-case scenario. This means that after the software simulator sends a response back to the hardware core module, it can still continue simulating until the second time point.

[0014] In the present invention, the submission module of the software and hardware joint simulation platform adopts a batch request method, which allows the submission module to merge several requests for one communication to offset a large amount of communication costs. In the scenario of an artificial intelligence inference engine, the processor chip may initiate frequent inference requests to the engine, and some requests may be congested within the framework. When the submission module initiates a communication request, it will merge several requests into one package according to the number of batches allowed by the platform, and add a header to indicate the batch information of the package. The hardware-side architecture of the software and hardware joint simulation platform will first combine several scattered data packets into a complete package, and then parse several requests from the package according to the information in the header and insert them into the task queue one after another.

[0015] In this invention, the hardware-software co-simulation platform employs a data flow fusion method. This method removes header information from tasks with consecutive addresses initiated by the processor chip and merges them into a single packet, which is then uniformly filled with header information. This packet still arrives at the hardware side of the framework as several data packets. Unlike control flow scenarios, which require waiting for all packet fragments to be collected, data flow scenarios allow the incoming data to be directly modified with the corresponding task header information before being inserted into the task queue.

[0016] Furthermore, when a software simulator accesses a hardware core module, the processing flow of the software and hardware joint simulation platform is as follows:

[0017] (1) Scheduling process: After the software simulator inserts a request into the task queue, the scheduling module obtains the request details from the queue and distributes them to the pre-submission queue according to the request type.

[0018] (2) Submission process: After the submission module obtains the request from the pre-submission queue, it modifies it into a data packet that complies with the communication protocol standard and sends it to the hardware FPGA.

[0019] (3) Data packet parsing process: After the data packet pre-processing module in the hardware FPGA receives the data packet, it parses it into the original request and inserts it into the queue leading to the signal conversion module.

[0020] (4) Signal conversion process: The signal conversion module configures the input signal of the core module according to the information in the request.

[0021] (5) Core module execution: After receiving the input stimulus, the core module executes according to the established logic and sets the corresponding output signal.

[0022] (6) Signal conversion process. The signal conversion module monitors the output signal of the core module. After obtaining the output signal, it attaches information such as the number of execution clock cycles, assembles it into a response that can be recognized by the software simulator, and sends it to the queue leading to the data preprocessing module.

[0023] (7) Data packet segmentation process. After receiving the response, the data packet preprocessing module notifies the acquisition module through an interrupt to obtain the hardware execution result and segment the data packet into several packets that meet the bandwidth requirements of the communication protocol.

[0024] (8) Collection process: After the collection module obtains the data packet, it parses the corresponding information from the data packet according to the header of the data packet and sends it to the post-collection queue.

[0025] (9) Scheduling process. The presence of a response in the post-collection queue triggers the operation of the scheduling module, which is responsible for delivering the data packet to the result queue accessible to the software simulator.

[0026] (10) Get response. The software simulator gets the hardware execution result from the result queue.

[0027] Compared with the prior art, the beneficial technical effects of the present invention are embodied in:

[0028] (1) The present invention integrates the software simulator and the hardware FPGA at the same time, and uses the optimistic synchronization mechanism to give full play to the advantages of both while avoiding the impact of the simulation speed incoordination on the overall simulation effect and speed.

[0029] (2) The present invention provides comprehensive architecture exploration capabilities for architectural simulation of processor chips, supports high-degree-of-freedom parameter configuration capabilities for processor chip architecture modeling by software simulators to support fast iterative simulation, and the FPGA platform provides real hardware performance to make the architecture exploration results more convincing.

[0030] (3) The present invention uses FPGA hardware as the simulation platform for core hardware modules, fully leveraging the existing natural ecosystem advantages of the FPGA platform. Any module that can be deployed on the FPGA platform can be directly simulated on the proposed joint simulation platform. This joint simulation platform also leverages the high speed of FPGAs to overcome the serious problem of insufficient simulation speed in existing joint platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 This is an overview of the hardware and software co-simulation platform used for processor chip architecture verification.

[0032] Figure 2 This is the software side architecture diagram of the hardware and software joint simulation platform.

[0033] Figure 3 This is the hardware side architecture diagram of the software and hardware joint simulation platform.

[0034] Figure 4 This is the principle diagram of the optimistic synchronization mechanism.

[0035] Figure 5 Schematic diagram for batch processing requests.

[0036] Figure 6 This is the principle diagram of data stream fusion. DETAILED DESCRIPTION

[0037] The software and hardware co-simulation platform for processor chip architecture verification proposed in this invention has an overall structure. Figure 1As shown. The joint simulation platform divides the processor chip architecture into two parts. One part is certain core modules in the processor architecture that need to be focused on. These core modules may be modules that need to be iteratively upgraded, or modules that need to be newly integrated into the processor chip architecture. The other part is the remaining processor chip architecture. Under the joint simulation platform, the core modules that need to be focused on are deployed on the hardware FPGA for simulation, focusing on their hardware feasibility and performance, while the remaining processor chip architectures are deployed on the software simulator for simulation. The core of the joint simulation platform is to provide high-performance communication interconnection between the software simulator and the hardware FPGA. It is responsible for forwarding the access requests of the processor chip architecture simulated on the software simulator to the core modules to the core modules running on the FPGA, and also feeding back the requests or responses generated by the core modules to the processor chip architecture. Each core module has a corresponding virtual module in the software simulator. The simulated processor chip architecture will interact normally with the virtual module. When the virtual module receives the request, it will submit it to the framework proposed by the present invention.

[0038] Assumptions Figure 1The hardware model to be evaluated, shown in Figure 1, is an artificial intelligence inference engine. The processor chip needs to frequently access the engine, passing inference information to the engine and obtaining inference results from the engine. In this scenario, the acquisition module is configured in polling mode. The modules in the hardware-software co-simulation platform work together as follows: After the software simulator inserts a request into the task queue, the scheduling module retrieves the request details from the queue and distributes them to the pre-submission queue based on the request type. After receiving the request from the pre-submission queue, the submission module modifies it into a data packet that conforms to the communication protocol standard and sends it to the hardware FPGA. After receiving the data packets, the packet preprocessing module in the hardware FPGA parses them into the original request and inserts it into the queue leading to the signal conversion module. Packet parsing process. After receiving the data packets, the packet preprocessing module in the hardware FPGA parses them into the original request and inserts it into the queue leading to the signal conversion module. The signal conversion module configures the input signals of the core module based on the information in the request. After receiving the input stimulus, the core module executes according to the established logic and sets the corresponding output signal. The signal conversion module monitors the core module's output signal. After receiving the output signal, it appends information such as the number of execution clock cycles to assemble a response recognizable by the software emulator and sends it to the queue leading to the data preprocessing module. Upon receiving the response, the packet preprocessing module notifies the acquisition module via an interrupt to obtain the hardware execution results and splits the data packet into several packets that meet the communication protocol bandwidth requirements. After acquiring the data packet, the acquisition module parses the corresponding information from the packet header and sends it to the post-acquisition queue. The presence of a response in the post-acquisition queue triggers the scheduling module, which is responsible for delivering the data packet to the result queue accessible to the software emulator. The software emulator obtains the hardware execution results from the result queue.

[0039] The software side architecture details of the hardware and software joint simulation platform proposed in this invention are as follows: Figure 2As shown. The responsibility of the software part is to modify the software simulator's request to the module into a data packet that complies with the communication protocol and send it to the hardware FPGA. The framework on the software side consists of an execution task table, 4 circular lock-free queues and 3 module loads. The execution task table records the detailed information of the request received by the platform, and the scheduling module is responsible for analyzing, modifying and resolving the software simulator's request. The submission module is responsible for sending the request assembled by the scheduling module to the hardware FPGA. Similarly, the acquisition module is also responsible for obtaining the information required to interact with the processor chip from the hardware FPGA. When the software simulator initiates a request to the hardware core module, normal simulation can continue. The subsequent process is handed over to the hardware and software joint simulation platform proposed by the present invention. The platform first applies for a table entry from the execution task table to execute the filling request, and then inserts the table entry sequence number into the task queue. Next, the scheduling module accesses the execution task table from the task queue according to the table entry sequence number retrieved, and analyzes the characteristics of the request. For example, the reasoning request of the artificial intelligence engine needs to carry the information required for reasoning, and also needs to retrieve the reasoning result from the RTL module. After assembling the request and inserting it into the pre-submission queue, the scheduling module configures the collection module to initiate a request for a response. Upon receiving the response, the collection module populates the result with the corresponding entry in the execution task table and inserts the entry's sequence number into the post-collection queue. The scheduling module then modifies the ready entry into a response that meets the simulator's standards and inserts it into the results. After a certain delay, the simulator retrieves the response.

[0040] The hardware side architecture details of the software and hardware joint simulation platform proposed in this invention are as follows: Figure 3 As shown in Figure 2, the hardware-side architecture is implemented in hardware and connected to the core hardware model before being deployed on the FPGA. The hardware-software co-simulation platform first parses the data packets received by the FPGA. Because the data bit width of the software simulator's request or response to the hardware core module may exceed the upper limit of the communication protocol, the packet preprocessing module is required to collect and reassemble several data packets, parse them into the initial request or response initiated by the software simulator, and insert them into the task queue. Each entry in this queue consists of a task header and a payload. The former is essential information for maintaining the operation of the hardware-software co-simulation platform, such as the entry number of the request or response in the execution task table of the software-side architecture, while the latter is the actual request or response. The signal conversion module of the hardware-side framework is directly connected to the hardware core module. It receives tasks from the task queue and configures the hardware core module's input based on the task payload information. It also records the response time and output of the hardware core module, assembles the data packets, and inserts them into the result queue. The data preprocessing module splits the data packets into several packets based on the communication protocol configuration and transmits them to the software side of the co-simulation platform.

[0041] The optimistic synchronization mechanism principle adopted by the hardware and software joint simulation platform proposed in this invention is as follows: Figure 4 As shown in the figure. When the co-simulation platform receives a request from the software simulator, it schedules an event for Y clock cycles later. Y clock cycles is an estimate of the hardware core module's minimum execution time. This means that the software simulator can continue simulating for Y clock cycles without risk after initiating the request. If the hardware-software co-simulation platform can send back a response from the hardware core module within these Y clock cycles, the software simulator can continue simulating without interruption. Otherwise, the software simulator will wait in place for Y clock cycles until it receives a response. After receiving the response, the software simulator reschedules the event to occur (XY) cycles later, formally accepting the response. For hardware core modules that can actively initiate requests, the hardware-software co-simulation platform will continuously inquire about the hardware core module's request status. When the hardware core module initiates a request to the processor chip, it optimistically continues executing for the expected number of clock cycles. At this time, the software simulator will receive two time information. It needs to process the request of the hardware core module at the first time point. The second time point is the estimate of the next active request initiated by the hardware core model in the worst case. This means that the software simulator can continue to simulate to the second time point after sending the response back to the hardware core module.

[0042] The submission module of the hardware and software joint simulation platform proposed in this invention adopts a batch request method, such as Figure 5 . This method allows the submission module to merge several requests for one communication, which can offset a large amount of communication costs. In the scenario of an artificial intelligence inference engine, the processor chip may initiate frequent inference requests to the engine, and some requests may be congested within the framework. When the submission module initiates a communication request, it will merge several requests into one package according to the number of batches allowed by the platform, and add a header to indicate the batch information of the package. The hardware-side architecture of the hardware-software joint simulation platform will first combine several scattered data packets into a complete package, and then parse several requests from the package according to the header information and insert them into the task queue one after another.

[0043] The software and hardware joint simulation platform proposed in this invention also adopts a data flow fusion method for the hardware core module of the data flow interaction scenario, such as Figure 6 This method removes the header information from several consecutively addressed tasks initiated by the processor chip, merges them into a single packet, and then fills in the header information uniformly. This packet still arrives at the framework's hardware side as several data packets. Unlike control flow scenarios, which require waiting for all packet fragments to be collected, data flow scenarios allow the incoming data to be directly modified with the corresponding task header information before being inserted into the task queue.

Claims

1. A hardware and software co-simulation platform for processor chip architecture verification, characterized in that: The software simulator simulates a complete processor chip, while the hardware FPGA simulates a newly developed or under-tested core module. The simulation platform is responsible for seamless communication between the software simulator and the hardware FPGA. It forwards access requests from the processor chip simulated on the software simulator to the core module running on the FPGA, and also feeds back requests or responses generated by the core module to the processor chip. Each core module has a corresponding virtual module in the software simulator. The simulated processor chip interacts with the virtual module. When the virtual module receives a request, it submits it to the processor chip framework. The simulation platform is an architecture that spans hardware and software. Its software part includes a scheduling module, a submission module, an acquisition module, an execution task table, and four circular lock-free queues. The hardware part includes a data packet preprocessing module, a signal conversion module, and two queues. Among them: The execution task table is used to record detailed information of requests received by the simulation platform; The scheduling module is responsible for receiving access requests from the software emulator to the core module, applying for corresponding entries in the execution task table according to the type of request, and configuring the submission module and the acquisition module to start the response work; for requests that do not require a response, the scheduling module only configures the submission module to execute the transfer of the request to the hardware FPGA, and for requests that require a response, the scheduling module configures both the submission module and the acquisition module; wherein, there are two options for configuring the acquisition module, one is a polling mode, that is, after the submission module transfers the request, the acquisition module continuously sends requests to the hardware FPGA to query the hardware execution result; the other mode is an interrupt mode, that is, after the hardware FPGA completes the execution and notifies the acquisition module, the acquisition module will actively initiate a request for the execution result; the scheduling module interacts with the submission module and the acquisition module respectively through two circular lock-free queues; The submission module is responsible for modifying the requests prepared by the scheduling module into data packets that comply with the communication protocol standards for transmission. When modifying the data packets, the submission module supports merging multiple requests for a single transmission. Specifically, when the submission module finds that there are more than one request waiting to be transmitted in the circular lock-free queue before executing the next submission, the submission module merges the multiple requests and adds an additional data packet header to these requests to indicate the number and type of requests merged in the current data packet. The acquisition module is responsible for obtaining the execution results of the hardware core module from the hardware FPGA. When the scheduling module informs the acquisition module that it needs to track the response to a request, the acquisition module starts to operate. The acquisition module supports two modes, namely polling mode and interrupt mode, which correspond to the way the acquisition module obtains the hardware execution results. In the polling mode, the acquisition module continuously initiates requests to obtain the execution request results in order to finally obtain the data, while the interrupt result is the hardware that informs the acquisition module to retrieve the hardware execution results. The two modes are suitable for different scenarios. The polling mode is suitable for application scenarios that are sensitive to simulation time, and the interrupt mode is suitable for scenarios with high tolerance for simulation time. The packet preprocessing module is responsible for receiving, reassembling, parsing, collecting, segmenting and sending packets. Due to the bandwidth limitation of the communication protocol, the communication between the software emulator and the hardware emulator is split into several packets for transmission. The packet preprocessing module is responsible for receiving the disassembled packets. After collecting all the packets, the preprocessing module sorts and reassembles the packets. After restoring the original packets, the header is decoded and the requests in the packets are split according to the header information. Each independent request is sent to the queue to notify the signal conversion module to perform the next stage of processing. The packet preprocessing module is also responsible for sending packets. The results of the hardware core module execution are sent to the packet preprocessing module in succession, and the module collects and organizes these execution results. Depending on the configuration of the acquisition module, the packet preprocessing module performs different actions. When the acquisition module is in polling mode, the packet preprocessing module waits until the acquisition module initiates the next polling request, packages the currently collected core module execution results, and modifies the packet header before sending it. When the acquisition module is in interrupt mode, the packet preprocessing module immediately notifies the acquisition module to retrieve the hardware execution results after collecting the core module execution results. The signal conversion module is responsible for parsing requests from the software emulator, configuring the input signals of the core hardware module, collecting the output signals of the core hardware module, and assembling them into responses that are recognizable to the software emulator. When assembling the responses, certain hardware execution information is also attached, including the number of execution clock cycles of the core module. The signal conversion module obtains requests and sends responses from two queues connected to the data packet preprocessing module respectively.

2. The software and hardware joint simulation platform according to claim 1, characterized in that: The software-side architecture is responsible for modifying the request submitted by the software simulator into a data packet that complies with the communication protocol and sends it to the hardware FPGA; the scheduling module is responsible for analyzing, modifying and parsing the software simulator's request; the submission module is responsible for sending the request assembled by the scheduling module to the hardware FPGA; the acquisition module is responsible for obtaining the information needed to interact with the processor chip from the hardware FPGA; when the software simulator initiates a request to the hardware core module, it continues the normal simulation; the subsequent process is handed over to the simulation platform, which first applies for an entry from the execution task table to execute the fill request, and then inserts the entry number into the task queue; then, the scheduling module accesses the execution task table from the task queue according to the retrieved entry number and analyzes the characteristics of the request; then, after assembling the request and inserting it into the pre-submission queue, the scheduling module also configures the acquisition module to initiate a request to obtain a response; after retrieving the response, the acquisition module fills the result into the entry corresponding to the execution task table and inserts the entry number into the post-acquisition queue; The scheduling module then modifies the ready table entry into a response that meets the software simulator standard and inserts it into the result until the software simulator takes the response after a certain delay.

3. The software and hardware joint simulation platform according to claim 2, characterized in that: The hardware-side structure is connected to the core hardware model and deployed together on the FPGA. The simulation platform first parses the data packets received by the FPGA. Because the data bit width of the software simulator's request or response to the hardware core module may exceed the upper limit of the bit width supported by the communication protocol, the data packet preprocessing module collects several data packets, reassembles them, and parses them into the initial request or response initiated by the software simulator, which is then inserted into the task queue. Each entry in this queue consists of a task header and a payload. The former is essential information for maintaining the operation of the simulation platform, including the entry number of the request or response in the execution task table of the software-side architecture, and the latter is the actual request or response. The signal conversion module of the hardware-side framework is directly connected to the hardware core module. It receives tasks from the task queue and configures the input of the hardware core module based on the task payload information. It also records the time when the hardware core module responds and the output of the hardware core module, assembles them into data packets, and then inserts them into the result queue. The data preprocessing module splits the data packet into several parts according to the configuration of the communication protocol and transmits them to the software side of the joint simulation platform.

4. The software and hardware joint simulation platform according to claim 3, characterized in that: An optimistic synchronization mechanism is employed to address the significant difference in simulation speed between software and hardware simulators. Specifically, when the software simulator initiates a request to a core hardware module, the simulator waits until the co-simulation platform receives a response from the hardware core module and executes a number of clock cycles, X. The simulator then schedules an event X clock cycles later, simulating the hardware core module's response. Furthermore, upon receiving a request from the software simulator, the co-simulation platform schedules an event Y clock cycles later. Y clock cycles is an estimate of the hardware core module's minimum execution time, meaning the simulator can continue simulating Y clock cycles without risk after initiating the request. If the simulation platform sends back a response from the hardware core module within these Y clock cycles, the simulator continues simulating without interruption. Otherwise, the simulator waits Y clock cycles until it receives a response. Upon receiving the response, the simulator reschedules the event to occur (X-Y) cycles later, formally accepting the response. For hardware core modules that can proactively initiate requests, the simulation platform continuously inquires about the status of the hardware core module's requests. When the hardware core module initiates a request to the processor chip, it optimistically continues to execute for the expected number of clock cycles. At this point, the software simulator receives two time information. It processes the hardware core module's request at the first time point, and the second time point is the worst-case estimate of the hardware core model's next active request. This means that the software simulator can continue simulating to the second time point after sending the response back to the hardware core module.

5. The software and hardware joint simulation platform according to claim 4, characterized in that: The submission module adopts a batch request method, which allows the submission module to merge several requests for one communication to offset a large amount of communication costs; specifically, when the submission module initiates a communication request, it merges several requests into one package according to the number of batches allowed by the platform, and adds a header to indicate the batch information of the package; the hardware-side architecture of the software-hardware joint simulation platform first combines several scattered data packets into a complete package, and then parses several requests from the package according to the header information and inserts them into the task queue one after another.

6. The software and hardware joint simulation platform according to claim 4, characterized in that: The data stream fusion method is adopted, specifically, the header information of several consecutive address tasks initiated by the processor chip is removed and merged into one packet, and the header information is filled in uniformly; this packet will still arrive at the hardware side in the form of several data packets.

7. The software and hardware joint simulation platform according to any one of claims 1 to 6, characterized in that: When a software simulator accesses a hardware core module, the simulation platform's processing flow is as follows: (1) After the software simulator inserts the request into the task queue, the scheduling module obtains the request details from the queue and distributes them to the pre-submission queue according to the request type; (2) After the submission module obtains the request from the pre-submission queue, it modifies it into a data packet that conforms to the communication protocol standard and sends it to the hardware FPGA; (3) After the data packet preprocessing module in the hardware FPGA receives the data packet, it parses it into the original request and inserts it into the queue leading to the signal conversion module; (4) The signal conversion module configures the input signal of the core module according to the information in the request; (5) After receiving the input stimulus, the core module executes according to the established logic and sets the corresponding output signal; (6) The signal conversion module monitors the output signal of the core module. After obtaining the output signal, it attaches the execution clock cycle number information, assembles it into a response that can be recognized by the software simulator, and sends it to the queue leading to the data preprocessing module; (7) After receiving the response, the data packet preprocessing module notifies the acquisition module through an interrupt to obtain the hardware execution result and divides the data packet into several packets that meet the bandwidth requirements of the communication protocol; (8) After the acquisition module obtains the data packet, it parses the corresponding data from the data packet according to the header of the data packet and sends it to the post-acquisition queue; (9) The presence of a response in the post-collection queue triggers the operation of a scheduling module, which is responsible for delivering the data packet to a result queue accessible to the software simulator; (10) The software simulator obtains the hardware execution results from the result queue.

Images