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

Abstract

The invention discloses a virtualization hardware verification method and verification system based on a multi-layer architecture, the multi-layer architecture sequentially comprises a first module, an exchange module and a second module, the first module is a client side, and the second module is a simulation side; the verification method comprises the following steps: starting and simulating virtual hardware equipment in a first module by adopting a virtualization platform, and generating hardware behavior data; transmitting the hardware behavior data to the exchange module; the switching module receives the hardware behavior data from the first module and processes the hardware behavior data to obtain target data meeting the requirement 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 adaptive to a second module based on a hardware event flow mechanism; the target data is transmitted to the second module, and the second module receives the target data and executes simulation of hardware behaviors based on the target data.

Description

Technical Field

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

[0002] With the continuous increase in the complexity of hardware design, traditional hardware verification methods have been difficult to meet the modern requirements of high efficiency and flexibility. Especially in the fields of high-performance computing, embedded systems, and hardware accelerators, hardware verification usually relies on physical devices, which not only increases the cost of hardware debugging but also prolongs the development cycle. In addition, the increasing scale of digital chips has made the simulation time of chips longer and longer, which further exacerbates the difficulty and cost of verification. Therefore, how to improve the efficiency of hardware verification and reduce the verification cost has become one of the main problems to be solved urgently.

[0003] Existing solutions mainly include: one is to use a pure software method to simulate the various functions of the chip, but there are differences between the clock of this method and the actual time simulation, resulting in a slow simulation speed and insufficient accuracy; another solution is to adopt a hardware-assisted simulation method to accelerate the simulation process through an FPGA (Field-Programmable Gate Array) or other hardware platforms. However, this method still has problems such as high cost and complex debugging.

[0004] On the other hand, in hardware simulation verification, the QEMU virtualization platform simulates hardware behaviors through C language, such as memory read / write (Memory Read / Memory Write), configuration read / write (Config Read / Config Write), message passing (Message), etc. These behaviors need to be transferred to the simulation side and verified using languages such as Python (such as the cocotb framework) and Verilog (hardware description language). However, due to the differences in data representation and semantics between C language and simulation languages, the existing methods have the following limitations: complex manual conversion: developers need to manually convert C language data into the target language format, which is time-consuming and error-prone; low efficiency: traditional intermediate formats (such as JSON, Protobuf) generate text data, which occupies a large space and has a high parsing overhead, and is not suitable for high-frequency hardware events; latency problem: transmitting data through TCP / IP or file I / O introduces additional latency, affecting real-time simulation; limited language adaptation: existing methods are difficult to directly support hardware verification-specific languages (such as Verilog) and require additional scripts for conversion; lack of scalability: adding new event types or target languages requires rewriting the conversion logic, resulting in high maintenance costs.

[0005] Therefore, the main problems of the existing technology include slow simulation speed, high cost, complex debugging, insufficient simulation accuracy, etc.; at the same time, it is impossible to efficiently and automatically convert the C language hardware behavior information generated by the virtualization platform (such as QEMU) into various language formats (such as Python, Verilog, Tcl, etc.) required on the simulation side. These problems not only prolong the development cycle but also increase the cost of hardware verification, especially in large-scale and high-performance hardware designs, where these problems are more prominent. Therefore, there is an urgent need for a new method to solve these problems, improve the efficiency and accuracy of hardware verification, and reduce the development cost at the same time.

[0006] The disclosure of the above background technical content is only used to assist in understanding the inventive concept and technical solution of the present invention, and it does not necessarily belong to the prior art of this patent application. Without clear evidence indicating that the above content was publicly available before the filing date of this patent application, the above background technology should not be used to evaluate the novelty and inventiveness of this application. Summary of the Invention

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

[0008] To achieve the above object, the present invention adopts the following technical solutions: A virtualized hardware verification method based on a multi-layer architecture, the multi-layer architecture sequentially includes a first module, a switching module, and a second module. The first module is the client side, and the second module is the simulation side; the verification method includes the following steps: Start and simulate a virtual hardware device in the first module using a virtualization platform to generate hardware behavior data; Transfer the hardware behavior data to the switching module; The switching module receives the hardware behavior data from the first module and processes it to obtain target data that meets 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; Transfer the target data to the second module, and the second module receives the target data and performs simulation of hardware behavior based on the target data.

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

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

