Method for single-thread operation automation in digital IC verification environment

Abstract

The invention discloses a single-thread operation automation method in a digital IC verification environment. The method comprises the following steps: S1, establishing a directory structure; s2, setting an automatic script, and establishing a simulation environment to start simulation; s3, running the automatic script to read the three files, and starting to verify and compile; and S4, reading the compiled file and the simulation file, and carrying out anomaly detection. According to the method, when a plurality of verification platforms run on one server at the same time, the verification platforms are submitted to the server cluster by adopting the bsub command, so that resources of the server cluster are fully utilized, and the probability of jamming is reduced; meanwhile, the verification process is refined by utilizing various parameters of UVM printing priority, coverage rate and test cases, so that the accuracy and comprehensiveness of verification are improved; in addition, the operation process of verification personnel is reduced, and the automation degree of verification is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of digital IC verification, and in particular to a method for automating single-thread operation in a digital IC verification environment. Background Art

[0002] With the development of integrated circuits, the requirements for digital IC verification are becoming increasingly higher, and verification accounts for an increasing proportion of the chip development cycle. Therefore, how to improve the efficiency of verification work is particularly important.

[0003] In the existing integrated circuit verification process, verification personnel usually build the verification platform based on the UVM verification methodology first, and then use VCS software for simulation. VCS is the supporting simulation software of Synopsys. To run VCS, you need to use the make command and Makefile file in the Linux system. The make command will manage the project according to the content of the Makefile, and the Makefile file specifies the dependencies between compile and simulation, target files, and execution commands.

[0004] However, as the chip scale becomes larger and larger, the amount of design code increases, and the amount of design code that needs to be loaded increases, the number of functional modules that need to be verified increases, especially the single-threaded verification where multiple verification platforms run on a server at the same time also faces greater pressure. At the same time, as the number of functional modules increases and the circuit scale of the functional modules themselves also increases, it is often necessary to establish a test platform for independent projects during verification, and the verification personnel also need to write their own test cases, which is an extremely cumbersome process.

[0005] However, these measures currently adopted contain at least the following three problems: 1) A single verification platform has high operating pressure, is difficult to process large amounts of data, and is prone to jamming; 2) When performing single-thread digital IC verification, in order to simplify management, only one server in the server cluster is often used for operation, which has low resource utilization of the server cluster and causes resource waste; 3) The verification process requires multiple manual operations by the verification personnel, which is extremely cumbersome and has a low degree of automation. Summary of the invention

[0006] In response to the above three problems, the purpose of the present invention is to propose a method for automating the single-threaded operation of a digital IC verification environment. When multiple verification platforms are running on a server at the same time, the bsub command is used to submit the verification platform to the server cluster, so as to make full use of the resources of the server cluster and reduce the probability of getting stuck. In addition, the operation process of the verification personnel is reduced, and the degree of automation of the verification is improved.

