Virtualization hardware verification method and verification system based on multi-layer architecture

Abstract

The present invention discloses a virtualized hardware verification method and verification system based on a multi-layer architecture, wherein the multi-layer architecture comprises a first module, a switching module and a second module in sequence, wherein the first module is a client side and the second module is a simulation side; the verification method comprises the following steps: in the first module, a virtualization platform is used to start and simulate a virtual hardware device to generate hardware behavior data; the hardware behavior data is transferred to the switching module; the switching module receives the hardware behavior data from the first module and processes it to obtain target data adapted to the requirements of the second module; the processing is to convert the language format of the hardware behavior data generated by the first module into a target language format adapted to the second module based on a hardware event stream mechanism; the target data is transferred to the second module, the second module receives the target data, and performs hardware behavior simulation based on the target data.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and in particular relates to a virtualization hardware verification method based on a multi-layer architecture and a verification system for executing the verification method. Background Art

[0002] With the increasing complexity of hardware design, traditional hardware verification methods are no longer able to meet modern demands for efficiency and flexibility. In areas such as high-performance computing, embedded systems, and hardware accelerators, hardware verification often relies on physical devices, which not only increases the cost of hardware debugging but also prolongs the development cycle. Furthermore, the increasing scale of digital chips has led to increasingly lengthy simulation times, further exacerbating the difficulty and cost of verification. Therefore, improving the efficiency and reducing the cost of hardware verification have become key challenges that need to be addressed.

[0003] Existing solutions mainly include: one is to use pure software to simulate various chip functions. However, this method has discrepancies between the clock and the actual time simulation, resulting in slow simulation speed and insufficient accuracy. Another solution is to use hardware-assisted simulation methods, using FPGAs (Field-Programmable Gate Arrays) or other hardware platforms to accelerate the simulation process. However, this method still has problems such as high cost and complex debugging.

[0004] On the other hand, in hardware emulation verification, the QEMU virtualization platform simulates hardware behaviors using C, such as memory read / write, configuration read / write, and message passing. These behaviors need to be transferred to the simulation side for verification using languages ​​such as Python (e.g., the cocotb framework) and Verilog (a hardware description language). However, due to differences in data representation and semantics between C and simulation languages, existing methods suffer from the following limitations: Manual conversion is complex: developers must manually convert C data into the target language format, which is time-consuming and error-prone; inefficiency: Traditional intermediate formats (such as JSON and Protobuf) generate text data, which takes up a lot of space and has high parsing overhead, making them unsuitable for high-frequency hardware events; latency: data transmission via TCP / IP or file I / O introduces additional latency, impacting real-time simulation; limited language adaptability: existing methods lack direct support for hardware verification-specific languages ​​(such as Verilog), requiring additional conversion scripts; and limited scalability: adding new event types or target languages ​​requires rewriting the conversion logic, resulting in high maintenance costs.

[0005] Therefore, existing technologies face major challenges, including slow simulation speed, high cost, complex debugging, and insufficient simulation accuracy. Furthermore, they are unable to efficiently and automatically convert C-language hardware behavior information generated by virtualization platforms (such as QEMU) into the various language formats required for simulation (such as Python, Verilog, and Tcl). These issues not only prolong development cycles but also increase hardware verification costs, particularly in large-scale, high-performance hardware designs. Therefore, a new approach is urgently needed to address these issues, improve the efficiency and accuracy of hardware verification, and reduce development costs.

[0006] The disclosure of the above background technology content is only used to assist in understanding the inventive concept and technical solution of the present invention. It does not necessarily belong to the prior art of this patent application. In the absence of clear evidence that the above content has been disclosed before the filing date of this patent application, the above background technology should not be used to evaluate the novelty and creativity of this application. Summary of the Invention

[0007] In view of this, in order to overcome the defects of the prior art, the purpose of the present invention is to provide a virtualized hardware efficient simulation verification method based on a multi-layer architecture.

[0008] In order to achieve the above object, the present invention adopts the following technical solutions:

[0009] A virtualization hardware verification method based on a multi-layer architecture, wherein the multi-layer architecture sequentially includes a first module, a switching module, and a second module, wherein the first module is a client side and the second module is a simulation side; the verification method comprises the following steps:

[0010] In the first module, a virtualization platform is used to start and simulate virtual hardware devices to generate hardware behavior data;

[0011] delivering the hardware behavior data to the switching module;

[0012] The exchange module receives the hardware behavior data from the first module and processes it to obtain target data adapted to the requirements of the second module; the processing is to convert the language format of the hardware behavior data generated by the first module into the target language format adapted to the second module based on the Hardware Event Stream (HES) mechanism;

[0013] The target data is transferred to the second module, and the second module receives the target data and performs simulation of hardware behavior based on the target data.

[0014] The HES (Hardware Event Stream) mechanism of the present invention realizes the automatic conversion from the client-side C language hardware behavior to the simulation-side multi-language format through compact HES data flow, event mapping rule-driven conversion and shared memory transmission; its high efficiency, automation and flexibility significantly improve the efficiency of hardware verification.

[0015] According to some preferred implementation aspects of the present invention, the hardware behavior data generated by the first module is in C language data format; and the target language format is Python, Verilog or Tcl language format.

