A universal verification system for integrated circuit chip verification

Abstract

The present invention belongs to the field of digital chips, and relates to a universal verification system for integrated circuit chip verification, wherein the top-level code directory includes a bin directory, a lib directory, and a pub directory, and the directory of each verification platform of the universal verification system includes a tb directory, an env directory, a testcases directory, an etc directory, and an inst.fl directory; after the simulation starts, all configuration information under each etc directory is collected, and then the compilation parameters inherited by the corresponding test case are selected according to the verification case to be simulated specified by the user to compile the verification platform; after the compilation is completed, the simulation parameters specified by the user are added for simulation; after the simulation is completed, the log file of the simulation is checked according to the inspection rules specified in the build to determine whether the verification case is passed. The present invention has the advantages of unified verification environment, flexible test case management, real-time verification result display, low learning cost, high resource utilization, cross-module collaboration, unified parameter management, and strong versatility.

Description

Technical Field

[0001] The invention relates to a universal verification system for integrated circuit chip verification, belonging to the technical field of digital chip verification. Background Art

[0002] In the front-end verification process of integrated circuit (IC) chips, most of the existing verification technologies are aimed at the verification of a specific interface or a specific verification scenario. For example, the "data interleaving processing method, AXI VIP device, apparatus and medium" disclosed in publication number CN118503165A is aimed at the verification module using the amba (advanced processor bus architecture) interface; the "a method for quickly accessing registers using bus addresses" disclosed in publication number CN118503161A is aimed at the scenario of scanning registers.

[0003] Since different levels have different modules, each of which is managed by different engineers, there is rarely consideration during the development process of reusing codes developed by others at different levels. Or, due to the lack of unified specifications, the verification platforms developed by each engineer have their own characteristics and are difficult to reuse.

[0004] In the existing technology, each verification platform is mostly managed by a separate makefile (a tool for managing the project build process), or each verification platform has a separate set of script files to manage it, without a unified plan.

[0005] The main defects of the prior art are as follows:

[0006] 1. Insufficient uniformity of verification environment

[0007] Defect description: Different projects and modules use different verification environments and tool configurations, which makes code reuse difficult. The communication and collaboration costs between verification personnel are high, and the same problem recurs in different verification stages.

[0008] Solution limitations: Although some verification platforms attempt to provide a unified verification environment, it is difficult to fully apply the unified environment due to differences in design complexity and project-specific requirements. Existing tools lack flexibility and cannot adapt to diverse verification requirements.

[0009] 2. Poor code change management

[0010] Defect description: The designer uploaded the wrong code, causing the test case that had passed to fail again, increasing the verification workload and unnecessary duplication of work.

[0011] Limitations of the solution: Although the existing code version control system can manage code changes, it lacks automated error detection and intelligent analysis capabilities and cannot detect and prevent the upload of erroneous code in advance.

[0012] 3. Complexity of test case management

[0013] Defect description: The number of test cases is large and complex. The existing system lacks flexibility in the classification, management and execution of test cases, resulting in low efficiency of regression testing.

[0014] Limitations of the solution: Although some test management tools provide basic classification and management functions, in large-scale and complex projects, these tools find it difficult to handle the flexible classification and priority adjustment of all test cases, resulting in low testing efficiency.

[0015] 4. Insufficient transparency and real-time verification results

[0016] Defect description: It is difficult for verification personnel to obtain simulation results and analyze them in a timely manner, and there is a lack of a unified platform to summarize and display verification results.

[0017] Limitations of the solution: Some tools provide result aggregation and display functions, but the data is usually not updated in a timely manner and lacks real-time performance, which cannot meet the needs of rapid iteration and feedback.

[0018] 5. High learning cost

[0019] Defect description: New verification engineers need to spend a lot of time learning and familiarizing themselves with the existing system. When personnel turnover occurs, the cost of work handover is high.

[0020] Limitations of the solution: Although some companies provide training and documentation support, the complex verification environment and tool configuration still require a lot of learning time and practical experience, and it is difficult to get started quickly.

