Chip simulation and verification system

Abstract

This application relates to a chip simulation and verification system. The system includes: a host-side testing module, a host-side data conversion module, an instantiation and interface module, a chip-side data conversion module, and a chip-side testing module. Since verification personnel only need to implement the interface conversion function—that is, converting upper-layer data to hardware virtio protocol data through the chip-side and host-side data conversion modules—it avoids requiring verification personnel to learn about the virtualization business of various projects, write cumbersome result comparison code, simulate the host-side IO generation process, simulate the entire virtio driver, design rm and checker as in the UVM architecture, and avoid the errors that may result from rewriting cumbersome code. This significantly reduces the workload of verification personnel, enables the rapid construction of the verification platform, and greatly improves verification efficiency and quality.

Description

Technical Field

[0001] This application relates to the field of chip verification technology, and in particular to a chip simulation verification system. Background Technology

[0002] With the rapid development of the cloud computing industry, some hardware implementations of virtio backend devices have emerged, such as smart network interface cards (NICs) and data processing units (DPUs). Hardware products typically require chip verification. In related technologies, chip verification primarily uses the Universal Verification Methodology (UVM) architecture, which places very high demands on verification personnel. They not only need to be familiar with the logical requirements of the virtio protocol implementation but also be proficient in the functionality of the virtio frontend driver. This significantly increases the workload of the verification process and reduces verification efficiency. Summary of the Invention

[0003] Therefore, it is necessary to provide a chip simulation and verification system that can improve verification efficiency and verification quality to address the aforementioned technical problems.

[0004] This application provides a chip simulation and verification system for simulating and verifying chips based on the Virtio protocol. The system includes: a host-side testing module, a host-side data conversion module, an instantiation and docking module, a chip-side data conversion module, and a chip-side testing module.

[0005] The chip-side testing module is used to acquire application configuration information and send it to the chip-side data conversion module. The chip-side data conversion module is used to convert the application configuration information into hardware configuration information that the chip can recognize and send the hardware configuration information to the instantiation and docking module. The instantiation and docking module is used to configure and initialize the chip according to the hardware configuration information.

[0006] The host-side testing module is used to generate first stimulus data using a first testing tool and send the first stimulus data to the host-side data conversion module; the host-side data conversion module is used to convert the first stimulus data into first test data recognizable by the chip and send it to the instantiation and docking module; the instantiation and docking module is used to send the first test data to the chip and return the first hardware processing result obtained by the chip based on the first test data to the host-side data conversion module; the host-side data conversion module is used to convert the first hardware processing result into a first test result recognizable by the first testing tool and return it to the host-side testing module; the host-side testing module is used to verify the first test result using the first testing tool.

[0007] In one embodiment, the host-side data conversion module includes at least one of a first register adapter submodule, a first Ethernet interface adapter submodule, or a first direct memory access submodule; the first register adapter submodule, the first Ethernet interface adapter submodule, and the first direct memory access submodule are all used to send the first test data to the instantiation docking module;

[0008] The first register adapter submodule interacts with the instantiation docking module through inter-process communication, and the first Ethernet interface adapter submodule and the first direct memory access submodule interact with the instantiation docking module through shared memory; inter-process communication includes message queues.

[0009] In one embodiment, the first testing tool is a network semi-virtualization testing tool, and the first stimulus data is network test stimulus data; the host-side testing module and the host-side data conversion module interact with each other through a virtual network device.

[0010] In one embodiment, the first testing tool is a virtual disk testing tool, and the first stimulus data is virtual disk stimulus data; the host-side testing module and the host-side data conversion module interact with each other through shared files.

[0011] In one embodiment, the host-side testing module is further configured to stop the simulation verification and report an error using a first testing tool when a data transmission error is detected; and to output a performance report based on the verification results when the simulation verification is completed.

[0012] In one embodiment, the chip-side testing module is further configured to generate second stimulus data using a second testing tool and send the second stimulus data to the chip-side data conversion module; the chip-side data conversion module is further configured to convert the second stimulus data into second test data recognizable by the chip and send it to the instantiation docking module; the instantiation docking module is further configured to send the second test data to the chip and return the second hardware processing result obtained by the chip processing the second test data to the chip-side testing module; the chip-side testing module is further configured to convert the second hardware processing result into a second test result recognizable by the second testing tool and return it to the chip-side testing module; the chip-side testing module is further configured to verify the second test result using the second testing tool.

[0013] In one embodiment, the chip-side data conversion module includes at least one of a second register adapter submodule, a second Ethernet interface adapter submodule, or a second direct memory access submodule; the second register adapter submodule, the second Ethernet interface adapter submodule, and the second direct memory access submodule are all used to send the second test data to the instantiation docking module.

[0014] The second register adapter submodule interacts with the instantiation docking module via inter-process communication, and the second Ethernet interface adapter submodule and the second direct memory access submodule interact with the instantiation docking module via shared memory; inter-process communication includes message queues.

[0015] In one embodiment, the second testing tool is a network semi-virtualization testing tool, and the second stimulus data is network test stimulus data; the chip-side data conversion module and the chip-side testing module interact with each other through a virtual network device.