[0007] This is achieved through the following technical solutions: A method for automating single-thread operation of a digital IC verification environment comprises the following steps: S1. Establish a directory structure: establish a directory structure of a verification platform according to verification requirements, the directory structure includes a project directory, a design directory and a simulation directory, the project directory is used as the root directory of the directory structure, the design directory includes the design code, the simulation directory includes a multi-level verification platform, and the directories corresponding to each level of the verification platform include a bench directory, a uvm_tb directory, a uvm_tc directory and an rsim directory; wherein the bench directory includes the top-level code for establishing the verification platform and the top-level code corresponding to the instantiation verification requirements, the uvm_tb directory includes various components corresponding to the verification requirements created according to the UVM verification methodology, the uvm_tc directory includes multiple test cases for the verification platform, and the rsim directory includes a Makefile file and an env_cfg directory; S2. Set up the automatic script, establish the simulation environment and start the simulation: the verification personnel set up the automatic script single.pl in the rsim directory of step S1, create three files flist_rtl.cfg, single.cfg and case.lst in the env_cfg directory and establish the simulation environment, and start the simulation; wherein, flist_rtl.cfg is used to specify the relative path of the design code corresponding file and the relative path of the environment code corresponding file of the verification platform, single.cfg is used to specify the file name and UVM printing priority level of each code corresponding file, and case.lst is used to specify the parameters of each test case; S3, run the automatic script to read three files, start verification and compilation: run the automatic script single.pl in step S2 to read flist_rtl.cfg, single.cfg and case.lst, generate specific parameters according to single.cfg and case.lst and use the specific parameters to configure the Makefile file; generate the final file flist_rtl.f according to flist_rtl.cfg, flist_rtl.f includes design code and verification code; the automatic script single.pl uses the bsub command to execute the compilation command, and the compilation command manages the simulation environment according to the Makefile file to obtain the compilation file cpmpile.log and the simulation file sim.log obtained by simulation; S4. Read the compiled file and simulation file to perform anomaly detection: the automatic script single.pl first reads the compiled file cpmpile.log in step S3, and determines whether there is an exception in the compilation stage based on the compiled file compile.log. If there is no exception, the compilation passes; if there is an exception, the automatic script automatically pops up a compilation problem dialog window, notifies the verification personnel and displays the content in the compiled file cpmpile.log corresponding to the exception; the automatic script then reads the simulation file sim.log in step S3, and determines whether there is an exception in the simulation stage based on the simulation file sim.log. If there is no exception, the simulation passes and the verification is completed; if there is an exception, the automatic script automatically pops up a simulation problem dialog window, notifies the verification personnel and displays the content in the simulation file sim.log corresponding to the exception.

[0008] The verification process is automated through automatic scripts, which effectively reduces the operations of verification personnel and improves the degree of automation of verification. The bsub command is also used to submit the verification platform to the server cluster, making full use of the resources of the server cluster, reducing the probability of jamming, and allowing the verification process to proceed smoothly.

[0009] Preferably, in step S1, the multi-level verification platform includes multiple module-level verification platforms, multiple subsystem-level verification platforms and system-level verification platforms; wherein, multiple module-level verification platforms are subordinate platforms of multiple subsystem-level verification platforms, and multiple subsystem-level verification platforms are subordinate platforms of system-level verification platforms. The main purpose of setting up a multi-level verification platform is to ensure the correctness and integrity of digital ICs at different levels. This multi-level verification strategy helps to discover and correct errors in the design as early as possible, ensure the correctness of functions at each level, and ultimately ensure the quality and reliability of the entire system.

[0010] Preferably, in step S1, when creating each component corresponding to the verification requirement according to the UVM verification methodology, each component at least includes env corresponding to the env_cfg directory, agent corresponding to env, monitor corresponding to env, driver corresponding to env, reference model corresponding to each test case, agent corresponding to the reference model, monitor corresponding to the referencemodel, and driver corresponding to the reference model. Multiple components facilitate the construction of a complete verification environment, thereby ensuring the comprehensiveness and effectiveness of the verification; at the same time, the large number of components and the subdivision are also convenient for expansion and maintenance.

[0011] Preferably, in step S2, the UVM printing priority level includes: UVM_NONE that does not output any information, UVM_LOW that outputs less information, UVM_MEDIUM that outputs moderate information, UVM_HIGH that outputs detailed information, and UVM_FULL that outputs complete information. The UVM printing priority level can effectively control the detail of the output information, and multiple levels are set to facilitate meeting actual verification requirements and improving the readability of verification.

[0012] Preferably, in step S2, single.cfg is also used to specify a coverage collection switch, which is used to control whether to collect the coverage of the design code during verification. The coverage information reflects the coverage of the design code corresponding requirements by the test case during simulation, which facilitates the completeness of the test.

[0013] Preferably, in step S2, the parameters of each test case include at least: name, seed number and number of runs. Name, seed number and number of runs are important for the execution, scheduling and analysis of the test case, and facilitate effective control and management of the test case.

