Multi-platform fusion verification system

Abstract

The invention relates to the technical field of chips, in particular to a multi-platform fusion verification system which comprises a Cmodel case issuing module, a hardware case issuing module, a software case issuing module, a system case issuing module, a first conversion interface, an application development interface module, a driving module, a Cmodel verification branch, an RTL verification branch, a hardware simulation verification branch and a chip verification branch. The driving module gates one verification branch by setting an environment variable; if the environment variable is set as a Cmodel type, the Cmodel verifies branch gating; if the environment variable is set as an RTL type, the RTL verifies branch gating; if the environment variable is set as a hardware simulation type, hardware simulation verifies branch gating; and if the environment variable is set to be the chip type, the chip verification branch is gated. The chip verification cost is reduced, and the chip verification efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the field of chip technology, and in particular to a multi-platform fusion 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 physical chip will be obtained, and then system-level verification is performed based on the hardware accelerator or physical chip. After the system-level verification is passed, software-level verification is performed based on the accelerator or physical chip. Before the hardware-level verification, verification can also be performed based on the C language design verification model (Cmodel). In the prior art, it is necessary to develop verification platforms for different stages for verification at different stages, which requires a lot of cost, and different verification platforms can only verify the test cases of the corresponding stages, and cannot realize the verification of cross-stage test cases. If there is a cross-stage verification requirement, for example, when there is a problem 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, but 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, and the chip verification efficiency is low. It can be seen from this that how to reduce the cost of chip verification and improve the efficiency of chip verification has become a technical problem that needs to be solved urgently. Summary of the invention

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

[0004] The present invention provides a multi-platform fusion verification system, including a Cmodel use case sending module, a hardware use case sending module, a software use case sending module, a system use case sending 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; Wherein, the hardware use case sending module is connected to the first conversion interface; The first conversion interface, the software use case delivery module, and the system use case delivery 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 enables a verification branch by setting an environment variable; if the environment variable is set to the Cmodel type, the Cmodel verification branch is enabled; if the environment variable is set to the RTL type, the RTL verification branch is enabled; if the environment variable is set to the hardware simulation type, the hardware simulation verification branch is enabled; if the environment variable is set to the chip type, the chip verification branch is enabled; The Cmodel use case sending module is used to send Cmodel test cases to the application development interface module; The hardware test case sending module is used to send hardware test cases to the first conversion interface; The first conversion interface is used to convert the hardware test case into a hardware test case implemented in a software language and send it to the application development interface module; The software test case sending module is used to send software test cases to the application development interface module; The system test case sending module is used to send system test cases to the application development interface module; The application development interface module is used to call the driver module to run the received test case on the branch currently selected by the driver module, and the received test case is a Cmodel test case, a hardware test case, a software test case or a system test case.

[0005] Compared with the prior art, the present invention has obvious advantages and beneficial effects. By means of the above technical solution, the multi-platform fusion verification system provided by the present invention can achieve considerable technical advancement and practicality, and has wide industrial utilization value, and has at least the following beneficial effects: The present invention integrates a Cmodel test platform, an RTL test platform, a hardware simulation test platform and a chip test platform into a verification system, selects corresponding verification branches by configuring environment variables in a driver module, and each verification branch can realize the verification of test cases in different stages, thereby realizing the verification of cross-stage test cases, reducing the chip verification cost and improving the chip verification efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0007] Figure 1 A schematic diagram of a multi-platform fusion verification system provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0008] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0009] The embodiment of the present invention provides a multi-platform fusion verification system, such as Figure 1 As shown, it includes a Cmodel use case sending module, a hardware use case sending module, a software use case sending module, a system use case sending 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 software language, and the software language can specifically be C language, C++ language, etc. The first conversion interface is implemented based on software language and hardware language, and the hardware language corresponding to the first conversion interface is SystemVeriliog language.