[0016] In one embodiment, the chip-side test module is also used to start the network interface card (NIC) control process and generate application configuration information through the NIC control process.

[0017] In one embodiment, the chip-side test module is further configured to start a virtual disk processing process when a virtual disk processing request is detected, and process the virtual disk processing request through the virtual disk processing process; the virtual disk processing process communicates with the network card control process through remote procedure calls, the remote procedure calls including the Thrift process.

[0018] Compared to traditional UVM-based simulation verification platforms, the aforementioned chip simulation verification system eliminates the need for verification personnel to understand the upper-layer virtualization operations based on the virtio protocol, such as host-side behaviors, the generation and distribution of various IO requests, and message queue structures for data interaction. Instead, they can utilize testing tools to simulate these operations, including simulating various data formats across multiple hosts, devices, and queues, and performing data verification and performance analysis. Verification personnel only need to implement interface conversion functions, namely, converting upper-layer data to hardware virtio protocol data through chip-side and host-side data conversion modules. This avoids the need for verification personnel to learn about the virtualization operations of various projects, write cumbersome result comparison code, simulate the host-side IO generation process, simulate the entire virtio driver, design rm and checker mechanisms as in the UVM architecture, and avoid the potential errors caused by rewriting heavy code. Consequently, it significantly reduces the workload of verification personnel, enabling the verification platform to be built quickly and greatly improving verification efficiency and quality.

[0019] Furthermore, by utilizing testing tools, multi-process simulation can be performed, resulting in fast simulation speeds and abundant checkpoints. This effectively exposes problems and defects during the simulation phase, facilitating rapid analysis and localization of code issues. Finally, because the aforementioned architecture connects simulation verification with real-world application devices, it avoids the need to design separate test cases for simulation-level and accelerator-level verification. This allows for the reuse of simulation and board-level test cases, reducing the workload of verification personnel and significantly improving verification efficiency and quality. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the structure of a smart network interface card in one embodiment;

[0021] Figure 2 This is a schematic diagram of a chip simulation and verification system based on UVM in one embodiment;

[0022] Figure 3 This is a schematic diagram of the chip simulation and verification system in one embodiment;

[0023] Figure 4 This is a schematic diagram of the chip simulation verification system in another embodiment;

[0024] Figure 5 This is a schematic diagram of the chip simulation verification system in another embodiment;

[0025] Figure 6 This is a schematic diagram of the chip simulation and verification system in another embodiment;

[0026] Figure 7 This is a schematic diagram of the chip simulation verification system in one embodiment. Detailed Implementation

[0027] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0028] First, a brief explanation of the terms used in the embodiments of this application will be provided:

[0029] The virtio protocol: virtio is an I / O paravirtualization solution, a set of general-purpose I / O device virtualization programs, and an abstraction of a set of general-purpose I / O devices in a paravirtualized hypervisor. It provides a communication framework and programming interface between upper-layer applications and various hypervisor virtualization devices (KVM, Xen, VMware, etc.), reducing compatibility issues caused by cross-platform issues and greatly improving driver development efficiency. Specifically, virtio is a general-purpose paravirtualized I / O framework through which the hypervisor simulates a series of virtualized devices. The virtio framework mainly consists of three parts: the front-end driver, the back-end device, and the Virtqueue. The front-end driver is the driver corresponding to the virtio emulation device inside the virtual machine (such as the common virtio-net and virtio-blk). The role of the front-end driver is to receive user-space requests, encapsulate these requests according to the protocol, and send them to the back-end device. Backend devices are typically implemented in QEMU (or can be implemented in the kernel). They receive I / O requests from the frontend driver, parse the received data, complete the send / receive requests from the actual physical device, and finally notify the frontend driver via an interrupt mechanism. Data between the frontend and backend is exchanged through virtqueues; a single virtio device can register several virtqueues.

[0030] Integrated circuit verification: This is performed along with the design before tape-out. The main purpose of verification is to ensure the correctness and completeness of the chip's logic functions.

[0031] DPU: A new type of programmable processor that integrates three key elements. A DPU is a System-on-Chip (SoC) that combines an industry-standard, high-performance, and software-programmable multi-core CPU, typically based on the widely used Arm architecture, working closely with its SoC components. Additionally, it incorporates a high-performance network interface, capable of parsing and processing data at line speed or available network speeds, and efficiently transferring data to the GPU and CPU. Finally, it integrates various flexible and programmable acceleration engines that can offload AI, machine learning, security, telecommunications, and storage applications, thereby improving performance.

[0032] UVM is a verification platform development framework based on the SystemVerilog class library. It can be used to build functional verification environments with standardized hierarchical structures and interfaces using its reusable components.

[0033] Host side: refers to the physical host side, corresponding to the main machine (host machine).

[0034] SoC side: System-on-a-chip side, corresponding to system-on-a-chip products, such as smart network cards.

[0035] testcase: test case.