[0014] Preferably, in step S3, when the automatic script single.pl uses the bsub command to execute the compile command, the compile command is used to manage the simulation environment in the LSF system, and the server cluster corresponding to the simulation environment is simulated and delivered. By performing simulation delivery in the LSF system, the simulation can be divided into multiple parts and delivered to the corresponding servers, so as to make full use of the resources of the server cluster and reduce the problem of stuck bugs.

[0015] Compared with the prior art, the present invention has the following beneficial effects: The technical solution of the present invention uses a bsub command to deliver the verification platform to a server cluster when multiple verification platforms are simultaneously run on a server, so as to make full use of the resources of the server cluster and reduce the probability of jamming; at the same time, the UVM printing priority, coverage and various parameters of the test case are used to refine the verification process and improve the accuracy and comprehensiveness of the verification; in addition, the operation process of the verification personnel is reduced and the automation degree of the verification is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A flowchart of a method for automating single-threaded operation of a digital IC verification environment; Figure 2 A flowchart of a verification method using a single-threaded automated operation in a digital IC verification environment. DETAILED DESCRIPTION

[0017] The technical solutions in the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0018] like Figure 1 As shown, it is a flowchart of a method for automating the single-threaded operation of a digital IC verification environment. The verification platform can read the commands and configuration parameters input by the verification personnel through a script, establish a simulation environment used for verification, and use the bsub command to assign the running jobs of the verification platform to the server cluster to complete the verification.

[0019] A method for automating single-thread operation of a digital IC verification environment, specifically comprising the following steps: S1. Establish a directory structure: Establish a directory structure of the verification platform according to the verification requirements. The directory structure includes a project directory, a design directory, and a simulation directory. The project directory is used as the root directory of the directory structure. The design directory includes the design code. The simulation directory includes a multi-level verification platform. The directories corresponding to each level of the verification platform include a bench directory, a uvm_tb directory, a uvm_tc directory, and an rsim directory. Among them, the bench directory includes the top-level code for establishing the verification platform and the top-level code corresponding to the instantiation verification requirements. The uvm_tb directory includes various components corresponding to the verification requirements created according to the UVM verification methodology. The uvm_tc directory includes multiple test cases for the verification platform. The rsim directory includes a Makefile file and an env_cfg directory.

[0020] In this embodiment, in step S1, the multi-level verification platform includes multiple module-level verification platforms, multiple subsystem-level verification platforms and system-level verification platforms; wherein, multiple module-level verification platforms are subordinate platforms of multiple subsystem-level verification platforms, and multiple subsystem-level verification platforms are subordinate platforms of system-level verification platforms; each module-level verification platform to be tested together constitutes a module-level verification platform directory, each subsystem-level verification platform to be tested together constitutes a subsystem-level verification platform directory, and each system-level verification platform to be tested together constitutes a system-level verification platform directory. The main purpose of setting up a multi-level verification platform is to ensure the correctness and integrity of digital ICs at different levels. This multi-level verification strategy helps to discover and correct errors in the design as early as possible, ensure the correctness of functions at each level, and ultimately ensure the quality and reliability of the entire system. Taking the verification of CPU as an example, the decoding module, cache, biu module, execution unit and MMU and other units can be verified at the module level, and multiple module-level verification platforms can be built; then, each of the module-level verification platforms with many interactions can be combined into a subsystem level for verification. For example, the cache can be combined with the biu module responsible for the connection to form a subsystem for verification; the entire CPU is verified as a system, that is, as a system-level verification platform.

[0021] In this embodiment, in step S1, when creating each component corresponding to the verification requirement according to the UVM verification methodology, each component at least includes env corresponding to the env_cfg directory, agent corresponding to env, monitor corresponding to env, driver corresponding to env, reference model corresponding to each test case, agent corresponding to the reference model, monitor corresponding to the referencemodel, and driver corresponding to the reference model. Multiple components facilitate the construction of a complete verification environment, thereby ensuring the comprehensiveness and effectiveness of the verification; at the same time, the large number of components and the subdivision are also convenient for expansion and maintenance.

