System-on-chip composite verification platform, system and construction method

Abstract

The invention provides a system-on-chip composite verification platform and system and a construction method. The method comprises the following steps: configuring a uniform directory structure; classifying all element files required by the operation of the composite verification platform, and respectively storing different types of element files into different standard directories; a plurality of subdirectories respectively corresponding to each verification platform in the composite verification platform are configured in each standard directory; a common control layer located on the bottom layer and a personalized control layer located on the top layer are configured on the control surface; the personalized control layer can overlay or constrain default settings in the common control layer such that the personalized control layer provides an operational interface to switch the verification platform. According to the composite verification platform constructed based on the method, the maintenance work of the platform is simplified, different verification platforms can share a resource scheduling mechanism, resource conflicts and waste are avoided, the resource utilization rate is improved, and the technical threshold for verification engineers can be reduced.

Description

Technical Field

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

[0002] As Moore's Law continues to advance, chip manufacturing processes are becoming more and more advanced, and the scale of chips has increased from the initial thousands of transistors to tens of billions today. For this reason, SoC (system on chip) can integrate more functions, including processor cores (CPU, GPU), memory (RAM, ROM), high-speed interfaces (PCIe), high-speed storage controllers (DDR), complex bus networks, security processing, etc. However, the complexity and diversity of these modules have put higher requirements on the construction and maintenance efficiency of the verification environment and platform.

[0003] For small-scale SoC chips, traditional chip companies often have two ways of dealing with them. One is to configure only one ST platform (system test platform). Taking MCU chips as an example, there is no need to develop multiple UT verification platforms (unit test platforms) because the main control can be completed by the CPU core, the bus and interface are relatively simple and standardized, the integration is not too complicated, and it does not involve additional self-developed function development, so the risk of one platform verification is not great; the other is to configure multiple platform environments. Taking MCU as an example, if it involves more critical and more self-developed function development, it not only requires one ST environment to achieve functional integration coverage, but also requires the development of multiple UT platform environments to specifically verify the self-developed modules to ensure better completeness. Both of these methods are simple and direct, without considering the importance of the platform to verification efficiency. It is OK to use it. This is because the design scale is usually small, the requirements for verification personnel are not high, and the EDA verification software speed is sufficient to quickly converge the entire design within the delivery cycle.

[0004] However, as the complexity and scale of chip design continue to increase, SoC design generally integrates multiple heterogeneous components, which usually have different design specifications and verification requirements, which increases the complexity of overall verification. For current large chips with tens of billions of gates, the EDA simulation speed has reached a bottleneck, and the iterative simulation cycle is calculated in hours or days. The demand for resources such as servers and licenses required for simulation has increased exponentially. If we still follow the small chip verification thinking of the traditional single and direct verification platform structure to handle such a large-scale design, and split it into multiple or more than a dozen large subsystem platform verifications according to heterogeneous or module components, not only will the platform development be difficult to maintain uniformly due to development diversity and simulation resource limitations, but it will also greatly increase the verification labor cost. At the same time, a lot of time needs to be invested in solving and optimizing platform problems during the entire verification cycle, which will inevitably lead to a waste of verification manpower and machine resources, thereby reducing the verification delivery efficiency of large-scale SoCs. Summary of the invention

[0005] The purpose of the present invention is to provide a system-on-chip composite verification platform, system and construction method that can perform all-round verification on a system-on-chip with multiple heterogeneous subsystems, and combine multiple verification platforms together through a unified and standardized environment to improve the efficiency of large-scale system-on-chip verification.

[0006] In order to achieve the above object, the present invention provides a method for constructing a composite verification platform of a system on chip, wherein the composite verification platform includes at least two verification platforms respectively used to verify different objects in the system on chip, and the construction method includes:

[0007] Configure a unified directory structure, the directory structure is used to store all the element files required for the operation of the composite verification platform;

[0008] Classifying all element files required for the operation of the composite verification platform according to their functions and uses, and storing element files of different categories in different standard directories;

[0009] In each of the standard directories, there are configured a number of sub-directories corresponding to each of the verification platforms in the composite verification platform, the sub-directories are used to store personalized element files corresponding to the corresponding verification platforms, and the sub-directories may also store common element files related to all the verification platforms in the composite verification platform;

[0010] Differentiately name the files in each subdirectory according to a unified rule;

[0011] On the control plane, configure the common control layer at the bottom and the personalized control layer at the top;

[0012] In the common control layer, top-level option constraints and process control element files required by all the verification platforms are stored;