[0036] QEMU is a free software suite that emulates a computer. It does not include or depend on the KVM (Kernel-based Virtual Machine) module. QEMU virtual machines are purely software-implemented and can run independently without the KVM module, but with relatively low performance. QEMU provides a complete virtual machine implementation, including processor virtualization, memory virtualization, and I / O device virtualization. QEMU is a user-space process that needs to access the functions provided by the KVM module through specific interfaces. From QEMU's perspective, during virtual machine execution, QEMU uses the system call interfaces provided by the KVM module to configure the kernel, and the KVM module is responsible for placing the virtual machine in a special processor mode. QEMU utilizes the virtualization capabilities of the KVM module to provide hardware virtualization acceleration for its virtual machines, thereby improving virtual machine performance.

[0037] Hypervisor, also known as VMM (Virtual Machine Monitor), is the software, firmware, or hardware used to create and execute virtual machines. The computer used by the hypervisor to run one or more virtual machines is called the host machine, and these virtual machines are called guest machines. The hypervisor provides a virtual operating platform to execute guest operating systems and manages the execution phase of these guest operating systems, which share virtualized hardware resources.

[0038] PCIe (Peripheral Component Interconnect Express) is a high-speed serial computer expansion bus standard. It is a high-speed serial point-to-point dual-channel high-bandwidth transmission standard. Each connected device is allocated its own channel bandwidth and does not share the bus bandwidth. It mainly supports active power management, error reporting, end-to-end reliable transmission, hot-plugging, and Quality of Service (QoS) functions.

[0039] ddr (Double Data Rate SDRAM): It transmits data twice in one clock cycle, once during the rising phase and once during the falling phase of the clock.

[0040] MAC (Media Access Control) layer: Primarily defines how data frames are transmitted over the medium. In a link sharing the same bandwidth, access to the connection medium is "first-come, first-served." Physical addressing is defined here, as is the logical topology (the path of signals through the physical topology). Line control, error notification (without correction), frame delivery order, and optional flow control are also implemented in this sublayer.

[0041] IP core: An IP core refers to a logic block or data block used in application-specific integrated circuits (ASICs) or programmable logic devices (PLDs). It allows for the design of commonly used but complex functional blocks in digital circuits, such as FIR (Finite Impulse Response) filters, SDRAM (Synchronous Dynamic Random-Access Memory) controllers, and PCI (Peripheral Component Interconnect) interfaces, into modules with modifiable parameters. This allows other users to directly call these modules, significantly reducing the workload of verification personnel and avoiding repetitive work. As CPLDs / FPGAs become larger and more complex, the use of IP cores is a growing trend.

[0042] Checker: In the UVM architecture, the verification component is responsible for simulating design behavior and functional verification tasks. This verification component can cache data collected from various monitor verification components; it can aggregate data from the DUT input interface side of the device under test to the built-in RM; and it can also check whether the actual collected DUT output interface data is consistent with the expected data generated by the reference model through data comparison.

[0043] Based on the above definitions, taking the Virtio protocol chip as an example, which is a smart network interface card (NIC), such as... Figure 1The diagram shows a smart network interface card (NIC) implemented based on the VirtIO protocol. The design is mainly divided into two parts: host-side logic and SoC-side logic. The host side primarily implements the standard VirtIO protocol, while the SoC side mainly implements some NIC control logic and standard VirtIO protocol logic. PCIe, DDR, and MAC are all implemented using IP cores. To improve simulation speed, a top-level system typically includes these functional blocks for full-function system-level testing. To simulate and verify the smart NIC, it is necessary to... Figure 1 The IPcore module provides a simulation verification framework to form a simulation verification system.

[0044] Therefore, a simulation verification framework based on UVM is provided in related technologies, and the corresponding simulation verification system can be referenced. Figure 2 .exist Figure 2 In the test suite, the `tb_vseq` module is primarily used for generating stimuli. It generates different sequence number (seq) requests based on the test cases, simulating the generation and distribution of upper-layer I / O requests on the host or SoC side. The `vseqr` module distributes different stimulus data to their respective agent modules. Each agent module has a different function. For example, within the `reg` module, the driver module sends register data, which is then sent from the platform to the DUT (Data Usage Outlet), while the monitor module collects register data and sends it to the `rm` module.

[0045] For DMA or DDR agent modules, their driver modules generate different responses based on the read / write requests sent by the DUT, while their monitor modules collect and upload data according to the request signals. The RM module serves as a reference model to implement the smart NIC functionality. The SCB module is used for verification; it is implemented within the RM module. Data sent to the DUT and data returned by the DUT are processed by the RM module and then uploaded to the SCB module for verification and comparison, thereby validating the correctness of the entire design.

[0046] The specific workflow mentioned above is as follows: Test cases are instantiated in the `tb_testcase` class. The `vseqr` module sends stimulus data to each agent module according to different test cases. Then, each driver module sends different stimulus data to the DUT. At the same time, each monitor module also collects data from the interface and sends it to the `rm` module. After processing, it is sent to the scoreboard for verification and comparison. Specifically, for network card output, there is a dedicated monitor module for receiving network card output results, which is also sent to the scoreboard for comparison.