[0022] It should be noted that the UVM verification methodology uses various components under the UVM framework to build a complete verification platform; env is the verification environment; agent is an independent verification component, which is responsible for generating the stimulus signal required for verification, collecting responses and performing verification; Monitor is a component used to collect output data of the design; driver is used to inject stimulus signals or user instructions into the design code; reference model is an idealized model, and the test case will be compared with the idealized model during testing to obtain the verification result.

[0023] S2, set up the automatic script, establish the simulation environment and start the simulation: the verification personnel set up the automatic script single.pl in the rsim directory of step S1, create three files flist_rtl.cfg, single.cfg and case.lst in the env_cfg directory and establish the simulation environment, and start the simulation; among them, flist_rtl.cfg is used to specify the relative path of the design code corresponding file and the relative path of the verification platform environment code corresponding file, which can be combined into a code path generation module in the verification environment. The environment code of the verification platform at each level is composed of their own platform directories, namely the bench directory, uvm_tb directory, uvm_tc directory and rsim directory corresponding to the platform. Under the four directories of bench directory, uvm_tb directory, uvm_tc directory and rsim directory, the verification code of the verification platform at the corresponding level is integrated, that is, the environment code described here. single.cfg is used to specify the file name and UVM print priority level of each code corresponding file, case.lst is used to specify the parameters of each test case, and single.cfg and case.lst can be combined into a configuration parameter reading module.

[0024] In this embodiment, in step S2, the UVM printing priority level includes: UVM_NONE that does not output any information, UVM_LOW that outputs less information, UVM_MEDIUM that outputs moderate information, UVM_HIGH that outputs detailed information, and UVM_FULL that outputs complete information. The UVM printing priority level can effectively control the detail of the output information, and multiple levels are set to facilitate meeting actual verification requirements and improving the readability of verification.

[0025] In this embodiment, in step S2, single.cfg is also used to specify a coverage collection switch, which is used to control whether to collect the coverage of the design code during verification. The coverage information reflects the coverage of the corresponding requirements of the design code by the test case during simulation, which is convenient for knowing the integrity of the test. The coverage of the design code is specifically: Line coverage, Toggle coverage, FSM coverage, Condition coverage and Branch coverage. Line coverage is used to verify whether each line of code in the design code is executed once, Toggle coverage is used to verify whether each code in the design code goes through a process from 0 to 1 and then from 1 to 0 to determine the change process, FSM coverage is used to verify whether all states and transitions of the FSM are executed once, Condition coverage is used to verify whether each conditional statement in the design code is satisfied once, and Branch coverage is used to verify whether each branch statement in the design code is satisfied once. When collecting the above five coverage rates after verification, it is necessary to ensure that 100% of the collection is achieved in order to know the validity of the design code to the maximum extent. If some coverage rates cannot be collected, the verifier must analyze the code that cannot be collected, determine the reasons and write the results of the analysis into the verification report first. After that, the exclude command of the VCS software can be selected to cover the corresponding code for subsequent processing by the verifier. The work of collecting coverage is performed by the VCS software. This function can choose to configure whether to collect it at present. Since it is time-consuming to run the software and run the simulation after turning on the collection of coverage, the coverage is generally collected only after there are no bugs and the design code is stable. Therefore, the switch for collecting coverage is set here. If you do not need to collect coverage, you can also choose to turn off the switch.