[0010] The verification object corresponding to the Cmodel verification branch is Cmodel, which is generated based on the software language. The verification object corresponding to the RTL verification branch is the RTL code of the chip design to be tested, which is generated based on the hardware language. The hardware language can specifically be Verilog language, SystemVeriliog language, etc. The verification object corresponding to the hardware simulation verification branch is the hardware emulator, and the verification object corresponding to the chip verification branch is the chip. Both the hardware emulator and the chip are hardware entities. In the prior art, each verification branch corresponds to an independent test platform, and 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 the hardware emulator or chip. The software test case runs on the software test platform, and the verification object corresponding to the software test case is the hardware emulator or chip.

[0011] The Cmodel use case sending module is used to send 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 sending module according to the writing rules of Cmodel test cases for sending. After subsequent processing, they can be run on the currently enabled 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, the test cases of the subsequent stages are usually verified in advance, that is, the verification is shifted to the left, and generally no right shift is required. Therefore, the Cmodel use case sending module usually only needs to run when the Cmodel verification branch is enabled.

[0012] The hardware use case sending module is connected to the first conversion interface; the first conversion interface, the software use case sending module, and the system use case sending 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.

[0013] The driver module enables a verification branch by setting an environment variable, that is, the system can only have one branch enabled at the same time, and cannot enable both branches at the same time. If the environment variable is set to the Cmodel type, the Cmodel verification branch is enabled; if the environment variable is set to the RTL type, the RTL verification branch is enabled; if the environment variable is set to the hardware simulation type, the hardware simulation verification branch is enabled; if the environment variable is set to the chip type, the chip verification branch is enabled. Based on this, only one integrated system needs to be set up to implement verification at different stages by configuring environment variables, without the need to develop a separate test platform for each stage, which greatly reduces the cost of chip verification.

[0014] The hardware use case sending module is used to send 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 sending module in accordance with the hardware test case writing rules for sending, and then run them on the currently enabled verification branch through subsequent processing, not limited to the RTL verification branch. It should be noted that RTL verification is also a relatively early verification stage. When performing cross-stage test case verification, the test cases of the later stages are usually verified in advance, that is, the verification is shifted to the left, and generally no right shift is required. Therefore, the hardware use case sending module usually only needs to run when the Cmodel verification branch and the RTL verification branch are enabled.

[0015] Since the application development interface module is based on software implementation, the hardware test cases generated based on the hardware language cannot be directly recognized by the application development interface module, so it needs to be converted first. The first conversion interface is used to convert the hardware test cases into hardware test cases implemented in the software language and send them to the application development interface module. The first conversion interface can be specifically implemented by the existing direct programming interface (Direct Programming Interface, referred to as DPI). 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 transferred between the two languages. Therefore, based on DPI, the conversion between software language and SystemVerilog language can be realized, which will not be repeated here.

[0016] The software use case sending module is used to send software test cases to the application development interface module; it should be noted that software engineers can generate software test cases based on the software use case sending module according to the software test case writing rules for sending, and then run them on the currently selected verification branch through subsequent processing, not limited to the hardware simulation verification branch and the chip verification branch.

[0017] The system use case sending module is used to send 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 use case sending module according to the system test case writing rules for sending, and then run them on the currently selected verification branch through subsequent processing, not limited to the hardware simulation verification branch and the chip verification branch.

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

[0019] As an embodiment, the application development interface module is used to parse the received test case, 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. The operation parameters can be the original operation parameters and the original operation logic corresponding to the test case. The operation parameters can also be the original operation parameters and the intermediate operation parameters obtained based on the original operation parameters, and the operation logic can be the original operation logic and the intermediate operation logic obtained based on the original operation logic. The driver module allocates a corresponding memory address to each operation parameter based on the memory size required by the operation parameter and the current memory resources.

[0020] As an example, Figure 1As shown, the driver module includes a virtual function interface (VirtualFunction I / O, referred to as VFIO). VFIO is a user-mode driver framework that can directly interact with the underlying library 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 turned on. It should be noted that the virtual function interface is enabled when the test case is a system test case. The granularity of the operation logic of the system test case is finer than that of other types of test cases. The system test case is undertaken through the virtual function interface, so that the system has better compatibility.

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