[0011] According to some preferred implementation aspects of the present invention, the HES 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 fields, and the representation of the fields in the target language format.

[0012] According to some preferred implementation aspects of the present invention, a storage module and a conversion module are provided in the exchange 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.

[0013] 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 an HES data stream and writing it into the storage module of the exchange module. 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 rule, parses the field key-value pairs in the content part, and extracts the field information. According to the event mapping rule, convert the parsed field information into a language-independent intermediate representation structure. According to the mapping rule of the target language format, map the intermediate representation structure into the target language format required by the second module. Output target data based on the target language format.

[0014] The above efficient and automated language conversion method realizes the automated language conversion from the client side (Client side or QEMU side) to the simulation side through a compact HES data stream, event mapping rule-driven conversion, and shared memory transmission. Compared with the existing data conversions such as JSON and Protobuf, the HES data stream of the present invention is compact and can automatically generate the target language format; HES is dynamically adapted through mapping rules and has stronger scalability; the HES mechanism is fully implemented in software, has a high degree of automation, and supports multiple languages.

[0015] According to some preferred implementation aspects of the present invention, 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.

[0016] According to some preferred implementation aspects of the present invention, the simulation includes the following steps: The second module loads the target data, initializes the simulation environment according to the target data, and sets the initial state; According to the hardware behavior described by the target data, the second module performs corresponding hardware behavior verification to check whether the behavior meets the expectations; The second module records the execution result of the hardware behavior, combines the timestamp information in the target data, and performs timing analysis to verify the timing correctness of the hardware behavior; The second module generates a simulation log, which includes the execution details and timing information of the hardware behavior, and outputs it in a developer-readable format.

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

[0018] According to some preferred implementation aspects of the present invention, starting and simulating virtual hardware devices using a virtualization platform means using the virtualization platform to simulate hardware devices through a virtualization module, creating a virtual machine environment at startup, and allocating necessary hardware resources for each virtual hardware device; when the virtual hardware device is running, the device behavior is simulated through the device model interface, and at the same time, the virtualization platform manages the hardware resources.

[0019] According to some preferred implementation aspects of the present invention, the virtualization platform is QEMU; the virtual hardware devices include single virtual devices such as PCIe devices, DMA controllers, network adapters, or interrupt controllers, general I / O devices, or custom devices; 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 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 devices with memory-mapped I / O; when the virtual hardware device is a network adapter, the virtualization driver module is the virtio-net module: used to implement the function of a virtual network device.

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

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

[0022] According to some preferred implementation aspects of the present invention, the CPU time slice scheduling adopts a priority grading 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 batch data transmission; the conventional I / O device has the default priority to handle ordinary tasks.

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

[0024] The present invention also provides a virtualized hardware verification system based on a multi-layer architecture, and the verification system is used to execute the steps included in the above-mentioned virtualized hardware verification method based on a multi-layer architecture.

[0025] Due to the above technical solutions, compared with the prior art, the advantages of the present invention are as follows: The virtualized hardware high-efficiency simulation verification method based on a multi-layer architecture of the present invention modularizes the hardware verification process through hierarchical design, improves the flexibility and scalability of the system, and enables the 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 the hardware debugging cost and development cycle, and is particularly suitable for hardware verification and simulation in fields such as high-performance computing, embedded systems, and hardware accelerators. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0027] Figure 1 It is a schematic structural diagram of the virtualized hardware verification system with a multi-layer architecture in the embodiments of the present invention; Figure 2 It is a schematic flow diagram of the initialization and simulation of the virtual hardware device in step S1 in Embodiment 3 of the present invention; Figure 3 It is a schematic flow diagram of data conversion in Embodiment 1 of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0028] To enable those skilled in the art to better understand the technical solution of the present invention, the technical solution 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 a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0029] The hardware emulation of the prior art has the following problems: The simulation speed of the pure software emulation method is slow and the simulation time is too long, especially obvious in large-scale and high-performance hardware designs; High cost: Traditional hardware verification methods rely on physical devices, increasing the hardware debugging cost. Especially in the fields of high-performance computing, embedded systems, and hardware accelerators, the cost issue is particularly prominent; Complicated debugging: In the existing hardware verification methods, the debugging process is complicated, resulting in an extended development cycle and affecting the product's time to market; Insufficient simulation accuracy: The simulation methods in the prior art have insufficient simulation accuracy and cannot fully simulate the behavior of the actual hardware, affecting the accuracy of verification.

