A chip testing method, testing platform and device

Abstract

Embodiments of the present application provide a chip test method, a test platform and equipment, the method comprising: obtaining a simulation verification mode, the simulation verification mode comprising: Virtio module level verification and PCIe-to-Virtio subsystem level verification; compiling corresponding DUT code and verification environment code according to the simulation verification mode; performing simulation verification by using test cases, a Host side Virtio driver simulating a test scene set according to the test cases, calling a corresponding register adapter, and verifying different simulation verification modes based on the same test cases. In the embodiments of the present application, automatic adaptation of a to-be-tested design DUT and a verification environment instantiation is realized, and when Virtio module level verification and PCIe-to-Virtio subsystem level verification are performed, the test cases can be fully reused, thereby accelerating chip verification convergence and shortening the verification period.

Description

Technical Field

[0001] This invention relates to the field of chip verification technology, and in particular to a chip testing method, testing platform and equipment. Background Technology

[0002] In smart network interface card (NIC) chips, PCIe (Peripheral Component Interconnect Express) and Virtio (Virtual I / O Device) are two key core functional modules. When testing smart NIC chips, depending on the chip's size, complexity, simulation speed, localization difficulty, and convergence speed, module-level verification of Virtio and subsystem-level verification of PCIe-to-Virtio are required.

[0003] In existing technologies, chip verification involves building two verification platforms: one at the module level and another at the subsystem level. This results in two verification platforms and two sets of test cases, leading to low reusability, redundant work, increased manpower requirements, and slow verification convergence. Therefore, achieving reusability to accelerate chip verification convergence is a problem that needs to be solved in verifying Virtio modules and PCIe-to-Virtio subsystems. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention provide a chip testing method, system, and device to overcome or at least partially solve the above problems.

[0005] A first aspect of this invention discloses a chip testing method, the method comprising:

[0006] Obtain the simulation verification mode, which includes: Virtio module-level verification and PCIe-to-Virtio subsystem-level verification;

[0007] Compile the corresponding DUT code and verification environment code according to the simulation verification mode;

[0008] Simulation verification is performed using test cases. The host-side Virtio driver simulates the test scenarios set by the test cases and calls the corresponding register adapter to verify different simulation verification modes based on the same test cases.

[0009] Optionally, obtaining the simulation verification mode includes:

[0010] Read the verification script from the test platform;

[0011] Based on the verification script, the simulation verification mode is obtained from the user's command line for running test cases or from the regression script.

[0012] Optionally, compiling the corresponding DUT code and verification environment code according to the simulation verification mode includes:

[0013] Read the verification script from the test platform;

[0014] For Virtio module-level verification, select the Virtio DUT file list and the corresponding verification environment instantiation interface from the verification script, and compile the verification environment code list;

[0015] For PCIe-to-Virtio subsystem-level verification, the PCIe and Virtio DUT file lists are selected from the verification script, and the corresponding verification environment instantiation and verification environment code lists are compiled.

[0016] Optionally, the Host-side Virtio driver simulates the test scenarios set according to the test cases, including:

[0017] The Host-side Virtio driver simulation, based on the test cases, simulates the generation and dispatch of upper-layer IO requests on the Host side, and simulates the structure maintenance of queues under various devices.

[0018] Optionally, the Host-side Virtio driver simulation, based on the test cases, simulates the generation and distribution of upper-layer IO requests on the Host side, including:

[0019] For configuring Virtio DUT register operations, the host-side Virtio driver calls the register model in the test platform and uses the register model to send the register read and write operation timing to the DUT;

[0020] For Virtio DMA operations, the host-side Virtio driver simulates the direct generation of DMA read / write bus timing operations based on data transmission and reception requests, and sends the DMA read / write timing operations to the DUT.

[0021] Optionally, the register model is used to send the register read / write operation timing to the DUT, including:

[0022] For Virtio module-level verification, the data is converted using the App adapter module in the test platform, and then the register read / write operation timing is sent to the DUT using the Driver module in the App agent module.

[0023] For PCIe-to-Virtio subsystem level verification, the data is converted using the PCIe adapter in the test platform, and then the register read / write operation timing is sent to the DUT using the Driver module in the PCIe VIP.

[0024] Optionally, after sending the DMA read / write timing operation to the DUT, the method further includes the following functional test for the DUT sending data to the Virtio device:

[0025] Collect DMA read operation data and send the collected DMA data to the reference model for processing to obtain the reference model processing result;