[0047] Since the aforementioned simulation verification systems are all built on the UVM architecture, it is extremely difficult for verification personnel to simulate the CPU behavior on the entire host or SoC side when performing verification based on the UVM architecture. This is mainly because verification personnel need to have a very deep understanding of the upper-layer virtualization services. For example, when simulating the CPU on the host or SoC side, they need to have a thorough understanding of the allocation and usage principles of devices such as VMs, device groups, virtio-blk, virtio-net, and virtio-crypto (e.g., understanding the allocation principles when these devices are assigned as primary network interfaces, elastic network interfaces, and blk devices), and also understand the generation and distribution of various IO requests. In addition, they need to understand the structure of various queues under each device. For example, they need to understand the tx queue, rx queue, and control queue of virtio-net. Furthermore, each queue supports multiple packet structures and supports multiple queues, multiple devices, multiple device groups, multiple VMs, and multiple hosts. Verification personnel need to understand all of these different combinations. As a result, verification personnel will spend a lot of time learning various behaviors on the host side. If simulation personnel misunderstand the requirements, and the developers also misunderstand them, overlooking bugs could pose a significant risk. After understanding the requirements, verification personnel need to translate them into code, paying attention to code conciseness to avoid cumbersome code that reduces simulation efficiency and increases the workload of verification personnel.

[0048] Furthermore, since the verification process requires simulating driver behavior, and there is currently no dedicated virtualization protocol documentation explaining the driver code structure, a significant amount of time is required to learn and understand the driver code, leading to low verification efficiency and the risk of misunderstanding. In addition, because UVM is incompatible with driver code, existing virtio drivers cannot be fully utilized. Verification personnel need to write separate code to simulate the virtio driver and debug this code, resulting in overall low efficiency. At the same time, undetected bugs may be carried over to the next level of code.

[0049] In addition to simulation-level verification, chip verification also requires accelerator-level verification (corresponding to different verification methods). For complex chips like smart network interface cards (NICs) based on the virtio protocol, thousands or even tens of thousands of test cases are needed to cover the verification. Currently, it is common practice to design one set of test cases for simulation-level verification and another set for accelerator-level verification, which results in a huge workload.

[0050] Finally, the implementation of the comparator checker and the reference model (RM) used to simulate hardware functions in the UVM architecture is quite complex. The RM needs to simulate the entire virtio protocol, requiring verification personnel to be familiar with the entire virtualization protocol. For verification personnel new to this field, this requires a significant amount of time to learn the protocol, as well as to design the checker. If the requirements are not fully understood, bugs may be missed in later testing processes, leading to very low efficiency.

[0051] Based on the above definitions and the technical problems raised in related technologies, in one embodiment, a chip simulation and verification system is provided. For example... Figure 3 As shown, Figure 3 This is primarily a simplified diagram illustrating the functional division of the system framework. This system can simulate and verify chips based on the Virtio protocol. The chips applicable to this system can be smart network interface cards (NICs) or other hardware products; this application embodiment does not specifically limit their application. For ease of explanation, this application embodiment uses a smart NIC as the chip in its description. The system includes: a host-side testing module 301, a host-side data conversion module 302, an instantiation and interfacing module 303, a chip-side data conversion module 304, and a chip-side testing module 305.

[0052] The chip-side test module 305 is used to acquire application configuration information and send the application configuration information to the chip-side data conversion module 304; the chip-side data conversion module 304 is used to convert the application configuration information into chip-recognizable hardware configuration information and send the hardware configuration information to the instantiation interface module 303; the instantiation interface module 303 is used to configure and initialize the chip according to the hardware configuration information.

[0053] The host-side test module 301 is used to generate first stimulus data through a first test tool and send the first stimulus data to the host-side data conversion module 302; the host-side data conversion module 302 is used to convert the first stimulus data into first test data that can be recognized by the chip and send it to the instantiation and docking module 303; the instantiation and docking module 303 is used to send the first test data to the chip and return the first hardware processing result obtained by the chip based on the first test data to the host-side data conversion module 302; the host-side data conversion module 302 is used to convert the first hardware processing result into a first test result that can be recognized by the first test tool and return it to the host-side test module 301; the host-side test module 301 is used to verify the first test result through the first test tool.

[0054] The application configuration information is primarily used to configure various functions of the smart network interface card (NIC), such as virtual switching, security features, multi-queue functionality, and virtual multi-NIC functionality. As the underlying hardware, the smart NIC needs to convert received upper-layer data into logically recognizable lower-layer data based on the virtio protocol through the chip-side data conversion module 304 and the host-side data conversion module 302. In other words, the chip-side data conversion module 304 converts the application configuration information into hardware configuration information recognizable by the smart NIC. After receiving the hardware configuration information, the smart NIC can complete the configuration and initialization of various functions based on it. Based on the application configuration information, not only can the smart NIC be configured, but the host side can also detect available NIC devices.

[0055] The first testing tool can be used to test disk performance or network performance. This application embodiment does not specifically limit the test items of the testing tool. Different types of stimulus data correspond to different test items. Taking network performance testing as an example, the stimulus data can be network data packets. After the network data packets are processed by the smart network card, hardware processing results used to provide feedback on packet loss rate or packet sending performance can be obtained. After being converted into test results recognizable by the host-side data conversion module 302, the testing tool can verify the test results to check their correctness.