[0016] According to some preferred implementation aspects of the present invention, the HES mechanism uses event mapping rules to define event structure and target language conversion logic, including event type and its fields, field data types and field representation in the target language format.

[0017] According to some preferred implementation aspects of the present invention, the switching module is provided with a storage module and a conversion module, the storage module is used to store data, and the conversion module is used to read the data in the storage module and convert it into target data adapted to the requirements of the second module.

[0018] According to some preferred implementation aspects of the present invention, the conversion includes the following steps: converting the hardware behavior data in the C language data format generated by the first module into a HES data stream, and writing the data into a storage module of the switching module, wherein the HES data stream structure includes a header and content;

[0019] The conversion module reads the HES data stream from the storage module, parses the header to obtain the event identifier, and then loads the corresponding event mapping rules, parses the field key-value pairs in the content part, and extracts the field information;

[0020] According to the event mapping rules, the parsed field information is converted into a language-independent intermediate representation structure;

[0021] Mapping the intermediate representation structure into the target language format required by the second module according to a mapping rule of the target language format;

[0022] The target data is output based on the target language format.

[0023] This efficient and automated language conversion method achieves automated language conversion from the client side (client or QEMU) to the emulator side through a compact HES data flow, event-mapping rule-driven conversion, and shared memory transfer. Compared to existing data conversion methods like JSON and Protobuf, the HES method offers a compact data flow and automatically generates the target language format. HES dynamically adapts through mapping rules, offering greater scalability. The HES mechanism is fully implemented in software, offering a high degree of automation and multi-language support.

[0024] According to some preferred implementation aspects of the present invention, the header includes an event identifier, a timestamp, and a device identifier; and the content includes a field identifier, a content length, and a content value.

[0025] According to some preferred implementation aspects of the present invention, the simulation comprises the following steps:

[0026] The second module loads the target data, initializes the simulation environment according to the target data, and sets an initial state;

[0027] Based on the hardware behavior described by the target data, the second module performs corresponding hardware behavior verification to check whether the behavior meets expectations;

[0028] The second module records the execution results of the hardware behavior and performs timing analysis in combination with the timestamp information in the target data to verify the timing correctness of the hardware behavior;

[0029] The second module generates a simulation log containing execution details and timing information of hardware behavior and outputs it in a developer-readable format.

[0030] According to some preferred implementation aspects of the present invention, the hardware behavior includes register access, memory read and write operations, interrupt requests, and DMA requests.

[0031] According to some preferred implementation aspects of the present invention, the use of a virtualization platform to start and simulate virtual hardware devices is to use the virtualization platform to simulate hardware devices through a virtualization module, create a virtual machine environment at startup, and allocate necessary hardware resources to each virtual hardware device; when the virtual hardware device is running, the device behavior is simulated through the device model interface, and the virtualization platform manages the hardware resources.

[0032] According to some preferred implementation aspects of the present invention, the virtualization platform is QEMU; the virtual hardware device includes a single virtual device or a custom device such as a PCIe device, a DMA controller, a network adapter or an interrupt controller, a conventional I / O device, etc.; the virtualization platform QEMU selects and loads a virtualization driver module according to the virtual hardware device; when the virtual hardware device is a PCIe device, the virtualization driver module is a virtio-pci module, which is used to simulate a device based on the PCIe bus; when the virtual hardware device is a DMA controller, the virtualization driver module is a virtio-mmio module, which is suitable for memory-mapped I / O devices; when the virtual hardware device is a network adapter, the virtualization driver module is a virtio-net module: used to implement the virtual network device function.

[0033] According to some preferred implementation aspects of the present invention, the hardware resources are memory, CPU time, and I / O ports; and the management includes memory allocation strategy, CPU time slice scheduling, and I / O port virtualization.

[0034] According to some preferred implementation aspects of the present invention, the memory allocation strategy is to allocate continuous physical memory blocks through a DMA controller and lock memory pages through an mlock system call to prevent page swapping.

[0035] According to some preferred implementation aspects of the present invention, the CPU time slice scheduling adopts a priority classification strategy to avoid delays caused by resource competition; among them, the interrupt controller has the highest priority to ensure real-time response; the DMA controller has the second highest priority to support the low-latency requirements of bulk data transmission; conventional I / O devices have the default priority to handle ordinary tasks.

[0036] According to some preferred implementation aspects of the present invention, the I / O port virtualization allocates an independent port range to each virtual hardware device and implements read and write interception logic in the virtualization platform QEMU.

[0037] The present invention also provides a virtualization hardware verification system based on a multi-layer architecture, wherein the verification system is used to execute the steps included in the virtualization hardware verification method based on a multi-layer architecture as described above.

[0038] Due to the adoption of the above technical solutions, compared with the existing technology, the benefits of the present invention are: the efficient simulation and verification method of virtualized hardware based on a multi-layer architecture of the present invention modularizes the hardware verification process in a layered design, improves the flexibility and scalability of the system, and enables hardware verification to quickly adapt and adjust in different scenarios; it can accurately simulate the hardware behavior of virtual devices, including the verification of interrupts and DMA requests, to ensure that the behavior of virtual devices in the virtualization platform meets expectations; it effectively solves the dependence on physical devices in traditional hardware verification, reduces hardware debugging costs and development cycles, and is particularly suitable for hardware verification and simulation in the fields of high-performance computing, embedded systems, hardware accelerators, etc. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0040] Figure 1 Schematic diagram of the structure of a virtualized hardware verification system with a multi-layer architecture according to an embodiment of the present invention;