[0026] In this embodiment, in step S2, the parameters of each test case include at least: name, seed number and number of runs. In the verification environment under the UVM framework, the parameter configuration of each test case is very important, especially the parameters of name, seed number and number of runs. These parameters play an important role in the execution, debugging and analysis of test cases. The name corresponds to the three aspects of identification, recording and log, that is, it is used to uniquely identify each test case, conveniently record and track the execution of the test case, and can quickly locate the specific test case by name in the log file. The seed number corresponds to the random number generation and reproduction problem. The random number generation is used to initialize the seed value of the random number generator to ensure that the random data generated by each test case is repeatable; and the reproduction problem is that when the test fails, the same problem can be reproduced by the same seed number, which is convenient for debugging. The number of runs is the number of times the specified test case needs to be executed. Through multiple executions, statistical analysis can be performed to evaluate the effect of the test case, which can also affect the coverage situation.

[0027] S3, run the automatic script to read three files, start verification and compilation: run the automatic script single.pl in step S2 to read flist_rtl.cfg, single.cfg and case.lst, generate specific parameters based on single.cfg and case.lst, and use the specific parameters to configure the Makefile file in the Makefile parameter generation module; generate the final file flist_rtl.f based on flist_rtl.cfg, and flist_rtl.f includes design code and verification code. When the automatic script single.pl uses the bsub command to execute the compilation command, the simulation environment is managed in the LSF system according to the Makefile file with the compilation command, and the compilation file cpmpile.log and the simulation file sim.log obtained by simulation are obtained, and then the server cluster corresponding to the simulation environment is simulated and delivered. When performing simulation delivery in the LSF system, the simulation can be divided into multiple parts and delivered to the corresponding server to make full use of the resources of the server cluster, and the problem of stuck bugs can also be reduced.

[0028] It should be noted that the LSF system is a distributed cluster management system software, which can also be directly called LSF. It uses the bsub command to run the VCS software, which can be regarded as submitting a job to LSF. LSF is responsible for the management of computing resources and the scheduling of batch processing jobs. It provides users with a unified cluster resource access interface, allowing users to transparently access the entire cluster resources. It is usually an indispensable basic software in a high-performance computing environment. LSF is a powerful workload management platform that provides intelligent scheduling functions based on various strategies and uses distributed infrastructure resources to improve the overall system performance. Users can use LSF to achieve load balancing between clusters, expand cluster architecture and resources, and maximize the efficiency of cluster utilization. The so-called cluster refers to a large computer service system composed of several independent computers using a high-speed communication network. Each cluster node, that is, each computer in the cluster, is an independent server running its own service. These servers can communicate with each other, collaboratively provide users with applications, system resources and data, and manage them in a single system mode. When a user requests a cluster system, the cluster gives the user the feeling of a single independent server, but in fact the user requests a group of cluster servers. Simply put, a cluster is a group of servers working together to do the same thing. These machines may need to be managed in a unified and coordinated manner. They can be distributed in one computer room or in multiple computer rooms in various regions across the country and the world. Server clusters will only show their advantages when the number of concurrent or total requests exceeds the capacity of a single server. This centralized monitoring and calling method can fully share the computer's CPU, memory, disk, license and other resources, reducing the occurrence of bugs such as freezing. For unified monitoring and scheduling of cluster resources, the command submitted to the LSF job is the bsub command.

[0029] In other words, when a user runs a large number of simulations on a server, it is easy to have problems such as insufficient internal space, which will cause other users to be unable to use the server. After using the bsub command to execute the compilation and simulation commands, the LSF system can deliver the current user's simulation to the corresponding multiple servers for running. This can avoid users running simulations on one server, and also achieve load balancing between clusters, maximizing the efficiency of cluster use.

[0030] S4. Read the compiled file and simulation file to perform anomaly detection: the automatic script single.pl first reads the compiled file cpmpile.log in step S3, and determines whether there is an exception in the compilation stage based on the compiled file compile.log. If there is no exception, the compilation passes; if there is an exception, the automatic script automatically pops up a compilation problem dialog window, notifies the verification personnel and displays the content in the compiled file cpmpile.log corresponding to the exception; the automatic script then reads the simulation file sim.log in step S3, and determines whether there is an exception in the simulation stage based on the simulation file sim.log. If there is no exception, the simulation passes and the verification is completed; if there is an exception, the automatic script automatically pops up a simulation problem dialog window, notifies the verification personnel and displays the content in the simulation file sim.log corresponding to the exception.