[0026] The data sent by the DUT to the Virtio device is collected, and the processing result of the reference model is compared with the data sent by the DUT to the scoreboard to check whether the sending behavior of the DUT is correct.

[0027] Optionally, after sending the DMA read / write timing operation to the DUT, the method further includes the following functional test for the DUT receiving data from the Virtio device:

[0028] The DUT receives data sent from the Virtio device and collects the data received by the DUT. The collected data received by the DUT is then sent to the reference model for processing to obtain the processing result of the reference model.

[0029] Collect DMA write operation data and send the collected DMA write operation data and the processing results of the reference model to the scoring board for comparison to check whether the DUT receiving behavior is correct.

[0030] A second aspect of this invention discloses a testing platform for performing the chip testing method described in the first aspect of this invention, the testing platform comprising:

[0031] Verification script, which is used to obtain the simulation verification mode and select the list of code files of the compiled DUT according to the simulation verification mode;

[0032] Test cases, which include test cases under various test scenarios, are used to verify different simulation verification modes;

[0033] Host-side Virtio driver simulation is used to simulate the IO generation process and Virtio driver on the host side, including: simulating the generation and distribution of upper-layer IO requests on the host side, and simulating the structure maintenance of queues under various devices.

[0034] An adapter that uses the bus2reg and reg2bus functions to convert between register access transactions and target bus transactions;

[0035] Virtio device-side driver simulation is used to simulate the response of the Virtio device to the IO issued by the Host side, or to simulate the Virtio device sending and receiving messages to the Host side.

[0036] Optionally, the test cases include:

[0037] A host-side virtual sequence, which is used to construct a host-side Virtio-generated driver sequence;

[0038] A device-side virtual sequence, which is used to construct a Virtio device-side response or generate a driver sequence.

[0039] Optionally, the test platform further includes:

[0040] The PCIe VIP module is used in the PCIe-to-Virtio subsystem verification to provide PCIe protocol support and simulate the PCIe message sending and receiving driver.

[0041] Optionally, the test platform further includes:

[0042] The App Agent module is used in Virtio module-level verification.

[0043] Optionally, the test platform further includes:

[0044] A reference model is used to simulate the function of the DUT, obtain the expected behavior of the DUT, and send the expected results to the scoreboard for comparison to check whether the behavior of the DUT is correct.

[0045] Optionally, the test platform further includes:

[0046] A scoring board is used to compare the expected results of the reference model input with the actual results of the DUT output to obtain a comparison result.

[0047] A third aspect of this invention discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes a chip testing method as described in the first aspect of this invention.

[0048] The embodiments of the present invention have the following advantages:

[0049] In this embodiment of the invention, depending on whether the simulation verification mode is Virtio module-level verification or PCIe-to-Virtio subsystem-level verification, the corresponding DUT code and verification environment code are compiled to achieve automatic adaptation between the DUT and the verification environment. When using test cases for simulation verification, the host-side Virtio driver simulates the test scenarios set by the test cases and calls the corresponding register adapters, thereby verifying different simulation verification modes based on the same test cases. Compared with existing methods, this method allows all test cases to be reused for both Virtio module-level verification and PCIe-to-Virtio subsystem-level verification, thereby accelerating chip verification convergence and shortening the verification cycle. Attached Figure Description

[0050] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 This is a flowchart of a chip testing method provided in an embodiment of the present invention;

[0052] Figure 2 This is a schematic diagram of a test platform structure provided in an embodiment of the present invention;

[0053] Figure 3 This is a schematic diagram illustrating the implementation of Virtio module-level verification on a test platform according to an embodiment of the present invention;

[0054] Figure 4 This is a schematic diagram illustrating the implementation of PCIe-to-Virtio subsystem-level verification on a test platform according to an embodiment of the present invention. Detailed Implementation

[0055] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] This invention provides a chip testing method, such as... Figure 1 As shown, Figure 1A flowchart of a chip testing method provided in this embodiment of the invention includes steps S101 to S103:

[0057] Step S101: Obtain the simulation verification mode, which includes: Virtio module-level verification and PCIe-to-Virtio subsystem-level verification.

[0058] In this embodiment, Virtio module-level verification focuses more on verifying the internal functions of the Virtio module. Virtio module-level verification has advantages such as fast simulation speed, low localization difficulty, and fast convergence speed. PCIe-to-Virtio subsystem-level verification focuses more on verifying the interaction functions between modules, that is, verifying the interaction functions between the PCIe module and the Virtio module. PCIe-to-Virtio subsystem-level verification has advantages such as ensuring simulation completeness.