[0041] Figure 2 Schematic diagram of the process of initializing and simulating the virtual hardware device in step S1 in embodiment 3 of the present invention;

[0042] Figure 3 Schematic diagram of the data conversion process in Example 1 of the present invention. DETAILED DESCRIPTION

[0043] In order to enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0044] The hardware simulation of the existing technology has the following problems: the simulation speed of the pure software simulation method is slow and the simulation time is too long, which is especially obvious in large-scale and high-performance hardware design; high cost: traditional hardware verification methods rely on physical equipment, which increases the cost of hardware debugging, especially in the fields of high-performance computing, embedded systems and hardware accelerators, where the cost issue is particularly prominent; complex debugging: the debugging process of the existing hardware verification methods is complicated, which leads to an extended development cycle and affects the product's time to market; insufficient simulation accuracy: the simulation methods in the existing technology lack simulation accuracy and cannot fully simulate the behavior of actual hardware, affecting the accuracy of verification.

[0045] This invention is primarily used for efficient and flexible verification of hardware device behavior in a virtual environment. It is particularly suitable for hardware verification and simulation in fields such as high-performance computing, embedded systems, and hardware accelerators. Through a layered design (a multi-layer architecture encompassing the client side, switching modules, and simulation side), the invention simulates the behavior of actual hardware, such as verifying interrupt requests and DMA (Direct Memory Access) operations, thereby ensuring that virtual hardware devices behave as expected. This invention offers advantages such as efficient data exchange capabilities, high flexibility and scalability, significant cost savings, and accurate hardware behavior simulation. It effectively eliminates the reliance on physical devices in traditional hardware verification, reduces hardware debugging costs and development cycles, and achieves an efficient, low-cost, easy-to-debug, and highly accurate hardware verification process.

[0046] The present invention discloses a virtualized hardware verification method based on a multi-layer architecture. The multi-layer architecture sequentially comprises a first module, a switching module, and a second module. The first module serves as the client side (also known as the QEMU side), and the second module serves as the simulation side. The switching module includes a storage module and a conversion module. The verification method comprises the following steps: the first module simulates hardware, captures hardware behavior (e.g., MemoryWrite: address = 0x1000, value = 42), and generates hardware behavior data; the switching module intercepts the hardware behavior data and encodes it into a HES data stream, which is then written to the storage module; the conversion module reads the HES data stream, parses it into an intermediate representation, and generates target language output according to mapping rules; and the simulation tool (e.g., cocotb, vivado, verilator, etc.) in the second module uses the conversion results (e.g., a Python dictionary or Verilog signal) for verification.

[0047] Specifically, the virtualization hardware verification method based on the multi-layer architecture of the present invention includes the following steps:

[0048] Step S1: Initialization and simulation of virtual hardware devices (Client side)

[0049] In the first module, a virtualization platform is used to start and simulate virtual hardware devices, generate hardware behavior data, and transmit this hardware behavior data to the switching module. This step is used to build an efficient and reliable virtual hardware environment, providing a foundation for subsequent behavior transmission and simulation.

[0050] Hardware behaviors include register access, memory read and write operations, interrupt requests, and DMA requests.

[0051] Using a virtualization platform to start and simulate virtual hardware devices involves using the virtualization platform to simulate hardware devices through virtualization modules. Upon startup, a virtual machine environment is created and the necessary hardware resources are allocated to each virtual hardware device. While the virtual hardware device is running, the device behavior is simulated through the device model interface, while the virtualization platform manages the hardware resources. Hardware resources include memory, CPU time, and I / O ports; management includes memory allocation policies, CPU time slice scheduling, and I / O port virtualization.

[0052] The virtualization platform is QEMU; the virtual hardware devices include PCIe devices, DMA controllers or network adapters or interrupt controllers, regular I / O devices and other single virtual devices or custom devices.

[0053] The virtualization platform QEMU selects and loads the virtualization driver module according to the virtual hardware device. When the virtual hardware device is a PCIe device, the virtualization driver module is the virtio-pci module, which is used to simulate a device based on the PCIe bus. When the virtual hardware device is a DMA controller, the virtualization driver module is the virtio-mmio module, which is suitable for memory-mapped I / O devices. When the virtual hardware device is a network adapter, the virtualization driver module is the virtio-net module: used to implement virtual network device functions.

[0054] The memory allocation strategy is to allocate continuous physical memory blocks through the DMA controller and lock memory pages through the mlock system call to prevent page swapping.

[0055] CPU time slice scheduling adopts a priority classification strategy to avoid delays caused by resource competition. Among them, the interrupt controller has the highest priority to ensure real-time response; the DMA controller has the second highest priority to support the low-latency requirements of bulk data transmission; regular I / O devices have the default priority to handle ordinary tasks.

[0056] I / O port virtualization allocates an independent port range to each virtual hardware device and implements read and write interception logic in the virtualization platform QEMU.

[0057] Step S2: Data processing and format conversion of the switching module

[0058] The switching module receives and processes the hardware behavior data from the first module to obtain target data that meets the requirements of the second module and transmits the target data to the second module. The storage module is used to store data, and the conversion module is used to read the data in the storage module and convert it into target data that meets the requirements of the second module.