[0021] 6. Efficiency and resource consumption issues

[0022] Defect description: Simulation and debugging require a lot of computing resources and time, especially in the early design stage. When running complex simulation tasks, long waiting times and a lot of error analysis are often encountered.

[0023] Limitations of the solution: Although existing simulation acceleration tools and high-performance computing resources can improve efficiency, the high cost and resource limitations prevent many companies from fully adopting them, resulting in uneven resource allocation.

[0024] 7. Insufficient verification coverage

[0025] Defect description: Ensuring verification coverage is a major challenge, especially in large-scale designs. Existing simulation and verification tools cannot guarantee comprehensive verification coverage, making potential design defects difficult to detect.

[0026] Solution limitations: Although formal verification and other advanced verification techniques can improve coverage, their complexity and resource requirements make these techniques difficult to apply at scale, especially in projects with limited resources.

[0027] Based on this, the present invention is proposed. Summary of the invention

[0028] A new data format with strong extensibility and inheritability has been invented. With the support of this data format, all parameters of simulation compilation and operation are inheritable and extensible.

[0029] This system does not limit the type of simulation tools and job scheduling systems, and supports the submission of ultra-large-scale work tasks when system resources are sufficient.

[0030] In terms of C and SV co-simulation at the SOC level, this system supports any CPU architecture.

[0031] During the entire cycle of digital chip development, based on the independently developed data format, this system has strong scalability and supports not only EDA verification, but also formal verification, Paladin verification process, FPGA verification process and post-silicon verification.

[0032] During EDA verification, compilation parameters are extendable and inheritable. Simulation parameters are extendable and inheritable. Check rules are extendable and inheritable.

[0033] The present invention provides a universal verification system for integrated circuit chip verification, and the specific technical solution is as follows:

[0034] A universal verification system for integrated circuit chip verification, wherein the top-level code directory of the universal verification system includes a bin directory, a lib directory and a pub directory, wherein the bin directory stores common script files; the lib directory stores common C codes, SV codes and VIP codes; and the pub directory stores common macro definitions and regmodel files;

[0035] The directory of each verification platform of the universal verification system includes a tb directory, an env directory, a testcases directory, an etc directory, and an inst.fl directory;

[0036] The tb directory stores the connection relationship files of the top-level DUT of this verification platform;

[0037] The env directory stores the top-level env file, configuration files of each verification component, and private sequences;

[0038] The testcases directory stores UVM_test files;

[0039] The etc directory stores the configuration information of all verification cases at this level;

[0040] The inst.fl directory is the top-level filelist;

[0041] After the simulation starts, the general verification system collects all configuration information under each etc directory, and then selects the compilation parameters inherited by the corresponding test case to be simulated according to the verification case specified by the user to compile the verification platform; after the compilation is completed, the simulation parameters specified by the user are added for simulation; after the simulation is completed, the simulation log file is checked according to the inspection rules specified in the build to determine whether the verification case passes.

[0042] As a further improvement, the simulation operation process of the universal verification system is divided into a single test case mode and a multiple test case mode;

[0043] After the user types in the simulation command, the system determines whether the command is multiple test cases or a single test case;

[0044] If it is a single test case, the system first grabs the compilation parameters and simulation parameters of the test case according to the configuration, then submits the compilation command in interactive mode, waits for the compilation to complete, and then submits the simulation command in interactive mode and waits for the simulation to end; after the simulation ends, the simulation log file is also checked according to the configured inspection rules to determine whether the test case is successful or not;

[0045] If there are multiple test cases, the submission task is submitted in non-interactive mode.

[0046] Further improvements, each verification case can flexibly specify UVM_test and C test files;

[0047] If the simulation parameters in the inherited build item are not appropriate, set the simulation parameters separately and add different tags for each verification case for classification.

[0048] For further improvement, each test inherits from a certain build. Test is a verification case. The build item contains compilation parameters, simulation parameters, and verification case checking rules. Tests inherited from the same build item share the same compilation parameters, simulation parameters, and checking rules.

