Heterogeneous prototype verification system and method based on transaction-level model

Abstract

The invention belongs to the technical field of computer system simulation, and particularly relates to a heterogeneous prototype verification system and method based on a transaction-level model, and the method comprises the steps: operating a virtual machine monitor and the transaction-level model on a host machine; instantiating a client host and a client slave through a virtual machine monitor, and respectively simulating a universal processor and acceleration equipment; the execution of the standard instructions in the client slave is accelerated through the instruction set simulator; executing the self-defined instruction in the client and the slave through the hardware accelerator; bus transaction logic is simulated by using the transaction-level model, and communication between the virtual machine monitor and the transaction-level model is realized through a unified communication protocol; state spaces of a virtual machine monitor, an instruction set emulator, and a hardware accelerator are synchronized. The problem that a traditional simulation tool cannot effectively integrate different types of simulation components is effectively solved, a unified verification platform is provided for a heterogeneous system, and the system-level verification efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of computer system simulation, and particularly relates to a heterogeneous prototype verification system and method based on a transaction level model. BACKGROUND

[0002] In the field of electronic system design, transaction level modeling (TLM) is a high-level modeling method, which is widely used for early verification of system functions, communication protocols and software-hardware interfaces before RTL implementation. By shielding register transfer level details and focusing on transaction level interaction, transaction level modeling can greatly shorten simulation time, enabling software teams to carry out collaborative development of drivers, firmware and operating systems before hardware is taped out.

[0003] However, with the continuous rise in the complexity of electronic systems, transaction level modeling development has encountered many technical bottlenecks. On the one hand, heterogeneous system collaboration faces difficulties, and traditional simulation tools cannot effectively integrate different types of simulation components, such as virtual processor models, hardware simulators and physical devices. There is a lack of unified communication interface and timing management mechanism between components, which leads to low efficiency of system-level verification. On the other hand, existing joint simulation solutions cannot efficiently introduce custom acceleration instructions into the prototype verification system, making it difficult to carry out software development and verification work at an early stage of electronic system design. SUMMARY

[0004] The present application provides a heterogeneous prototype verification system and method based on a transaction level model to solve the above technical problems.

[0005] In a first aspect, the present application provides a heterogeneous prototype verification system based on a transaction level model, comprising a hardware component and a software component; the hardware component comprises a host, an instruction set simulator and a hardware accelerator; the software component comprises a virtual machine monitor and a transaction level model; wherein: The host is configured to run the virtual machine monitor and the transaction level model, and provide a hardware access physical interface for the instruction set simulator and the hardware accelerator; The instruction set simulator is a hardware virtualization-enabled processor, which adopts the same instruction set architecture as the acceleration device side in the heterogeneous system, and is configured to accelerate the execution of guest instructions for simulating acceleration devices in the prototype verification system; The hardware accelerator is implemented based on a field programmable gate array, and is configured to execute custom acceleration instructions in hardware acceleration; The virtual machine monitor runs on the host computer and is used for running one or more heterogeneous clients, the clients at least including a client host representing a general-purpose processor in a heterogeneous system and a client slave representing an acceleration device in the heterogeneous system; the virtual machine monitor includes a prototype verification system runtime, and the runtime implements a customized high-efficiency interconnection protocol used for communicating with a transaction-level model; The transaction-level model runs on the host computer and is used for simulating bus transaction logic in the heterogeneous system and is coupled with the virtual machine monitor through the customized high-efficiency interconnection protocol to integrate hardware components and software components to form the heterogeneous prototype verification system.

[0006] The three-layer heterogeneous hardware of the host computer, the instruction set emulator and the hardware accelerator is used for the first time, and is combined with the double-layer software stack of the virtual machine monitor and the transaction-level model to build a closed-loop verification platform capable of simultaneously running the general-purpose processor, the standard instruction and the customized acceleration instruction in a single environment; the problem that the traditional platform can only run a single type of simulation unit and cannot integrate multiple components is solved.

[0007] As a further limitation of the technical scheme of the application, the virtual machine monitor identifies and forwards the client instruction through adding a customized acceleration backend, including: Instantiating and managing the state space of the client slave; Initializing and synchronizing the state space in the instruction set emulator and the hardware accelerator through a user space interface; Capturing the instruction sent by the client slave, and sending the standard instruction to the instruction set emulator for execution and sending the customized instruction to the hardware accelerator for execution; Synchronizing the state space of the instruction set emulator or the hardware accelerator to the internal state space of the virtual machine monitor.

[0008] The virtual machine monitor identifies and forwards the client instruction through adding a customized acceleration backend, can accurately distinguish the standard instruction and the customized instruction, and send them to the instruction set emulator and the hardware accelerator for execution, respectively. Meanwhile, the state space of the client slave is instantiated and managed, and the state space is synchronized between the components, so that the consistency and accuracy of the system state are ensured, the efficiency and reliability of the instruction execution are improved, and the verification process of the heterogeneous system is further optimized.

[0009] As a further limitation of the technical scheme of the application, the hardware accelerator is connected to the host computer through a PCIe bus, and the virtual machine monitor mounts the instruction set emulator and the hardware accelerator to the client slave through a device bypass direct connection technology to realize hardware simulation acceleration.

[0010] The hardware accelerator is connected to the host through a PCIe bus, and a device bypass direct connection technology is used by the virtual machine monitor to mount the instruction set emulator and the hardware accelerator to the guest slave, so that hardware simulation acceleration is realized.The connection and mounting mode fully utilizes the performance advantage of the hardware accelerator, reduces the data transmission delay, improves the running speed of the entire prototype verification system, and helps to complete the system verification work more quickly.

[0011] As a further limitation of the technical scheme of the application, the transaction-level model is connected to the guest slave through a self-defined efficient interconnection protocol, simulates the PCIe interface of the acceleration device, includes configuration space, BAR space processing logic, TLP encoding and decoding and processing logic, and interacts with the virtual machine monitor through the efficient interconnection protocol encapsulated PCIe bus transactions.