[0059] The hardware behavior data generated by the first module is in C language format; the target language format is Python, Verilog, or Tcl. Processing involves converting the language format of the hardware behavior data generated by the first module into the target language format compatible with the second module based on the HES mechanism. The HES mechanism uses event mapping rules to define the event structure and target language conversion logic, including the event type and its fields, the field data types, and the field representation in the target language format.

[0060] Specifically, the conversion includes the following steps:

[0061] Step S21: Generate HES data stream of hardware behavior data

[0062] The hardware behavior data in the C language data format generated by the first module is converted into an HES data stream and written into the storage module of the switching module. The HES data stream structure includes a header and content.

[0063] The header includes event ID, timestamp and device ID; the content includes field ID, content length and content value.

[0064] Step S22: Parse the HES data stream to extract field information

[0065] The conversion module reads the HES data stream from the storage module, parses the header to obtain the event identifier, and then loads the corresponding event mapping rules, parses the field key-value pairs in the content part, and extracts the field information.

[0066] Step S23: Load event mapping rules to generate intermediate representation

[0067] According to the event mapping rules, the parsed field information is converted into a language-independent intermediate representation structure.

[0068] Step S24: Generate target language format through intermediate representation

[0069] According to the mapping rules of the target language format, the intermediate representation structure is mapped into the target language format required by the second module.

[0070] Step S25: Output target data for simulation

[0071] Output the target data based on the target language format and pass it to the second module.

[0072] The data conversion method based on the HES mechanism of the present invention has the following technical advantages: efficient transmission: HES data flow is compact, reducing bandwidth usage; shared memory transmission achieves sub-microsecond latency; automated conversion: event mapping rules drive conversion, eliminating the need for manual coding; dynamic adaptation to languages ​​such as Python and Verilog; flexible expansion: supports multiple events and languages, and new additions only require updating rules and adapters; hardware optimization: designed for high-frequency events (such as interrupts and DMA); data streams directly map to C language types, with zero conversion overhead; debugging support: can generate human-readable output.

[0073] Step S3: Hardware behavior verification on the simulation side

[0074] The second module receives the target data and performs hardware behavior simulation based on the target data. The second module includes a simulator (such as cocotb, vivado, verilator, etc.). Specifically, the simulation includes the following steps:

[0075] Step S31: Load the simulation language format to initialize the simulation environment

[0076] The simulator loads the target data passed by the exchange module, initializes the simulation environment according to the target data, and sets the initial state.

[0077] Step S32: Execute simulation verification of hardware behavior

[0078] Based on the hardware behavior described by the target data, the simulator performs corresponding hardware behavior verification to check whether the behavior meets expectations.

[0079] Step S33: Record simulation results and perform timing analysis

[0080] The simulator records the execution results of the hardware behavior and performs timing analysis based on the timestamp information in the target data to verify the timing correctness of the hardware behavior.

[0081] Step S34: Generate simulation log to support debugging

[0082] The simulator generates simulation logs that contain execution details and timing information of hardware behavior and outputs them in a developer-readable format, enabling developers to debug and optimize hardware designs.

[0083] like Figure 1As shown, the present invention also provides a virtualization hardware verification system for executing one or more steps included in the above-mentioned virtualization hardware verification method based on a multi-layer architecture, including a first module, a switching module and a second module of a hierarchical design, the first module is the client side, the second module is the simulation side, the switching module is used to obtain data and convert it, and it is provided with a storage module and a conversion module, the storage module is used to store data, and the conversion module is used to read the data in the storage module and convert it into target data that adapts to the requirements of the second module.

[0084] The efficient, flexible, and accurate virtualized hardware verification method based on a multi-layer architecture of the present invention is significantly superior to existing technologies and has wide applicability and practicality. It has the following advantages:

[0085] 1) Multi-layer Architecture Design: This invention utilizes a multi-layered architecture, encompassing the client side, the switching module, and the simulation side. This modularizes the hardware verification process, significantly improving system flexibility and scalability. This layered design allows each module to have a clear functional division, facilitating management and optimization.

[0086] 2) Efficient Data Exchange and Format Conversion: This invention utilizes HES to enable efficient data exchange between different programming languages ​​(such as C and Python). The exchange module is responsible for converting the format of hardware behavior data, ensuring consistency and accuracy when transferring data between different layers, thereby simplifying the development process.

[0087] 3) Accurate Hardware Behavior Simulation: The simulation side uses hardware simulation tools (such as cocotb) to accurately simulate the hardware behavior of virtual devices, including verification of interrupt requests and DMA operations, ensuring that virtual devices behave as expected within the virtualization platform. This overcomes the lack of simulation accuracy in existing technologies and improves the accuracy and reliability of hardware verification.

[0088] 4) Cost and Time Optimization: This invention effectively solves the reliance on physical devices in traditional hardware verification, reducing hardware debugging costs and development cycles. It is particularly suitable for hardware verification and simulation in fields such as high-performance computing, embedded systems, and hardware accelerators, significantly improving hardware verification efficiency. Example 1