[0059] In this embodiment, Virtio module-level verification and PCIe-to-Virtio subsystem-level verification are performed on the same test platform. Since the functions and verification environments of Virtio module-level verification and PCIe-to-Virtio subsystem-level testing are different, the simulation verification mode is determined first during testing so that the corresponding code and verification environment can be set up and compiled according to the corresponding simulation verification mode in subsequent steps.

[0060] In one optional embodiment, obtaining the simulation verification mode includes:

[0061] Read the verification script from the test platform;

[0062] Based on the verification script, the simulation verification mode is obtained from the user's command line for running test cases or from the regression script.

[0063] In this embodiment, script parameter control is introduced to determine whether to perform Virtio module-level verification or PCIe-to-Virtio subsystem-level verification using the verification script. For example, if pcie_to_virtio_it_sim_mode = off is obtained in the user's test case command line or regression script, it indicates that Virtio module-level verification is selected; if pcie_to_virtio_it_sim_mode = on is obtained in the user's test case command line or regression script, it indicates that PCIe-to-Virtio subsystem-level verification is selected.

[0064] Step S102: Compile the corresponding DUT code and verification environment code according to the simulation verification mode.

[0065] In this embodiment, DUT stands for Design Under Test, which represents the chip design to be tested. During Virtio module-level verification, DUT represents the design of the Virtio module. During PCIe-to-Virtio subsystem-level verification, DUT represents the design of both the PCIe module and the Virtio module, as well as the design between the two modules.

[0066] Since PCIe controller code is generally quite large, during Virtio module-level verification, the PCIe controller-related code is not added to the compilation file list, and the PCIe VIP verification-related code is not added back to the compilation file list. This significantly reduces compilation time and speeds up chip testing, i.e., accelerates chip convergence. Therefore, the corresponding DUT code and verification environment code are compiled according to the simulation verification mode obtained in step S101. If the user selects Virtio module verification, the test platform will automatically instantiate and interface with the Virtio DUT Top layer. If the user selects PCIe-to-Virtio subsystem verification, the test platform will automatically instantiate and interface with both the PCIe and Virtio DUT Top layers.

[0067] In one optional embodiment, compiling the corresponding DUT code and verification environment code according to the simulation verification mode includes:

[0068] Read the verification script from the test platform;

[0069] For Virtio module-level verification, select the Virtio DUT file list and the corresponding verification environment instantiation interface from the verification script, and compile the verification environment code list;

[0070] For PCIe-to-Virtio subsystem-level verification, the PCIe and Virtio DUT file lists are selected from the verification script, and the corresponding verification environment instantiation and verification environment code lists are compiled.

[0071] The Virtio DUT file list refers to the design related to the Virtio module. During Virtio module-level verification, only the list of Virtio module-related DUT files and the corresponding verification environment code list are loaded to instantiate the verification environment and the Virtio DUT module. The PCIe and Virtio DUT file lists refer to the design related to the PCIe-to-Virtio subsystem. During PCIe-to-Virtio subsystem-level verification, the PCIe and Virtio DUT file lists and the corresponding verification environment code list are loaded to instantiate the verification environment and the Virtio-to-PCIe DUT subsystem.

[0072] In this embodiment, by introducing script parameter control, when running test cases, simulation settings are obtained from the command line or script, and the docking verification environment and DUT Virtio module or DUT Virtio-to-PCIe subsystem are instantiated, thereby achieving automatic instantiation and docking adaptation.

[0073] Step S103: Simulation verification is performed using test cases. The Host-side Virtio driver simulates the test scenarios set by the test cases and calls the corresponding register adapter to verify different simulation verification modes based on the same test cases.

[0074] In this embodiment, the test cases include test cases under various test scenarios. The test cases mainly include: Virtio-network, Virtio-block, Virtio-scsi, Virtio-mac, and Virtio-device test cases. The test cases can be used for both Virtio module-level verification and PCIe-to-Virtio subsystem-level verification. The test cases at the Virtio module level can be used directly for testing in PCIe-to-Virtio subsystem-level verification without any modification, thereby reducing the development of repetitive test cases, improving verification efficiency, and shortening the verification convergence time.