[0012] The transaction-level model is connected to the guest slave through a self-defined efficient interconnection protocol, simulates the PCIe interface of the acceleration device, includes configuration space, BAR space processing logic, TLP encoding and decoding and processing logic, etc.This makes the transaction-level model more accurately simulate the behavior of the actual hardware device, efficiently interact with the virtual machine monitor, and further enhance the simulation reality and verification accuracy of the system, providing a more reliable verification environment for software development.

[0013] As a further limitation of the technical scheme of the application, the self-defined efficient interconnection protocol is used to bridge different buses to realize an efficient simulation interface; specifically including: adding the self-defined efficient interconnection protocol related code in the virtual machine monitor to realize the encoding and decoding of protocol packets, and providing a bus root device interface based on the protocol; modeling the bus interface part of the device through a transaction-level modeling language, including configuration space, BAR space processing logic, TLP encoding and decoding and processing logic, and encapsulating bus transactions through the self-defined efficient interconnection protocol to interact with the virtual machine monitor.

[0014] The self-defined efficient interconnection protocol realizes the encoding and decoding of protocol packets by adding related code in the virtual machine monitor, and provides a bus root device interface, while modeling the bus interface part of the device through a transaction-level modeling language to encapsulate bus transactions and interact with the virtual machine monitor.This design realizes the bridging between different buses, provides an efficient simulation interface, simplifies the complexity of internal communication of the system, improves the data transmission efficiency, and thus improves the performance of the entire prototype verification system.

[0015] As a further limitation of the technical scheme of the application, the transaction-level model and the virtual machine monitor transmit data packets encapsulated based on the Inspur-Uni-Port protocol through a Unix socket.

[0016] The transaction-level model and the virtual machine monitor transmit data packets encapsulated based on the Inspur-Uni-Port protocol through a Unix socket, and the communication has the characteristics of high stability and reliability. The Unix socket provides a mature inter-process communication mechanism, and the Inspur-Uni-Port protocol encapsulation guarantees the standardization and efficiency of data transmission, so that the data interaction between the two is smoother, which is beneficial to the stable operation and efficient verification of the system.

[0017] As a further limitation of the technical scheme of the application, the prototype verification system runtime includes a kernel mode device driver and a user mode device driver, which are used to scan and match the instruction set simulator and the hardware accelerator, and provide a hardware programming interface.

[0018] The prototype verification system runtime includes a kernel mode device driver and a user mode device driver, which can scan and match the instruction set simulator and the hardware accelerator, and provide a hardware programming interface. This provides convenience for the interaction between hardware components and software components, so that developers can more conveniently program and control hardware, improve the flexibility and scalability of the system, and facilitate customization and adjustment according to different verification requirements.

[0019] In a second aspect, the technical scheme of the application also provides a heterogeneous prototype verification method based on a transaction-level model, including the following steps: S1, running a virtual machine monitor and a transaction-level model on a host computer; S2, instantiating a client host and a client slave through the virtual machine monitor, respectively simulating a general-purpose processor and an acceleration device; S3, establishing a remote communication channel between the virtual machine monitor and the transaction-level model through the Inspur-Uni-Port remote communication protocol, realizing clock domain synchronization and transaction packet forwarding; S4, the virtual machine monitor captures instructions issued by the client slave and performs instruction type identification: If it is a standard instruction, send the instruction block to the instruction set simulator for execution, and synchronize the virtual machine state after execution; If it is a custom acceleration instruction, synchronize the virtual machine state to the FPGA-based hardware accelerator, execute the instruction by the hardware accelerator and return the result, and then synchronize the virtual machine state again; S5, using the transaction-level model to simulate bus transaction logic, and realizing communication between the virtual machine monitor and the transaction-level model through the Inspur-Uni-Port remote communication protocol; S6, loop execution of S4-S5 until the system-level verification is completed.

[0020] By running a virtual machine monitor and a transaction level model on a host computer, a client host and a slave are instantiated to simulate a general-purpose processor and an acceleration device, a remote communication channel is established to realize clock domain synchronization and transaction packet forwarding, instructions of the client slave are captured and identified for corresponding processing, bus transaction logic is simulated using the transaction level model to realize communication, and the loop is executed until the system level verification ends.

[0021] As a further limitation of the technical solution of the application, in S3, the establishment of the remote communication channel specifically includes: unix socket is created between the virtual machine monitor and the transaction level model; synchronization messages are encapsulated and exchanged to enable both parties to maintain a synchronized virtual clock; a set of message types is defined: {test, write, read, interrupt, synchronization, address translation service request, address translation service invalid, configuration}.

[0022] When establishing the remote communication channel, the creation of unix socket, the encapsulation and exchange of synchronization messages to maintain a synchronized virtual clock, and the definition of a rich set of message types ensure the accuracy and efficiency of communication between the virtual machine monitor and the transaction level model. The synchronized virtual clock ensures the consistency of both parties in time, and the rich set of message types meets the communication needs in different scenarios, providing strong support for stable operation and efficient verification of the system.

[0023] As a further limitation of the technical solution of the application, in S4, the virtual machine monitor captures the instruction block issued by the client slave and processes it according to the following steps: S41, determine the instruction type: if it is a standard instruction, go to S42; if it is a custom acceleration instruction, go to S43; S42, execute the standard instruction path, specifically including: S421, send the instruction block to the instruction set emulator through shared memory; S422, after the instruction set emulator completes execution, notify the virtual machine monitor through MSI-X interrupt; S423, the virtual machine monitor reads the result register and updates the CPU state of the client slave; S43, execute the custom acceleration instruction path, specifically including: S431, the virtual machine monitor packages the current CPU state, memory mapping, and instruction block into an Inspur-Uni-Port transaction packet; S432, write the transaction packet to the FPGA hardware accelerator through PCIe BAR0; S433, the FPGA triggers an MSI-X interrupt after completing the calculation; S434, the virtual machine monitor reads the write-back data and updates the guest state; S44, if either path of step S42 or S43 times out, an abnormal fallback is performed: the last checkpoint is restored and rescheduled.