[0089] like Figure 3As shown, the automated language conversion method based on the HES (Hardware Event Stream) mechanism of this embodiment is used to efficiently and automatically convert C language hardware behavior information generated by a virtualization platform (such as QEMU) into multiple language formats required by the simulation side (such as Python, Verilog, Tcl, etc.). It is suitable for scenarios such as high-performance computing, embedded systems, and ASIC / FPGA design verification. It specifically includes the following steps:

[0090] Step S21: Generate HES data stream corresponding to hardware behavior data

[0091] Capture hardware behaviors (such as MemoryRead / Write, ConfigRead / Write, and Message) on the customer QEMU side, obtain hardware behavior data, convert the C language hardware behavior data into a HES data stream structure, including a header (event ID, timestamp, device ID) and content (field key-value pairs), and write it to the storage module.

[0092] The HES mechanism encodes the client-side hardware behavior into a compact HES data stream, which uses a binary structure and is divided into two parts: header and content.

[0093] The header is fixed at 16 bytes and includes event identifier, timestamp, and device identifier. The details are as follows:

[0094] Event ID (4 bytes), used to distinguish event types, for example: MemoryRead: ID = 1; MemoryWrite: ID = 2; ConfigRead: ID = 3; ConfigWrite: ID = 4; Message: ID = 5;

[0095] Timestamp (8 bytes): used to record the time when an event occurs and assist in timing verification.

[0096] Device ID (4 bytes): used to identify the hardware device that triggered the event.

[0097] The content part is of variable length and stores event details in the form of key-value pairs, including field identifier, content length, and content value. The details are as follows:

[0098] Field identifier (1 byte): indicates the field type (such as address = 1, value = 2).

[0099] Content-Length (1 byte): The number of bytes in the field value.

[0100] Content value (variable length): the specific data of the field (such as address value, message content).

[0101] For example, the HES data flow of the MemoryWrite event (address = 0x1000, value = 42) is as follows:

[0102] [0x00000002 | 0x1234567890ABCDEF | 0x00000001 | 0x01 | 0x08 |0x0000000000001000 | 0x02 | 0x04 | 0x0000002A]

[0103] Among them, the header: event ID = 2 (MemoryWrite), timestamp = 0x1234567890ABCDEF, device ID = 1.

[0104] Contents: Address field (identifier = 1, 8 bytes, value = 0x1000), value field (identifier = 2, 4 bytes, value = 42).

[0105] The HES mechanism supports multiple hardware behaviors, including: MemoryRead / Write: memory operations; ConfigRead / Write: configuration register operations; Message: interrupts, status notifications, etc. Other behaviors can be supported through extended mapping rules.

[0106] The HES data flow based on the HES mechanism has the following advantages:

[0107] Compactness: Compared with text formats such as JSON, HES data streams take up less space and reduce transmission overhead.

[0108] Efficient parsing: The binary format directly maps to C language data types (such as uint64_t), which allows for fast parsing.

[0109] Real-time: supports high-frequency events (such as interrupts and DMA), suitable for real-time simulation.

[0110] Step S22: Parse the HES data stream to extract field information

[0111] The conversion module reads the HES data stream from the storage module, parses the header to obtain the event identifier, and then loads the corresponding event mapping rules, parses the field key-value pairs in the content part, and extracts the field information (such as address and value).

[0112] The HES mechanism uses event mapping rules (stored in YAML format) to define the event structure and conversion logic of the target language, including: event type and its fields (such as MemoryWrite contains address and value); field data type (such as u64, u32, bytes); and how the field is represented in the target language (such as Python's int and Verilog's reg [63:0]).

[0113] Taking MemoryWrite as an example, the event mapping rules are as follows:

[0114] MemoryWrite:

[0115] fields:

[0116] address:

[0117] type: u64 # 64-bit unsigned integer

[0118] python: int # integer in Python

[0119] verilog: reg [63:0] # 64-bit register in Verilog

[0120] value:

[0121] type: u32 # 32-bit unsigned integer

[0122] python: int # integer in Python

[0123] verilog: reg [31:0] # 32-bit register in Verilog

[0124] Taking Message as an example, the event mapping rules are as follows:

[0125] Message:

[0126] fields:

[0127] msg_type:

[0128] type: u8 # 8-bit unsigned integer

[0129] python: int # integer in Python

[0130] verilog: reg [7:0] # 8-bit register in Verilog

[0131] msg_data:

[0132] type: bytes # byte array

[0133] python: bytes # Byte object in Python

[0134] verilog: reg [7:0] data [0:127] # 128-byte array in Verilog

[0135] Through the definition of event mapping rule structure, the meaning and length of each field in the HES data stream are clarified; the fields are guided to be mapped to languages ​​such as Python and Verilog to achieve language conversion; the conversion process is driven without manual coding, achieving automated conversion; support for adding new events or languages ​​only requires updating the rule file, with good scalability.

[0136] Step S23: Load event mapping rules to generate intermediate representation

[0137] According to the event mapping rules, the parsed field information is converted into a language-independent intermediate representation structure (such as the key-value pair format: {address: 0x1000, value: 42}). The field format is constrained by the mapping rules to generate an intermediate representation that can be used for language conversion.

[0138] Step S24: Generate target language format through intermediate representation

[0139] According to the mapping rules of the target language (such as Python and Verilog), the intermediate representation is mapped into the specific language format required by the simulation side (such as Python dictionary and Verilog signal assignment).