[0075] Furthermore, the adapter set up in the test platform can convert between register access transactions and target bus transactions through the bus2reg and reg2bus functions. If Virtio module-level testing is performed, the target bus transaction is the target bus transaction in the App agent module; if PCIe-to-Virtio subsystem-level testing is performed, the target bus transaction is the memory read / write target bus transaction in the PCIe VIP module. Furthermore, depending on whether the test is at the Virtio module level or the PCIe-to-Virtio subsystem level, the adapter can automatically adapt the conversion between register access transactions (uvm_reg_item) and memory read / write target transactions in the PCIe VIP, as well as the conversion between bus read / write target transactions in the AppAgent module. This allows for complete reuse of the host-side Virtio driver between Virtio module-level verification and PCIe-to-Virtio subsystem-level verification.

[0076] Furthermore, when the test case issues an operation request, the Host-side Virtio driver simulates receiving the operation request. Then, based on the test scenario set in the operation request, it can verify different simulation verification modes on the same test platform and with the same test cases by calling the corresponding register adapter.

[0077] In one optional embodiment, the test scenarios set by the Host-side Virtio driver according to the test cases include: the Host-side Virtio driver simulating the generation and dispatch of upper-layer IO requests on the Host side, and simulating the structure maintenance of queues under various devices, according to the test cases.

[0078] The structure maintenance of queues under various simulated devices includes: maintenance of tx queue, rx queue, control queue, available ring, used ring, and multi-function multi-queue.

[0079] Specifically, the Host-side Virtio driver, based on the test cases, simulates the generation and distribution of upper-layer I / O requests on the Host side, including:

[0080] (1) For configuring Virtio DUT register operations, the Host-side Virtio driver calls the register model in the test platform and uses the register model to send the register read and write operation timing to the DUT.

[0081] In this embodiment, the method of sending the register read / write operation timing to the DUT using the register model differs for different simulation verification simulations. Specifically:

[0082] For Virtio module-level verification, the data is converted using the App adapter in the test platform, and then the register read / write operation timing is sent to the DUT using the Driver module in the App agent module. For PCIe-to-Virtio subsystem-level verification, the data is converted using the PCIe adapter in the test platform, and then the register read / write operation timing is sent to the DUT using the Driver module in the PCIe VIP.

[0083] The adapters in the test platform are selected based on simulation verification. For Virtio module-level verification, the adapter is the App adapter, and for PCIe-to-Virtio subsystem-level verification, the adapter is the PCIe adapter.

[0084] (2) For Virtio DMA (Direct Memory Access) operations, the Host-side Virtio driver directly generates DMA read / write bus timing operations based on data transmission and reception requests, and sends the DMA read / write timing operations to the DUT.

[0085] In this embodiment, by implementing automatic adapter adaptation and introducing PCIe adapter and App adapter, the target bus transaction and the memory read / write transaction in the PCIe VIP module can be converted to each other, and the bus read / write transaction can be converted to each other. This allows the Host-side Virtio driver to perform register read / write operations through RAL without distinguishing between Virtio module-level testing and PCIe-to-Virtio subsystem testing.

[0086] In an optional embodiment, after sending the DMA read / write timing operation to the DUT, the functional test of the DUT sending data to the Virtio device specifically includes steps A1 and A2:

[0087] Step A1: Collect DMA read operation data and send the collected DMA data to the reference model for processing to obtain the reference model processing result.

[0088] In this step, DMA read operation data is collected using DMA monitoring. The collected DMA data is then sent to the reference model for processing via the TLM (Transaction Level Modeling) interface. The reference model is used to simulate the function of the DUT and to anticipate the behavior of the DUT.

[0089] Step A2: Collect the data sent by the DUT to the Virtio device, and compare the processing result of the reference model with the collected data sent by the DUT into the scoreboard to check whether the sending behavior of the DUT is correct.

[0090] In this step, the DUT sends data to the Virtio device via the TX interface. Collecting the data sent by the DUT to the Virtio device refers to monitoring and collecting the data from the TX interface using the Virtio device. Then, the reference model processing result from step A1 and the data collected via the TX interface are sent to the scoring board via the TLM interface for automatic comparison to check whether the DUT's sending behavior is correct, i.e., to check whether the DUT's sending behavior via the TX interface is correct. The scoring board uses an out-of-order comparison method to compare whether the reference model's processing result and the DUT's output are consistent and provides the comparison result.

[0091] In an optional embodiment, after sending the DMA read / write timing operation to the DUT, the functional test for the DUT receiving data from the Virtio device specifically includes steps B1 and B2:

[0092] Step B1: Use the DUT to receive data sent from the Virtio device and collect the data received by the DUT. Send the collected DUT data to the reference model for processing to obtain the processing result of the reference model.