[0024] After the virtual machine monitor captures the instruction block issued by the guest, the standard instruction path and the custom accelerated instruction path are executed respectively by judging the instruction type, and the abnormal fallback is executed when either path times out. This fine instruction processing flow can fully exert the advantages of the instruction set emulator and the hardware accelerator, improve the instruction execution efficiency, and at the same time, the abnormal fallback mechanism guarantees the stability and recoverability of the system when an exception occurs, and enhances the reliability and robustness of the entire prototype verification method.

[0025] As a further limitation of the technical scheme of the application, in S5, the step of the transaction-level model performing bus transaction simulation includes: S51, TLP-level decoding is performed on the received Inspur-Uni-Port transaction packet; S52, periodic approximate simulation of PCIe configuration space, BAR space and MSI-X interrupt is performed; S53, the simulation result is packaged as an Inspur-Uni-Port response packet and returned; As a further limitation of the technical scheme of the application, the method further includes: S7, if it is detected during verification that the PCIe link is disconnected or the FPGA resource is insufficient, a degradation mode is triggered: the custom accelerated instruction is rolled back to the instruction set emulator for execution and the performance deviation is recorded.

[0026] The application has the beneficial effect that through the cooperative matching of hardware components (host, instruction set emulator, hardware accelerator) and software components (virtual machine monitor and transaction-level model), a complete heterogeneous prototype verification system is constructed. The host provides a running environment and a hardware access interface for each component, the instruction set emulator accelerates the execution of guest instructions, the hardware accelerator implements the hardware accelerated execution of custom accelerated instructions, the virtual machine monitor manages the heterogeneous guests and implements efficient communication, and the transaction-level model simulates bus transaction logic. The system effectively solves the problem that traditional simulation tools cannot effectively integrate different types of simulation components, provides a unified verification platform for heterogeneous systems, and improves the system-level verification efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without any creative effort.

[0028] Figure 1 A schematic block diagram of a system according to an embodiment of the present application.

[0029] Figure 2 A system block diagram based on an Inspur-Uni-Port protocol.

[0030] Figure 3 A schematic flow chart of a method according to an embodiment of the present application. DETAILED DESCRIPTION

[0031] In order to make the objectives, features and advantages of the present application more obvious and easy to understand, the technical solutions in the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the embodiments described below are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without any creative effort fall within the scope of protection of the present application.

[0032] As shown in Figure 1 , the embodiment of the present application provides a heterogeneous prototype verification system based on a transaction-level model, which comprises hardware components and software components; the hardware components comprise a host, an instruction set simulator and a hardware accelerator; the software components comprise a virtual machine monitor and a transaction-level model; wherein: The host is configured to run the virtual machine monitor and the transaction-level model, and to provide a hardware access physical interface for the instruction set simulator and the hardware accelerator; The instruction set simulator is a hardware virtualization supporting processor, which adopts the same instruction set architecture as the side of the acceleration device in the heterogeneous system, and is configured to accelerate the execution of the guest instructions of the simulation acceleration device in the prototype verification system; The hardware accelerator is implemented based on a field programmable gate array, and is configured to perform the customized acceleration instructions in hardware acceleration; The virtual machine monitor runs on the host, and is configured to run one or more heterogeneous guests, wherein the guests at least comprise a guest host representing a general-purpose processor in the heterogeneous system and a guest slave representing an acceleration device in the heterogeneous system; the virtual machine monitor comprises a prototype verification system runtime, and the runtime implements a customized high-efficiency interconnection protocol, which is configured to communicate with the transaction-level model; The high-efficiency interconnection protocol is an Inspur-Uni-Port protocol. Runtime is a dynamic software layer that runs continuously after the hypervisor (such as QEMU) is started, responsible for managing communication, state synchronization and resource scheduling between heterogeneous components (instruction set simulator, hardware accelerator, transactional model).

[0033] The core functions include: encapsulating the Inspur-Uni-Port protocol, processing cross-bus (such as PCIe, AXI) transaction communication; scanning and binding instruction set simulators and hardware accelerators through kernel / user space drivers, providing a unified hardware operation interface; synchronizing state space (such as registers, memory data) between the hypervisor, instruction set simulator, and hardware accelerator; cooperating with the custom acceleration backend of QEMU to route standard instructions to the instruction set simulator and custom instructions to the hardware accelerator.

[0034] Runtime exists as an extension module of QEMU, for example: adding encoding and decoding logic of the Inspur-Uni-Port protocol in QEMU. Implementing a PCIe root device interface (such as the Inspur-Uni-Port root port) to enable the transactional model to be mounted to a virtual PCIe bus.

[0035] Interaction with hardware accelerator: runtime interacts with FPGA accelerator drivers through user space interfaces (such as ioctl or memory mapping) to pass custom instruction blocks. After FPGA execution is complete, read state data from the hardware accelerator and synchronize it to the virtual machine state of QEMU.

[0036] Communication with transactional model: transmit Inspur-Uni-Port protocol packets through Unix socket, and the transactional model parses and forwards them to specific bus transaction logic (such as PCIe TLP packet processing).

[0037] Runtime hides the interface differences of different components (virtual processors, hardware simulators, physical devices) through a unified protocol (Inspur-Uni-Port), solving the problem of inconsistent communication interfaces and timing management in traditional solutions.

[0038] Runtime cooperates with the custom acceleration backend of QEMU to implement custom instruction capture, forwarding, and hardware acceleration execution, enabling software development to validate acceleration instruction functions early in the design phase.

[0039] The transactional model runs on the host machine, simulating bus transaction logic in a heterogeneous system, and communicates with the hypervisor through a custom high-efficiency interconnection protocol, integrating hardware components and software components to form a heterogeneous prototype verification system.

