A chip verification system and method

Abstract

The present application provides a chip verification system and method, relating to the technical field of high-performance computing, in particular to a chip verification system, including: a test case module, an AXI bus function model, an AXI bus monitor, an APB bus function model, an APB bus monitor, a CPU, and a device under test module; wherein, the AXI bus function model and the APB bus function model based on the VMM verification framework are used to implement the format conversion of transmitted data, achieve high management and control efficiency for the device under test module, and can perform relatively sufficient verification on the RDMA network card chip by performing real-time processing on the read / write response or read / write request information sent by the device under test module, provide a verification platform for the application of the RDMA network card chip in multiple scenarios in the field of high-performance computing, shorten the development cycle of the RDMA network card chip, and improve the verification efficiency of the RDMA network card chip.

Description

Technical Field

[0001] This application relates to the field of high-performance computing technology, and particularly to a chip verification system and method. Background Art

[0002] In the rapidly developing era of information technology, the demand for high-performance networks in the fields of high-performance computing (HPC), big data processing, and distributed storage is gradually emerging. When dealing with a large amount of data, the traditional TCP / IP protocol stack requires multi-layer processing, resulting in high CPU (Central Processing Unit) and memory overheads. Moreover, due to its multiple memory copy characteristics, it cannot meet the requirements of high-speed networks. Therefore, the RDMA (Remote Direct Memory Access) technology is introduced into the data center network. The RDMA technology enables remote computers to communicate over the network by bypassing the kernel and zero-copy. The characteristics of high bandwidth and low latency of RDMA can better meet the bandwidth requirements of future data center networks. The network interface controller that implements the RDMA protocol is called an RDMA network card chip. To reduce the development risk, it is very important to perform software and hardware co-verification based on an FPGA prototype before the RDMA network card chip is taped out.

[0003] In the prior art, there are two methods for verifying chips: the verification platform of the high-performance ASIC (HighPperformance ASIC System) series of Synopsys and EDA (Electronic Design Automationr) simulation. For the RDMA network card chip, a large amount of random data verification is very important. However, the traditional EDA simulation takes a long time to verify a large amount of data and has a high complexity. Therefore, the EDA simulation cannot meet the verification requirements of the RDMA network card chip. Moreover, the above technical methods for verifying chips focus on simulating circuit behavior, lack the flexibility of the simulation architecture, and have a high complexity when dealing with a large amount of data and multiple test scenarios, making it difficult to verify complex chip designs and unable to meet the high-efficiency requirements for simulating and verifying the RDMA network card chip.

[0004] Therefore, how to improve the verification efficiency of the RDMA network card chip is a technical problem that needs to be urgently solved by those skilled in the art. Summary of the Invention

[0005] To solve the above technical problems, this application provides a chip verification system that can improve the verification efficiency of the RDMA network card chip. This application also provides a chip verification method with the same technical effect.

[0006] The first object of this application is to provide a chip verification system.

[0007] The above-mentioned first application object of this application is achieved through the following technical solutions:

[0008] A chip verification system is applied to an RDMA network card chip. The system is implemented based on the VMM verification framework. The system includes: a test case module, an AXI bus function model, an AXI bus monitor, an APB bus function model, an APB bus monitor, a CPU, and a design under test module. The test case module is connected to the CPU, and the CPU is also respectively connected to the AXI bus function model, the AXI bus monitor, the APB bus function model, and the APB bus monitor. The design under test module is respectively connected to the AXI bus function model and the AXI bus monitor through the AXI bus. The design under test module is also respectively connected to the APB bus function model and the APB bus monitor through the APB bus, where:

[0009] The test case module is used to obtain the configuration data of the verification task and send the configuration data to the CPU;

[0010] The CPU is used to encapsulate the configuration data into transaction-level data and send the transaction-level data to the AXI bus function model and the APB bus function model respectively;

[0011] The AXI bus function model is used to convert the transaction-level data into a first interface timing signal according to the AXI protocol and send the first interface timing signal to the design under test module to drive the design under test module to output a first interface response signal according to the first interface timing signal;

[0012] The APB bus function model is used to convert the transaction-level data into a second interface timing signal according to the APB protocol and send the second interface timing signal to the design under test module to drive the design under test module to output a second interface response signal according to the second interface timing signal;

[0013] The AXI bus monitor is used to convert the first interface response signal into a first message transaction according to the AXI protocol and output the first message transaction;

[0014] The APB bus monitor is used to convert the second interface response signal into a second message transaction according to the APB protocol and output the second message transaction.

[0015] Preferably, in the chip verification system, the CPU is further configured to detect whether the configuration data is valid and obtain a detection result;

[0016] Correspondingly, when the CPU executes the encapsulation of the configuration data into transaction-level data, it is specifically configured to: when the detection result indicates that the configuration data is valid, encapsulate the configuration data into transaction-level data.