[0056] In the above embodiments, compared to traditional simulation verification platforms based on the UVM architecture, verification personnel do not need to understand the upper-layer virtualization services based on the virtio protocol, such as various behaviors on the host side, the generation and issuance of various IO requests, and the message queue structure used for data interaction. Instead, they can use testing tools to simulate the upper-layer virtualization services based on the virtio protocol. For example, they can simulate various data format messages from multiple hosts, multiple devices, and multiple queues, and can also perform data verification and performance analysis. Verification personnel only need to implement the interface conversion function, that is, to convert upper-layer data to hardware virtio protocol data through chip-side data conversion modules and host-side data conversion modules. This avoids verification personnel from learning and understanding the virtualization services of each project, writing heavy result comparison code, simulating the IO generation process on the host side, simulating the entire virtio driver, designing rm and checker as in the UVM architecture, and avoiding errors that may result from rewriting heavy code. This greatly reduces the workload of verification personnel, enables the construction of the verification platform to be completed in a short time, and greatly improves verification efficiency and quality.

[0057] Furthermore, by utilizing testing tools, multi-process simulation can be performed, resulting in fast simulation speeds and abundant checkpoints. This effectively exposes problems and defects during the simulation phase, facilitating rapid analysis and localization of code issues. Finally, because the aforementioned architecture connects simulation verification with real-world application devices, it avoids the need to design separate test cases for simulation-level and accelerator-level verification. This allows for the reuse of simulation and board-level test cases, reducing the workload of verification personnel and significantly improving verification efficiency and quality.

[0058] In some embodiments, the host-side data conversion module includes at least one of a first register adapter submodule, a first Ethernet interface adapter submodule, or a first direct memory access submodule; the first register adapter submodule, the first Ethernet interface adapter submodule, and the first direct memory access submodule are all used to send the first test data to the instantiation docking module;

[0059] The first register adapter submodule interacts with the instantiation docking module through inter-process communication, and the first Ethernet interface adapter submodule and the first direct memory access submodule interact with the instantiation docking module through shared memory; inter-process communication includes message queues.

[0060] Specifically, the first register adapter submodule (reg adaptor) primarily sends a portion of the first stimulus data to the instantiated docking module via a register channel. This register channel can be implemented based on inter-process communication (IPC), which can further be implemented using a message queue. Additionally, the reg adaptor implements the register channel's send / receive functions (reg receive and regsend). The first Ethernet interface adapter submodule (mac adaptor) primarily sends a portion of the first stimulus data to the instantiated docking module via an Ethernet interface. The mac adaptor implements the Ethernet interface's send / receive functions (mac client and mac server). The first direct memory access (DMA) submodule (dma adaptor) primarily sends a portion of the first stimulus data to the instantiated docking module via direct memory access. The dma adaptor implements the Ethernet interface's send / receive functions (dma client and dma server).

[0061] Based on the above, the process of sending the first test data will now be described. Specifically, when the host-side data conversion module detects the data stream of the first stimulus data transmitted from the host-side test module, it can parse the data stream to obtain information such as the data stream type, length, host_id, vf_id, queue_id, and 5-tuple, and reconstruct it into first test data with a data structure based on virt-queue that can be recognized by the smart network card. The host-side data conversion module places a portion of the first test data into the shared memory DMA memory, which is then sent to the instantiation docking module by the first Ethernet interface adaptation submodule and the first direct memory access submodule, respectively. The other portion of the data is sent to the instantiation docking module through a message queue.

[0062] In the above embodiments, since the verifiers only need to implement the interface conversion function, the workload of the verifiers can be greatly reduced, the verification platform can be built in a short time, and the verification efficiency and verification quality can be greatly improved.

[0063] In some embodiments, the first testing tool is a network semi-virtualization testing tool, and the first stimulus data is network test stimulus data; the host-side testing module and the host-side data conversion module interact with each other through a virtual network device.

[0064] Specifically, network semi-virtualization testing tools may include iperf or net-perf, and this application embodiment does not specifically limit them. iperf is a third-party network performance testing tool based on virtio-net, capable of testing TCP and UDP bandwidth quality, and can also obtain network packet loss rate or packet sending performance through UDP testing. net-perf is also a third-party network performance testing tool based on virtio-net, primarily targeting TCP or UDP-based transmissions. Depending on the application, it can perform different modes of network performance testing, such as bulk data transfer mode and request / response mode.

[0065] Virtual network devices can be tun and tap, which are virtual network devices within the operating system kernel. Unlike ordinary devices implemented using hardware network adapters, these virtual network devices are all implemented in software and provide the software running on the operating system with the same functionality as hardware network devices.

[0066] tun is a virtual network device at the network layer, capable of sending and receiving Layer 3 data packets, such as IP packets, and is therefore commonly used in point-to-point IP tunnels, such as OpenVPN and IPSec. tap is a virtual network device at the link layer, equivalent to an Ethernet device, capable of sending and receiving Layer 2 data packets, such as Ethernet frames. The most common use of tap is as a network interface card (NIC) for virtual machines, mainly because it is more similar to a regular physical NIC, and it is also frequently used as a virtual NIC for regular machines.

[0067] In the above embodiments, since network semi-virtualization testing tools can be used to simulate upper-layer virtualization services based on virtio-net, verification personnel only need to implement interface conversion functions, which can greatly reduce the workload of verification personnel, enable the construction of the verification platform in a short time, and greatly improve verification efficiency and verification quality.