[0140] Step S25: Output target data for simulation

[0141] Output the generated simulation language format as target data recognizable by the simulator (such as {"address": 4096, "value": 42} in Python or reg [63:0] address = 64'h1000 in Verilog) for subsequent simulation steps. Adding a new language only requires defining adapters and mapping rules; there's no need to modify the conversion module.

[0142] That is, the conversion module in this embodiment is used to parse the HES data stream and generate the target language format. The steps are as follows:

[0143] 1. Read the HES data stream from the storage module.

[0144] 2. Parse the header to extract the event ID, timestamp, and device ID.

[0145] 3. Load the event mapping rules based on the event ID and determine the field structure.

[0146] 4. Parse the key-value pairs in the content part to form an intermediate representation (such as {address: 0x1000, value: 42}).

[0147] 5. Convert to the target language format according to the mapping rules.

[0148] For example, for a MemoryWrite event (address = 0x1000, value = 42), the corresponding intermediate representation is: {address: 0x1000, value: 42}; Python output: {"address": 4096, "value": 42}; Verilog output: reg [63:0]address = 64'h1000;reg [31:0]value = 32'd42.

[0149] The HES data stream is stored in the storage module and transferred between the first module and the exchange module. The conversion module extracts the HES data stream and ultimately converts it into target data, which is then passed to the second module. This achieves zero-copy transmission with low latency, making it suitable for high-frequency events. The second module uses the converted results (such as Python dictionaries and Verilog signals) for verification.

[0150] The above data conversion method can automatically convert the hardware behaviors (such as MemoryRead / Write, ConfigRead / Write, Message) described in C language on the customer's QEMU side into the language formats such as Python and Verilog required by the simulation side; support low-latency transmission and fast parsing of high-frequency hardware events; adapt to a variety of hardware behaviors and target languages, and have high scalability; simplify the development process and improve hardware verification efficiency.

[0151] The following uses MemoryWrite as an example to illustrate the data conversion process:

[0152] Input: MemoryWrite (address = 0x1000, value = 42)

[0153] HES data flow:

[0154] [0x00000002 | 0x1234567890ABCDEF | 0x00000001 | 0x01 | 0x08 |0x0000000000001000 | 0x02 | 0x04 | 0x0000002A]

[0155] Output:

[0156] Python: {"address": 4096, "value": 42}

[0157] Verilog:

[0158] reg [63:0] address = 64'h1000;

[0159] reg [31:0] value = 32'd42

[0160] The following uses Message as an example to illustrate the data conversion process:

[0161] Input: Message (msg_type=1, msg_data="0x1A2B")

[0162] HES data flow:

[0163] [0x00000005 | 0x1234567890ABCDEF | 0x00000001 | 0x01 | 0x01 | 0x01 |0x02 | 0x02 | 0x1A2B]

[0164] Output:

[0165] Python: {"msg_type": 1, "msg_data": b"\x1A\x2B"}

[0166] Verilog:

[0167] reg [7:0] msg_type = 8'h01;

[0168] reg [7:0] msg_data [0:1];

[0169] initial begin

[0170] msg_data[0] = 8'h1A;

[0171] msg_data[1] = 8'h2B;

[0172] end

[0173] Example 2

[0174] This embodiment is used to receive target data transmitted by the switching module and perform hardware behavior simulation based on the target data, including the following steps:

[0175] Step S31: Load the simulation language format to initialize the simulation environment

[0176] The simulator (such as cocotb, vivado, verilator, etc.) loads the simulation language format (such as Python dictionary or Verilog signal assignment) generated by the data conversion step, initializes the simulation environment according to the language format, and sets the initial state (such as register value, signal state).

[0177] Step S32: Execute simulation verification of hardware behavior

[0178] Based on the hardware behavior described in the simulation language format (such as the address and value of MemoryWrite), the simulator performs corresponding hardware behavior verification to check whether the behavior meets expectations (such as whether the register value is updated correctly).

[0179] Step S33: Record simulation results and perform timing analysis

[0180] The simulator records the execution results of the hardware behavior (such as signal changes and status updates), and combines them with the timestamp information in the target data to perform timing analysis to verify the timing correctness of the hardware behavior.

[0181] Step S34: Generate simulation log to support debugging

[0182] The simulator generates detailed simulation logs that contain execution details and timing information of hardware behaviors (such as the address, value, and timestamp of MemoryWrite), and outputs them in a developer-readable format to support developers in debugging and optimizing hardware designs. Example 3

[0183] like Figures 1 to 3 As shown, the virtualized hardware verification method based on the multi-layer architecture of this embodiment is used to achieve efficient, flexible, and low-cost virtualized hardware simulation verification, including the following steps:

[0184] Step S1: Initialization and simulation of virtual hardware devices (Client side)

[0185] On the client side, the QEMU virtualization platform is used to start and emulate virtual hardware devices, ensuring their behavior is consistent with real hardware and effectively interacts with the emulated side. QEMU uses virtualization modules (such as virtio) to emulate a variety of devices, including PCIe devices, DMA controllers, network adapters or interrupt controllers, regular I / O devices, and custom devices. During startup, QEMU creates a virtual machine environment and allocates the necessary hardware resources (such as memory, CPU time, and I / O ports) to each device. The behavior of virtual hardware devices is simulated through device model interfaces, such as configuration register accesses and memory-mapped I / O (MMIO) operations.

[0186] QEMU dynamically selects and loads virtualization driver modules based on device types to adapt to different hardware requirements. The module selection rules are as follows:

[0187] PCIe device: virtio-pci module, used to simulate devices based on PCIe bus.

[0188] DMA controller: virtio-mmio module, suitable for memory-mapped I / O devices.

[0189] Network adapter: virtio-net module, which implements virtual network device functions.

[0190] Custom device: Users inject custom driver modules through plug-in interfaces (such as .so or .dll files).

[0191] Virtio is a virtualized I / O standard designed to improve the performance of virtual devices. It achieves efficient data exchange by defining front-end and back-end drivers (the front-end resides within the virtual machine, and the back-end resides in QEMU). For example, virtio-pci emulates devices using the PCIe interface, while virtio-net provides virtualized networking functions. Virtio's advantages lie in its standardization and lightweight nature, reducing virtualization overhead.

[0192] At the same time, to ensure the efficiency and real-time performance of virtual devices, QEMU manages hardware resources in a refined manner, isolates device ports to avoid conflicts, and supports accurate simulation of hardware operations (such as serial port data reading and writing). This includes memory allocation strategies, CPU time slice scheduling, and I / O port virtualization, as follows:

[0193] Memory allocation strategy: Allocate continuous physical memory blocks to the DMA controller and lock memory pages through the mlock system call to prevent page swapping and ensure real-time transmission.

[0194] DMA transfers require continuous physical addresses. Fragmented or swapped memory can lead to discontinuous addresses or missing pages, causing transfer interruptions. mlock locks memory, eliminating the risk of page swaps and ensuring the integrity and real-time performance of DMA operations.

[0195] CPU time slice scheduling: adopts a priority classification strategy to avoid delays caused by resource competition:

[0196] Interrupt controller: The highest priority, ensuring real-time response (such as interrupt triggering).

[0197] DMA controller: The second highest priority, supports low latency requirements for bulk data transfer.

[0198] Conventional I / O devices: Default priority, handles common tasks.

[0199] In traditional virtualization, all devices compete equally for CPU resources, and high-real-time operations (such as interrupts) are easily delayed. This priority scheduling ensures that critical tasks are executed first, preventing simulation timing distortion.

[0200] I / O port virtualization: Allocate an independent port range for each device (such as serial port 0x3F8-0x3FF) and implement read and write interception logic in the QEMU device model to simulate hardware operations (such as register access, MMIO).

[0201] The dynamically loaded virtio modules and resource scheduling in this step optimize virtual device performance; memory locking and priority scheduling ensure the real-time and correctness of key operations; and support for custom modules adapts to diverse device requirements.

[0202] The generation of hardware behavior data is actively initiated by the simulation side, and the virtual device simulated by the QEMU side responds and returns the hardware behavior data. At this time, the returned hardware behavior data is intercepted and converted by the middle layer (switch module), that is, the following step S2, corresponding to Example 1.

[0203] Step S2: Data processing and format conversion of the switching module

[0204] The switching module bridges different programming languages ​​and tools, ensuring compatibility and accuracy of data transmitted across layers. It receives and processes hardware behavior data from the client to adapt it to the requirements of the simulation side.

[0205] In a multi-layered architecture-based approach to efficient virtualized hardware simulation and verification, the switching module is a key intermediary layer connecting the client side (the QEMU virtualization platform) and the simulation side. Its core function is to receive, process, and convert the hardware behavior data generated by QEMU to meet the processing requirements of the simulation side. After the hardware behavior data is transmitted to the switching module, the switching module is responsible for receiving the message and performing the necessary format conversion so that the simulation side can accurately perform simulation and verification tasks based on the converted target data.

[0206] The specific steps are shown in Example 1 and will not be described again here.

[0207] Step S3: Hardware behavior verification on the simulation side

[0208] The second module accurately reproduces hardware behavior based on target data, improving verification reliability and accuracy. On the simulation side, hardware behavior data is received from the switch module and simulated for verification, simulating the hardware's response to these behaviors. The simulation side uses a hardware simulation tool (such as cocotb) to initialize a virtual hardware device model and initiates simulation based on the hardware behavior data delivered by the switch module. The simulation side configures the virtual device based on the received data and performs corresponding verification tasks, including interrupt handling and DMA operation verification, to ensure that the behavior meets expectations.

[0209] The specific steps are shown in Example 2 and will not be described again here.

[0210] The main advantages of this invention are as follows: 1) Efficient Data Exchange: Through format conversion based on the HES mechanism, data exchange between different programming languages ​​and tools is efficient and compatible. This design simplifies the development process, enabling smooth data transfer between languages ​​like C and Python, avoiding compatibility issues caused by language differences. 2) High Flexibility and Scalability: This invention utilizes a layered design to modularize the hardware verification process, significantly improving the system's flexibility and scalability. This design allows the hardware verification process to quickly adapt and adjust to different needs, supporting the verification requirements of a wide range of complex hardware. 3) Reduced Hardware Debugging Costs: This invention effectively eliminates the traditional reliance on physical devices in hardware verification, reducing hardware debugging costs and development cycles. This is particularly important for hardware verification and simulation in fields such as high-performance computing, embedded systems, and hardware accelerators, helping to shorten product time to market and reduce R&D costs. 4) Accurate Hardware Behavior Simulation: The simulation side accurately simulates the hardware behavior of virtual devices, including the verification of interrupts and DMA requests, ensuring that virtual devices behave as expected within the virtualization platform. Complex hardware interactions are verified through interrupt and DMA simulation, ensuring accurate transmission and verification of hardware behavior, and improving verification accuracy and reliability.