[0013] In the personalized control layer, the configuration element files customized by the user according to the requirements of any of the verification platforms are stored;

[0014] The personalized control layer can override or constrain the default settings in the public control layer so that the personalized control layer provides an operation interface for switching the verification platform.

[0015] Preferably, the standard directory includes eight sub-directories, namely, a configuration directory, an environment directory, a list directory, a register directory, a simulation directory, a test directory, a test code directory and a system directory;

[0016] The configuration directory is used to store configuration files of the composite verification platform, wherein the configuration files include common configuration files required by all the verification platforms and personalized configuration files corresponding to each of the verification platforms;

[0017] The environment directory is used to store a number of environment files corresponding to each of the verification platforms;

[0018] The list directory is used to store a plurality of list files corresponding to each of the verification platforms, wherein the list files record lists of design files and library files specified during simulation;

[0019] The register directory is used to store a number of register models corresponding to each of the verification platforms, script files for generating register models, and register input files;

[0020] The simulation directory stores the scheduling files for switching the verification platforms and the source directories of the environment variables of the different verification platforms;

[0021] The test directory is used to store a number of test cases for simulation corresponding to each of the verification platforms;

[0022] The test code directory is used to store a number of test cases corresponding to a preset development language and used for simulation, respectively corresponding to each of the verification platforms;

[0023] The system directory is used to store a plurality of top-level environment files for simulation corresponding to each of the verification platforms.

[0024] Preferably, in the public control layer, variable parameters are set for the common configurations corresponding to all the verification platforms, and the variable parameters are modified through the personalized control layer to switch the verification platform.

[0025] Preferably, the system on chip has at least one subsystem, and the composite verification platform includes a main verification platform and at least one sub-verification platform, the main verification platform is used to perform integrated verification on the system on chip, and the sub-verification platform is used to verify the subsystem.

[0026] Preferably, the system on chip includes at least two project modules, the composite verification platform includes at least two verification platforms corresponding to the project modules respectively, and the verification platforms correspond to the project modules one by one.

[0027] The present invention also provides a composite verification platform for a system on chip, which includes at least two verification platforms respectively used to verify different objects in the system on chip, and is constructed based on the composite verification platform construction method for the system on chip as described above.

[0028] The present invention also provides a system-on-chip composite verification system, which includes:

[0029] one or more processors;

[0030] Memory;

[0031] and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the programs including instructions for executing the method for constructing a composite verification platform for a system on chip as described above.

[0032] The present invention also provides a computer-readable storage medium, which includes a computer program, and the computer program can be executed by a processor to complete the method for constructing a composite verification platform of a system on a chip as described above.

[0033] Compared with the prior art, the above-mentioned technical solution of the present invention provides a method for constructing a composite verification platform of a system on a chip. First, through a unified directory structure and naming rules, the element files of different verification platforms are managed in a standardized manner, avoiding the problems of a messy environment and difficult-to-find files in the traditional way, and providing a basis for hierarchical control. At the same time, the hierarchical control mechanism separates the public part from the personalized part, simplifies the maintenance of the platform, and reduces the requirements for the professional skills of the maintenance personnel; secondly, the solution supports the integration of multiple verification platforms under a composite platform, and realizes the unified scheduling and management of simulation resources through an open control layer. Different verification platforms can share the resource scheduling mechanism, avoid resource conflicts and waste, and improve resource utilization; in addition, the standardized directory structure and control mechanism make it easier to create a new verification platform. The construction of a new platform only needs to focus on personalized configuration, without having to build the entire environment from scratch, thereby reducing the technical threshold for verification engineers and improving the efficiency of platform environment construction. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 This is a flow chart of a method for constructing a SoC composite verification platform in an embodiment of the present invention.

[0035] Figure 2 It is a schematic structural diagram of a composite verification platform in one embodiment of the present invention.

[0036] Figure 3 It is a principle structure diagram of a composite verification platform in another embodiment of the present invention.

[0037] Figure 4 The platform switching mechanism part of the composite verification platform in the embodiment of the present invention is implemented in the code.

[0038] Figure 5 It is part of the implementation code of the public control layer in the embodiment of the present invention.

[0039] Figure 6 It is part of the implementation code of the personalized control layer in the embodiment of the present invention.

[0040] Figure 7 The organizational structure implementation code of the composite verification platform in the embodiment of the present invention.

[0041] Figure 8 The figure is an organizational structure diagram of a system on a chip in the prior art.

[0042] Fig. 9 This is an organizational chart of the verification platform in the prior art. DETAILED DESCRIPTION