[0040] In view of the problem that traditional simulation tools cannot effectively integrate different types of simulation components, and there is a lack of unified communication interface and timing management mechanism between components, resulting in low efficiency of system-level verification, the heterogeneous prototype verification system of the application constructs a complete platform, integrates hardware components (host, instruction set simulator, hardware accelerator) and software components (virtual machine monitor and transaction-level model) together. This integration method breaks the isolated state of each component in traditional simulation tools, and provides a unified running environment for different types of simulation components. The virtual machine monitor, as the core component, runs on the host and is responsible for running the heterogeneous client (including the client host representing the general-purpose processor and the client slave representing the acceleration device), and communicates with the transaction-level model through a custom high-efficiency interconnection protocol. The transaction-level model simulates the bus transaction logic in the heterogeneous system and interacts with the virtual machine monitor through the protocol. This custom high-efficiency interconnection protocol provides a unified communication interface between components, so that different components can transmit data and interact according to a unified specification, solving the problem of non-uniform communication interface in traditional tools.

[0041] During system operation, the management of client instances by the virtual machine monitor and the communication coordination with the transaction-level model realize the management of system timing. For example, during instruction execution, the virtual machine monitor captures the instructions issued by the client slave, and sends them to the instruction set simulator or hardware accelerator for execution according to the instruction type, while synchronizing the state space of each component to ensure the consistency and coordination of each component in time, and improve the efficiency of system-level verification.

[0042] The existing joint simulation scheme is difficult to introduce the self-defined acceleration instruction into the prototype verification system in an efficient manner, resulting in that the corresponding software development work cannot be developed and verified in the early stage of electronic system design. A hardware accelerator is arranged in the system of the present application, which is implemented based on a field programmable gate array (FPGA) and is used to execute the self-defined acceleration instruction in hardware acceleration. This hardware acceleration manner can fully exert the parallel computing advantage of the FPGA, greatly improve the execution speed of the self-defined acceleration instruction, and significantly improve the efficiency compared with the traditional software simulation manner. The virtual machine monitor can identify and forward the guest machine instruction by adding a self-defined acceleration back end. When the instruction issued by the guest machine is captured, the virtual machine monitor can judge the instruction type, and if it is a self-defined instruction, it will be sent to the hardware accelerator for execution. This instruction identification and forwarding mechanism ensures that the self-defined acceleration instruction can be accurately guided to the hardware accelerator for processing, realizing the efficient introduction and execution of the self-defined acceleration instruction. Since the system can introduce the self-defined acceleration instruction into the prototype verification system in the early stage of electronic system design, and provides a reliable verification environment for software development. The software team can perform collaborative development of drivers, firmware and operating systems based on the system before the hardware is taped out, and timely verify and debug the software development work, thereby solving the problem that the software development work cannot be carried out and verified in the early stage in the existing scheme.

[0043] In some embodiments, the virtual machine monitor identifies and forwards the guest machine instruction by adding a self-defined acceleration back end, comprising: instantiation and management of the state space of the guest; note that during the boot process, the virtual machine monitor allocates necessary system resources, such as memory space, virtual devices, etc., to each guest according to the system configuration information. For example, if a guest emulates a hardware accelerator with specific functions, the virtual machine monitor allocates a memory region of certain size for it to store data and instructions. The virtual machine monitor creates the virtual central processing unit (CPU) context of the guest, including register state, program counter (PC), etc. These context information will be used to save and restore the running state of the guest. For example, the program counter is set to the first instruction address of the guest program. The virtual machine monitor needs to track the state changes of the guest in real time. When the guest executes instructions, its register values, memory content, etc. will change constantly. The virtual machine monitor monitors these changes through specific mechanisms (such as memory mapping, register access interface, etc.). State saving and restoring function is provided. When the system needs to perform state migration, fault recovery, etc., the virtual machine monitor can save the current state of the guest to a designated storage location (such as a disk file), and read the state information from the location when needed, and restore it to the guest. For example, when the system fails, the state of the guest is saved so that it can be restored to the state before the failure when restarted.

[0044] Initialization and synchronization of the state space in the instruction set emulator and the hardware accelerator through the user space interface; specifically including: the virtual machine monitor provides a set of user space interfaces, which allow external programs (such as drivers, management tools, etc.) to communicate with the virtual machine monitor and access and operate the state space of the instruction set emulator and the hardware accelerator. For example, data transmission between user space and kernel space (the virtual machine monitor usually runs in kernel space) is achieved through device files or network sockets, etc. During the system boot phase, the external program sends initialization instructions to the instruction set emulator and the hardware accelerator through the user space interface. The instruction set emulator initializes its internal registers, memory, etc. according to the received instructions, simulating an initial hardware environment. For example, clear the general-purpose registers, set the values of certain control registers, etc.

[0045] The hardware accelerator also receives initialization parameters through the user space interface to configure its internal hardware modules, such as arithmetic logic units (ALUs), memory units, etc. For example, parameters such as the working mode and clock frequency of the hardware accelerator are set. The virtual machine monitor ensures that the initial state of the instruction set emulator and the hardware accelerator is consistent with the guest slave state space maintained internally by the virtual machine monitor. After initialization is complete, the virtual machine monitor reads the state information of the instruction set emulator and the hardware accelerator through the user space interface and compares and synchronizes it with the guest slave state saved by itself. For example, it is checked whether the register values in the instruction set emulator are consistent with the initial values of the registers allocated for the guest slave in the virtual machine monitor, and if not, it is corrected.