[0022] As an example, Figure 1 As shown, the driver module also includes a logic conversion interface, and the logic conversion interface is before the virtual function interface. When the selected verification branch is a hardware simulation verification branch or a chip verification branch, and the received test case is a software test case, the logic conversion interface is turned on. It should be noted that the logic conversion interface is used in conjunction with the virtual function interface. When the logic conversion interface is turned on, the virtual function interface must also be turned on.

[0023] As an embodiment, if the logic conversion interface is turned on, 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. It should be noted that the interaction with the hardware emulator and the chip can be achieved through the virtual function interface. The granularity of software test cases is usually coarser than that of system test cases. Therefore, before interacting with the virtual function interface, the operation parameters and operation logic of the software test cases need to be converted into operation parameters and operation logic that conform to the granularity of interaction with the virtual function interface. The granularity of the system test case conforms to the operation parameters and operation logic of the granularity of interaction with the virtual function interface, so it can directly interact with the virtual function interface without conversion through the logic conversion interface.

[0024] Since the verification object corresponding to the RTL verification branch is the RTL code of the chip design to be tested, which is generated based on the hardware language, and the original register type instructions, original memory type instructions and original doorbell type instructions are generated based on the software language, language conversion is required. As an embodiment, the RTL verification branch also 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 the SystemVerilog language. The specific device of the second conversion interface is DPI.

[0025] 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, the target memory type instructions and the target doorbell type instructions, and the test cases received by the RTL verification branch are hardware test cases, system test cases or software test cases.

[0026] 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, the original memory type instructions and the 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.

[0027] The hardware simulation verification branch is used to run the test case received by the hardware simulation verification branch on the hardware simulation model based on the original register type instruction, the original memory type instruction and the original doorbell type instruction. The test case received by the hardware simulation verification branch is a system test case or a software test case.

[0028] The chip verification branch is used to run the test case received by the chip verification branch on the chip based on the original register type instruction, the original memory type instruction and the original doorbell type instruction. The test case received by the chip verification branch is a system test case or a software test case.

[0029] As an embodiment, the application development interface module is used to call the driver module to generate an original register configuration instruction based on each operation parameter and the memory address corresponding to each operation parameter, and issue it to the current gating verification branch. If there is a second conversion interface in the current gating verification branch, it is necessary to convert the original register configuration instruction into a target register configuration instruction based on the SystemVerilog language through the second conversion interface. If there is a second conversion interface in the current gating verification branch, the current gating verification branch configures the register in the verification object corresponding to the current gating verification branch based on the target register configuration instruction, otherwise, the current gating verification branch configures the register in the verification object corresponding to the current gating verification branch based on the original register configuration instruction. After the register configuration is completed, the current gating verification branch generates a register configuration completion instruction. If there is a second conversion interface in the current gating verification branch, it is necessary to convert the register configuration completion instruction into a software-implemented register configuration completion instruction through the second conversion interface, and then return it to the application development interface module through the driver module, otherwise, directly return the register configuration completion instruction to the application development interface module through the driver module.

[0030] As an embodiment, after receiving the register configuration completion instruction, the application development interface module is used to call the driver module to generate the original data handling instruction based on each operation parameter and the register configuration information, and issue it to the current gating verification branch. If there is a second conversion interface in the current gating verification branch, it is necessary to convert the original data handling instruction into a target data handling instruction based on the SystemVerilog language through the second conversion interface. If there is a second conversion interface in the current gating verification branch, the current gating verification branch stores the original data in the corresponding memory based on the target data handling instruction, otherwise, the current gating verification branch stores the original data in the corresponding memory based on the original data handling instruction. After the original data storage is completed, the current gating verification branch generates a data handling completion instruction. If there is a second conversion interface in the current gating verification branch, it is necessary to convert the data handling completion instruction into a software-implemented data handling completion instruction through the second conversion interface, and then return it to the application development interface module through the driver module, otherwise, directly return the data handling completion instruction to the application development interface module through the driver module.