[0043] In order to explain the technical content, structural features, achieved objectives and effects of the present invention in detail, the following is a detailed description in conjunction with the implementation methods and the accompanying drawings.

[0044] Currently, SoC (system on chip) verification platforms with multiple subsystems generally have decentralized structures and lack of unified management, which leads to a series of inefficiencies and resource waste. Figure 8 and Fig. 9 , a SoC containing four subsystems usually requires a system-level verification platform (SoC verification platform) and four independent subsystem verification platforms. This decentralized platform architecture will cause the following problems:

[0045] 1. A surge in labor costs: Each verification platform requires experienced verification personnel to develop and maintain it, which means that a SoC with four subsystems requires at least five engineers.

[0046] 2. Chaotic platform structure and difficulty in collaboration: Due to the lack of unified standards, the directory structure, naming rules, use cases and VIP (Verification IP) storage methods of each platform are different, resulting in:

[0047] Low code reuse rate: It is difficult for system-level tests to directly call subsystem test cases, and important tasks and test cases cannot be directly transplanted.

[0048] Difficult to maintain: It is difficult to use scripts to perform batch modifications and updates, and code review and management are confusing.

[0049] 3. Environment variable conflicts: Each platform defines environment variables independently, which is prone to naming conflicts and overwriting, increasing the difficulty and error risk of cross-platform operations.

[0050] 4. Fierce competition for resources: Each platform operates independently and excessively pursues maximizing its own simulation speed, resulting in fierce competition for resources such as servers and licenses, which in turn reduces the overall verification efficiency.

[0051] In summary, the lack of a unified management SoC verification platform architecture has led to problems such as high labor costs, difficulty in platform collaboration, and low resource utilization, which seriously restricts the efficiency and quality of chip verification.

[0052] In order to solve the above technical problems, this embodiment discloses a method for constructing a SoC composite verification platform, which provides an efficient SoC verification structure and operation mechanism from the perspective of platform structure integration to achieve the unification and standardization of multi-heterogeneous subsystem platform environments. The composite verification platform in this embodiment includes at least two verification platforms respectively used to verify different objects in the SoC. Figure 1 , the construction method includes:

[0053] S1: Configure a unified directory structure, which is used to store all the essential files required for the operation of the composite verification platform.

[0054] S2: Classify all element files required for the operation of the composite verification platform according to their functions and uses, and store element files of different categories into different standard directories.

[0055] S3: In each of the standard directories, there are several subdirectories corresponding to each of the verification platforms in the composite verification platform, and the subdirectories are used to store personalized element files corresponding to the corresponding verification platforms. The subdirectories can also store common element files related to all the verification platforms in the composite verification platform. It should be noted that the personalized element files are element files required for the operation of a single verification platform, and the common element files are element files required for all verification platforms to operate a certain function.

[0056] S4: Differentiate and name the files in each of the subdirectories according to a unified rule. Specifically, the files may be named according to the environment specification of the verification platform to which each subdirectory corresponds, so as to form a hierarchical directory for the coexistence of multiple platform environments.

[0057] S5: On the control plane of the composite verification platform, configure a common control layer at the bottom layer and a personalized control layer at the top layer.

[0058] In the common control layer, top-level option constraints and process control element files required by all the verification platforms are stored;

[0059] In the personalized control layer, configuration element files customized by the user according to the requirements of any of the verification platforms are stored.

[0060] The personalized control layer can override or constrain the default settings in the public control layer, so that the personalized control layer provides an operation interface for switching the verification platform. For the user, only a simple operation of the personalized control layer is required to indirectly control the public control layer to achieve the purpose of switching the verification platform.

[0061] In this embodiment, by integrating the directory structure and layering the control structure, a composite verification platform is formed that includes several verification platforms that can respectively verify different objects of the SoC. During use, the user can switch the composite verification platform to the corresponding verification platform according to the current object to be verified.

[0062] According to the standardized directory structure with hierarchical distribution, all the element files required for the composite verification platform are clearly classified, and each sub-directory is named according to this structural specification to form a hierarchical directory that is easy to manage and maintain.

[0063] In this embodiment, a standardized directory structure is uniformly set up to lay the foundation for hierarchical control of the control plane (the combination of the public control layer and the personalized control layer). Hierarchical control is the goal of a unified standard directory structure. The two complement each other and jointly create an efficient, easy-to-maintain and easy-to-expand chip verification platform.