[0046] The instruction issued by the guest slave is captured, and if it is a standard instruction, it is sent to the instruction set emulator for execution; if it is a custom instruction, it is sent to the hardware accelerator for execution; further, it is necessary to explain that the virtual machine monitor captures the instruction by monitoring the program counter (PC) and memory access operations of the guest slave. When the CPU of the guest slave issues a memory read request, the virtual machine monitor intercepts the request and checks whether the read memory address contains an instruction. If so, the instruction is captured. For example, in the x86 architecture, the virtual machine monitor can set the permissions of the page table entry, and when the guest slave attempts to read the instruction, an exception is triggered, and the virtual machine monitor captures the instruction through the exception handling mechanism. After the instruction is captured, the virtual machine monitor analyzes and identifies the instruction. According to the pre-defined instruction format and coding rules, it is determined whether the instruction is a standard instruction or a custom instruction. For example, for a custom instruction, a specific opcode range can be allocated for it, and the virtual machine monitor determines the instruction type by checking the opcode of the instruction.

[0047] If the instruction is a standard instruction, the virtual machine monitor sends it to the instruction set emulator for execution. The instruction set emulator simulates the execution process of the standard instruction, updates its internal state space (such as register values, memory content, etc.), and returns the execution result to the virtual machine monitor. If the instruction is a custom instruction, the virtual machine monitor sends it to the hardware accelerator for execution. The hardware accelerator performs corresponding hardware operations, such as specific data processing, encryption and decryption, according to the opcode and operand of the custom instruction. After execution is completed, the hardware accelerator returns the result to the virtual machine monitor.

[0048] The state space of the instruction set simulator or hardware accelerator is synchronized to the internal state space of the virtual machine monitor. The specific process includes: after the instruction set simulator or hardware accelerator completes the instruction execution, it triggers a state synchronization operation. This can be achieved through an interrupt mechanism, a polling mechanism, or an event notification mechanism. For example, after the hardware accelerator completes the execution of a custom instruction, it sends an interrupt signal to the virtual machine monitor, notifying it that the instruction execution is complete and the state needs to be synchronized.

[0049] After the virtual machine monitor receives the state synchronization notification, it reads the state information of the instruction set simulator or hardware accelerator through the user space interface. For the instruction set simulator, it reads its register values, memory contents, etc.; for the hardware accelerator, it reads its internal state registers, processing results, etc. The virtual machine monitor updates the read state information to the guest slave state space maintained in its internal state. Ensures that the virtual machine monitor has accurate knowledge of the state of the guest slave, so as to subsequently perform state management, instruction capture and forwarding, etc. For example, update the processing result returned by the hardware accelerator to the memory of the guest slave, so that the subsequent instructions of the guest slave can correctly access and use the result.

[0050] In some embodiments, the hardware accelerator is connected to the host through a PCIe bus, and the virtual machine monitor mounts the instruction set simulator and the hardware accelerator to the guest slave through the device bypass direct connection technology to achieve hardware simulation acceleration.

[0051] The hardware accelerator is physically connected to the host through a PCIe bus. The PCIe bus provides a high-speed data transmission channel to ensure efficient data exchange between the hardware accelerator and the host. After the connection is completed, the host needs to initialize and configure the hardware accelerator, including setting parameters such as the working mode, clock frequency, and memory mapping of the hardware accelerator, so that it is in a working state. The virtual machine monitor is started on the host and loads the necessary drivers and configuration files. It is responsible for managing the creation, running, and destruction of virtual machines, as well as virtualizing and allocating hardware resources. During the initialization process, the virtual machine monitor identifies the hardware accelerator connected to the host and allocates corresponding resources such as memory space and interrupt numbers to it.

[0052] The Virtual Machine Monitor (VM) employs device bypass direct connection technology, bypassing the traditional software emulation layer to directly mount the instruction set emulator and hardware accelerator to the guest machine. This typically requires implementing a specific hardware abstraction layer and driver interface within the VM, enabling the guest machine to access the instruction set emulator and hardware accelerator as if they were local devices. For example, by modifying the VM's memory management and I / O processing modules, the memory space and I / O ports of the instruction set emulator and hardware accelerator can be mapped to the address space of the guest machine. To ensure system security and stability, the VM requires permission management and isolation for device bypass direct connection. It uses mechanisms such as Access Control Lists (ACLs) to restrict the guest machine's access permissions to the instruction set emulator and hardware accelerator, preventing unauthorized access and operations. Simultaneously, the VM isolates different guest machines to ensure that their data and operations do not interfere with each other.

[0053] The Virtual Machine Monitor (VM) monitors the program counter (PC) and memory access operations of the guest slave. When the guest slave's CPU issues a memory read request, the VM intercepts the request and checks if the memory address to be read contains an instruction. If so, the instruction is captured. For example, in the x86 architecture, the VM can set page table entry permissions. When the guest slave attempts to read an instruction, an exception is triggered, and the VM captures the instruction through an exception handling mechanism. After capturing the instruction, the VM parses and identifies it. Based on predefined instruction formats and encoding rules, it determines whether the instruction is a standard instruction or a user-defined instruction. If the instruction is a standard instruction, the VM sends it to the instruction set emulator for execution; if the instruction is a user-defined instruction, the VM sends it to the hardware accelerator for execution. After receiving the instruction, the instruction set emulator and hardware accelerator return execution status information to the VM, such as whether the instruction was executed successfully or whether an exception occurred.

[0054] Instruction set simulators simulate the execution of standard instructions, updating their internal state space (such as register values ​​and memory contents) based on the instruction's opcode and operands. Instruction set simulators can employ software simulation or combine hardware acceleration technologies, such as dynamic binary translation (DBT), to improve execution efficiency. During execution, the instruction set simulator communicates with the virtual machine monitor, providing timely feedback on execution status and results. Hardware accelerators, implemented using Field-Programmable Gate Arrays (FPGAs) or Application-Specific Integrated Circuits (ASICs), can efficiently execute custom accelerated instructions. Upon receiving a custom instruction, the hardware accelerator invokes the corresponding hardware module for processing based on the instruction's opcode and operands. The parallel computing capabilities and dedicated hardware design of hardware accelerators significantly improve the execution speed of custom instructions, resulting in a substantial efficiency improvement compared to traditional software simulation methods.