[0017] Preferably, in the chip verification system, the CPU is further configured to monitor the number of elements in the send queue sent by the AXI bus function model and the number of elements in the work queue received by the AXI bus monitor, and when the number of elements in the send queue is equal to the number of elements in the work queue, control the simulation process to end.

[0018] Preferably, the chip verification system further includes a generator, where:

[0019] The generator is respectively connected to the APB bus function model and the AXI bus function model;

[0020] The generator is configured to generate randomized transaction data that meets preset constraint conditions according to the configuration data by means of randomization, and send the randomized transaction data to the APB bus function model and the AXI bus function model.

[0021] Preferably, in the chip verification system, the APB bus function model is further configured to obtain the configuration data of the XGMAC core and start the to-be-tested design module according to the configuration data of the XGMAC core.

[0022] The second object of the present application is to provide a chip verification method.

[0023] The above object two of the present application is achieved by the following technical solutions:

[0024] A chip verification method is applied to an RDMA network card chip. The method is implemented based on the above chip verification system. Among them, the system is implemented based on the VMM verification framework. The system includes: a test case module, an AXI bus function model, an AXI bus monitor, an APB bus function model, an APB bus monitor, a CPU, and a design under test module. The test case module is connected to the CPU, and the CPU is also respectively connected to the AXI bus function model, the AXI bus monitor, the APB bus function model, and the APB bus monitor. The design under test module is respectively connected to the AXI bus function model and the AXI bus monitor through the AXI bus. The design under test module is also respectively connected to the APB bus function model and the APB bus monitor through the APB bus. The method includes:

[0025] Using the test case module, obtain the configuration data of the verification task and send the configuration data to the CPU;

[0026] Using the CPU, encapsulate the configuration data into transaction-level data and send the transaction-level data to the AXI bus function model and the APB bus function model respectively;

[0027] Using the AXI bus function model, according to the AXI protocol, convert the transaction-level data into the first interface timing signal and send the first interface timing signal to the design under test module to drive the design under test module to output the first interface response signal according to the first interface timing signal;

[0028] Using the APB bus function model, according to the APB protocol, convert the transaction-level data into the second interface timing signal and send the second interface timing signal to the design under test module to drive the design under test module to output the second interface response signal according to the second interface timing signal;

[0029] Using the AXI bus monitor, according to the AXI protocol, convert the first interface response signal into the first message transaction and output the first message transaction;

[0030] Using the APB bus monitor, according to the APB protocol, convert the second interface response signal into the second message transaction and output the second message transaction.

[0031] Preferably, in the chip verification method, it further includes:

[0032] Using the CPU, detect whether the configuration data is valid to obtain a detection result;

[0033] Correspondingly, using the CPU to encapsulate the configuration data into transaction-level data specifically includes: when the detection result indicates that the configuration data is valid, using the CPU to encapsulate the configuration data into transaction-level data.

[0034] Preferably, the chip verification method further includes:

[0035] Using the CPU to monitor the number of elements in the send queue sent by the AXI bus function model and the number of elements in the work queue received by the AXI bus monitor, and when the number of elements in the send queue is equal to the number of elements in the work queue, controlling the simulation process to end.

[0036] Preferably, the chip verification method further includes:

[0037] Using the APB bus function model to obtain the configuration data of the XGMAC core, and starting the design module to be tested according to the configuration data of the XGMAC core.

[0038] Preferably, the chip verification method further includes:

[0039] Using the APB bus monitor to determine whether the read and write operations of the design module to be tested are successful according to the second interface response signal.

[0040] The above technical solution particularly relates to a chip verification system applied to an RDMA network card chip, including: a test case module, an AXI bus function model, an AXI bus monitor, an APB bus function model, an APB bus monitor, a CPU, and a design module to be tested; wherein, based on the AXI bus function model and the APB bus function model of the VMM verification framework, the format conversion of the transmitted data is realized, the high management and control efficiency of the design module to be tested is achieved, and by real-time processing of the read and write response or read and write request information sent by the design module to be tested, the RDMA network card chip can be verified more fully, providing a verification platform for the application of the RDMA network card chip in multiple scenarios in the high-performance computing field, and shortening the development cycle of the RDMA network card chip. Compared with the traditional EDA simulation method, the above technical solution has lower complexity and faster verification speed, and can improve the verification efficiency of the RDMA network card chip. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0042] Figure 1 It is a schematic structural diagram of the VMM verification framework in the embodiments of the present application;

[0043] Figure 2 It is a schematic structural diagram of a chip verification system in the embodiments of the present application;

[0044] Figure 3 It is a schematic flowchart of a chip verification method in the embodiments of the present application. Detailed implementation manners

[0045] In order to enable those skilled in the art to better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts shall fall within the protection scope of the present application.

[0046] In the embodiments provided in the present application, it should be understood that the disclosed methods and systems can be implemented in other ways. The system embodiments described below are only illustrative. For example, the division of units and modules is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or modules can be combined, or can be integrated into another system, or some features can be ignored, or not executed. In addition, the couplings, direct couplings, or communication connections between the components shown or discussed with each other can be through some interfaces, indirect couplings or communication connections of devices or modules, and can be electrical, mechanical or other forms.