[0031] like Figure 2 As shown, it is a flow chart of using the single-threaded automated method of digital IC verification environment to perform verification, combined with Figure 1 and Figure 2 As shown, a specific example of applying the above verification method is given: Create a corresponding verification platform directory according to the level of the function to be tested. In the bench directory, create the top-level code of the verification platform and instantiate the top-level of the design code to be tested. In the uvm_tb directory, create env, reference model, agent, monitor, driver and other parameters of each component according to the UVM verification methodology. Create test cases for the verification platform to be tested in the uvm_tc directory. In the rsim directory, create a Makefile file and an env_cfg directory, and continue to create three files in the env_cfg directory, namely: (1) flist_rtl.cfg file, to specify the relative path of the design code file and the verification environment code file; (2) single.cfg file, to specify the file name that records the relative path of all code files, the top-level file name of the design code, the collection coverage switch and the UVM printing priority level; (3) case.lst file, to specify the name, seed number and number of runs of each test case.

[0032] Then, run the automatic script single.pl and select single case=1, that is, run the first test case, and the serial number of the test case corresponds to the serial number in case.lst. After running the single.pl script, the script automatically reads the file names of the relative paths of all code files in the single.cfg file, the top-level file names of the design code, the collection coverage switch and the UVM printing priority level, as well as the name, seed number and running times of each test case in the case.lst file.

[0033] After reading the single.cfg and case.lst files, continue to read the relative paths of the design code files and verification environment code files specified in the flist_rtl.cfg file, and generate the final flist_rtl.f file. Configure the Makefile file based on the parameters extracted in step 7. Use the bsub command to run the make command. The make command manages the server cluster of the simulation environment according to the content of the Makefile and dispatches enough servers for compilation.

[0034] Then, after the compilation is completed, the script actively reads the compilation file compile.log, and no abnormality is found, so the compilation passes. After the simulation is completed, the script actively reads the simulation file sim.log, and an abnormality is found at this time, and a window is automatically popped up to prompt the verification personnel that there is an abnormality, and the verification of this test case is completed.

[0035] Repeat the above verification process for the remaining test cases until all test cases are verified, store the results of each verification in the form of a log, and then stop all operations.

[0036] In summary, when multiple verification platforms are run on a server at the same time, the present invention adopts the bsub command to submit the verification platform to the server cluster, fully utilizes the resources of the server cluster, and reduces the probability of jamming; at the same time, the UVM printing priority, coverage and various parameters of the test case are used to refine the verification process, improve the accuracy and comprehensiveness of the verification, and facilitate the staff to know the verification results; in addition, the operation process of the verification personnel is reduced, the degree of automation of the verification is improved, and it has significant progress.

[0037] The above embodiments are only for illustrating the technical idea of ​​the present invention, and cannot be used to limit the protection scope of the present invention. Any changes made on the basis of the technical solution in accordance with the technical idea proposed by the present invention shall fall within the protection scope of the present invention.

Claims

