Multi-platform integration verification system

Abstract

The present invention relates to the field of chip technology, and particularly to a multi-platform fusion verification system, including a Cmodel test case distribution module, a hardware test case distribution module, a software test case distribution module, a system test case distribution module, a first conversion interface, an application development interface module, a driver module, a Cmodel verification branch, an RTL verification branch, a hardware simulation verification branch, and a chip verification branch; the driver module selects a verification branch by setting environment variables; if the environment variable is set to the Cmodel type, the Cmodel verification branch is selected; if the environment variable is set to the RTL type, the RTL verification branch is selected; if the environment variable is set to the hardware simulation type, the hardware simulation verification branch is selected; if the environment variable is set to the chip type, the chip verification branch is selected. The present invention reduces the chip verification cost and improves the chip verification efficiency.

Description

Technical Field

[0001] The present invention relates to the field of chip technology, and in particular, to a multi-platform integrated verification system. Background Art

[0002] During the chip development process, different chip verification stages need to be experienced. Usually, hardware-level verification is first performed based on the chip RTL (Register Transfer Level) code. After the basic hardware verification, a chip hardware accelerator or a physical chip will be obtained. Then, system-level verification is performed based on the hardware accelerator or the physical chip. After the system-level verification passes, software-level verification is performed based on the accelerator or the physical chip. Before the hardware-level verification, verification can also be performed based on a C language design verification model (Cmodel). In the prior art, different verification platforms need to be developed for the verification of different stages, which requires a large amount of cost, and only test cases corresponding to the corresponding stages can be verified between different verification platforms, and cross-stage test case verification cannot be achieved. If there is a cross-stage verification requirement, for example, when a problem occurs in the system verification and the problem point cannot be found through the system-level verification, the same test case needs to be verified on the hardware-level verification platform. However, the system-level test case cannot be directly run on the hardware-level verification platform, and the test case corresponding to the hardware-level verification platform needs to be rewritten, resulting in low chip verification efficiency. Therefore, how to reduce the chip verification cost and improve the chip verification efficiency has become an urgent technical problem to be solved. Summary of the Invention

[0003] The purpose of the present invention is to provide a multi-platform integrated verification system, which reduces the chip verification cost and improves the chip verification efficiency.

[0004] The present invention provides a multi-platform integrated verification system, including a Cmodel use case distribution module, a hardware use case distribution module, a software use case distribution module, a system use case distribution module, a first conversion interface, an application development interface module, a driver module, a Cmodel verification branch, an RTL verification branch, a hardware simulation verification branch, and a chip verification branch;

[0005] Among them, the hardware use case distribution module is connected to the first conversion interface;

[0006] The first conversion interface, the software use case distribution module, and the system use case distribution module are respectively connected to the application development interface module, and the driver module is respectively connected to the application development interface module, the Cmodel verification branch, the RTL verification branch, the hardware simulation verification branch, and the chip verification branch;

[0007] The driving module selects a verification branch by setting an environment variable; if the environment variable is set to the Cmodel type, the Cmodel verification branch is selected; if the environment variable is set to the RTL type, the RTL verification branch is selected; if the environment variable is set to the hardware simulation type, the hardware simulation verification branch is selected; if the environment variable is set to the chip type, the chip verification branch is selected;

[0008] The Cmodel test case issuing module is used to issue Cmodel test cases to the application development interface module;

[0009] The hardware test case issuing module is used to issue hardware test cases to the first conversion interface;

[0010] The first conversion interface is used to convert the hardware test cases into hardware test cases implemented in software language and send them to the application development interface module;

[0011] The software test case issuing module is used to issue software test cases to the application development interface module;

[0012] The system test case issuing module is used to issue system test cases to the application development interface module;

[0013] The application development interface module is used to call the driving module to run the received test cases on the currently selected branch of the driving module, and the received test cases are Cmodel test cases, hardware test cases, software test cases or system test cases.

[0014] Compared with the prior art, the present invention has obvious advantages and beneficial effects. By means of the above technical solutions, a multi-platform integrated verification system provided by the present invention can achieve considerable technological progressiveness and practicality, and has wide industrial utilization value. It has at least the following beneficial effects:

[0015] The present invention integrates the Cmodel test platform, the RTL test platform, the hardware simulation test platform and the chip test platform into a verification system. By configuring the environment variables in the driving module to select the corresponding verification branches, and each verification branch can implement the verification of test cases in different stages, the verification of cross-stage test cases is realized, the chip verification cost is reduced, and the chip verification efficiency is improved. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] Figure 1 Schematic diagram of the multi-platform fusion verification system provided by the embodiment of the present invention. Detailed implementation manners

[0018] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative efforts fall within the protection scope of the present invention.

[0019] The embodiment of the present invention provides a multi-platform fusion verification system, as Figure 1 shown, including a Cmodel test case distribution module, a hardware test case distribution module, a software test case distribution module, a system test case distribution module, a first conversion interface, an application development interface module, a driver module, a Cmodel verification branch, an RTL verification branch, a hardware simulation verification branch, and a chip verification branch. The application development interface module and the driver module are implemented based on a software language, and the software language can specifically be a C language, a C++ language, etc. The first conversion interface is implemented based on a software language and a hardware language, and the hardware language corresponding to the first conversion interface is a SystemVeriliog language.

[0020] The verification object corresponding to the Cmodel verification branch is Cmodel, and Cmodel is generated based on a software language. The verification object corresponding to the RTL verification branch is the RTL code of the chip to be tested, which is generated based on a hardware language, and the hardware language can specifically be a Verilog language, a SystemVeriliog language, etc. The verification object corresponding to the hardware simulation verification branch is a hardware simulator, and the verification object corresponding to the chip verification branch is a chip. Both the hardware simulator and the chip are hardware entities. In the prior art, each verification branch corresponds to an independent test platform. The Cmodel test case runs on the Cmodel test platform. The hardware test case runs on the RTL test platform. The system test case runs on the system test platform, and the verification object corresponding to the system test platform is a hardware simulator or a chip. The software test case runs on the software test platform, and the verification object corresponding to the software test case is a hardware simulator or a chip.

[0021] The Cmodel use case distribution module is used to distribute Cmodel test cases to the application development interface module. It should be noted that Cmodel engineers can write and generate Cmodel test cases based on the Cmodel use case distribution module according to the writing rules of Cmodel test cases for distribution. Through subsequent processing, the test cases can be run on the currently selected verification branch, not limited to the Cmodel verification branch. It should be noted that Cmodel verification is the earliest verification stage. When performing cross-stage test case verification, usually the test cases of the later stage are verified in advance, that is, the verification is shifted to the left. Generally, there is no need to shift to the right. Therefore, the Cmodel use case distribution module usually only needs to run when the Cmodel verification branch is selected.

[0022] The hardware use case distribution module is connected to the first conversion interface; the first conversion interface, the software use case distribution module, and the system use case distribution module are respectively connected to the application development interface module, and the driver module is respectively connected to the application development interface module, the Cmodel verification branch, the RTL verification branch, the hardware simulation verification branch, and the chip verification branch.

[0023] The driver module selects a verification branch by setting environment variables, that is, at the same time, only one branch of the system can be selected, and they cannot be selected simultaneously. If the environment variable is set to the Cmodel type, the Cmodel verification branch is selected; if the environment variable is set to the RTL type, the RTL verification branch is selected; if the environment variable is set to the hardware simulation type, the hardware simulation verification branch is selected; if the environment variable is set to the chip type, the chip verification branch is selected. Based on this, only one integrated system needs to be set up, and different-stage verifications can be achieved by configuring environment variables, without the need to develop a separate test platform for each stage, greatly reducing the chip verification cost.

[0024] The hardware use case distribution module is used to distribute hardware test cases to the first conversion interface; it should be noted that hardware engineers can write and generate hardware test cases based on the hardware use case distribution module according to the writing rules of hardware test cases for distribution. Through subsequent processing, the test cases can be run on the currently selected verification branch, not limited to the RTL verification branch. It should be noted that RTL verification is also an earlier verification stage. When performing cross-stage test case verification, usually the test cases of the later stage are verified in advance, that is, the verification is shifted to the left. Generally, there is no need to shift to the right. Therefore, the hardware use case distribution module usually only needs to run when the Cmodel verification branch and the RTL verification branch are selected.