[0047] In addition, each functional unit in the embodiments of the present application can be all integrated in one processor, or each unit can be separately used as a device, or two or more units can be integrated in one device; each functional unit in the embodiments of the present application can be implemented in the form of hardware, or in the form of a combination of hardware and software functional units.

[0048] Those of ordinary skill in the art can understand that all or part of the steps of implementing the following method embodiments can be completed through program instructions and related hardware. The foregoing program instructions can be stored in a computer-readable storage medium. When the program instructions are executed, the steps of the following method embodiments are executed; and the foregoing storage medium includes: various media that can store program codes such as removable storage devices, read-only memory (ROM), magnetic disks, or optical discs.

[0049] It should be understood that in this application, if terms such as "system", "device", "unit" and / or "module" are used, they are only a way to distinguish different components, elements, parts, portions or assemblies at different levels. However, if other terms can achieve the same purpose, they can be replaced by other expressions.

[0050] In addition, the terms "first" and "second" are only used for descriptive purposes and should not be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of this application, the meanings of "a plurality of" and "several" are two or more, unless otherwise specifically defined.

[0051] If a flowchart is used in this application, the flowchart is used to illustrate the operations performed by the system according to the embodiments of this application. It should be understood that the previous or subsequent operations do not necessarily need to be executed precisely in sequence. On the contrary, the steps can be processed in reverse order or simultaneously. At the same time, other operations can also be added to these processes, or one or several steps can be removed from these processes.

[0052] It should also be noted that in this article, terms such as "including", "comprising" or any other variants thereof are intended to cover non-exclusive inclusion, so that an article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such an article or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of another identical element in the article or device including the above elements.

[0053] The embodiments of this application are written in a progressive manner.

[0054] The embodiments of this application provide a chip verification system, which is applied to an RDMA network card chip and is used to verify the functional correctness of the RDMA network card chip design so as to timely discover defects in the RDMA network card chip design.

[0055] The above chip verification system is implemented based on the VMM (Verification Methodology Manual) verification framework; among them, the VMM verification framework is a verification methodology based on the SystemVerilog language launched by Synopsys, aiming to improve the efficiency and quality of design verification. It has the advantages of fast verification speed and more comprehensive verification. Its general and flexible structure enables it to be reused in multiple different projects, and by simulating the actual working environment of the chip, accurate simulation can be obtained.

[0056] Such as Figure 1As shown, the core components of the VMM verification framework include TC (Test Case), TH (Test Harness), ENV (Environment), SUBENV (Sub-Environment), BFM (Bus Function Model), MONITOR, GENERATOR, RM (Reference Model), SCOREBOARD, and DUT (Design Under for Test), etc.

[0057] Among them, DUT is the target object of verification and is a module or the entire system in the hardware design. In the VMM verification methodology, DUT is usually a complex integrated circuit or system that needs to undergo strict verification to ensure that its functions and performance meet the design requirements. DUT is deployed between BFM and MONITOR. It refers to the hardware design system that needs to be verified. Multiple functional modules are integrated inside DUT, such as message encapsulation and parsing modules based on the RoCEv2 protocol, send queue cache modules, receive queue cache modules, completion queue cache modules, congestion control modules, and flow control modules, etc.

[0058] TC is the basic unit in the verification process. It defines the specific test behaviors for DUT. Each test case usually focuses on verifying a specific aspect or a set of characteristics of DUT. The test case implements stimuli based on operations such as RDMA Write, RDMA Read, and RDMA Send, and checks whether the behavior of DUT meets the expectations, which is used to verify the specified test scenario. In the VMM verification framework, the test case usually contains a series of transactions or operations that are sent to DUT to verify whether its functions meet the expectations.

[0059] TH contains all the logic required to execute the test, including instantiating DUT, instantiating and connecting the interface system bus, etc. It is the bridge connecting the test case and the verification environment.

[0060] ENV represents the entire verification platform. The environment layer defines the set of resources required to execute the test, such as bus function models, monitors, etc. The environment provides the necessary context information for the test and allows users to adjust the verification parameters as needed.

[0061] SUBENV is a subset of the verification environment ENV, used to represent a finer-grained functional area, and is used to encapsulate and manage the verification logic of specific functions or modules. Through SUBENV, a complex environment can be decomposed into several sub-environments, making the verification environment more modular and facilitating management and maintenance.

[0062] The BFM simulates the bus behavior in the DUT. It is responsible for converting transaction-level stimuli into signal-level stimuli and passing them to the DUT. In addition, it is also responsible for converting the response of the design under test from signal level back to transaction level for further analysis and checking by the verification environment.

[0063] The MONITOR is responsible for listening to the output results of the DUT interface, converting the signal-level data output by the DUT into transaction-level data in the VMM verification environment, so as to further analyze the behavior of the DUT or serve as the basic data for coverage collection.