[0211] The above-described embodiments, prepared by the methods of the present invention, are intended only to illustrate the technical concepts and features of the present invention. Their purpose is to enable those skilled in the art to understand the present invention and implement it accordingly. They are not intended to limit the scope of protection of the present invention. Any equivalent variations or modifications made in accordance with the spirit and substance of the present invention are intended to be encompassed within the scope of protection of the present invention.

Claims

1. A virtualization hardware verification method based on a multi-layer architecture, characterized in that: The multi-layer architecture includes a first module, a switching module, and a second module in sequence, wherein the first module is a client side and the second module is a simulation side; the verification method includes the following steps: In the first module, a virtualization platform is used to start and simulate virtual hardware devices to generate hardware behavior data; delivering the hardware behavior data to the switching module; The exchange module receives the hardware behavior data from the first module and processes it to obtain target data adapted to the requirements of the second module; the processing is to convert the language format of the hardware behavior data generated by the first module into the target language format adapted to the second module based on the hardware event stream mechanism; passing the target data to the second module, the second module receiving the target data and performing a simulation of hardware behavior based on the target data; The hardware event flow mechanism uses event mapping rules to define the event structure and the conversion logic of the target language, including the event type and its fields, the data type of the field and the representation of the field in the target language format; The conversion comprises the following steps: converting the hardware behavior data in the C language data format generated by the first module into an HES data stream and writing the data into the storage module of the switching module, wherein the HES data stream structure includes a header and content; The conversion module reads the HES data stream from the storage module, parses the header to obtain the event identifier, and then loads the corresponding event mapping rules, parses the field key-value pairs in the content part, and extracts the field information; According to the event mapping rules, the parsed field information is converted into a language-independent intermediate representation structure; Mapping the intermediate representation structure into the target language format required by the second module according to a mapping rule of the target language format; The target data is output based on the target language format.