[0025] Since the application development interface module is implemented based on software, the hardware test cases generated based on the hardware language cannot be directly recognized by the application development interface module. Therefore, conversion is required first. The first conversion interface is used to convert the hardware test cases into hardware test cases implemented in software language and send them to the application development interface module. The first conversion interface can be specifically implemented through the existing Direct Programming Interface (DPI for short). DPI is a standard interface that allows SystemVerilog code to directly call C or C++ functions, and vice versa. DPI allows data and control information to be passed between the two languages. Therefore, based on DPI, the conversion between software language and SystemVerilog language can be realized, which will not be elaborated here.

[0026] The software test case distribution module is used to distribute software test cases to the application development interface module. It should be noted that software engineers can write and generate software test cases based on the software test case distribution module according to the writing rules of software test cases for distribution, and through subsequent processing, they can run on the currently selected verification branch, not limited to the hardware simulation verification branch and the chip verification branch.

[0027] The system test case distribution module is used to distribute system test cases to the application development interface module. It should be noted that system engineers can write and generate system test cases based on the system test case distribution module according to the writing rules of system test cases for distribution, and through subsequent processing, they can run on the currently selected verification branch, not limited to the hardware simulation verification branch and the chip verification branch.

[0028] The application development interface module is used to call the driver module to run the received test cases on the branch currently selected by the driver module. The received test cases are Cmodel test cases, hardware test cases, software test cases, or system test cases, to achieve the verification of cross-stage test cases.

[0029] As an embodiment, the application development interface module is used to parse the received test cases, obtain operation parameters and operation logics, and call the driver module to obtain the memory address corresponding to each operation parameter based on the operation parameters. Among them, the operation parameters can be the original operation parameters and original operation logics corresponding to the test cases. The operation parameters can also be the original operation parameters and intermediate operation parameters obtained based on the original operation parameters, and the operation logics can be the original operation logics and intermediate operation logics obtained based on the original operation logics. The driver module allocates corresponding memory addresses for each operation parameter based on the required memory size of the operation parameters and the current memory resources.

[0030] As an embodiment, such as Figure 1As shown in the figure, the drive module includes a Virtual Function I / O (VFIO for short). VFIO is a user-state drive framework that can directly interact with the underlying libraries of Linux and then interact with the selected verification branch. When the received test case is a system test case, the virtual function interface is enabled. It should be noted that the virtual function interface is enabled when the test case is a system test case. The operation logic of the system test case has a finer granularity than that of other types of test cases. By using the virtual function interface to undertake the system test case, the system has better compatibility.

[0031] As an embodiment, the application development interface module is used to generate original register type instructions, original memory type instructions, and original doorbell type instructions by calling the drive module based on the received test case; if the virtual function interface is enabled, the application development interface module calls the virtual function interface in the drive module to generate original register type instructions, original memory type instructions, and original doorbell type instructions. That is, when the virtual function interface is not enabled, the generation of original register type instructions, original memory type instructions, and original doorbell type instructions can be achieved only through the basic drive unit in the drive module.

[0032] As an embodiment, as Figure 1 shown in the figure, the drive module further includes a logic conversion interface. The logic conversion interface is before the virtual function interface. When the selected verification branch is the hardware emulation verification branch or the chip verification branch, and the received test case is a software test case, the logic conversion interface is enabled. It should be noted that the logic conversion interface and the virtual function interface are used in combination. When the logic conversion interface is enabled, the virtual function interface must also be enabled.

[0033] As an embodiment, if the logic conversion interface is enabled, the application development interface module first calls the logic conversion interface to convert the operation parameters and operation logic of the software test case into fine-grained operation parameters and operation logic, and then calls the virtual function interface in the drive module to generate original register type instructions, original memory type instructions, and original doorbell type instructions. It should be noted that the virtual function interface can be used to interact with the hardware emulator and the chip. The granularity of the software test case is usually coarser than that of the system test case. Therefore, before interacting with the virtual function interface, it is necessary to first convert the operation parameters and operation logic of the software test case into operation parameters and operation logic that meet the granularity of interacting with the virtual function interface. The granularity of the system test case meets the operation parameters and operation logic of interacting with the virtual function interface, so it can directly interact with the virtual function interface without conversion through the logic conversion interface.