[0049] As a further improvement, the lib directory stores the verification components after secondary development, and the verification environment of the task module developed on this basis is stored in the first directory. The verification environment is integrated into the second directory of the SOC verification environment and configured in passive mode to serve as a monitoring component to monitor the behavior of the task module in the SOC simulation.

[0050] As a further improvement, when there are two different verification cases using the same uvm_test file and C code file, two completely different verification cases are constructed and the two verification cases can be simulated at the same time.

[0051] Beneficial effects of the present invention:

[0052] 1. Unified verification environment: The universal verification system for integrated circuit chip verification described in the present invention (hereinafter referred to as this system) provides a unified verification environment and tool configuration, so that codes between different projects and modules can be directly reused, which significantly improves the verification efficiency and collaboration effect and solves the problem of insufficient uniformity of the verification environment.

[0053] 2. Flexible test case management: The system supports flexible test case classification and management, and can simulate test cases individually or in batches according to requirements, significantly improving regression testing efficiency. The system allows flexible adjustment of simulation parameters and inspection rules to meet different verification requirements.

[0054] 3. Real-time display of verification results: This system can publish verification results in real time and provide verification personnel with viewing through a web interface, which improves the transparency and real-time nature of the verification results and enables verification personnel to obtain simulation results in a timely manner and conduct analysis.

[0055] 4. Reduce learning costs: By providing detailed verification documents and automated scripts, new verification engineers can quickly get started, reducing learning costs and the difficulty of work handover.

[0056] 5. Efficient resource utilization: This system significantly reduces the computing resources and time required for simulation and debugging by optimizing the simulation process and efficient resource allocation, thereby improving the overall verification efficiency.

[0057] 6. Cross-module collaboration: Verifiers can quickly simulate test cases that they are not responsible for, facilitating collaboration among colleagues and promoting teamwork.

[0058] 7. Unified parameter management: The system uses a self-developed data format to uniformly organize all parameter information of the verification environment, and effectively manages complex verification environments where multiple codes, including C code and SV code, coexist.

[0059] 8. Strong versatility: This system is suitable for IP, Subsys, and SoC level verification work. It has strong versatility and can be widely used in different projects and modules. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 Configuration information of a verification use case of the present invention;

[0061] Figure 2 The logical structure of the test case of the present invention;

[0062] Figure 3 It is a flow chart of simulation script operation of the present invention;

[0063] Figure 4 To reuse the verification case of uvm_test. DETAILED DESCRIPTION

[0064] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0065] Definitions of Abbreviations and Key Terms

[0066] VIP: Abbreviation for Verification IP, a verification component that can be reused for a specific general protocol bus.

[0067] UVM: A Universal Verification Methodology.

[0068] UVC: Development completed verification component.

[0069] filelist: file list.

[0070] Verification components: UVM_env, UVM_agent, UVM_component, etc. with specific functions.

[0071] build: A combination of compilation options, simulation options, and checking rules, as well as the executable files compiled by these options.

[0072] tb: abbreviation of verification platform, verification platform.

[0073] *.sv: Files that conform to SystemVerilog syntax.

[0074] *.c: Files that conform to c syntax.

[0075] *.fl: filelist, this type of file contains multiple file names and is parsed by the simulation tool.

[0076] uvm_test, uvm_agent, uvm_env, uvm_driver: all represent a verification component.

[0077] tag: tag.

[0078] ip: a verification platform for storing simple ip modules

[0079] Subsys: verification platform for storing subsystems;

[0080] top: the verification platform for storing top;

[0081] SOC: system on chip, which is a collection of multiple subsystems that can execute C code. Usually it is a whole chip or a tailored chip.

[0082] check, a constraint used to limit the value of a column or data in a database table.

[0083] log: The record file output during the test case simulation process.

[0084] CMN600 bus, consistent mesh network interconnect bus.

[0085] Active: Active mode, which can actively generate incentives.