1. A method for automating single-thread operation in a digital IC verification environment, characterized in that: The steps include: S1. Establish directory structure: Establish the directory structure of the verification platform according to the verification requirements. The directory structure includes the project directory, the design directory and the simulation directory. The project directory is used as the root directory of the directory structure. The design directory includes the design code. The simulation directory includes multi-level verification platforms. The directories corresponding to each level of verification platform include the bench directory, the uvm_tb directory, the uvm_tc directory and the rsim directory. Among them, the bench directory includes the top-level code for establishing the verification platform and the top-level code corresponding to the instantiation verification requirements, the uvm_tb directory includes the components corresponding to the verification requirements created according to the UVM verification methodology, the uvm_tc directory includes multiple test cases for the verification platform, and the rsim directory includes the Makefile file and the env_cfg directory; S2. Set up the automatic script, establish the simulation environment and start the simulation: The verification personnel sets up the automatic script single.pl in the rsim directory of step S1, creates three files flist_rtl.cfg, single.cfg and case.lst in the env_cfg directory, establishes the simulation environment, and starts the simulation; Among them, flist_rtl.cfg is used to specify the relative path of the design code corresponding file and the relative path of the verification platform environment code corresponding file, single.cfg is used to specify the file name and UVM printing priority level of each code corresponding file, and case.lst is used to specify the parameters of each test case; S3. Run the automatic script to read three files and start verification and compilation: Run the automatic script single.pl in step S2 to start verification. The automatic script single.pl reads flist_rtl.cfg, single.cfg and case.lst, generates specific parameters according to single.cfg and case.lst, and configures the Makefile file using the specific parameters; generates the final file flist_rtl.f according to flist_rtl.cfg, and flist_rtl.f includes the design code and the verification code; The automatic script single.pl uses the bsub command to execute the compile command. The compile command manages the simulation environment according to the Makefile file to obtain the compile file cpmpile.log and the simulation file sim.log obtained by simulation. S4. Read the compiled file and simulation file and perform anomaly detection: The automatic script single.pl first reads the compilation file cpmpile.log in step S3, and determines whether there is an exception in the compilation stage according to the compilation file compile.log. If there is no exception, the compilation passes; if there is an exception, the automatic script automatically pops up a compilation problem dialog window to notify the verification personnel and display the content of the compilation file cpmpile.log corresponding to the exception; The automatic script then reads the simulation file sim.log in step S3, and determines whether there is an abnormality in the simulation stage based on the simulation file sim.log. If there is no abnormality, the simulation passes and the verification is completed; if there is an abnormality, the automatic script automatically pops up a simulation problem dialog window, notifies the verification personnel and displays the content of the simulation file sim.log corresponding to the abnormality.

2. The method for automating single-thread operation of a digital IC verification environment according to claim 1, characterized in that: In step S1, the multi-level verification platform includes multiple module-level verification platforms, multiple subsystem-level verification platforms and a system-level verification platform; wherein the multiple module-level verification platforms are subordinate platforms of the multiple subsystem-level verification platforms, and the multiple subsystem-level verification platforms are subordinate platforms of the system-level verification platform.

3. The method for automating single-thread operation of a digital IC verification environment according to claim 1, characterized in that: In step S1, when creating various components corresponding to the verification requirements according to the UVM verification methodology, each component includes at least env corresponding to the env_cfg directory, agent corresponding to env, monitor corresponding to env, driver corresponding to env, reference model corresponding to each test case, agent corresponding to the reference model, monitor corresponding to the reference model, and driver corresponding to the reference model.

4. The method for automating single-thread operation of a digital IC verification environment according to claim 1, characterized in that: In step S2, the UVM printing priority levels include: UVM_NONE which does not output any information, UVM_LOW which outputs less information, UVM_MEDIUM which outputs moderate information, UVM_HIGH which outputs detailed information, and UVM_FULL which outputs complete information.

5. The method for automating single-thread operation of a digital IC verification environment according to claim 1, characterized in that: In step S2, single.cfg is also used to specify a coverage collection switch, which is used to control whether to collect the coverage of the design code during verification.

6. The method for automating single-thread operation of a digital IC verification environment according to claim 1, characterized in that: In step S2, the parameters of each test case include at least: name, seed number and number of runs.

7. The method for automating single-thread operation of a digital IC verification environment according to claim 1, characterized in that: In step S3, when the automatic script single.pl uses the bsub command to execute the compile command, the compile command is used to manage the simulation environment in the LSF system, and the server cluster corresponding to the simulation environment is simulated and delivered.

Images