[0064] The GENERATOR is responsible for generating randomized transactions, which are the basis for verifying the DUT. It generates various possible input stimuli according to predefined constraints to cover various operation modes of the DUT. By generating diverse input stimuli, it ensures that the verification process can fully cover the design space of the DUT and discover potential design problems.

[0065] The RM is used to generate the expected output results. It calculates the expected response according to the input stimuli and the design specifications of the DUT. The RM can be implemented in SystemVerilog or other programming languages, usually based on Transaction Level Modeling (TLM). The output of the RM serves as a benchmark for verifying the functional correctness of the DUT and is compared with the actual output of the DUT.

[0066] The SCOREBOARD is used to compare the actual output of the DUT with the expected output of the RM. It records the execution status of all transactions, counts the number of successful and failed transactions, and reports the verification results. The SCOREBOARD verifies whether the function of the DUT is correct by comparing the actual results with the expected results. It is also responsible for recording the execution status of transactions and providing detailed information about the verification process.

[0067] Such as Figure 2As shown in the figure, the above chip verification system includes: a test case module 1, a CPU 2, an AXI bus function model 3, an AXI bus monitor 4, an APB bus function model 5, an APB bus monitor 6, and a design under test module 7; the test case module 1 is connected to the CPU 2, and the CPU 2 is also respectively connected to the AXI bus function model 3, the AXI bus monitor 4, the APB bus function model 5, and the APB bus monitor 6; the design under test module 7 is connected to the AXI bus function model 3 and the AXI bus monitor 4 respectively through the AXI bus; the design under test module 7 is also connected to the APB bus function model 5 and the APB bus monitor 6 respectively through the APB bus.

[0068] Specifically, in the above chip verification system, the test case module 1 is used as the TC test case component in the VMM verification framework, which is connected to the ENV verification environment component through the TH test framework component. The subset SUBENV sub-verification environment of the ENV verification environment component consists of the AXI bus function model 3, the AXI bus monitor 4, the APB bus function model 5, the APB bus monitor 6, and the CPU 2, and the design under test module 7 is the target object to be verified.

[0069] The test case module 1 is used to obtain the configuration data of the verification task and send the configuration data to the CPU 2.

[0070] Specifically, the configuration data can be data preset based on a specific verification task, and the obtained configuration data can be passed to the CPU 2 through the ENV verification environment component and the SUBENV sub-verification environment. For the verification of the RDMA network card chip, the configuration data that the test case module 1 needs to obtain includes, but is not limited to: CQC (Completion Queue Context), SMAC (Source MAC Address), SGID (Subnet Group Identifier), QPC (Queue Pair Context), MRC (Memory Region Context), SQE (Send Queue Element), and RQE (Receive Queue Element). The detailed information is shown in the following table:

[0071] Table 1 Detailed Information of Configuration Data

[0072]

[0073] The CPU 2 is configured to encapsulate configuration data into transaction-level data and send the transaction-level data to the AXI bus function model 3 and the APB bus function model 5 respectively;

[0074] Specifically, the CPU 2 encapsulates the configuration data into transaction (Transactions)-level data according to the data format specified by software and hardware, and then transfers it to the AXI bus function model 3 and the APB bus function model 5.

[0075] In some embodiments, the CPU 2 is further configured to detect whether the configuration data is valid and obtain a detection result; correspondingly, when the CPU 2 executes the operation of encapsulating the configuration data into transaction-level data, it is specifically configured to: when the detection result indicates that the configuration data is valid, encapsulate the configuration data into transaction-level data.

[0076] Specifically, the CPU 2 detects whether the configuration data, mask, and operation type provided by the test case module 1 are valid and obtains the corresponding detection result. For example, the theoretical length of the configuration data is 32 bytes. If the length of the configuration data is less than 32 bytes, it is invalid configuration data. The value of the operation type is 0 to 7. If the operation type provided by the test case module 1 is not within the range of 0 to 7, it is an invalid operation type. If the detection result indicates that the configuration data is valid, the configuration data is encapsulated into transaction-level data. This application is not limited thereto.

[0077] The AXI bus function model 3 is configured to convert the transaction-level data into first interface timing signals according to the AXI protocol and send the first interface timing signals to the device under test module 7 to drive the device under test module 7 to output first interface response signals according to the first interface timing signals;

[0078] The APB bus function model 5 is configured to convert the transaction-level data into second interface timing signals according to the APB protocol and send the second interface timing signals to the device under test module 7 to drive the device under test module 7 to output second interface response signals according to the second interface timing signals;