[0093] In this step, the DUT receives data sent from the Virtio device via the RX interface, and uses the Virtio device to monitor and collect data from the RX interface. Then, it uses the TLM interface to send the collected data received by the DUT to the reference model for processing.

[0094] Step B2: Collect DMA write operation data, and send the collected DMA write operation data and the reference model processing results to the scoring board for comparison to check whether the DUT receiving behavior is correct.

[0095] In this step, DMA monitoring is used to collect DMA write operation data. Through the TLM interface, the collected DMA write operation data and the processing results of the reference model in step B1 are sent to the scoring board for automatic comparison to check whether the DUT's receiving behavior is correct, that is, to check whether the DUT's receiving behavior through the RX interface is correct.

[0096] In this embodiment, the data transmission and reception functions of the DUT are quickly verified by combining the reference model and the scoreboard. The verification method for the data transmission and reception functions of the DUT is the same in both Virtio module-level verification and PCIe-to-Virtio subsystem-level verification.

[0097] In practical applications, considering the different verification levels of Virtio module-level verification and PCIe-to-Virtio subsystem-level verification, the compilation and simulation times are generally not on the same order of magnitude. Furthermore, after compiling the PCIe controller code and PCIe VIP, the compilation time for the PCIe-to-Virtio subsystem level is more than 10 times that of the Virtio module-level compilation. In addition, the PCIe link establishment process and data serial-to-parallel conversion process during simulation also require additional time. For the same test cases, the simulation time for the PCIe-to-Virtio subsystem level is more than 20 times longer than that for the Virtio module level. Therefore, to accelerate the convergence of PCIe-to-Virtio chip verification, Virtio module-level verification is generally converged first, followed by PCIe-to-Virtio subsystem-level verification.

[0098] In this embodiment, depending on whether the simulation verification mode is Virtio module-level verification or PCIe-to-Virtio subsystem-level verification, the corresponding DUT code and verification environment code are compiled to achieve automatic adaptation between the DUT and the verification environment. When using test cases for simulation verification, the host-side Virtio driver simulates the test scenarios set by the test cases and calls the corresponding register adapters, thereby verifying different simulation verification modes based on the same test cases. Compared with existing methods, this method can reuse all test cases for Virtio module-level verification and PCIe-to-Virtio subsystem-level verification, thereby accelerating chip verification convergence and shortening the verification cycle.

[0099] This invention provides a testing platform for executing the aforementioned chip testing method, such as... Figure 2 As shown, Figure 2This is a schematic diagram of a test platform structure provided in an embodiment of the present invention. The test platform includes: verification scripts, test cases, host-side Virtio driver simulation, adapters, Virtio device-side driver simulation, PCIe VIP module, App Agent module, reference model, and scoreboard. Specifically:

[0100] (1) Verification script, which is used to obtain the simulation verification mode and select the list of code files of the compiled DUT according to the simulation verification mode.

[0101] Based on the verification script, the system obtains whether Virtio module-level verification or PCIe-to-Virtio subsystem-level verification is being performed from the user's test case command line or regression script, and then determines the list of code files to load from the DUT. If the user selects module testing, the verification platform will automatically instantiate and connect to the Virtio DUT Top layer; if the user selects subsystem testing, the verification platform will automatically instantiate and connect to both PCIe and Virtio DUT Top layers.

[0102] (2) Test cases, which include test cases under various test scenarios, used to verify different simulation verification modes.

[0103] Specifically, the test cases include test cases for Virtio devices such as Virtio-network, Virtio-block, Virtio-scsi, Virtio-mac, and Virtio-device. Furthermore, considering the test environment and scenarios, each test case includes a host-side virtual sequence (i.e., host_virtio_virtual_seq) and a device-side virtual sequence (i.e., device_virtio_virtual_seq). The host-side virtual sequence is used to construct the host-side Virtio generation driver sequence; the device-side virtual sequence is used to construct the Virtio device-side response or generation driver sequence.

[0104] In actual testing, test cases can be fully reused. Virtio module-level test cases can be used directly in PCIe-to-Virtio subsystem-level verification without any modification, thereby reducing the development of repetitive test cases, improving verification efficiency, and shortening verification convergence time.

[0105] (3) Host-side Virtio driver simulation, which is used to simulate the IO generation process and Virtio driver on the Host side, including: simulating the generation and distribution of upper-layer IO requests on the Host side, and simulating the structure maintenance of queues under various devices.