[0068] In some embodiments, the first testing tool is a virtual disk testing tool, and the first stimulus data is virtual disk stimulus data; the host-side testing module and the host-side data conversion module interact with each other through shared files.

[0069] Specifically, virtual disk testing tools can include fio, a third-party disk performance testing tool based on virtio-net, which can be used to stress test and verify hardware. Disk I / O is an important indicator for checking disk performance, and can be divided into two main categories according to the load: sequential read / write and random read / write. fio can be used to test disk IOPS (Input / Output Operations Per Second).

[0070] In the above embodiments, since virtual disk testing tools can be used to simulate upper-layer virtualization services based on virtio-blk, verification personnel only need to implement interface conversion functions, which can greatly reduce the workload of verification personnel, enable the construction of the verification platform in a short time, and greatly improve verification efficiency and verification quality.

[0071] In some embodiments, the host-side testing module is further configured to stop the simulation verification and report an error using a first testing tool when a data transmission error is detected; and to output a performance report based on the verification results when the simulation verification is completed.

[0072] Taking iperf as the first testing tool as an example, after receiving the IO processing result (corresponding to the first hardware processing result), iperf can verify the IO processing result. If a data transfer operation is detected, it can stop generating stimulus data, halt the simulation verification, and issue an error. If the simulation verification is complete, it can print out an IO performance report.

[0073] In the above embodiments, since the first testing tool can be used to verify errors and output a verification performance report after the simulation verification is completed, the verification quality is improved.

[0074] In some embodiments, the chip-side testing module is further configured to generate second stimulus data using a second testing tool and send the second stimulus data to the chip-side data conversion module; the chip-side data conversion module is further configured to convert the second stimulus data into second test data recognizable by the chip and send it to the instantiation interface module; the instantiation interface module is further configured to send the second test data to the chip and return the second hardware processing result obtained by the chip processing the second test data to the chip-side testing module; the chip-side testing module is further configured to convert the second hardware processing result into a second test result recognizable by the second testing tool and return it to the chip-side testing module; the chip-side testing module is further configured to verify the second test result using the second testing tool.

[0075] Specifically, the above embodiments mainly involve verification on the host side, while the embodiments of this application mainly involve verification on the SoC side. The specific verification process can be referred to the content of the above embodiments, and will not be repeated here.

[0076] In the above embodiments, since verification personnel only need to implement the interface conversion function—that is, to convert upper-layer data to hardware virtio protocol data through the chip-side data conversion module and the host-side data conversion module—the workload of verification personnel can be greatly reduced, enabling the verification platform to be built in a short time, and greatly improving verification efficiency and quality. Furthermore, by utilizing testing tools, multi-process simulation can be performed, resulting in fast simulation speed and abundant checkpoints, effectively exposing problems and defects during the simulation stage, thus facilitating rapid analysis and localization of code issues. Finally, because the above architecture can connect simulation verification with real-world application devices, it avoids the need to design separate test cases for simulation-level verification and accelerator-level verification, enabling the reuse of simulation and board-level test cases, thereby reducing the workload of verification personnel and greatly improving verification efficiency and quality.

[0077] In some embodiments, the chip-side data conversion module includes at least one of a second register adapter submodule, a second Ethernet interface adapter submodule, or a second direct memory access submodule; the second register adapter submodule, the second Ethernet interface adapter submodule, and the second direct memory access submodule are all used to send the second test data to the instantiation docking module.

[0078] The second register adapter submodule interacts with the instantiation docking module via inter-process communication, and the second Ethernet interface adapter submodule and the second direct memory access submodule interact with the instantiation docking module via shared memory; inter-process communication includes message queues.

[0079] The descriptions of the second register adapter submodule, the second Ethernet interface adapter submodule, and the second direct memory access submodule can be found in the descriptions of the first register adapter submodule, the first Ethernet interface adapter submodule, and the first direct memory access submodule in the above embodiments, and will not be repeated here.

[0080] In the above embodiments, since the verifiers only need to implement the interface conversion function, the workload of the verifiers can be greatly reduced, the verification platform can be built in a short time, and the verification efficiency and verification quality can be greatly improved.

[0081] In some embodiments, the second testing tool is a network semi-virtualization testing tool, and the second stimulus data is network test stimulus data; the chip-side data conversion module and the chip-side testing module interact with each other through a virtual network device.

[0082] The second testing tool can be iperf or net-perf, and relevant descriptions can be found in the above embodiments, which will not be repeated here.

[0083] In the above embodiments, since network semi-virtualization testing tools can be used to simulate upper-layer virtualization services based on virtio-net, verification personnel only need to implement interface conversion functions, which can greatly reduce the workload of verification personnel, enable the construction of the verification platform in a short time, and greatly improve verification efficiency and verification quality.

[0084] In some embodiments, the chip-side test module is also used to start the network interface card (NIC) control process and generate application configuration information through the NIC control process.

[0085] In the above embodiments, since the smart network card can be configured through the network card control program, a convenient interface can be provided for verification personnel, thereby improving verification efficiency.