[0079] Specifically, AXI (Advanced eXtensible Interface) is a high-performance, high-bandwidth, low-latency on-chip communication protocol and is part of the AMBA (Advanced Microcontroller Bus Architecture) bus architecture proposed by ARM. The AXI bus function model 3 (which can also be simply referred to as AXI-BFM) realizes the conversion between message transactions and AXI interface signals according to the AXI protocol. Specifically, it converts transaction-level data into the first interface timing signals for driving the design-under-test module 7. APB (Advanced Peripheral Bus), as an advanced peripheral bus, is also one of the most basic bus protocols in the AMBA bus architecture. According to the official definition of ARM, APB is a low-cost interface protocol that can achieve low power consumption and a streamlined interface design, reducing the complexity of the interface design. The APB bus function model 5 (which can also be simply referred to as APB-BFM) realizes the conversion between message transactions and APB interface signals according to the APB protocol. Specifically, it converts transaction-level data into the second interface timing signals for driving the design-under-test module 7. The design-under-test module 7 receives the first interface timing signals sent by the AXI bus function model 3 and the second interface timing signals sent by the APB bus function model 5 as injected stimuli and outputs response information respectively, that is, it outputs the first interface response signal and the second interface response signal respectively. It should be noted that the number of design-under-test modules 7 can be 1 or multiple, and it can be flexibly set based on actual needs. Figure 2 Taking the embodiment shown in

[0080] as an example, where the number of design-under-test modules 7 is 2, and the present application does not make specific limitations on this.

[0081] The AXI bus monitor 4 is used to convert the first interface response signal into the first message transaction according to the AXI protocol and output the first message transaction;

[0082] Specifically, the AXI bus monitor 4 (which can also be simply referred to as AXI-MONITOR) converts the collected timing signals into data packets according to the AXI protocol. Specifically, it converts the first interface response signal into the first message transaction and outputs it; the APB bus monitor 6 (which can also be simply referred to as APB-MONITOR) converts the collected timing signals into data packets according to the APB protocol. Specifically, it converts the second interface response signal into the second message transaction and outputs it. The output first message transaction and second message transaction can be stored in a preset storage file, and the present application does not make specific limitations on this.

[0083] In some embodiments, an array for storing data (e.g., rom_space[(5120 + 213)*4096 - 1], where (5120 + 213)*4096 represents a storage space of 820KB) is provided inside the APB bus monitor 6 to simulate the memory area space of RDMA. The design module 7 under test can initiate read requests or write requests for a specified memory area.

[0084] In some embodiments, the CPU 2 is further configured to monitor the number of transmit queue elements sent by the AXI bus function model 3 and the number of work queue elements received by the AXI bus monitor 4, and control the end of the simulation process when the number of transmit queue elements is equal to the number of work queue elements.

[0085] Specifically, the CPU 2 monitors the number of SQEs sent by the AXI bus function model 3 and the number of CQEs received by the AXI bus monitor 4. If the two are consistent, it indicates that all packets have been sent, and the operations of the design module 7 under test and the verification framework have been completed, and then the simulation process is ended. Otherwise, an error message can be prompted.

[0086] Traditional EDA simulation takes a long time and has high complexity for verifying large amounts of data. Therefore, EDA simulation cannot meet the verification requirements of RDMA network card chips. Moreover, the traditional technical methods for verifying chips focus on simulating circuit behavior, lack the flexibility of the simulation architecture, and have high complexity when dealing with large amounts of data and multiple test scenarios, making it difficult to verify complex chip designs and unable to meet the high-efficiency requirements for simulating and verifying RDMA network card chips.

[0087] The above embodiments particularly relate to a chip verification system applied to an RDMA network card chip, including: a test case module 1, an AXI bus function model 3, an AXI bus monitor 4, an APB bus function model 5, an APB bus monitor 6, a CPU 2, and a design module 7 under test; wherein, the AXI bus function model 3 and the APB bus function model 5 based on the VMM verification framework are used to implement the format conversion of transmitted data, achieve high management and control efficiency for the design module 7 under test, and can perform relatively sufficient verification on the RDMA network card chip by processing the read / write response or read / write request information sent by the design module 7 under test in real time, providing a verification platform for the application of the RDMA network card chip in multiple scenarios in the high-performance computing field and shortening the development cycle of the RDMA network card chip. Compared with traditional EDA simulation methods, the above embodiments have lower complexity and faster verification speed, and can improve the verification efficiency of RDMA network card chips.

[0088] In addition, the above embodiments are for the coupling design of the RDMA chip architecture, and dedicated protocol extensions can be made for RDMA. Among them, the AXI bus function model 3 and the APB bus function model 5 can support dynamic configuration of RDMA transmission parameters (such as parameters like memory size, QP attributes, local ACK timeout, retransmission count limit, etc.), while the current AXI-VIP library and APB-VIP library of Synopsys only provide support for the general AXI and APB protocols. The AXI bus monitor 4 can be used for RDMA semantic-level monitoring, such as identifying RoCEv2 packet data and comparing packet data (the packets actively driven by the VMM framework to the DUT and the packets output by the DUT to the DUT).

[0089] In addition, the AXI bus function model 3 can also support injection of specific RDMA scenarios (such as PSN jumps, packet retransmission simulation, memory protection errors) to achieve dynamic error injection, while the current SVTVIP only supports standard AXI errors. The AXI bus monitor 4 can also be used to integrate a custom coverage model (such as counting the distribution of RDMA operation types) to enhance coverage.