[0106] The queue structure maintenance includes: tx queue, rx queue, control queue maintenance, available ring maintenance, used ring maintenance, and multi-function multi-queue maintenance. Furthermore, for configuration and DUT register read / write operations, the host-side Virtio driver simulation uses a register model (RAL); for Virtio DMA read / write operations, it uses an automatically adapted DMA read / write bus operation; thus achieving complete reuse of the host-side Virtio driver for Virtio module-level verification and PCIe-to-Virtio subsystem-level verification.

[0107] (4) PCIe VIP module: This PCIe VIP module is used in the PCIe-to-Virtio subsystem verification to provide PCIe protocol support and simulate the PCIe packet transmission and reception driver. The PCIe VIP module includes: PCIe Driver and PCIeSeqr. Generally, a third-party commercial PCIe VIP is integrated, such as a PCIe VIP from Synopsys or Cadence.

[0108] (5) App Agent module, which is used in Virtio module-level verification. The App VIP module includes: App Driver and App Seqr.

[0109] The register interface of DUT Virtio typically uses the APB, AHB, or AXI interfaces from AMBA, or a company-defined register interface. If the DUT Virtio register interface uses the APB, AHB, or AXI interface, then you can directly integrate third-party commercial APB, AHB, or AXI VIPs. If the DUT Virtio register interface uses a company-defined interface, then the App Driver needs to be redeveloped to implement the register read / write interface timing.

[0110] (6) Adapter, which implements the mutual conversion between register access transactions and target bus transactions through the bus2reg and reg2bus functions.

[0111] If Virtio module-level testing is performed, the target bus transaction is the transaction in the App agent component, and the adapter here is the App adapter. If PCIe-to-Virtio subsystem-level testing is performed, the target bus transaction is the memory read / write transaction in the PCIe VIP, and the adapter here is the PCIe adapter. The adapter automatically adapts the mutual conversion between the register access transaction uvm_reg_item and the memory read / write transaction in the PCIe VIP module, and the mutual conversion between the bus read / write transaction in the App Agent module, depending on whether the test is at the Virtio module level or the PCIe-to-Virtio subsystem level. This allows for complete reuse of the host-side Virtio driver between Virtio module-level verification and PCIe-to-Virtio subsystem-level verification.

[0112] (7) Virtio device-side driver simulation, which is used to simulate the Virtio device side responding to the IO issued by the Host side, or to simulate the Virtio device side sending and receiving messages to the Host side.

[0113] (8) Reference model, which is used to simulate the function of DUT, obtain the expected behavior of DUT, and send the expected results to the scoreboard for comparison to check whether the behavior of DUT is correct.

[0114] (9) Scoreboard, which is used to compare the expected result of the reference model input with the actual result of the DUT output to obtain a comparison result. Specifically, the scoreboard adopts a random comparison method to compare whether the reference model input and the DUT output are consistent.

[0115] In this embodiment, automatic adaptation through host-side Virtio driver simulation eliminates the need for Virtio test cases to differentiate between Virtio module-level testers and PCIe-to-Virtio subsystem testing. This combines module-level and subsystem-level verification, allowing Virtio test cases to be tested at both the Virtio module level and the PCIe-to-Virtio subsystem without any modification. This achieves complete reuse of test platform components and test cases, significantly reducing the development work of the verification platform and test cases, minimizing manpower investment, and improving verification efficiency. It fully leverages the advantages of module-level compilation and simulation, such as fast speed, low location difficulty, and rapid convergence, combined with the advantages of subsystem simulation completeness guarantees, to significantly accelerate the convergence of PCIe-to-Virtio chip verification.

[0116] For example, Figure 3 This diagram illustrates the implementation of Virtio module-level verification on a test platform. First, the verification script obtains simulation settings from the command line or regression script. Then, based on the simulation settings, the script selects the Virtio DUT file list and the corresponding verification environment for instantiation and compilation, and compiles the verification environment code list. After successful compilation, simulation testing begins. Using the Virtio network test case as an example, the test case sends Virtio networksequences requests to the Host-side Virtio driver module. Upon receiving the request, the Host-side Virtio driver module simulates the generation and distribution of upper-layer I / O requests on the Host side. Specifically, for configuring Virtio DUT register operations, the Host-side Virtio driver automatically selects and calls the App agent module. After data conversion in the App configurator, the App Driver module sends the register read / write operation timing to the DUT through the App interface. For Virtio DMA operations, the Host-side Virtio driver directly generates DMA read / write bus timing operations based on data transmission and reception requests and sends them to the DUT through the Virtio DMA interface.