[0055] After completing instruction execution, the instruction set emulator or hardware accelerator synchronizes its own status information (such as register values, memory contents, and execution results) to the virtual machine monitor's internal state space. The virtual machine monitor reads the status information of the instruction set emulator or hardware accelerator through the user space interface and updates its own maintained guest slave state space, ensuring that the virtual machine monitor has an accurate understanding of the guest slave's state. The virtual machine monitor feeds back the instruction execution results to the guest slave. If the instruction execution is successful, the guest slave can continue executing the next instruction; if an exception occurs during instruction execution, the virtual machine monitor will handle it appropriately according to the exception type, such as interrupting the guest slave's execution or logging exception information. Simultaneously, the virtual machine monitor can also pass the execution results to other related components, such as the operating system or applications within the virtual machine, for subsequent processing.

[0056] In some embodiments, the transaction-level model connects to the client slave via a custom high-efficiency interconnect protocol to simulate the PCIe interface of the acceleration device, including configuration space, BAR space processing logic, TLP encoding / decoding and processing logic, and encapsulates PCIe bus transactions to interact with the virtual machine monitor through the high-efficiency interconnect protocol. Further, the custom high-efficiency interconnect protocol is used to bridge different buses to achieve a high-efficiency emulation interface; specifically, it includes: implementing protocol packet encoding / decoding by adding the custom high-efficiency interconnect protocol-related code to the virtual machine monitor, and providing a bus root device interface based on this protocol; modeling the bus interface portion of the device using a transaction-level modeling language, including configuration space, BAR space processing logic, TLP encoding / decoding and processing logic, and encapsulating bus transactions through the custom high-efficiency interconnect protocol to interact with the virtual machine monitor.

[0057] It should be noted that the PCIe interface emulation implementation includes: (1) Configuration space processing logic Register mapping: Implements the standard PCIe configuration space (256 bytes), including device ID, vendor ID, base address register (BAR), etc. For example, BAR space is automatically allocated through an enumeration algorithm to avoid address conflicts.

[0058] Dynamic configuration: Supports the operating system to dynamically modify the BAR value at runtime (such as the dual BAR configuration of the NVMe controller) and trigger the device re-initialization process.

[0059] (2) BAR spatial interaction logic Address mapping and access control: The access type is determined based on the low-order attributes of the BAR (e.g., 0x0 represents 32-bit memory space), and TLP packet routing is implemented by matching the high-order address bits. For example, when the CPU accesses the register mapped by BAR0, a MemRdTLP packet is generated.

[0060] Embedded scenario adaptation: Implement a BAR freezing mechanism in FreeRTOS to disable BAR mapping when the device enters a low-power state and reactivate it after waking up.

[0061] (3) TLP encoding and decoding logic The TLP structure definition includes a header (3 / 4 DW), a data payload (0~1024 DW), and an ECRC checksum field. For example, the TLP header for a memory write request needs to specify the request type, target address, data length, etc.

[0062] Encoding and decoding optimization: Hardware-accelerated codecs are used to reduce TLP assembly / disassembly latency to the nanosecond level, and parallel processing is achieved through pipeline technology.

[0063] PCIe bus transaction processing: Standard transactions: Implement PCIe standard transactions such as memory read / write (MemRd / MemWr), configuration read / write (CfgRd / CfgWr), and IO read / write (IORd / IOWr).

[0064] Extended Transactions: Added Message transactions (such as INTx interrupts and power management) and atomic operations (AtomicOp) to support complex hardware acceleration scenarios.

[0065] Credit mechanism: Flow control is implemented through data link layer sequence numbers and credit counters to prevent buffer overflows at the receiver.

[0066] Multicast routing: Supports TLP multicast based on device ID or bus number, such as broadcasting an interrupt signal to multiple client slaves.

[0067] Error detection: Data integrity is verified by LCRC (link layer CRC) and ECRC (end-to-end CRC). When an error is detected, retransmission is triggered or the error status is reported.

[0068] Recovery process: Define error recovery protocols, such as link retraining and device reset, to ensure system stability.

[0069] Encapsulation of interaction with the virtual machine monitor: User-space interface: Provides device file or network socket interface, allowing the virtual machine monitor to send / receive TLP packets through read / write operations. For example, control command transmission is implemented through the / dev / pcie_emul device file.

[0070] High-performance channels: Employing shared memory or RDMA (Remote Direct Memory Access) technology reduces data copying and increases throughput to the GB / s level.

[0071] Virtual to physical address translation: The virtual machine monitor maintains a mapping table from the virtual address of the guest machine to the physical address of the host machine, and the address fields in the TLP packet need to be translated in real time.

[0072] Interrupt injection: The interrupt signals of the hardware accelerator are encapsulated as MSI (Message Signal Interrupt) TLP packets and injected into the interrupt vector table of the guest slave through the virtual machine monitor.

[0073] State synchronization mechanism: After the instruction is executed, the hardware accelerator notifies the virtual machine monitor to synchronize the state space (such as register values ​​and DMA buffers) through interrupt or polling.

[0074] Snapshots and Recovery: Supports virtual machine monitors to take snapshots of hardware accelerator status for fault recovery or migration scenarios.

[0075] In some embodiments, the transaction-level model and the virtual machine monitor transmit data packets encapsulated based on the Inspur-Uni-Port protocol via Unix sockets.

[0076] In some embodiments, the prototype verification system runtime includes kernel-mode device drivers and user-mode device drivers for scanning and matching instruction set emulators and hardware accelerators, and provides hardware programming interfaces.