[0030] The present invention is mainly used to efficiently and flexibly verify the behavior of hardware devices in a virtual environment, and is particularly suitable for hardware verification and emulation in the fields of high-performance computing, embedded systems, and hardware accelerators. Through a hierarchical design (a multi-layer architecture including the Client side, switching module, and emulation side), the present invention can simulate the behavior of the actual hardware, such as the verification of interrupt requests and DMA (Direct Memory Access) operations, so as to ensure that the behavior of the virtual hardware device meets the expectations. The present invention has advantages such as efficient data exchange capabilities, high flexibility and scalability, significant cost savings, and accurate simulation of hardware behavior, effectively solving the dependence on physical devices in traditional hardware verification, reducing the hardware debugging cost and development cycle, and realizing an efficient, low-cost, easy-to-debug, and high-precision hardware verification process.

[0031] The virtualized hardware verification method based on a multi-layer architecture of the present invention. The multi-layer architecture sequentially includes a first module, a switching module, and a second module. The first module is the client side (Client side or QEMU side), the second module is the simulation side, and a storage module and a conversion module are provided in the switching module. The steps of the verification method are mainly as follows: The first module simulates the hardware, captures the hardware behavior (such as 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, writes it into the storage module. The conversion module reads the HES data stream, parses it into an intermediate representation, and generates a target language output according to the mapping rules. The simulation tools (such as cocotb, vivado, verilator, etc.) of the second module use the conversion results (such as Python dictionary, Verilog signal) for verification.

[0032] Specifically, the virtualized hardware verification method based on a multi-layer architecture of the present invention includes the following steps: Step S1, initialization and simulation of virtual hardware devices (Client side) In the first module, a virtualization platform is used to start and simulate virtual hardware devices, generate hardware behavior data, and transfer the hardware behavior data to the switching module. This step is used to build an efficient and reliable virtual hardware environment, providing a basis for subsequent behavior transfer and simulation.

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

[0034] Using a virtualization platform to start and simulate virtual hardware devices means using the virtualization platform to simulate hardware devices through a virtualization module, creating a virtual machine environment at startup, and allocating necessary hardware resources for each virtual hardware device; when the virtual hardware device is running, the device behavior is simulated through the device model interface, and at the same time, the virtualization platform manages the hardware resources. The hardware resources are memory, CPU time, and I / O ports; the management includes memory allocation policies, CPU time slice scheduling, and I / O port virtualization.

[0035] The virtualization platform is QEMU; the virtual hardware devices include single virtual devices such as PCIe devices, DMA controllers, network adapters, or interrupt controllers, general I / O devices, or custom devices.

[0036] The virtualization platform QEMU selects and loads virtualization driver modules according to virtual hardware devices. When the virtual hardware device is a PCIe device, the virtualization driver module is the virtio-pci module, which is used to simulate devices 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 devices with memory-mapped I / O. When the virtual hardware device is a network adapter, the virtualization driver module is the virtio-net module, which is used to implement the functions of virtual network devices.

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

[0038] The CPU time slice scheduling adopts a priority grading 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 transfer. Conventional I / O devices have the default priority to handle ordinary tasks.

[0039] I / O port virtualization assigns independent port ranges to each virtual hardware device and implements read / write interception logic in the virtualization platform QEMU.

[0040] Step S2: Data processing and format conversion of the switching module The switching module receives the hardware behavior data from the first module, processes it to obtain the target data that meets the requirements of the second module, and transfers 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 the target data that meets the requirements of the second module.

[0041] The hardware behavior data generated by the first module is in the C language data format. The target language format is the Python, Verilog, or Tcl language format. 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 HES mechanism. The HES 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 fields, and the representation of the fields in the target language format.

[0042] Specifically, the conversion includes the following steps: Step S21: Generate the HES data stream of the hardware behavior data Convert the hardware behavior data in the C language data format generated by the first module into an HES data stream and write it into the storage module of the switching module. The HES data stream structure includes a header and content.

[0043] 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.

[0044] Step S22: Parse the HES data stream to extract field information The conversion module reads the HES data stream from the storage module, parses the header to obtain the event identifier, then loads the corresponding event mapping rule, parses the field key-value pairs in the content part, and extracts the field information.

[0045] Step S23: Load the event mapping rule to generate an intermediate representation According to the event mapping rule, convert the parsed field information into a language-independent intermediate representation structure.

[0046] Step S24: Generate the target language format through the intermediate representation According to the mapping rule of the target language format, map the intermediate representation structure to the target language format required by the second module.

[0047] Step S25: Output the target data for simulation use Output the target data based on the target language format and pass it to the second module.

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

[0049] Step S3: Hardware behavior verification on the simulation side The second module receives the target data and performs hardware behavior simulation based on the target data. The second module includes simulators (such as cocotb, vivado, verilator, etc.). Specifically, the simulation includes the following steps: Step S31: Load the simulation language format to initialize the simulation environment 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.

[0050] Step S32: Perform hardware behavior simulation verification According to the hardware behavior described by the target data, the simulator performs the corresponding hardware behavior verification to check whether the behavior meets the expectations.

[0051] Step S33: Record the simulation results and perform timing analysis The simulator records the execution results of the hardware behavior, and combines the timestamp information in the target data to perform timing analysis to verify the timing correctness of the hardware behavior.

[0052] Step S34: Generate a simulation log to support debugging The simulator generates a simulation log, which contains the execution details and timing information of the hardware behavior, and outputs it in a developer-readable format to support developers in debugging and optimizing the hardware design.

[0053] As Figure 1 shown, the present invention also provides a virtualized hardware verification system for executing one or more steps included in the above-described virtualized hardware verification method based on a multi-layer architecture, including a first module, a switching module, and a second module with a hierarchical design. The first module is the client side, the second module is the simulation side, and the switching module is used to obtain data and perform conversion. 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 meets the requirements of the second module.

[0054] The efficient, flexible, and accurate virtualized hardware verification method of the present invention is significantly superior to the prior art, has wide applicability and practicability, and has the following advantages: 1) Multi-layer architecture design: The present invention adopts a design idea based on a multi-layer architecture, namely the Client side, the switching module, and the simulation side, modularizes the hardware verification process, and significantly improves the flexibility and scalability of the system. Through hierarchical design, each module has a clear function division, which is convenient for management and optimization.