[0090] In other embodiments of the present application, in the above chip verification system, a generator is further included, where: the generator is respectively connected to the APB bus function model 5 and the AXI bus function model 3; the generator is used to generate randomized transaction data that conforms to preset constraint conditions by means of randomization according to the configuration data, and send the randomized transaction data to the APB bus function model 5 and the AXI bus function model 3.

[0091] Specifically, the generator is the GENERATOR component in the VMM verification framework. By using the generator, the random and constraint processing of the configuration data obtained by the test case module 1 can be modified to obtain randomized transaction data, which is further processed by the AXI bus function model 3 and the APB bus function model 5 to drive the device under test module 7 to respond, and the response signals output by the device under test module 7 are converted by the AXI bus monitor 4 and the APB bus monitor 6 to output packet transactions, so as to ensure as much as possible the coverage of the function points of each sub-module of the device under test module 7 and improve the comprehensiveness of the RDMA network card chip verification.

[0092] In other embodiments of the present application, the APB bus function model 5 is further used to obtain the configuration data of the XGMAC core and start the device under test module 7 according to the configuration data of the XGMAC core.

[0093] Specifically, the XGMAC (10 Gigabit Media Access Control) core is a MAC layer hardware module for 10G Ethernet, which is used to manage and control the sending and receiving of Ethernet data; the APB bus function module can receive the configuration data of the XGMAC core from the APB-CFG component of the test case module 1. In the VMM verification framework, the APB-CFG component is an important module for configuring APB bus-related parameters and behaviors. The test case module 1 can configure the APB-CFG component to achieve the configuration of the XGMAC core; the APB bus function module can convert the configuration data of the XGMAC core and transfer it to the device under test module 7 to drive the device under test module 7 to open the RX channel (receive channel), TX channel (send channel), configure the working mode of CRC (Cyclic Redundancy Check), etc. to start the operation of the XGMAC core.

[0094] As Figure 3 shown, in another embodiment of the present application, a chip verification method is further provided, which is applied to the RDMA network card chip. The method is implemented based on the above chip verification system. Among them, the chip verification system is implemented based on the VMM verification framework. The chip verification system includes: test case module 1, AXI bus function model 3, AXI bus monitor 4, APB bus function model 5, APB bus monitor 6, CPU 2, and device under test module 7; the test case module 1 is connected to the CPU 2, and the CPU 2 is also respectively connected to the AXI bus function model 3, AXI bus monitor 4, APB bus function model 5, and APB bus monitor 6; the device under test module 7 is respectively connected to the AXI bus function model 3 and AXI bus monitor 4 through the AXI bus; the device under test module 7 is also respectively connected to the APB bus function model 5 and APB bus monitor 6 through the APB bus. The above chip verification method includes:

[0095] S101. Use the test case module 1 to obtain the configuration data of the verification task and send the configuration data to the CPU 2;

[0096] S102. Use the CPU 2 to encapsulate the configuration data into transaction-level data and send the transaction-level data to the AXI bus function model 3 and the APB bus function model 5 respectively;

[0097] S103. Use the AXI bus function model 3 to convert the transaction-level data into the first interface timing signal according to the AXI protocol and send the first interface timing signal to the device under test module 7 to drive the device under test module 7 to output the first interface response signal according to the first interface timing signal;

[0098] S104. Using the APB bus function model 5, according to the APB protocol, convert the transaction-level data into the second interface timing signal, and send the second interface timing signal to the device under test module 7 to drive the device under test module 7 to output the second interface response signal according to the second interface timing signal;

[0099] S105. Use the AXI bus monitor 4 to convert the first interface response signal into the first message transaction according to the AXI protocol and output the first message transaction;

[0100] S106. Use the APB bus monitor 6 to convert the second interface response signal into the second message transaction according to the APB protocol and output the second message transaction.

[0101] The above embodiments are based on the AXI bus function model 3 and the APB bus function model 5 of the VMM verification framework to implement the format conversion of the transmitted data, achieve high management and control efficiency for the device under test module 7, and can perform relatively sufficient verification on the RDMA network card chip by performing real-time processing on the read / write response or read / write request information sent by the device under test module 7, provide a verification platform for the application of the RDMA network card chip in multiple scenarios in the high-performance computing field, and shorten the development cycle of the RDMA network card chip. Compared with the traditional EDA simulation method, the above embodiments have lower complexity and faster verification speed, and can improve the verification efficiency of the RDMA network card chip.

[0102] In other embodiments of the present application, in the above chip verification method, it further includes: using the CPU 2 to detect whether the configuration data is valid to obtain a detection result; correspondingly, one implementation manner of the step of using the CPU 2 to encapsulate the configuration data into transaction-level data specifically includes: when the detection result is that the configuration data is valid, using the CPU 2 to encapsulate the configuration data into transaction-level data.

[0103] In other embodiments of the present application, another chip verification method is further provided, which specifically includes:

[0104] S201. Use the test case module 1 to obtain the configuration data of the verification task and send the configuration data of the verification task to the CPU 2 and the APB bus function model 5;

[0105] In S201, specifically, after the configuration data of the verification task is transmitted through the verification environment, it reaches CPU2 and the APB bus function model 5. Taking the RDMA Write operation as an example, the configuration data specifically includes: the type opcode of the send operation is RC_WRITE, the memory address remote_addr of the remote operation is 44'h6ac000, the memory size remote_length of the remote operation is 1024 bytes, the virtual start address sge_addr of the local buffer is 44'h6a8000, the length sge_length of the local buffer is 1024 bytes, etc. It represents that the requesting end writes the 1024-byte memory data starting from the address 44'h6a8000 of the local buffer to the target location of the remote memory address 44'h6ac000.

[0106] S202. Use the APB bus function model 5 to obtain the configuration data of the XGMAC core from the configuration data of the verification task, and start the design-under-test module 7 according to the configuration data of the XGMAC core;

[0107] In S202, specifically, the APB bus function module obtains the configuration data of the XGMAC core from the configuration data of the verification task, converts the configuration data of the XGMAC core and transmits it to the design-under-test module 7 to drive the design-under-test module 7 to open the RX channel, TX channel, configure the working mode of CRC, etc. to start the XGMAC core.

[0108] S203. Use CPU2 to encapsulate the configuration data of the verification task into transaction-level data and send the transaction-level data to the AXI bus function model 3 and the APB bus function model 5;

[0109] In S203, use CPU2 to encapsulate the configuration data of the verification task, such as CQC, SMAC, SGID, QPC, MRC, etc., into transaction-level data and transmit it to the AXI bus function model 3 and the APB bus function model 5.

[0110] S204. Use the AXI bus function model 3 to convert the transaction-level data into the first interface timing signal according to the AXI protocol, and send the first interface timing signal to the design-under-test module 7 to drive the design-under-test module 7 to output the first interface response signal according to the first interface timing signal, and use the AXI bus function model 3 to initialize the local memory area space to random values according to the send queue elements and output them to the preset storage file;

[0111] In S204, specifically, the AXI bus function model 3 receives the transaction-level data sent by the CPU 2, converts it into the first interface timing signal according to the AXI protocol to configure the design-under-test module 7 to start the operation of the design-under-test module 7, initializes the local memory area space to random values according to the SQE, and outputs it to a preset storage file.

[0112] S205. Use the APB bus function model 5 to convert the transaction-level data into the second interface timing signal according to the APB protocol, and send the second interface timing signal to the design-under-test module 7 to drive the design-under-test module 7 to output the second interface response signal according to the second interface timing signal.

[0113] In S205, specifically, the APB bus function model 5 receives the transaction-level data sent by the CPU 2, converts it into the second interface timing signal according to the APB protocol to configure the design-under-test module 7 to start the operation of the design-under-test module 7.

[0114] S206. Use the AXI bus monitor 4 to convert the first interface response signal into the first message transaction according to the AXI protocol and output the first message transaction.

[0115] In S206, specifically, use the AXI bus monitor 4 to monitor and receive the first interface response signal output by the design-under-test module 7, convert it into the first message transaction, and store it in a preset storage file for data update and display; among them, if the AXI bus monitor 4 can receive the CQE information sent by the design-under-test module 7, then this RDMA operation is successful, otherwise it fails.

[0116] S207. Use the APB bus monitor 6 to determine whether the read / write operation of the design-under-test module 7 is successful according to the second interface response signal, convert the second interface response signal into the second message transaction according to the APB protocol, and output the second message transaction.

[0117] In S207, specifically, the APB bus monitor 6 is used to receive the second interface response signal of the design module 7 under test to check whether the read and write operations of the design module 7 under test configured by the APB bus function model 5 are successful. Specifically, the design module 7 under test uses the write response channel of the APB protocol to inform the APB bus monitor 6 whether the write operation is successful. The BRESP signal of the write response channel indicates the transmission status: OKAY (normal access successful / exclusive access failed), EXOKAY (exclusive access successful), SLVERR (arrived at the slave, but slave error), DECERR (decode error, transmission address has no slave). The AXI bus monitor 4 is used to monitor and receive the second interface response signal output by the design module 7 under test, convert it into a second message transaction, and output it to be stored in a preset storage file.

[0118] S208. Use the CPU 2 to monitor the number of send queue elements sent by the AXI bus function model 3 and the number of work queue elements received by the AXI bus monitor 4, and when the number of send queue elements is equal to the number of work queue elements, control the simulation process to end.

[0119] In summary of the above embodiments, the above chip verification method uses the AXI bus function model 3 to "translate" the configuration data output by the test case module 1 into the data format transmitted by the AXI bus to implement the configuration of the relevant information required for RDMA transmission in the design module 7 under test, verify the generation of random numbers and the constraint mechanism to ensure that random messages are injected into the design module 7 under test, and can implement the verification of each sub-design module of the design module 7 under test.