[0064] On the other hand, the SoC has at least one subsystem, and the composite verification platform includes a main verification platform and at least one sub-verification platform, the main verification platform is used to perform integrated verification on the SoC, and the sub-verification platform is used to verify the subsystem.

[0065] like Figure 2, there are four subsystems on the SoC, then the composite verification platform includes five verification platforms, namely the SoC verification platform, sub-platform 1, sub-platform 2, sub-platform 3 and sub-platform 4. The SoC verification platform, sub-platform 1, sub-platform 2, sub-platform 3 and sub-platform 4 have a common underlying public platform.

[0066] On the other hand, the SoC includes at least two project modules, and the composite verification platform includes at least two verification platforms corresponding to the project modules respectively, and the verification platforms correspond to the project modules one by one.

[0067] like Figure 3 , there are four project modules on the SoC, namely project module A, project module B, project module C, and project module D. Then, the composite verification platform includes four verification platforms, namely verification platform A, verification platform B, verification platform C, and verification platform D. Verification platform A, verification platform B, verification platform C, and verification platform D use a common underlying public platform.

[0068] On the other hand, the standard directory tb includes eight subdirectories, as shown in the following directory structure, namely, configuration directory cfg, environment directory env, list directory filelist, register directory reg, simulation directory sim, test directory tc, test code directory testcode and system directory th.

[0069]

[0070] For cfg, the following directory structure is used to store the configuration files of the composite verification platform, wherein the configuration files include the common configuration files required by all the verification platforms and the personalized configuration files corresponding to each of the verification platforms.

[0071]

[0072]

[0073] Among them, the contents of *.mk (such as SubSys1.mk) include simulation option configuration, simulation tool selection, regression resource scheduling, coverage collection configuration, waveform dump settings, and other execution controls of the entire verification platform compilation simulation.

[0074] It should be noted that, in the directory structure of this embodiment and the following embodiments, SoC represents the SoC integrated verification platform, and SubSys1, SubSys2, SubSys3, and SubSys4 respectively represent the verification platforms corresponding to each subsystem on the SoC.

[0075] For env, the following directory structure is used to store several environment files corresponding to each of the verification platforms. Taking the SoC subdirectory as an example, it includes main environment files such as env, vritual sequence, vritualsequencer, config class, coverage, and vip agent.

[0076]

[0077] For filelist, the following directory structure is used to store a number of list files corresponding to each of the verification platforms, and the list files record the list of design files and library files specified during simulation.

[0078]

[0079] For the reg, the following directory structure is used to store a number of register models corresponding to each of the verification platforms, a script file for generating the register model, and a register input file.

[0080]

[0081] For sim, the directory structure is as follows, which stores the scheduling file makefile used to switch each verification platform, and the source directory of the environment variables of different verification platforms.

[0082]

[0083]

[0084] For the test directory tc, the directory structure is as follows, which is used to store a number of test cases for simulation corresponding to each of the verification platforms.

[0085]

[0086] For testcode, the following directory structure is used to store a number of test cases corresponding to a preset development language (such as C language) for simulation corresponding to each of the verification platforms.

[0087]

[0088] For th, the following directory structure is used to store a number of top-level files of the environment for simulation corresponding to each of the verification platforms.

[0089]

[0090]

[0091] From this, we can see that each subdirectory contains all verification platform environment directories. In other words, each verification platform environment is split into eight subdirectories such as tc / th / cfg according to the characteristics of the organization. This forms a standard hierarchical directory with a fixed hierarchy and unified naming, which is very conducive to script processing. Therefore, with this standard symbiotic platform environment hierarchical directory, it is possible to flexibly switch between multiple platform environments through sim / makefile. Figure 4 If no additional specification is made in the simulation command line, the default platform for simulation is SoC. If tb=SubSys1 is specified, the platform environment of the current simulation platform is SubSys1, thus realizing platform reuse in multiple environments.

[0092] On the other hand, whether it is SubSys1.mk or SubSys2.mk, the main contents are basically the same. In order to facilitate maintenance and operation, variable parameters are set for the common configuration corresponding to all the verification platforms in the public control layer, and the variable parameters are modified through the personalized control layer to switch the verification platform.

[0093] For example, Figure 5 , in common.mk, the symbol '? =' is used to set a default value, such as fsdb? = 1, or even no default value is given, such as seed? =;

[0094] However, the default parameters set in common.mk may not be the parameters required by the SubSys1 environment, which requires special specification in SubSys1.mk, such as Figure 6 , such as seed: = 1000, fsdb: = 2; when the verification platform is switched to SubSys1 through tb, SubSys1.mk will be executed and the default settings in common.mk will be overwritten.