[0086] Passive, passive mode, no excitation is generated. Example 1

[0087] 1. A general verification system for integrated circuit chip verification, whose top-level code directory includes the bin directory (bin directory is an abbreviation, standing for "binary", meaning binary file), the lib directory (lib directory is a library file directory, containing all library files useful to the system) and the pub directory (a directory for storing public files). These three directories are general directories, storing scripts and code files common to the entire verification architecture. The bin directory stores public script files; the lib directory stores public C code (code written in C language), SV code (code written in SystemVerilog language) and VIP code; the pub directory stores public macro definitions and regmodel files (used for the generation and management of register models). The ip / subsys / top layers store verification platforms of corresponding levels respectively.

[0088] 2. The directory of each verification platform of the universal verification system includes a tb directory, an env directory, a testcases directory, an etc directory, and an inst.fl directory.

[0089] The tb directory stores the connection relationship files of the top-level DUT (device under test) of this verification platform; the env directory stores the top-level env files (used to configure environment variables), configuration files of each verification component, and private sequence (database system); the (test case) directory stores the uvm_test file; the etc directory stores the configuration information of all verification cases at this level; the inst.fl directory is the top-level filelist. Each directory ending with _tb is similar to a verification platform directory.

[0090] 3. The configuration information stored in the etc directory is as follows Figure 1 As shown in the figure, each verification case can flexibly specify the uvm_test and C test files. If the simulation parameters in the inherited build item are not suitable, you can set the simulation parameters separately and add different tags to each verification case for classification. Figure 1 The data format example is self-developed. xxx_module_test is the name of the test case, and the compilation parameter of the test case is build_info, which is specified by the extend keyword (used to create the inheritance relationship of the class).

[0091] The uvm_test file used is test_file. The tag keyword is a label for the test case. Test cases of the same type will be labeled with the same label. sw_test specifies the c file (data stored on external media) used by the test case and the compilation parameters of the c file. sim_option specifies the simulation parameters that need to be provided when simulating the test case.

[0092] 4. If Figure 2 As shown in the figure, each test inherits from a certain build, where test is a verification case, and build item contains compilation parameters, simulation parameters, and verification case check rules. Tests inherited from the same build item share the same compilation parameters, simulation parameters, and check rules. The test item can also modify the simulation parameters and check rules, and there is no limit on the number of inheritances at each inheritance level.

[0093] exist Figure 2 In the example, base_build refers to the most basic build.

[0094] 5. After the simulation starts, Figure 3As shown, first, all configuration information under each etc directory is collected, and then according to the verification case to be simulated specified by the user, the compilation parameters inherited by the corresponding test case are selected to compile the verification platform; after the compilation is completed, the simulation parameters specified by the user are added for simulation; after the simulation is completed, the simulation log file is checked according to the inspection rules specified in the build to determine whether the verification case passes.

[0095] exist Figure 3 In , the running process can be divided into two parts, namely single test case mode and multiple test case mode.

[0096] After the user enters the simulation command, the system determines whether the command is a simulation flow for multiple test cases or a single test case. Figure 3 In the right branch, the system first grabs the compilation parameters and simulation parameters of the test case according to the configuration, then submits the compilation command in interactive mode, waits for the compilation to complete, and then submits the simulation command in interactive mode and waits for the simulation to end. After the simulation is completed, the simulation log file is also checked according to the configured inspection rules to determine whether the test case is successful or not.

[0097] The multiple test case mode is similar to the single test case mode, but the submission task is submitted in non-interactive mode. In addition, the simulation process will be refreshed to the company's internal website in real time, and the simulation path of the test case that failed the simulation will be sent to the corresponding maintenance personnel.

[0098] 6. During the compilation and simulation stages, the system will count the completion status of each compilation and simulation task in real time and publish it to the company's internal website.

[0099] 7. If the test case simulation fails, the system can automatically initiate a simulation task with a simulation waveform and notify the maintenance personnel of the test case by email. Example 2