[0077] This invention uses QEMU as the virtual machine monitor. Taking a PCIe bus-based simulation system as an example, the system block diagram based on the Inspur-Uni-Port protocol is as follows: Figure 2As shown, by adding Inspur-Uni-Port protocol-related code to QEMU, the encoding and decoding of Inspur-Uni-Port protocol packets are implemented, and a PCIe root device interface based on the Inspur-Uni-Port protocol, the Inspur-Uni-Port root port, is provided to the device. Furthermore, the PCIe interface portion of the PCIe device is modeled using the transaction-level modeling language SystemC, including the PCIe configuration space, BAR space processing logic, TLP encoding / decoding and processing logic, MSI-X interrupts, etc., and PCIe bus transactions are encapsulated using the Inspur-Uni-Port protocol for interaction with the QEMU virtual machine. In actual use, the transaction-level modeled PCIe device is mounted on the PCIe root bus provided by QEMU and transmits data packets encapsulated based on the Inspur-Uni-Port protocol via Unix sockets. Both ends parse the Inspur-Uni-Port data packets before transmitting them to the specific bus transaction processing logic.

[0078] QEMU is used as the virtual machine monitor, serving as the core of the simulation modeling device. This core is implemented based on the RISC-V instruction set, supporting both standard and custom RISC-V instructions. A custom acceleration backend is added to QEMU to identify and forward guest instructions. The instruction set emulator and FPGA are connected to the x86 host via PCIe, and their operation interfaces are exposed in the x86 host's user space through corresponding drivers. The custom acceleration backend added in QEMU interacts with the corresponding device through the user space interface. Initially, the state space of the virtual machine in the core is instantiated and managed in QEMU. The state space is initialized and synchronized in the instruction set emulator and the hardware accelerator implemented on the FPGA via the user space interface. Afterward, the virtual machine identifies standard and custom RISC-V instructions in the program. If it is a standard instruction, it sends the instruction block to the instruction set emulator for execution. After the instruction set emulator completes the execution of the instruction block, QEMU is responsible for synchronizing its internally maintained virtual machine state space with the state space in the instruction set emulator. If it is a custom instruction, QEMU is responsible for synchronizing the internally maintained virtual machine state space with the state space of the hardware accelerator in the FPGA, and sending the custom instruction block to the hardware accelerator for execution. After the hardware accelerator finishes execution, QEMU will synchronize the state space on the hardware accelerator back to the internally maintained state space.

[0079] like Figure 3 As shown, this embodiment of the invention also provides a heterogeneous prototype verification method based on a transaction-level model, including the following steps: S1. Run a virtual machine monitor and transaction-level model on the host machine; S2. Instantiate the guest host and guest slave through the virtual machine monitor to simulate a general-purpose processor and an acceleration device, respectively; S3. Establish a remote communication channel between the virtual machine monitor and the transaction-level model through the Inspur-Uni-Port remote communication protocol to achieve clock domain synchronization and transaction packet forwarding; S4. The virtual machine monitor captures commands issued by the guest slave and identifies the command type: If it is a standard instruction, the instruction block is sent to the instruction set emulator for execution, and the virtual machine state is synchronized after execution; If it is a custom acceleration instruction, the virtual machine state is synchronized to the FPGA-based hardware accelerator, which executes the instruction and returns the result. Then the virtual machine state is synchronized again. S5. Use a transaction-level model to simulate bus transaction logic and implement communication between the virtual machine monitor and the transaction-level model through the Inspur-Uni-Port remote communication protocol. S6. Repeat steps S4-S5 until the system-level verification is complete.

[0080] In some embodiments, establishing a remote communication channel in step S3 specifically includes: Create a Unix socket between the virtual machine monitor and the transaction-level model; Encapsulate and exchange synchronization messages so that both parties maintain synchronized virtual clocks; Define the message type set: {test, write, read, interrupt, synchronization, address translation service request, address translation service invalid, configuration}.

[0081] In some embodiments, in S4, the virtual machine monitor captures the instruction block issued by the guest slave and processes it as follows: S41. Determine the instruction type: If it is a standard instruction, proceed to S42; if it is a custom acceleration instruction, proceed to S43. S42. Execute the standard instruction path, which specifically includes: S421. Send the instruction block to the instruction set emulator via shared memory; S422. After the instruction set emulator completes execution, it notifies the virtual machine monitor via an MSI-X interrupt. S423, The virtual machine monitor reads the result register and updates the CPU state of the guest slave; S43. Execute the custom acceleration instruction path, specifically including: S431, The Virtual Machine Monitor packages the current CPU state, memory mapping, and instruction blocks into an Inspur-Uni-Port transaction packet; S432, Write the transaction packet to the FPGA hardware accelerator via PCIe BAR0; S433: After the FPGA completes the calculation, it triggers an MSI-X interrupt. S434. The virtual machine monitor reads the write-back data and updates the client slave status. S44. If either step S42 or S43 times out, perform an abnormal rollback: restore the previous checkpoint and reschedule.

[0082] In some embodiments, in S5, the steps of the transaction-level model performing bus transaction simulation include: S51. Perform TLP-level decoding on the received Inspur-Uni-Port transaction packet; S52. Based on "PCI_Express_Base_4.0r1.0", complete the periodic approximate simulation of PCIe configuration space, BAR space, and MSI-X interrupt; S53. Encapsulate the simulation results into an Inspur-Uni-Port response packet and send it back; In some embodiments, the method further includes: S7. If a PCIe link disconnection or insufficient FPGA resources are detected during the verification process, a degradation mode is triggered: the custom acceleration instructions are rolled back to the instruction set simulator for execution and the performance deviation is recorded.