[0034] Since the verification object corresponding to the RTL verification branch is the RTL code of the chip design under test, which is generated based on a hardware language, and the original register type instructions, original memory type instructions, and original doorbell type instructions are generated based on a software language, language conversion is required. As an embodiment, the RTL verification branch further includes a second conversion interface, and the second conversion interface is used to convert the original register type instructions, original memory type instructions, and original doorbell type instructions into target register type instructions, target memory type instructions, and target doorbell type instructions implemented in SystemVerilog language. The specific device of the second conversion interface is DPI.

[0035] As an embodiment, the RTL verification branch is used to run the test cases received by the RTL verification branch based on the target register type instructions, target memory type instructions, and target doorbell type instructions. The test cases received by the RTL verification branch are hardware test cases, system test cases, or software test cases.

[0036] The Cmodel verification branch is used to run the test cases received by the Cmodel verification branch on the Cmodel based on the original register type instructions, original memory type instructions, and original doorbell type instructions; the test cases received by the Cmodel verification branch are Cmodel test cases, hardware test cases, system test cases, or software test cases.

[0037] The hardware simulation verification branch is used to run the test cases received by the hardware simulation verification branch on the hardware simulation model based on the original register type instructions, original memory type instructions, and original doorbell type instructions. The test cases received by the hardware simulation verification branch are system test cases or software test cases.

[0038] The chip verification branch is used to run the test cases received by the chip verification branch on the chip based on the original register type instructions, original memory type instructions, and original doorbell type instructions. The test cases received by the chip verification branch are system test cases or software test cases.

[0039] As an embodiment, the application development interface module is used to call the driver module to generate original register configuration instructions based on each operation parameter and the memory address corresponding to each operation parameter, and send them to the currently selected verification branch. If there is a second conversion interface in the currently selected verification branch, the original register configuration instructions need to be converted into target register configuration instructions implemented based on the SystemVerilog language through the second conversion interface. If there is a second conversion interface in the currently selected verification branch, the currently selected verification branch configures the registers in the verification object corresponding to the currently selected verification branch based on the target register configuration instructions; otherwise, the currently selected verification branch configures the registers in the verification object corresponding to the currently selected verification branch based on the original register configuration instructions. After the register configuration is completed, the currently selected verification branch generates a register configuration completion instruction. If there is a second conversion interface in the currently selected verification branch, the register configuration completion instruction needs to be converted into a software-implemented register configuration completion instruction through the second conversion interface and then returned to the application development interface module through the driver module; otherwise, the register configuration completion instruction is directly returned to the application development interface module through the driver module.

[0040] As an embodiment, after receiving the register configuration completion instruction, the application development interface module is used to call the driver module to generate original data transfer instructions based on each operation parameter and the register configuration information, and send them to the currently selected verification branch. If there is a second conversion interface in the currently selected verification branch, the original data transfer instructions need to be converted into target data transfer instructions implemented based on the SystemVerilog language through the second conversion interface. If there is a second conversion interface in the currently selected verification branch, the currently selected verification branch stores the original data in the corresponding memory based on the target data transfer instructions; otherwise, the currently selected verification branch stores the original data in the corresponding memory based on the original data transfer instructions. After the original data storage is completed, the currently selected verification branch generates a data transfer completion instruction. If there is a second conversion interface in the currently selected verification branch, the data transfer completion instruction needs to be converted into a software-implemented data transfer completion instruction through the second conversion interface and then returned to the application development interface module through the driver module; otherwise, the data transfer completion instruction is directly returned to the application development interface module through the driver module.

[0041] As an embodiment, after receiving the data transfer completion instruction, the application development interface module calls the driver module to generate an original doorbell instruction based on the operation logic and sends it to the currently selected verification branch.

[0042] If there is a second conversion interface in the currently selected verification branch, the original doorbell instruction needs to be converted into a target doorbell instruction implemented based on the SystemVerilog language through the second conversion interface. If there is a second conversion interface in the currently selected verification branch, the currently selected verification branch executes the operation logic based on the target doorbell instruction and the original data stored in the memory to generate an operation result. Otherwise, the currently selected verification branch executes the operation logic based on the original doorbell instruction and the original data stored in the memory to generate an operation result. If there is a second conversion interface in the currently selected verification branch, the operation result needs to be converted into an operation result implemented by software through the second conversion interface and then returned to the application development interface module through the driver module. Otherwise, the operation result is directly returned to the application development interface module through the driver module. It should be noted that each test case is set with a corresponding target result. Finally, the operation result is compared with the target result. If they are consistent, the test passes; if not, the test fails.