[0120] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A chip verification system, characterized in that, Applied to an RDMA network card chip, the system is implemented based on a VMM verification framework. The system includes: a test case module, an AXI bus function model, an AXI bus monitor, an APB bus function model, an APB bus monitor, a CPU, and a design under test module; the test case module is connected to the CPU, and the CPU is also respectively connected to the AXI bus function model, the AXI bus monitor, the APB bus function model, and the APB bus monitor; the design under test module is respectively connected to the AXI bus function model and the AXI bus monitor through the AXI bus; the design under test module is also respectively connected to the APB bus function model and the APB bus monitor through the APB bus, where: The test case module is used to obtain configuration data of a verification task and send the configuration data to the CPU; The CPU is used to encapsulate the configuration data into transaction-level data and send the transaction-level data to the AXI bus function model and the APB bus function model respectively; The AXI bus function model is used to convert the transaction-level data into first interface timing signals according to the AXI protocol and send the first interface timing signals to the design under test module to drive the design under test module to output first interface response signals according to the first interface timing signals; The APB bus function model is used to convert the transaction-level data into second interface timing signals according to the APB protocol and send the second interface timing signals to the design under test module to drive the design under test module to output second interface response signals according to the second interface timing signals; The AXI bus monitor is used to convert the first interface response signals into first message transactions according to the AXI protocol and output the first message transactions; The APB bus monitor is used to convert the second interface response signals into second message transactions according to the APB protocol and output the second message transactions.

2. The system according to claim 1, wherein: The CPU is further used to detect whether the configuration data is valid to obtain a detection result; Correspondingly, when the CPU executes the step of encapsulating the configuration data into transaction-level data, it is specifically used for: when the detection result indicates that the configuration data is valid, encapsulating the configuration data into transaction-level data.

3. The system according to claim 1, characterized in that The CPU is further used to monitor the number of elements in the send queue sent by the AXI bus function model and the number of elements in the work queue received by the AXI bus monitor, and when the number of elements in the send queue is equal to the number of elements in the work queue, control the simulation process to end.

4. The system according to claim 1, wherein It further includes a generator, where: The generator is respectively connected to the APB bus function model and the AXI bus function model; The generator is used to generate randomized transaction data that meets preset constraint conditions through a randomization method according to the configuration data, and send the randomized transaction data to the APB bus function model and the AXI bus function model.

5. The system according to claim 1, wherein The APB bus function model is further used to obtain the configuration data of the XGMAC core and start the design under test module according to the configuration data of the XGMAC core.

6. A chip verification method, characterized in that, Applied to an RDMA network card chip, the method is implemented based on the chip verification system according to any one of claims 1-5, wherein the system is implemented based on a VMM verification framework, and the system includes: a test case module, an AXI bus function model, an AXI bus monitor, an APB bus function model, an APB bus monitor, a CPU, and a design under test module; the test case module is connected to the CPU, and the CPU is further connected to the AXI bus function model, the AXI bus monitor, the APB bus function model, and the APB bus monitor respectively; the design under test module is connected to the AXI bus function model and the AXI bus monitor respectively through the AXI bus; the design under test module is further connected to the APB bus function model and the APB bus monitor respectively through the APB bus, and the method includes: Using the test case module, obtain the configuration data of the verification task and send the configuration data to the CPU; Using the CPU, encapsulate the configuration data into transaction-level data and send the transaction-level data to the AXI bus function model and the APB bus function model respectively; Using the AXI bus function model, convert the transaction-level data into first interface timing signals according to the AXI protocol, and send the first interface timing signals to the design under test module to drive the design under test module to output first interface response signals according to the first interface timing signals; Using the APB bus function model, convert the transaction-level data into second interface timing signals according to the APB protocol, and send the second interface timing signals to the design under test module to drive the design under test module to output second interface response signals according to the second interface timing signals; Using the AXI bus monitor, convert the first interface response signals into first message transactions according to the AXI protocol and output the first message transactions; Using the APB bus monitor, convert the second interface response signals into second message transactions according to the APB protocol and output the second message transactions.

7. The method according to claim 6, wherein It further includes: Using the CPU, detect whether the configuration data is valid to obtain a detection result; Correspondingly, the using the CPU to encapsulate the configuration data into transaction-level data specifically includes: when the detection result indicates that the configuration data is valid, using the CPU to encapsulate the configuration data into transaction-level data.

8. The method according to claim 6, wherein It further includes: Using the CPU, monitor the number of transmission queue elements sent by the AXI bus function model and the number of work queue elements received by the AXI bus monitor, and when the number of transmission queue elements is equal to the number of work queue elements, control the simulation process to end.

9. The method according to claim 6, wherein It further includes: Using the APB bus function model, obtain the configuration data of the XGMAC core, and start the DUT module according to the configuration data of the XGMAC core.

10. The method according to claim 6, wherein It further includes: Using the APB bus monitor, determine whether the read and write operations of the DUT module are successful according to the second interface response signal.

Images