[0086] In some embodiments, the chip-side testing module is further configured to, upon detecting a virtual disk processing request, initiate a virtual disk processing process to process the virtual disk processing request; the virtual disk processing process communicates with the network interface card control process via remote procedure calls, the remote procedure calls including the Thrift process.

[0087] The virtual disk processing process can be represented by the VTGT process. The VTGT process can remain in a waiting state until it receives a virtual disk processing request, at which point the chip-side test module can initiate the virtual disk processing. Virtual disk processing requests typically involve processing large files. The virtual disk processing process can divide the requested file into network data based on virtio-net and then transfer it to the corresponding disk for storage via the virtual network.

[0088] In the above embodiments, since virtual disk testing tools can be used to simulate upper-layer virtualization services based on virtio-blk, verification personnel only need to implement interface conversion functions, which can greatly reduce the workload of verification personnel, enable the construction of the verification platform in a short time, and greatly improve verification efficiency and verification quality.

[0089] For ease of understanding, the five modules mentioned above—host-side testing module, host-side data conversion module, instantiation and interface module, chip-side data conversion module, and chip-side testing module—are represented by host_test_program, host_wrapper, tb_top, soc_wrapper, and soc_test_program, respectively. The following is a detailed explanation of these five modules in light of practical applications.

[0090] The structural diagram and connection diagram between host_test_program and host_wrapper can be found in the following reference. Figure 4 A diagram illustrating the structure and connection between host_wrapper and tb_top can be found here. Figure 5 A diagram illustrating the structure and connection between tb_top and soc_wrapper can be found here. Figure 6 A diagram illustrating the structure and connection between soc_wrapper and soc_test_program can be found here. Figure 7 . Figures 3 to 7 The curved arrow represents the process.

[0091] exist Figure 4 In this framework, `host_test_program` generates host stimulus data, verifies the results, and performs performance analysis. FIO is a virtual disk testing tool, while `iperf` and `net-perf` are network paravirtualization testing tools. `host_test_program` and `host_wrapper` exchange virtual disk-related data via shared files. Using a network interface card (NIC) simulated by the tun / tap virtual network device (virtio-net), `host_test_program` and `host_wrapper` can exchange network-related data.

[0092] The `host_wrapper` performs data conversion, primarily transforming data generated by testing tools into a virtio-based hardware data format recognizable by the smart network interface card (NIC) before sending it to `tb_top`. The reg channel is implemented using a reg FIFO message queue for inter-process communication. Internally, `host_wrapper` includes a reg adaptor that implements the `reg send` and `reg receive` functions for register channel data interaction. The DMA and MAC data channels are implemented using shared memory. DMA data uses the `DMA mem` shared memory, while MAC data uses `mac0 mem` and `mac1 mem`. `host_wrapper` internally implements DMA and MAC adaptors, each with its own server, client, server, and client functions, ultimately enabling the transfer of DMA and MAC data. A comparator (checker) can also be implemented internally within `host_wrapper` as needed.

[0093] exist Figure 5 In this code, `tb_top` is responsible for sending received data from the reg, DMA, or MAC interfaces to the smart network interface card (NIC). Simultaneously, it returns the smart NIC's output to the host wrapper or soc wrapper. Internally, `tb_top` instantiates the smart NIC, implements the `reg send` and `reg receive` functions for the reg channel, and also implements the server and client functions for DMA and MAC.

[0094] exist Figure 6 For more information on soc_wrapper, please refer to the above explanation of host_wrapper. Similarly, soc_wrapper can also internally implement a comparator checker as needed.

[0095] exist Figure 7In the `soc_test_program`, there are three main programs: a control program for the smart network interface card (NIC), a VTGT program, and a third program for testing. The control and VTGT processes interact via Thrift processes. The `soc_test_program` also includes a third program, the test program. The NIC on the SoC side can run standard virtio-net test programs such as net-perf and iperf. Similarly, the SoC test program can send stimulus data via a NIC (virtio-net) simulated by a tun / tap virtual network device.

[0096] Those skilled in the art will understand that Figures 3 to 7 The structure shown is merely a block diagram of a portion of the structure related to the solution of this application and does not constitute a limitation on the chip simulation and verification system to which the solution of this application is applied. A specific chip simulation and verification system may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0097] To facilitate understanding, and considering the structure of the chip simulation and verification system described above, the operation process of the chip simulation and verification system will now be illustrated using the virtio-net test flow as an example:

[0098] (1) Start the network card control program and VTGT program in soc_test_program. Start them as two separate processes, and these two processes communicate with each other via Thift. The network card control program mainly configures the various functions of the smart network card to ensure that the host side can detect the available network card. This is the first process to start. The VTGT program waits and processes any BLK-related requests. This is the second process to start.

[0099] (2) Start the two processes soc_wrapper and tb_top. soc_wrapper mainly implements the interface conversion and sends the configuration information to tb_top through the register channel to complete the configuration and initialization of various specifications of tb_top. This is the third and fourth process.

[0100] (3) Start the host_test_program process, which will start the test cases. The specific process is to start the iperf test software, configure information such as the size and number of packets to be sent, send packets, and wait for the processing result of the smart network card. This is the fifth process.