[0031] 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 current selection verification branch.

[0032] If there is a second conversion interface in the current gating verification branch, it is necessary to convert the original doorbell instruction 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 current gating verification branch, the current gating verification branch executes the operation logic based on the target doorbell instruction and the original data stored in the memory to generate the operation result, otherwise, the current gating verification branch executes the operation logic based on the original doorbell instruction and the original data stored in the memory to generate the operation result. If there is a second conversion interface in the current gating verification branch, it is necessary to convert the operation result into the operation result implemented by the software through the second conversion interface, and then return it to the application development interface module through the driver module, otherwise, directly return the operation result 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, and finally the operation result is compared with the target result. If they are consistent, the test passes, and if they are inconsistent, the test fails.

[0033] The system described in the embodiment 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, and selects the corresponding verification branch by configuring the environment variables in the driver module. Each verification branch can realize the verification of test cases in different stages, thereby realizing the verification of cross-stage test cases, reducing the chip verification cost and improving the chip verification efficiency.

[0034] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any form. Although the present invention has been disclosed as a preferred embodiment as above, it is not used to limit the present invention. Any technician familiar with this profession can make some changes or modifications to equivalent embodiments of equivalent changes using the technical contents disclosed above without departing from the scope of 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 without departing from the content of the technical solution of the present invention still falls within the scope of the technical solution of the present invention.

Claims

1. A multi-platform fusion verification system, characterized in that: It includes a Cmodel use case sending module, a hardware use case sending module, a software use case sending module, a system use case sending 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; Wherein, the hardware use case sending module is connected to the first conversion interface; The first conversion interface, the software use case delivery module, and the system use case delivery 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 enables a verification branch by setting an environment variable; if the environment variable is set to the Cmodel type, the Cmodel verification branch is enabled; if the environment variable is set to the RTL type, the RTL verification branch is enabled; if the environment variable is set to the hardware simulation type, the hardware simulation verification branch is enabled; if the environment variable is set to the chip type, the chip verification branch is enabled; The Cmodel use case sending module is used to send Cmodel test cases to the application development interface module; The hardware test case sending module is used to send hardware test cases to the first conversion interface; The first conversion interface is used to convert the hardware test case into a hardware test case implemented in a software language and send it to the application development interface module; The software test case sending module is used to send software test cases to the application development interface module; The system test case sending module is used to send system test cases to the application development interface module; The application development interface module is used to call the driver module to run the received test case on the branch currently selected by the driver module, and the received test case is a Cmodel test case, a hardware test case, a software test case or a system test case.

2. The system according to claim 1, characterized in that The application development interface module is used to parse the received test case, 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 driving module includes a virtual function interface, and when the received test case is a system test case, the virtual function interface is turned on.

4. The system according to claim 3, 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 case; 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.

5. The system according to claim 3, characterized in that The driver module also includes a logic conversion interface, which is before the virtual function interface. When the selected verification branch is a hardware simulation verification branch or a chip verification branch, and the received test case is a software test case, the logic conversion interface is turned on.

6. The system according to claim 5, characterized in that If the logic conversion interface is turned on, 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.

7. The system according to claim 4 or 6, characterized in that: The RTL verification branch also includes a second conversion interface, which is used to convert 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.

8. The system according to claim 7, characterized in that The RTL verification branch is used to run the test case received by the RTL verification branch based on the target register type instruction, the target memory type instruction and the target doorbell type instruction; The Cmodel verification branch is used to run the test case received by the Cmodel verification branch on the Cmodel based on the original register type instruction, the original memory type instruction and the original doorbell type instruction; The hardware simulation verification branch is used to run the test case received by the hardware simulation verification branch on the hardware simulation model based on the original register type instruction, the original memory type instruction and the original doorbell type instruction; 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, the original memory type instructions and the original doorbell type instructions.

Images