2. The verification method according to claim 1, wherein: The hardware behavior data generated by the first module is in C language data format; the target language format is Python, Verilog or Tcl language format.

3. The verification method according to claim 1, wherein: The switching module is provided with a storage module and a conversion module. The storage module is used to store data, and the conversion module is used to read the data in the storage module and convert it into target data that meets the requirements of the second module.

4. The verification method according to claim 1, wherein: The header includes an event identifier, a timestamp, and a device identifier; the content includes a field identifier, a content length, and a content value.

5. The verification method according to claim 1, wherein: The simulation comprises the following steps: The second module loads the target data, initializes the simulation environment according to the target data, and sets an initial state; Based on the hardware behavior described by the target data, the second module performs corresponding hardware behavior verification to check whether the behavior meets expectations; The second module records the execution results of the hardware behavior and performs timing analysis in combination with the timestamp information in the target data to verify the timing correctness of the hardware behavior; The second module generates a simulation log containing execution details and timing information of hardware behavior and outputs it in a developer-readable format.

6. The verification method according to claim 1, wherein: The hardware behavior includes register access, memory read and write operations, interrupt requests and DMA requests.

7. The verification method according to claim 1, wherein: The use of a virtualization platform to start and simulate virtual hardware devices is to use the virtualization platform to simulate hardware devices through a virtualization module, create a virtual machine environment at startup, and allocate necessary hardware resources to each virtual hardware device; when the virtual hardware device is running, the device behavior is simulated through the device model interface, and the virtualization platform manages the hardware resources.

8. The verification method according to claim 7, characterized in that: The virtualization platform is QEMU; the virtual hardware device includes a PCIe device, a DMA controller, a network adapter, an interrupt controller or an I / O device; the virtualization platform QEMU selects and loads a virtualization driver module according to the virtual hardware device; when the virtual hardware device is a PCIe device, the virtualization driver module is a virtio-pci module; when the virtual hardware device is a DMA controller, the virtualization driver module is a virtio-mmio module; when the virtual hardware device is a network adapter, the virtualization driver module is a virtio-net module.

9. The verification method according to claim 7, characterized in that: The hardware resources include memory, CPU time, and I / O ports; the management includes memory allocation strategy, CPU time slice scheduling, and I / O port virtualization.

10. The verification method according to claim 9, characterized in that: The memory allocation strategy is to allocate continuous physical memory blocks through a DMA controller and lock memory pages through an mlock system call.

11. The verification method according to claim 9, characterized in that: The CPU time slice scheduling adopts a priority classification strategy; among which, the interrupt controller has the highest priority; the DMA controller has the second highest priority; and the I / O device has the default priority.

12. The verification method according to claim 9, characterized in that: The I / O port virtualization allocates an independent port range to each virtual hardware device and implements read and write interception logic in the virtualization platform QEMU.

13. A virtualized hardware verification system based on a multi-layer architecture, characterized in that: The verification system is used to execute the virtualization hardware verification method based on multi-layer architecture as described in any one of claims 1 to 12.

Images