[0117] For the functional test of DUT sending data to the Virtio device (i.e., Virtio network sending data to the Virtio device), firstly, DMA read operation data is collected and sent to the reference model for processing to obtain the reference model processing result; then, the data sent by DUT to the Virtio device is collected, and the reference model processing result is compared with the collected DUT sending data to the scoring board to check whether the DUT's sending behavior is correct.

[0118] For the functional test of the DUT receiving data from the Virtio device (i.e., the Virtio network receiving data from the Virtio device), firstly, the DUT receives data sent from the Virtio device, and the data received by the DUT is collected. The collected data received by the DUT is sent to the reference model for processing to obtain the processing result of the reference model. Then, DMA write operation data is collected, and the collected DMA write operation data and the processing result of the reference model are sent to the scoring board for comparison to check whether the DUT's receiving behavior is correct.

[0119] For example, Figure 4 This diagram illustrates the implementation of PCIe-to-Virtio subsystem-level verification on a test platform. First, the verification script obtains simulation settings from the command line or regression script. Then, based on the simulation settings, the script selects the PCIe and Virtio DUT file lists, instantiates and interfaces with the corresponding verification environment, and compiles the verification environment code list. After successful compilation, simulation testing begins. Here, the Virtio network test case is used as an example. The test case sends Virtio network sequences requests to the Host-side Virtio driver module. Upon receiving the request, the Host-side Virtio driver module simulates the generation and sending of upper-layer I / O requests on the Host side. For configuring Virtio DUT register operations, the Host-side Virtio driver automatically selects and calls the PCIe VIP module. After data conversion by the PCIe adapter, the register read / write operation timing is sent to the DUT via the PCIe interface through the PCIeDriver module. For Virtio DMA operations, the Host-side Virtio driver directly generates DMA read / write bus timing operations based on the data transmission and reception requests, and sends them to the DUT via the Virtio DMA interface.

[0120] For the functional test of DUT sending data to the Virtio device (i.e., Virtio network sending data to the Virtio device), firstly, DMA read operation data is collected and sent to the reference model for processing to obtain the reference model processing result; then, the data sent by DUT to the Virtio device is collected, and the reference model processing result is compared with the collected DUT sending data to the scoring board to check whether the DUT's sending behavior is correct.

[0121] For the functional test of the DUT receiving data from the Virtio device (i.e., the Virtio network receiving data from the Virtio device), firstly, the DUT receives data sent from the Virtio device, and the data received by the DUT is collected. The collected data received by the DUT is sent to the reference model for processing to obtain the processing result of the reference model. Then, DMA write operation data is collected, and the collected DMA write operation data and the processing result of the reference model are sent to the scoring board for comparison to check whether the DUT's receiving behavior is correct.

[0122] Based on the chip testing method and testing platform adopted in this embodiment, the efficiency of chip verification can be improved, the verification cycle can be shortened, and manpower can be saved. One person can simultaneously carry out Virtio module-level and PCIe-to-Virtio subsystem-level verification. After the functional verification of Virtio module level is passed, verification can be carried out in PCIe-to-Virtio subsystem immediately. It makes full use of the advantages of module-level compilation and simulation such as fast speed, low positioning difficulty, and fast convergence speed, combined with the advantages of subsystem simulation completeness guarantee, to accelerate the verification convergence of Virtio module and PCIe-to-Virtio subsystem, thereby achieving the goal of accelerating the convergence of PCIe-to-Virtio chip verification.

[0123] Furthermore, the chip testing method and testing platform provided in this embodiment have good adaptability and can be used in different PCIe bridging chip verification projects, including the verification of PCIe-to-USB, PCIe-to-SATA, PCIe-to-SRIO and other bridging chips, which can significantly accelerate the convergence of PCIe bridging chip verification.

[0124] This invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the chip testing method described in the above embodiments.