[0055] 2) Efficient data exchange and format conversion: The present invention uses HES to achieve efficient data exchange between different programming languages (such as C language and Python). The switching module is responsible for converting the format of the hardware behavior data to ensure the consistency and accuracy of the data when it is transmitted between different layers, thereby simplifying the development process.

[0056] 3) Accurate hardware behavior simulation: The simulation side accurately simulates the hardware behavior of the virtual device through a hardware simulation tool (such as cocotb), including the verification of interrupt requests and DMA operations, to ensure that the behavior of the virtual device in the virtualization platform meets the expectations. It overcomes the problem of insufficient simulation accuracy in the prior art and improves the accuracy and reliability of hardware verification.

[0057] 4) Cost and time optimization: The present invention effectively solves the problem of dependence on physical devices in traditional hardware verification, reducing the hardware debugging cost and development cycle. It is particularly applicable to hardware verification and simulation in fields such as high-performance computing, embedded systems, and hardware accelerators, significantly improving the hardware verification efficiency. Embodiment 1

[0058] As Figure 3 shown, the automated language conversion method based on the HES (Hardware Event Stream) mechanism in this embodiment is used to efficiently and automatically convert the C language hardware behavior information generated by a virtualization platform (such as QEMU) into various language formats (such as Python, Verilog, Tcl, etc.) required on the simulation side, and is applicable to scenarios such as high-performance computing, embedded systems, ASIC / FPGA design verification, etc. It specifically includes the following steps: Step S21, generate the HES data stream corresponding to the hardware behavior data Capture the hardware behavior (such as MemoryRead / Write, ConfigRead / Write, Message) on the customer QEMU side, obtain the hardware behavior data, convert the C language hardware behavior data into the HES data stream structure, which includes a header (event identifier, timestamp, device identifier) and content (field key-value pairs), and write it into the storage module.