[0095] For example, Figure 7 The composite verification platform created by the above construction method includes multiple verification platforms with different tb names such as demo, mscpss, css, and pss.

[0096] The default verification platform is demo. If you want to simulate different test cases in demo, you only need to execute make run tc=tc_name in the sim directory. You do not need to specify tb. It can be seen that the compilation directory and corresponding simulation directory of the demo environment are automatically generated during simulation.

[0097] If you want to switch to the mscpss platform environment and simulate the tc_mscpss_sanity use case of the mscpss environment, just execute the command make run tb=mscpss tc=tc_mscpss_sanity in the sim directory. It can be seen that the compilation directory and simulation directory of mscpss are automatically generated during simulation.

[0098] From this, we can see that in the standard symbiotic environment hierarchy directory, different simulation environments can be switched and different test cases can be simulated by specifying the tb environment name in a sim directory.

[0099] In summary, the present invention discloses a method for constructing a SoC composite verification platform, which constructs a composite verification platform based on a hierarchical multi-platform control mechanism, and brings many benefits to large-scale SoC verification:

[0100] (1) Simplify platform maintenance

[0101] In the traditional way, each subsystem needs a dedicated person to build and maintain the platform. However, the composite verification platform formed based on the construction method of the present invention only requires a verification personnel who is familiar with the core mechanism of the platform to maintain the common.mk file and define the core control logic, compilation options, simulation process, etc. of the platform. Other verification engineers only need to pay attention to the user configuration files (such as SubSys1.mk) corresponding to their respective subsystems, and can customize the configuration of the subsystem platform by modifying the interface parameters reserved in common.mk without having to deeply understand the underlying mechanism.

[0102] This approach greatly reduces the cost of platform maintenance, while concentrating professional talent on the development and optimization of the core platform, avoiding duplication of work and improving the utilization of human resources.

[0103] (2) Seamless upgrade and flexible expansion

[0104] The maintainers of the core platform can continuously optimize the common.mk file, such as adding new functions, improving simulation processes, optimizing resource scheduling strategies, etc. These changes are transparent to verification engineers using the platform, and they can enjoy the convenience brought by platform upgrades without modifying the configuration files related to their subsystems.

[0105] For example, when a new subsystem verification environment needs to be connected, the new verification engineer only needs to create the environment according to the standardized directory structure and pay attention to the configuration related to its subsystem, which greatly reduces the learning cost of using the platform and makes the platform easier to expand and maintain.

[0106] (3) Allocate resources on demand to improve utilization

[0107] The common.mk file can pre-allocate simulation resources (such as server multi-core resources) according to the scale and needs of different subsystems. The subsystem verification environment (that is, the verification platform corresponding to the subsystem) can overwrite the preset resource configuration in the user configuration file according to the actual situation to achieve flexible resource scheduling.

[0108] For example, common.mk can pre-allocate multi-core resources according to the size of four subsystems. If a subsystem needs more resources, it can be directly specified in SubSys1.mk to override the default allocation of common.mk.

[0109] (4) Standardized management to improve efficiency

[0110] The unified directory structure, naming conventions, environment variables and simulation operation mechanism make the entire platform clearer and easier to manage. All reusable macro definitions and environment variables are concentrated in common.mk, avoiding duplicate definitions and confusion, and improving the readability and maintainability of the code.

[0111] (5) Support multiple verification environments

[0112] The composite verification platform architecture supports pure UVM verification environment, pure C language verification environment and UVM+C language mixed environment, providing flexible options for different verification requirements.

[0113] In summary, this hierarchical multi-platform control mechanism achieves easy maintainability, scalability, efficient resource utilization and standardized management of the verification platform by separating the core functions of the platform from user configurations, effectively solving the challenges faced by traditional verification platforms and significantly improving the efficiency of large-scale SoC verification.

[0114] In another preferred embodiment of the present invention, a SoC composite verification platform is disclosed, which includes at least two verification platforms respectively used to verify different objects in the SoC, and the composite verification platform is constructed based on the SoC composite verification platform construction method in the above embodiment.

[0115] The present invention also discloses a SoC composite verification system, which includes one or more processors, a memory and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the program includes instructions for executing the SoC composite verification platform construction method as described above. The processor can adopt a general central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), or one or more integrated circuits, which are used to execute relevant programs to implement the functions required to be executed by the modules in the SoC composite verification system of the embodiment of the present application, or to execute the SoC composite verification platform construction method of the method embodiment of the present application.