[0100] In a complete chip project, there are generally various single-function IP modules, such as UART (Universal Asynchronous Receiver / Transmitter) module, SPI (Serial Peripheral Interface, a synchronous serial communication interface) module, etc. Multiple IP modules form subsystem modules with specific functions, and all subsystem modules form top modules, which is a complete chip design.

[0101] The modules generally use the same communication protocols to communicate with each other. The lib directory contains verification components for various VIPs after secondary development, as well as self-developed public interface verification components. The verification environment for the bus IP developed on this basis is stored in the ip directory. The IP verification environment is further integrated into the SOC verification environment and configured in passive mode as a monitoring component to monitor the behavior of all interfaces on the bus in SOC simulation. The same reuse logic applies to all custom codes stored in the lib directory, as well as all ip / subsys / top layer verification environments under the same project. Example 3

[0102] like Figure 4 As shown in the figure, two different verification cases use the same uvm_test file and C code file, but because they inherit different builds, they have different compilation options, simulation options, and simulation log check rules, thus constructing two completely different verification cases. Since the two verification cases have the same tag, you can use the command:

[0103] sim-tag tagA / tagB

[0104] Simulate two verification cases simultaneously. The same reuse logic also applies to sim_option, sw_test, and tag tags. Among them, sim-tag is pseudo code.

[0105] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A universal verification system for integrated circuit chip verification, characterized in that: The top-level code directory of the universal verification system includes a bin directory, a lib directory, and a pub directory, and the bin directory stores public script files; The lib directory stores public C code, SV code and VIP code; The pub directory stores public macro definitions and regmodel files; The directory of each verification platform of the universal verification system includes a tb directory, an env directory, a testcases directory, an etc directory, and an inst.fl directory; The tb directory stores the connection relationship files of the top-level DUT of this verification platform; The env directory stores the top-level env file, configuration files of each verification component, and private sequences; The testcases directory stores UVM_test files; The etc directory stores the configuration information of all verification cases at this level; The inst.fl directory is the top-level filelist; After the simulation starts, the general verification system collects all configuration information under each etc directory, and then selects the compilation parameters inherited by the corresponding test case to be simulated according to the verification case specified by the user to compile the verification platform; After the compilation is completed, add the simulation parameters specified by the user for simulation; After the simulation is completed, the simulation log file is checked according to the check rules specified in the build to determine whether the verification case passes; The simulation operation process of the universal verification system is divided into a single test case mode and a multiple test case mode; After the user types in the simulation command, the system determines whether the command is multiple test cases or a single test case; If it is a single test case, the system first grabs the compilation parameters and simulation parameters of the test case according to the configuration, then submits the compilation command in interactive mode, waits for the compilation to complete, and then submits the simulation command in interactive mode and waits for the simulation to end; After the simulation is finished, the simulation log file is also checked according to the configured check rules to determine whether the test case is successful or not; If there are multiple test cases, the submission task is submitted in non-interactive mode; Each test inherits from a certain build. Test is a verification case. The build item contains compilation parameters, simulation parameters, and verification case inspection rules. Tests inherited from the same build item share the same compilation parameters, simulation parameters, and inspection rules.

2. A universal verification system for integrated circuit chip verification according to claim 1, characterized in that: Each verification case can flexibly specify UVM_test and C test files; If the simulation parameters in the inherited build item are not appropriate, set the simulation parameters separately and add different tags for each verification case for classification.

3. A universal verification system for integrated circuit chip verification according to claim 1, characterized in that: The lib directory stores the verification components after secondary development, and the verification environment of the task module developed on this basis is stored in the first directory. The verification environment is integrated into the second directory of the SOC verification environment and configured in passive mode as a monitoring component to monitor the behavior of the task module in the SOC simulation.

4. A universal verification system for integrated circuit chip verification according to claim 1, characterized in that: When there are two different verification cases using the same uvm_test file and C code file, two completely different verification cases are constructed and the two verification cases can be simulated at the same time.

Images