[0059] The HES mechanism encodes the hardware behavior on the customer side into a compact HES data stream, adopting a binary structure, which is divided into two parts: a header and content. Among them, The header is fixed at 16 bytes and includes an event identifier, a timestamp, and a device identifier. Specifically as follows: The event identifier (4 bytes) is used to distinguish event types. For example: MemoryRead: identifier = 1; MemoryWrite: identifier = 2; ConfigRead: identifier = 3; ConfigWrite: identifier = 4; Message: identifier = 5; The timestamp (8 bytes): is used to record the event occurrence time to assist in timing verification.

[0060] The device identifier (4 bytes): is used to identify the hardware device that triggers the event.

[0061] The content part is of variable length and stores the event details in the form of key-value pairs, including a field identifier, a content length, and a content value. Specifically as follows: The field identifier (1 byte): represents the field type (such as address = 1, value = 2).

[0062] The content length (1 byte): the number of bytes of the field value.

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

[0064] For example, the HES data stream of a MemoryWrite event (address = 0x1000, value = 42) is as follows: [0x00000002 | 0x1234567890ABCDEF | 0x00000001 | 0x01 | 0x08 |0x0000000000001000 | 0x02 | 0x04 | 0x0000002A] Among them, the header: event identifier = 2 (MemoryWrite), timestamp = 0x1234567890ABCDEF, device identifier = 1.

[0065] Content: address field (identifier = 1, 8 bytes, value = 0x1000), value field (identifier = 2, 4 bytes, value = 42).

[0066] 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.

[0067] The HES data stream based on the HES mechanism has the following advantages: Compactness: Compared with text formats such as JSON, the HES data stream occupies less space and reduces transmission overhead.

[0068] Efficient parsing: The binary format directly maps to C language data types (such as uint64_t), and the parsing speed is fast.

[0069] Real-time performance: Supports high-frequency events (such as interrupts, DMA), suitable for real-time simulation.

[0070] Step S22: Parse the HES data stream to extract field information 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 rule, parses the field key-value pairs in the content part, and extracts field information (such as address, value).

[0071] The HES mechanism uses event mapping rules (stored in YAML format) to define the event structure and the conversion logic for the target language, including: the event type and its fields (e.g., MemoryWrite contains address and value); the data types of the fields (e.g., u64, u32, bytes); the representation of the fields in the target language (e.g., int in Python, reg [63:0] in Verilog).

[0072] Taking MemoryWrite as an example, the event mapping rules are as follows: MemoryWrite: fields: address: type: u64 # 64-bit unsigned integer python: int # Integer in Python verilog: reg [63:0] # 64-bit register in Verilog value: type: u32 # 32-bit unsigned integer python: int # Integer in Python verilog: reg [31:0] # 32-bit register in Verilog Taking Message as an example, the event mapping rules are as follows: Message: fields: msg_type: type: u8 # 8-bit unsigned integer python: int # Integer in Python verilog: reg [7:0] # 8-bit register in Verilog msg_data: type: bytes # Byte array python: bytes # Byte object in Python verilog: reg [7:0] data [0:127]# 128-byte array in Verilog Define the meaning and length of each field in the HES data stream through the event mapping rule structure; guide the field mapping to languages such as Python and Verilog to achieve language conversion; drive the conversion process without manual coding to achieve automatic conversion; support adding new events or languages, only need to update the rule file, with good scalability.

[0073] Step S23: Load the event mapping rules to generate an intermediate representation According to the event mapping rules, convert the parsed field information into a language-independent intermediate representation structure (such as key-value pair form: {address: 0x1000, value: 42}), and constrain the field format through the mapping rules to generate an intermediate representation for language conversion.