[0083] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A heterogeneous prototype verification system based on a transaction-level model, characterized in that, It includes hardware components and software components; the hardware components include a host machine, an instruction set emulator, and a hardware accelerator; the software components include a virtual machine monitor and a transaction-level model; wherein: The host machine is used to run the virtual machine monitor and transaction-level model, and to provide physical interfaces for hardware access to the instruction set emulator and hardware accelerator. The instruction set emulator is a processor that supports hardware virtualization and adopts the same instruction set architecture as the acceleration device side in the heterogeneous system. It is used to accelerate the execution of client instructions of the simulated acceleration device in the prototype verification system. The hardware accelerator is implemented based on a field-programmable gate array and is used for hardware acceleration of custom acceleration instructions. The virtual machine monitor runs on the host machine and is used to run one or more heterogeneous clients, the clients including at least a client host representing a general-purpose processor in the heterogeneous system and a client slave representing an acceleration device in the heterogeneous system; the virtual machine monitor includes a prototype verification system runtime, the runtime implementing a custom high-efficiency interconnect protocol for communicating with a transaction-level model; The transaction-level model runs on the host machine and is used to simulate bus transaction logic in heterogeneous systems. It is coupled with the virtual machine monitor through a custom high-efficiency interconnect protocol and integrates hardware and software components to form a heterogeneous prototype verification system.

2. The heterogeneous prototype verification system based on a transaction-level model according to claim 1, characterized in that, The virtual machine monitor identifies and forwards client commands by adding a custom acceleration backend, including: Instantiate and manage the state space of the client and slave machines; Initialize and synchronize the state space in the instruction set simulator and hardware accelerator through the user space interface; Capture commands issued by the client slave device; if the command is a standard command, send it to the instruction set emulator for execution; if the command is a custom command, send it to the hardware accelerator for execution. Synchronize the state space of the instruction set emulator or hardware accelerator to the internal state space of the virtual machine monitor.

3. The heterogeneous prototype verification system based on a transaction-level model according to claim 2, characterized in that, The hardware accelerator is connected to the host machine via the PCIe bus, and the virtual machine monitor connects the instruction set emulator and the hardware accelerator to the client machine via device bypass direct connection technology to achieve hardware emulation acceleration.

4. The heterogeneous prototype verification system based on a transaction-level model according to claim 3, characterized in that, The transaction-level model connects to the client slave via a custom high-efficiency interconnect protocol, simulating the PCIe interface of the acceleration device, including configuration space, BAR space processing logic, TLP encoding / decoding and processing logic, and encapsulating PCIe bus transactions and interacting with the virtual machine monitor through the high-efficiency interconnect protocol.

5. The heterogeneous prototype verification system based on a transaction-level model according to claim 4, characterized in that, The custom high-efficiency interconnect protocol is used to bridge different buses to achieve a high-efficiency emulation interface. Specifically, it includes: implementing protocol packet encoding and decoding by adding relevant code of the custom high-efficiency interconnect protocol to the virtual machine monitor, and providing a bus root device interface based on the protocol; modeling the bus interface part of the device through a transaction-level modeling language, including configuration space, BAR space processing logic, TLP encoding and decoding and processing logic, and encapsulating bus transactions through the custom high-efficiency interconnect protocol to interact with the virtual machine monitor.

6. The heterogeneous prototype verification system based on a transaction-level model according to claim 5, characterized in that, The transaction-level model and the virtual machine monitor transmit data packets encapsulated based on the Inspur-Uni-Port protocol via Unix sockets.

7. The heterogeneous prototype verification system based on a transaction-level model according to claim 6, characterized in that, The prototype verification system runtime includes kernel-mode device drivers and user-mode device drivers, used to scan and match instruction set simulators and hardware accelerators, and provides hardware programming interfaces.

8. A heterogeneous prototype verification method based on a transaction-level model, characterized in that, Includes the following steps: S1. Run a virtual machine monitor and transaction-level model on the host machine; S2. Instantiate the guest host and guest slave through the virtual machine monitor to simulate a general-purpose processor and an acceleration device, respectively; S3. Establish a remote communication channel between the virtual machine monitor and the transaction-level model through the Inspur-Uni-Port remote communication protocol to achieve clock domain synchronization and transaction packet forwarding; S4. The virtual machine monitor captures commands issued by the guest slave and identifies the command type: if it is a standard command, the command block is sent to the instruction set emulator for execution, and the virtual machine state is synchronized after execution; if it is a custom acceleration command, the virtual machine state is synchronized to the FPGA-based hardware accelerator, which executes the command and returns the result, and then the virtual machine state is synchronized again. S5. Use a transaction-level model to simulate bus transaction logic and implement communication between the virtual machine monitor and the transaction-level model through the Inspur-Uni-Port remote communication protocol. S6. Repeat steps S4-S5 until the system-level verification is complete.

9. The heterogeneous prototype verification method based on a transaction-level model according to claim 8, characterized in that, In S3, establishing a remote communication channel specifically includes: Create a Unix socket between the virtual machine monitor and the transaction-level model; Encapsulate and exchange synchronization messages so that both parties maintain synchronized virtual clocks; Define the message type set: {test, write, read, interrupt, synchronization, address translation service request, address translation service invalid, configuration}.

10. The heterogeneous prototype verification method based on a transaction-level model according to claim 9, characterized in that, In S4, the virtual machine monitor captures instruction blocks issued by the guest slave and processes them as follows: S41. Determine the instruction type: If it is a standard instruction, proceed to S42; if it is a custom acceleration instruction, proceed to S43. S42. Execute the standard instruction path, specifically including: S421. Send the instruction block to the instruction set emulator via shared memory; S422. After the instruction set emulator completes execution, it notifies the virtual machine monitor via an MSI-X interrupt. S423, The virtual machine monitor reads the result register and updates the CPU state of the guest slave; S43. Execute the custom acceleration instruction path, specifically including: S431, The Virtual Machine Monitor packages the current CPU state, memory mapping, and instruction blocks into an Inspur-Uni-Port transaction packet; S432, Write the transaction packet to the FPGA hardware accelerator via PCIe BAR0; S433: After the FPGA completes the calculation, it triggers an MSI-X interrupt. S434. The virtual machine monitor reads the write-back data and updates the client slave status. S44. If either step S42 or S43 times out, perform an abnormal rollback: restore the previous checkpoint and reschedule.

Images