[0116] The present invention also discloses a computer-readable storage medium, which includes a computer program, and the computer program can be executed by a processor to complete the SoC composite verification platform construction method as described above. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes one or more available media integrated. The available medium can be a read-only memory (ROM), or a random access memory (RAM), or a magnetic medium, such as a floppy disk, a hard disk, a tape, a magnetic disk, or an optical medium, such as a digital versatile disc (DVD), or a semiconductor medium, such as a solid state disk (SSD), etc.

[0117] The embodiment of the present application also discloses a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of an electronic device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the electronic device executes the above-mentioned SoC composite verification platform construction method.

[0118] The above disclosure is only the preferred embodiment of the present invention, which certainly cannot be used to limit the scope of rights of the present invention. Therefore, equivalent changes made according to the scope of the patent application of the present invention are still within the scope covered by the present invention.

Claims

1. A method for constructing a system-on-chip composite verification platform, characterized in that: The composite verification platform includes at least two verification platforms respectively used to verify different objects in the system on chip, and the construction method includes: Configure a unified directory structure, the directory structure is used to store all the element files required for the operation of the composite verification platform; Classifying all element files required for the operation of the composite verification platform according to their functions and uses, and storing element files of different categories in different standard directories; In each of the standard directories, there are configured a number of sub-directories corresponding to each of the verification platforms in the composite verification platform, the sub-directories are used to store personalized element files corresponding to the corresponding verification platforms, and the sub-directories may also store common element files related to all the verification platforms in the composite verification platform; Differentiately name the files in each subdirectory according to a unified rule; On the control plane, configure the common control layer at the bottom and the personalized control layer at the top; In the common control layer, top-level option constraints and process control element files required by all the verification platforms are stored; In the personalized control layer, the configuration element files customized by the user according to the requirements of any of the verification platforms are stored; The personalized control layer can override or constrain the default settings in the public control layer, so that the personalized control layer provides an operation interface for switching the verification platform.

2. The method for constructing a system-on-chip composite verification platform according to claim 1, characterized in that: The standard directory includes eight subdirectories, namely, a configuration directory, an environment directory, a list directory, a register directory, a simulation directory, a test directory, a test code directory and a system directory; The configuration directory is used to store configuration files of the composite verification platform, wherein the configuration files include common configuration files required by all the verification platforms and personalized configuration files corresponding to each of the verification platforms; The environment directory is used to store a number of environment files corresponding to each of the verification platforms; The list directory is used to store a plurality of list files corresponding to each of the verification platforms, wherein the list files record lists of design files and library files specified during simulation; The register directory is used to store a number of register models corresponding to each of the verification platforms, script files for generating register models, and register input files; The simulation directory stores the scheduling files for switching the verification platforms and the source directories of the environment variables of the different verification platforms; The test directory is used to store a number of test cases for simulation corresponding to each of the verification platforms; The test code directory is used to store a number of test cases corresponding to a preset development language and used for simulation, respectively corresponding to each of the verification platforms; The system directory is used to store a plurality of top-level environment files for simulation corresponding to each of the verification platforms.

3. The method for constructing a system-on-chip composite verification platform according to claim 1, characterized in that: In the public control layer, variable parameters are set for the common configurations corresponding to all the verification platforms, and the variable parameters are modified through the personalized control layer to switch the verification platform.

4. The method for constructing a system-on-chip composite verification platform according to claim 1, characterized in that: The system on chip has at least one subsystem, and the composite verification platform includes a main verification platform and at least one sub-verification platform. The main verification platform is used to perform integrated verification on the system on chip, and the sub-verification platform is used to verify the subsystem.

5. The method for constructing a system-on-chip composite verification platform according to claim 1, characterized in that: The system on chip includes at least two project modules, and the composite verification platform includes at least two verification platforms corresponding to the project modules respectively, and the verification platforms correspond to the project modules one by one.

6. A system-on-chip composite verification platform, characterized in that: The composite verification platform includes at least two verification platforms respectively used to verify different objects in the system on chip, and the composite verification platform is constructed based on the method for constructing a composite verification platform of a system on chip according to any one of claims 1 to 5.

7. A system-on-chip composite verification system, characterized in that: include: one or more processors; Memory; And one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the programs include instructions for executing the method for constructing a system-on-chip composite verification platform as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that: It includes a computer program, which can be executed by a processor to complete the method for constructing a system-on-chip composite verification platform as described in any one of claims 1 to 5.

Images