[0074] Step S24: Generate the target language format through the intermediate representation According to the mapping rules of the target language (such as Python, Verilog), map the intermediate representation to the specific language format required on the simulation side (such as Python dictionary, Verilog signal assignment).

[0075] Step S25: Output the target data for simulation use 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. For adding a new language, only need to define the adapter and mapping rules without modifying the conversion module.

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

[0077] 2. Parse the header to extract the event identifier, timestamp, and device identifier.

[0078] 3. Load the event mapping rules according to the event identifier to determine the field structure.

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

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

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

[0082] The HES data stream is stored in the storage module for transfer between the first module and the switching module. The conversion module extracts the HES data stream and finally converts it into target data and passes it to the second module, achieving zero-copy transfer, low latency, and being suitable for high-frequency events. The second module uses the converted results (such as Python dictionaries, Verilog signals) for verification.

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

[0084] The following takes MemoryWrite as an example to show the data conversion process: Input: MemoryWrite (address = 0x1000, value = 42) HES data stream: [0x00000002 | 0x1234567890ABCDEF | 0x00000001 | 0x01 | 0x08 | 0x0000000000001000 | 0x02 | 0x04 | 0x0000002A] Output: Python: {"address": 4096, "value": 42} Verilog: reg [63:0] address = 64'h1000; reg [31:0] value = 32'd42 The following takes Message as an example to show the data conversion process: Input: Message (msg_type = 1, msg_data = "0x1A2B") HES data stream: [0x00000005 | 0x1234567890ABCDEF | 0x00000001 | 0x01 | 0x01 | 0x01 |0x02 | 0x02 | 0x1A2B] Output: Python: {"msg_type": 1, "msg_data": b"\x1A\x2B"} Verilog: reg [7:0] msg_type = 8'h01; reg [7:0] msg_data [0:1]; initial begin msg_data[0] = 8'h1A; msg_data[1] = 8'h2B; end Example 2

[0085] This example is used to receive the target data passed by the switching module and perform a simulation of the hardware behavior based on the target data, including the following steps: Step S31, load the simulation language format to initialize the simulation environment 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 values, signal states).

[0086] Step S32, perform simulation verification of the hardware behavior According to the hardware behavior described by the simulation language format (such as the address and value of MemoryWrite), the simulator performs the corresponding hardware behavior verification to check whether the behavior meets the expectations (such as whether the register values are updated correctly).

[0087] Step S33, record the simulation results and perform timing analysis The simulator records the execution results of the hardware behavior (such as signal changes, state updates), and combines the timestamp information in the target data to perform timing analysis to verify the timing correctness of the hardware behavior.

[0088] Step S34, generate a simulation log to support debugging The emulator generates detailed simulation logs, including execution details of hardware behavior and timing information (such as the address, value, and timestamp of MemoryWrite), and outputs them in a developer-readable format to support developers in debugging and optimizing the hardware design. Embodiment 3

[0089] As Figures 1 to 3 shown, the virtualized hardware verification method based on a multi-layer architecture in this embodiment is used to achieve efficient, flexible, and low-cost virtualized hardware simulation verification, and includes the following steps: Step S1, initialization and simulation of virtual hardware devices (Client side) On the Client side, the QEMU virtualization platform is used to start and simulate virtual hardware devices, ensure that their behavior is consistent with that of real hardware, and effectively interact with the simulation side. QEMU simulates various devices through virtualization modules (such as virtio), including virtual devices such as PCIe devices, DMA controllers, network adapters or interrupt controllers, conventional I / O devices, or custom devices, and creates a virtual machine environment at startup, allocating necessary hardware resources (such as memory, CPU time, I / O ports) for each device. The behavior of virtual hardware devices is simulated through the device model interface, such as configuration register access or memory-mapped I / O (MMIO) operations.

[0090] Among them, QEMU dynamically selects and loads virtualization driver modules according to the device type to adapt to different hardware requirements. The module selection rules are as follows: PCIe device: virtio-pci module, used to simulate devices based on the PCIe bus.

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

[0092] Network adapter: virtio-net module, implementing the functions of virtual network devices.