[0125] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0126] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0127] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, devices, and media according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0128] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0129] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0130] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0131] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0132] The chip testing method, testing platform, and equipment provided by the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A chip testing method, characterized in that, The method includes: Obtain the simulation verification mode, which includes: Virtio module-level verification and PCIe-to-Virtio subsystem-level verification; Compile the corresponding DUT code and verification environment code according to the simulation verification mode; Simulation verification is performed using test cases. The host-side Virtio driver simulates the test scenarios set by the test cases and calls the corresponding register adapter to verify different simulation verification modes based on the same test cases. The host-side Virtio driver simulates the test scenarios set according to the test cases, including: The Host-side Virtio driver simulation simulates the generation and distribution of upper-layer IO requests on the Host side, and the structure maintenance of queues under various devices, based on the test cases. The Host-side Virtio driver simulation, based on the test cases, simulates the generation and dispatch of upper-layer I / O requests on the Host side, including: For configuring Virtio DUT register operations, the host-side Virtio driver simulates calling the register model in the test platform and uses the register model to send the register read and write operation timing to the DUT; For Virtio DMA operations, the Host-side Virtio driver simulation directly generates DMA read / write bus timing operations based on data transmission and reception requests, and sends the DMA read / write timing operations to the DUT. Sending the register read / write operation timing to the DUT using the aforementioned register model includes: For Virtio module-level verification, the data is transformed using the App adapter in the test platform, and then the register read / write operation timing is sent to the DUT using the Driver module in the Appagent module. For PCIe-to-Virtio subsystem level verification, the data is converted using the PCIe adapter in the test platform, and then the register read / write operation timing is sent to the DUT using the Driver module in the PCIe VIP.

2. The method according to claim 1, characterized in that, The acquisition of the simulation verification mode includes: Read the verification script from the test platform; Based on the verification script, the simulation verification mode is obtained from the user's command line for running test cases or from the regression script.

3. The method according to claim 1, characterized in that, The process of compiling the corresponding DUT code and verification environment code according to the simulation verification mode includes: Read the verification script from the test platform; For Virtio module-level verification, select the Virtio DUT file list and the corresponding verification environment instantiation interface from the verification script, and compile the verification environment code list; For PCIe-to-Virtio subsystem-level verification, the PCIe and Virtio DUT file lists are selected from the verification script, and the corresponding verification environment instantiation and verification environment code lists are compiled.

4. The method according to claim 1, characterized in that, After sending the DMA read / write timing operations to the DUT, the method further includes the functional testing of the DUT sending data to the Virtio device: Collect DMA read operation data and send the collected DMA data to the reference model for processing to obtain the reference model processing result; The data sent by the DUT to the Virtio device is collected, and the processing result of the reference model is compared with the data sent by the DUT to the scoreboard to check whether the sending behavior of the DUT is correct.

5. The method according to claim 1, characterized in that, After sending the DMA read / write timing operations to the DUT, the method further includes the following functional testing for the DUT receiving data from the Virtio device: The DUT receives data sent from the Virtio device and collects the data received by the DUT. The collected data received by the DUT is then sent to the reference model for processing to obtain the processing result of the reference model. Collect DMA write operation data and send the collected DMA write operation data and the processing results of the reference model to the scoring board for comparison to check whether the DUT receiving behavior is correct.

6. A testing platform, characterized in that, The testing platform is used to perform the chip testing method according to any one of claims 1-5, and the testing platform includes: Verification script, which is used to obtain the simulation verification mode and select the list of code files of the compiled DUT according to the simulation verification mode; Test cases, which include test cases under various test scenarios, are used to verify different simulation verification modes; Host-side Virtio driver simulation is used to simulate the IO generation process and Virtio driver on the host side, including: simulating the generation and distribution of upper-layer IO requests on the host side, and simulating the structure maintenance of queues under various devices. An adapter that uses the bus2reg and reg2bus functions to convert between register access transactions and target bus transactions; Virtio device-side driver simulation is used to simulate the Virtio device side responding to IO issued by the Host side, or to simulate the Virtio device side sending and receiving messages to the Host side.

7. The testing platform according to claim 6, characterized in that, The test cases include: A host-side virtual sequence, which is used to construct a host-side Virtio-generated driver sequence; A device-side virtual sequence, which is used to construct a Virtio device-side response or generate a driver sequence.

8. The testing platform according to claim 6, characterized in that, The testing platform also includes: The PCIe VIP module is used in the PCIe-to-Virtio subsystem verification to provide PCIe protocol support and simulate the PCIe message sending and receiving driver.

9. The testing platform according to claim 6, characterized in that, The testing platform also includes: The App Agent module is used in Virtio module-level verification.

10. The testing platform according to claim 6, characterized in that, The testing platform also includes: A reference model is used to simulate the function of the DUT, obtain the expected behavior of the DUT, and send the expected results to the scoreboard for comparison to check whether the behavior of the DUT is correct.

11. The testing platform according to claim 6, characterized in that, The testing platform also includes: A scoring board is used to compare the expected results of the reference model input with the actual results of the DUT output to obtain a comparison result.

12. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executed, implements the chip testing method as described in any one of claims 1-5.

Images