[0043] The system described in the embodiments of the present invention integrates the Cmodel test platform, the RTL test platform, the hardware simulation test platform, and the chip test platform into a verification system. By configuring the environment variables in the driver module to select the corresponding verification branch, and each verification branch can implement the verification of test cases at different stages, the verification of cross-stage test cases is realized, the chip verification cost is reduced, and the chip verification efficiency is improved.

[0044] The above are only the preferred embodiments of the present invention, and do not impose any form of limitation on the present invention. Although the present invention has been disclosed above with the preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some changes or modifications to the above-disclosed technical content to be equivalent embodiments without departing from the technical solution of the present invention. However, any simple modification, equivalent change, and modification made to the above embodiments based on the technical essence of the present invention still fall within the scope of the technical solution of the present invention.

Claims

1. A multi-platform integrated verification system, characterized in that it includes a Cmodel test case distribution module, a hardware test case distribution module, a software test case distribution module, a system test case distribution module, a first conversion interface, an application development interface module, a driver module, a Cmodel verification branch, an RTL verification branch, a hardware simulation verification branch, and a chip verification branch; Among them, the hardware test case distribution module is connected to the first conversion interface; The first conversion interface, the software test case distribution module, and the system test case distribution module are respectively connected to the application development interface module, and the driver module is respectively connected to the application development interface module, the Cmodel verification branch, the RTL verification branch, the hardware simulation verification branch, and the chip verification branch; The driver module selects a verification branch by setting environment variables; The driver module includes a virtual function interface, which is a user-mode driver framework that can directly interact with the libraries at the Linux bottom layer and then interact with the selected verification branch. When the received test case is a system test case, the virtual function interface is enabled; The first conversion interface is used to convert hardware test cases into hardware test cases implemented in software language and send them to the application development interface module; The application development interface module is used to call the driver module to run the received test cases on the branch selected by the current driver module. The received test cases are hardware test cases, software test cases, or system test cases; The driver module also includes a logic conversion interface, which is before the virtual function interface. When the selected verification branch is the hardware simulation verification branch or the chip verification branch, and the received test case is a software test case, the logic conversion interface is enabled. The logic conversion interface and the virtual function interface are used in combination. When the logic conversion interface is enabled, the virtual function interface must also be enabled; If the logic conversion interface is enabled, the application development interface module first calls the logic conversion interface to convert the operation parameters and operation logic of the software test case into fine-grained operation parameters and operation logic, and then calls the virtual function interface in the driver module to generate original register type instructions, original memory type instructions, and original doorbell type instructions.

2. The system according to claim 1, characterized in that the application development interface module is used to parse the received test cases, obtain operation parameters and operation logic, and call the driver module to obtain the memory address corresponding to each operation parameter based on the operation parameters.

3. The system according to claim 2, characterized in that the application development interface module is used to call the driver module to generate original register type instructions, original memory type instructions, and original doorbell type instructions based on the received test cases; If the virtual function interface is enabled, the application development interface module calls the virtual function interface in the driver module to generate original register type instructions, original memory type instructions, and original doorbell type instructions.

4. The system according to claim 3, characterized in that The RTL verification branch further includes a second conversion interface, which is used to convert the original register type instructions, original memory type instructions, and original doorbell type instructions into target register type instructions, target memory type instructions, and target doorbell type instructions implemented in SystemVerilog language.

5. The system according to claim 4, wherein the RTL verification branch is used to run the test cases received by the RTL verification branch based on the target register type instructions, target memory type instructions, and target doorbell type instructions; the Cmodel verification branch is used to run the test cases received by the Cmodel verification branch on the Cmodel based on the original register type instructions, original memory type instructions, and original doorbell type instructions; the hardware simulation verification branch is used to run the test cases received by the hardware simulation verification branch on the hardware simulation model based on the original register type instructions, original memory type instructions, and original doorbell type instructions; the chip verification branch is used to run the test cases received by the chip verification branch on the chip based on the original register type instructions, original memory type instructions, and original doorbell type instructions.

Images