[0093] Custom device: The user injects a custom driver module through a plugin interface (such as.so or.dll files).

[0094] 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 is inside the virtual machine, and the back-end is in QEMU). For example, virtio-pci simulates devices using the PCIe interface, while virtio-net provides virtual network functions. The advantages of Virtio lie in standardization and lightweight, reducing virtualization overhead.

[0095] Meanwhile, to ensure the high efficiency and real-time performance of virtual device operation, QEMU conducts refined management of hardware resources, isolates device ports to avoid conflicts, and simultaneously supports precise 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: Memory allocation strategy: Allocate continuous physical memory blocks for the DMA controller, and lock memory pages through the mlock system call to prevent page swapping out, ensuring transmission real-time performance.

[0096] DMA transfers require continuous physical addresses. If memory becomes fragmented or is swapped out, it may lead to discontinuous addresses or page misses, triggering transmission interruptions. mlock locks the memory, eliminating the risk of page swapping and ensuring the integrity and real-time performance of DMA operations.

[0097] CPU time slice scheduling: Adopt a priority grading strategy to avoid delays caused by resource competition: Interrupt controller: Highest priority to ensure real-time response (such as when an interrupt is triggered).

[0098] DMA controller: Second-highest priority to support the low-latency requirements of bulk data transfer.

[0099] Conventional I / O devices: Default priority to handle ordinary tasks.

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

[0101] 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).

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

[0103] The generation of hardware behavior data is initiated actively by the simulation side, and the virtual device simulated on the QEMU side responds and returns the hardware behavior data. At this time, the returned hardware behavior data is intercepted and converted by the intermediate layer (switching module), which is the following step S2, corresponding to Embodiment 1.

[0104] Step S2, Data processing and format conversion by the switching module The exchange module is used to bridge different programming languages and tools to ensure the compatibility and accuracy of cross-layer data transfer. The exchange module receives and processes the hardware behavior data from the Client side to adapt to the requirements of the simulation side.

[0105] In the efficient simulation verification method for virtualized hardware based on a multi-layer architecture, the exchange module is a key intermediate layer connecting the Client side (QEMU virtualization platform) and the simulation side. Its core function is to receive, process, and convert the hardware behavior data generated by QEMU to adapt to the processing requirements of the simulation side. After the hardware behavior data is transmitted to the exchange module, the exchange module is responsible for receiving the messages and performing necessary format conversions so that the subsequent simulation side can accurately carry out the simulation verification task based on the converted target data.

[0106] For the specific steps, please refer to Embodiment 1 and will not be elaborated here.

[0107] Step S3: Hardware behavior verification on the simulation side The second module accurately reproduces the hardware behavior based on the target data to improve the reliability and accuracy of the verification. On the simulation side, it receives the hardware behavior data from the exchange module and performs simulation verification to simulate the response of the hardware to these behaviors. The simulation side uses a hardware simulation tool (such as cocotb) to initialize the virtual hardware device model and starts the simulation process according to the hardware behavior data transmitted by the exchange module. The simulation side configures the virtual device according to the received data and performs corresponding verification tasks, including interrupt handling and DMA operation verification, to ensure that the behaviors meet the expectations.

[0108] For the specific steps, please refer to Embodiment 2 and will not be elaborated here.

[0109] The main advantages of the present invention are as follows: 1) Efficient data exchange: Through the format conversion function based on the HES mechanism, it ensures that data exchange between different programming languages and tools becomes efficient and compatible. This design simplifies the development process, enabling data to be smoothly transferred between languages such as C and Python, avoiding compatibility issues caused by language differences; 2) High flexibility and scalability: The present invention adopts a hierarchical design, modularizing the hardware verification process, significantly improving the flexibility and scalability of the system. This design enables the hardware verification process to quickly adapt and adjust according to different requirements, supporting the verification needs of various complex hardware; 3) Reducing hardware debugging costs: The present invention effectively solves the problem of dependence on physical devices in traditional 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 the product launch time and reduce R & D costs; 4) Accurately simulating hardware behavior: The simulation side can accurately simulate the hardware behavior of virtual devices, including the verification of interrupts and DMA requests, ensuring that the behavior of virtual devices in the virtualization platform meets expectations. Through interrupt and DMA simulations, complex hardware interactions are verified, ensuring the accurate transmission and verification of hardware behavior, and improving the accuracy and reliability of verification.