[0101] (4) Start the host_wrapper process. When data input is detected in host_test_program, parse the data stream to obtain necessary information such as data type, length, host_id, vf_id, queue_id, and 5-tuple. Reassemble it into test data that the smart network card can recognize and is based on the virt-queue data structure. Store the test data in shared memory and send the test data to tb_top through shared memory and reg message queue to trigger the smart network card to start data processing. This is the sixth process.

[0102] (5) When the tb_top process detects a request for processing test data, the smart network interface card (NIC) will process the request and obtain the processing result. If necessary, the data can be sent to the SoC side for processing before returning to the smart NIC. The processing result is then returned to the host_wrapper via shared memory. The host_wrapper can detect the data upload, and after processing the data, it will send it to the host_test_program. The iperf process in the host_test_program will receive the data and perform content verification on the I / O. If a data transmission error is detected, an error will be reported and the simulation will stop. Finally, after all I / O operations are processed, a performance report can be printed. At this point, a basic virtio-net test process is complete.

[0103] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0104] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0105] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A chip simulation and verification system, characterized in that, The system includes: a host-side testing module, a host-side data conversion module, an instantiation and docking module, a chip-side data conversion module, and a chip-side testing module; The chip-side testing module is used to acquire application configuration information and send the application configuration information to the chip-side data conversion module; the chip-side data conversion module is used to convert the application configuration information into hardware configuration information based on the virtio protocol and recognizable by the chip, and send the hardware configuration information to the instantiation interface module; the instantiation interface module is used to configure and initialize the chip according to the hardware configuration information. The host-side testing module is used to generate first stimulus data using a first testing tool and send the first stimulus data to the host-side data conversion module; the host-side data conversion module is used to convert the first stimulus data into first test data recognizable by the chip and send it to the instantiation and docking module; the instantiation and docking module is used to send the first test data to the chip and return the first hardware processing result obtained by the chip based on the first test data to the host-side data conversion module; the host-side data conversion module is used to convert the first hardware processing result into a first test result recognizable by the first testing tool and return it to the host-side testing module; the host-side testing module is used to verify the first test result using the first testing tool; the first testing tool is used to simulate upper-layer virtualization services based on the virtio protocol.

2. The system according to claim 1, characterized in that, The host-side data conversion module includes at least one of a first register adaptation submodule, a first Ethernet interface adaptation submodule, or a first direct memory access submodule; the first register adaptation submodule, the first Ethernet interface adaptation submodule, and the first direct memory access submodule are all used to send the first test data to the instantiation docking module. The first register adapter submodule interacts with the instantiation docking module via inter-process communication, and both the first Ethernet interface adapter submodule and the first direct memory access submodule interact with the instantiation docking module via shared memory; the inter-process communication includes message queues.

3. The system according to claim 2, characterized in that, The first testing tool is a network semi-virtualization testing tool, and the first stimulus data is network test stimulus data; the host-side testing module and the host-side data conversion module interact with each other through a virtual network device.

4. The system according to claim 2, characterized in that, The first testing tool is a virtual disk testing tool, and the first stimulus data is virtual disk stimulus data; the host-side testing module and the host-side data conversion module interact with each other through shared files.

5. The system according to claim 1, characterized in that, The host-side testing module is also used to stop the simulation verification and report an error when a data transmission error is detected, using the first testing tool; and to output a performance report based on the verification results when the simulation verification is completed.

6. The system according to claim 1, characterized in that, The chip-side testing module is further configured to generate second stimulus data using a second testing tool and send the second stimulus data to the chip-side data conversion module; the chip-side data conversion module is further configured to convert the second stimulus data into second test data recognizable by the chip and send it to the instantiation interface module; the instantiation interface module is further configured to send the second test data to the chip and return the second hardware processing result obtained by the chip based on the second test data to the chip-side testing module; the chip-side testing module is further configured to convert the second hardware processing result into a second test result recognizable by the second testing tool and return it to the chip-side testing module; the chip-side testing module is further configured to verify the second test result using the second testing tool.

7. The system according to claim 6, characterized in that, The chip-side data conversion module includes at least one of a second register adapter submodule, a second Ethernet interface adapter submodule, or a second direct memory access submodule; the second register adapter submodule, the second Ethernet interface adapter submodule, and the second direct memory access submodule are all used to send the second test data to the instantiation docking module; The second register adapter submodule interacts with the instantiation docking module via inter-process communication, and the second Ethernet interface adapter submodule and the second direct memory access submodule interact with the instantiation docking module via shared memory; the inter-process communication includes message queues.

8. The system according to claim 7, characterized in that, The second testing tool is a network semi-virtualization testing tool, and the second stimulus data is network test stimulus data; the chip-side data conversion module and the chip-side testing module interact with each other through a virtual network device.

9. The system according to claim 1, characterized in that, The chip-side testing module is also used to start the network interface card (NIC) control process and generate the application configuration information through the NIC control process.

10. The system according to claim 9, characterized in that, The chip-side testing module is also used to start a virtual disk processing process when a virtual disk processing request is detected, and to process the virtual disk processing request through the virtual disk processing process; the virtual disk processing process communicates with the network card control process through remote procedure calls, and the remote procedure calls include a Thrift process.

Images