[0110] The above embodiments obtained by the method of the present invention are only for illustrating the technical concept and features of the present invention, and the purpose is to enable those skilled in the art to understand the content of the present invention and implement it accordingly, and it cannot be used to limit the protection scope of the present invention. Any equivalent changes or modifications made according to the spirit and essence of the present invention should be covered within the protection scope of the present invention.

Claims

1. A virtualized hardware verification method based on a multi-layer architecture, characterized in that The multi-layer architecture sequentially includes a first module, a switching module, and a second module. The first module is the client side, and the second module is the simulation side. The verification method includes the following steps: Start and simulate virtual hardware devices in the first module using a virtualization platform to generate hardware behavior data; Transfer the hardware behavior data to the switching module; The switching module receives the hardware behavior data from the first module and processes it to obtain target data that meets 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; Transfer the target data to the second module. The second module receives the target data and performs simulation of hardware behavior based on the target data.

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

3. The verification method according to claim 1, wherein The hardware event stream mechanism is to define the event structure and the conversion logic of the target language using event mapping rules, including the event type and its fields, the data type of the fields, and the representation of the fields in the target language format.

4. The verification method according to claim 1, wherein A storage module and a conversion module are provided in the switching 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.

5. The verification method according to claim 1, characterized in that The conversion includes the following steps: Convert the hardware behavior data in the C language data format generated by the first module into a HES data stream and write it into the storage module of the switching module. 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, then loads the corresponding event mapping rule, parses the field key-value pairs in the content part, and extracts the field information; According to the event mapping rule, convert the parsed field information into an intermediate representation structure independent of the language; According to the mapping rule of the target language format, map the intermediate representation structure into the target language format required by the second module; Output target data based on the target language format.

6. The verification method according to claim 5, characterized in that, 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.

7. The verification method according to claim 1, wherein The simulation includes the following steps: The second module loads the target data, initializes the simulation environment according to the target data, and sets the initial state; According to the hardware behavior described by the target data, the second module performs corresponding hardware behavior verification to check whether the behavior meets the expectations; The second module records the execution result of the hardware behavior, combines the timestamp information in the target data, and performs timing analysis to verify the timing correctness of the hardware behavior; The second module generates a simulation log, including the execution details and timing information of the hardware behavior, and outputs it in a developer-readable format.

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

9. The verification method according to claim 1, characterized in that The above-mentioned use of a virtualization platform to start and simulate virtual hardware devices means using a virtualization platform to simulate hardware devices through a virtualization module, creating a virtual machine environment at startup, and allocating 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 at the same time, the virtualization platform manages the hardware resources.

10. The verification method according to claim 9, characterized in that, The virtualization platform is QEMU; the virtual hardware devices include PCIe devices, DMA controllers, network adapters, interrupt controllers, or I / O devices; the virtualization platform QEMU selects and loads virtualization driver modules according to the virtual hardware devices; when the virtual hardware device is a PCIe device, the virtualization driver module is the virtio-pci module; when the virtual hardware device is a DMA controller, the virtualization driver module is the virtio-mmio module; when the virtual hardware device is a network adapter, the virtualization driver module is the virtio-net module.

11. The verification method according to claim 9, wherein The hardware resources are memory, CPU time, and I / O ports; the management includes memory allocation policies, CPU time slice scheduling, and I / O port virtualization.

12. The verification method according to claim 11, wherein The memory allocation policy is to allocate continuous physical memory blocks through the DMA controller and lock memory pages through the mlock system call.

13. The verification method according to claim 11, wherein The CPU time slice scheduling adopts a priority grading strategy; among them, the interrupt controller has the highest priority; the DMA controller has the second highest priority; the I / O device has the default priority.

14. The verification method according to claim 11, wherein The I / O port virtualization allocates an independent port range to each virtual hardware device and implements read / write interception logic in the virtualization platform QEMU.

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

Images