Checking method for chip front-end design, storage medium and computer program product

Abstract

The invention discloses a chip front-end design inspection method, a storage medium and a computer program product, and relates to the technical field of chip front-end design verifier.The method comprises the steps that a corresponding environment variable is added to a sub-project file of each level according to a chip front-end design project level architecture; adding a corresponding preset quality inspection folder under the hierarchical path represented by each environment variable; constructing an inspection tree according to the quality inspection folder and the hierarchical architecture of the chip front-end design project; and checking the chip front-end design item according to the quality checking folder of each level in the checking tree. According to the method, the corresponding quality inspection folder is added for the sub-project file of each level, and the inspection tree is constructed according to the quality inspection folder and the chip front-end design project level architecture, so that the quality inspection efficiency and level are improved, and the quality of chip front-end design inspection is improved.

Description

Technical Field

[0001] The present application relates to the technical field of chip front-end design verification, and in particular to a chip front-end design inspection method, storage medium and computer program product. Background Art

[0002] With the advancement of integrated circuit manufacturing technology, chip integration and complexity are getting higher and higher. A system-on-chip (SOC) can integrate billions of transistors. To ensure correct functions and meet performance indicators, the chip design team needs to conduct comprehensive and accurate quality checks on design codes, functional verification schemes, timing constraints, physical layout, etc. Traditional inspection methods are inefficient and cannot meet the needs of high quality and fast time to market.

[0003] In view of the above situation, it is urgent to establish an automated and standardized quality inspection process that can quickly identify problems in code and implementation and reduce repair costs. The inspection process needs to be able to integrate the quality inspection content of different design levels (netlist, layout) to form a systematic and hierarchical inspection system to achieve efficient collaboration among design teams. However, the quality inspection of chip front-end design projects is currently carried out in a fragmented and decentralized manner. Different design levels and different local designs use independent inspection mechanisms, which result in duplicate inspections and missed inspections. Inspectors need to manually integrate a lot of different inspection contents and configurations, and the degree of automation is low.

[0004] Therefore, how to organically integrate the front-end design quality checks scattered at different design levels to form a unified and automated inspection system is a problem that needs to be solved urgently. Summary of the invention

[0005] The main purpose of this application is to provide a chip front-end design inspection method, storage medium and computer program product, aiming to solve the technical problem of how to organically integrate front-end design quality inspections scattered at different design levels to form a unified and automated inspection system.

[0006] To achieve the above objectives, the present application proposes a chip front-end design inspection method, the chip front-end design inspection method comprising:

[0007] According to the chip front-end design project hierarchy, add corresponding environment variables to each sub-project file;

[0008] Add a corresponding preset quality check folder under the hierarchical path represented by each of the environment variables;

[0009] Building a check tree according to the quality check folder and the chip front-end design project hierarchy;

[0010] The chip front-end design project is checked according to the quality check folders at each level in the check tree.

[0011] In one embodiment, the step of constructing a check tree according to the quality check folder and the chip front-end design project hierarchy specifically includes:

[0012] Collect all the quality inspection folders of the chip front-end design project;

[0013] Different quality folders are used as branch nodes of the inspection tree, and an inspection tree is constructed according to the different quality folders. The inspection tree includes a hierarchical structure corresponding to the hierarchical structure of the chip front-end design project.

[0014] In one embodiment, the different quality folders are used as branch nodes of the inspection tree, and the inspection tree is constructed according to the different quality folders. The inspection tree includes hierarchical steps corresponding to the hierarchical architecture of the chip front-end design project, including:

[0015] In the project management warehouse of the chip front-end design project, a general design quality folder is added, and in the process management warehouse of the chip front-end design project, a self-developed design tool quality folder is added;

[0016] An inspection tree is constructed according to the quality inspection folder, the general design quality folder, the self-developed design tool quality folder and the chip front-end design project hierarchy.

[0017] In one embodiment, after the step of constructing a check tree according to the quality check folder, the general design quality folder, the self-developed design tool quality folder and the chip front-end design project hierarchy, the step further includes:

[0018] Checking the general inspection items in the project management warehouse through the general design quality folder in the inspection tree;

[0019] The self-developed design tool of the chip front-end design project is checked through the self-developed design tool quality folder in the inspection tree.

[0020] In one embodiment, the quality inspection folder specifically includes: inspection project files, configuration files, and command line parameter files;

[0021] The inspection item file is a file containing different inspection items;

[0022] The step of inspecting the chip front-end design project according to the quality inspection folders at each level in the inspection tree includes:

[0023] Defining the inspection parameter information that the inspection project file needs to obtain from the command line according to the received command line parameters through the command line parameter file;

[0024] Adding the acquired information to the inspection project file;

[0025] Dividing the inspection items in the inspection item file after adding the inspection parameter information into different groups through the configuration file;

[0026] The inspection item files of different groups are inspected according to the quality inspection folders at each level in the inspection tree.

[0027] In one embodiment, the step of constructing a check tree according to the quality check folder, the general design quality folder, the self-developed design tool quality folder and the chip front-end design project hierarchy also includes:

[0028] Add corresponding YAML files to the quality folder, the general design quality folder, and the self-developed design tool quality folder of the sub-project in the project repository;

[0029] Building a check tree according to the quality check folder, the general design quality folder, the self-developed design tool quality folder and the chip front-end design project hierarchy after adding the YAML file;

[0030] Accordingly, checking the chip front-end design project according to the quality inspection folders at each level in the inspection tree includes:

[0031] Using the YAML file, different groups in the corresponding configuration file are divided into different severity levels;

[0032] If the severity level of the group is higher than a preset severity level, the inspection items in the group are inspected, and the preset severity level changes dynamically according to different design stages of the chip front-end design project.

[0033] In one embodiment, the different quality folders are used as branch nodes of the inspection tree, and the inspection tree is constructed according to the different quality folders. After the inspection tree includes the hierarchical structure corresponding to the hierarchical structure of the chip front-end design project, the following steps are further included:

[0034] adding a violation manager to each level of the inspection tree;

[0035] The sub-project files violating the project rules are marked as violation files by the violation manager, and the violation files are stored in a preset database when the check is completed.

[0036] In one embodiment, the step of checking the chip front-end design project according to the quality folders at each level in the inspection tree comprises:

[0037] Converting the inspection results obtained based on the inspection tree into a data table;

[0038] The data table is output to the user for review.

[0039] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the chip front-end design inspection method as described above are implemented.

[0040] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the chip front-end design inspection method as described above.

[0041] The present application provides a method for checking chip front-end design. The present application first adds corresponding environment variables to the sub-project files of each level according to the hierarchical architecture of the chip front-end design project, then adds the corresponding preset quality inspection folder under the hierarchical path represented by each of the environment variables, and constructs an inspection tree according to the quality inspection folder and the hierarchical architecture of the chip front-end design project, and finally checks the chip front-end design project according to the quality inspection folders of each level in the inspection tree. In the present application, the environment variables clearly define the relationship between the design levels, and the inspection folder contains the inspection content for the design of this level. The inspection tree integrates and represents different design levels in the form of tree nodes, and the child nodes contain corresponding inspection folders. According to the tree structure, each design level node can be recursively traversed to automatically execute the inspection content in the inspection folder. Inspections at different levels are integrated through the inspection tree to form a unified inspection system. It replaces the repetitive work of manually integrating inspections at different levels, realizes the automation of the inspection process, and solves the problem of how to organically integrate the front-end design quality inspections scattered at different design levels to form a unified and automated inspection system. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0043] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0044] Figure 1 A flow chart of the first embodiment of the chip front-end design inspection method provided in the present application;

[0045] Figure 2 A flow chart of the second embodiment of the chip front-end design inspection method provided in the present application;

[0046] Figure 3 Another flow chart provided for the second embodiment of the inspection method for the chip front-end design of the present application;

[0047] Figure 4 A flow chart of the third embodiment of the chip front-end design inspection method provided in the present application;

[0048] Figure 5 Another flow chart provided for the third embodiment of the inspection method for the chip front-end design of the present application;

[0049] Figure 6 A flow chart of a fourth embodiment of the chip front-end design inspection method provided in the present application;

[0050] Figure 7 Another flow chart provided for the fourth embodiment of the inspection method for the chip front-end design of the present application;

[0051] Figure 8 A schematic diagram of a chip front-end design inspection device provided for the chip front-end design inspection method application;

[0052] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0053] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0054] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0055] The existing technology currently performs quality inspections on chip front-end design projects in a fragmented and decentralized manner. Different design levels and different local designs use independent inspection mechanisms, which results in duplicate inspections and missed inspections. Inspectors need to manually integrate a large amount of different inspection contents and configurations, and the degree of automation is low. Therefore, how to organically integrate the front-end design quality inspections scattered at different design levels to form a unified, automated inspection system is a problem that needs to be solved urgently.

[0056] The present application provides a solution, in which the environment variables clearly define the relationship between the design levels, and the inspection folder contains the inspection content for the design of this level. The inspection tree integrates and represents different design levels in the form of tree nodes, and the child nodes contain corresponding inspection folders. According to the tree structure, each design level node can be recursively traversed to automatically execute the inspection content in the inspection folder. Inspections at different levels are integrated through the inspection tree to form a unified inspection system. It replaces the repetitive work of manually integrating inspections at different levels, realizes the automation of the inspection process, solves the problem of how to organically integrate the front-end design quality inspections scattered at different design levels to form a unified and automated inspection system, and improves the efficiency and level of quality inspection.

[0057] It should be noted that the execution subject of this embodiment can be a chip front-end design inspection system, or a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or a chip front-end design inspection device capable of realizing the above functions, etc., and this embodiment does not specifically limit this. The following takes the chip front-end design inspection system as the execution subject as an example to illustrate this embodiment and the following embodiments.

[0058] Based on this, the embodiment of the present application provides a method for checking chip front-end design, referring to Figure 1 , Figure 1 A flowchart of the first embodiment of the inspection method for the chip front-end design of the present application.

[0059] In this embodiment, the chip front-end design inspection method includes steps S101 to S104:

[0060] S101. Add corresponding environment variables to sub-project files at each level according to the chip front-end design project hierarchy;

[0061] For a complex chip front-end design project, its hierarchical architecture may include multiple levels such as the top solution layer, the subsystem layer, and the chip IP (Intellectual Property, IP) core layer. In order to facilitate the inspection system to identify different levels, the inspection system needs to first parse the hierarchical relationship of the project and add specific environment variables for each design sub-project to indicate the hierarchical information to which it belongs. The full name of the environment variable is the environment configuration variable, which refers to a type of variable used to specify system configuration information in the operating system. In the Linux system, environment variables are often used to define information such as proxy servers and command search paths. The inspection system can call the operating system interface to obtain and set environment variables. The value of the environment variable can be the full path of the project, or it can contain information such as the project name and level. In the scenario of this chip front-end design project, the environment variable is a variable customized by the inspection system to record the hierarchical information of each sub-project. In this step, the environment variable is a customized variable used to identify the hierarchical information to which each design sub-project belongs. The addition of environment variables can be implemented programmatically; the inspection system can parse the hierarchical information of the chip front-end design project, and then insert a configuration file containing the environment variable definition into the directory where each sub-project is located through programming.

[0062] For example, first, the inspection system needs to call the operating system interface to traverse and obtain all subfolder paths under the design project directory. Then, for each obtained subfolder path, the inspection system determines which level the design subproject corresponding to the folder belongs to according to the project hierarchy table. Then, based on the determined hierarchy information, the corresponding environment variable name is generated, such as the variable corresponding to the top solution layer can be defined as ENV_TOP_project name. Then, the generated environment variable is written into a shell script file to define the variable. Then, the inspection system calls the operating system interface to insert the generated script file declaring the environment variable into the corresponding subproject folder, and the file name can be set to env.sh. The specific insertion can be achieved by copying or symbolic linking. Then, the inspection system repeats the above steps of generating the environment variable script and inserting the script for all subproject folders under the design project until all subprojects have successfully inserted the env.sh script file. Finally, the inspection system can obtain the environment variable information of the level to which the project belongs by reading the env.sh file under each subproject folder. The system interface getenv can also be directly called to obtain the variable value, thereby determining the hierarchical relationship of the project.

[0063] In this way, the inspection system inserts environment variables representing the hierarchical information of each design sub-project in turn through scripting, providing support for the subsequent quality inspection process. The value of the environment variable can include project name, hierarchical information, file path, etc., which are used to identify file attributes. When the inspection system subsequently builds the inspection process, it can determine the level to which the file belongs based on the environment variable, so as to make reasonable inspection configuration.

[0064] S102, adding a corresponding preset quality inspection folder under the hierarchical path represented by each of the environment variables;

[0065] For the design sub-projects at different levels to which environment variables were added in the previous step, the inspection system can create quality inspection folders under their corresponding paths. The quality inspection folder is a folder used by the inspection system to store the design quality inspection content, and is a technical means to achieve modular management of inspection content. The quality folder can contain all the content for quality inspection, such as inspection scripts, configuration files, and code rules. These contents are pre-packaged in folders to facilitate calling and configuration for each design sub-project. The quality folder needs to be stored under the environment variable path of the level to which the design sub-project belongs to establish an association between the project level and the inspection content. The inspection system can quickly locate the corresponding quality folder based on the environment variables. The inspection content under the quality folder can be updated and expanded according to the different stages of the chip design process to meet the quality assessment needs at different stages.

[0066] For example, in the coding stage, code specification checking rules can be configured; in the simulation verification stage, functional coverage checking scripts can be added. In this step, the inspection folder can be named "quality_check", in which specific inspection rules, scripts, configuration files, etc. designed for this level can be preset. For example, the inspection folder of the subsystem layer can contain code inspection rules for checking code style, syntax errors, etc. The folder contents can be customized according to company or project standards. The inspection system can then locate the corresponding inspection folder based on the environment variables and perform the quality inspection process according to the configuration therein.

[0067] The specific ways to add the quality inspection folder in this step are:

[0068] For example, first, the inspection system needs to obtain the specific development stage of the current chip design project, such as the coding stage, the netlist layout stage, the simulation verification stage, etc. Then, the inspection system consults the preset quality inspection content template according to different development stages to determine the inspection rules, scripts, configuration files, etc. corresponding to the stage. The inspection content template can be imported when the system is initialized. Next, the inspection system traverses the hierarchical structure of the chip design project to obtain the level to which each design sub-project belongs, such as the top-level solution layer, the subsystem layer, etc. For each level, the inspection system creates a quality folder with a fixed name, such as "quality_check", under the environment variable path of the corresponding design sub-project. Then, the inspection system imports the quality inspection content required for the current development stage into the quality folder according to the predefined organizational structure. For example, import code specification inspection scripts, simulation coverage configuration files, etc. After the import is completed, the inspection system repeats the above steps until all levels in the design project have imported the corresponding quality folders. Finally, when the design process switches to the next stage, the inspection system can update the inspection content in the quality folder to adapt to new requirements. The import of quality folders can be completed in batches through automatic scripts, or a user interface can be provided for manual operation.

[0069] S103, constructing an inspection tree according to the quality inspection folder and the chip front-end design project hierarchy;

[0070] It should be noted that in this solution, the inspection tree is an abstract representation of the hierarchical structure of the chip design project, which reflects the hierarchical relationship of the design project in the form of a tree diagram. The inspection tree can more intuitively represent the hierarchical solution of quality inspection.

[0071] In this solution, building the inspection tree requires utilizing two elements simultaneously: one is the hierarchical architecture information of the chip front-end design project itself, and the other is the quality inspection folder set for each level.

[0072] Each tree node in the inspection tree represents a level of the design project, such as top-level solution, subsystem, IP core, etc. The connection relationship between nodes represents the superior-subordinate relationship between levels. Each tree node contains two main attributes: one is the level name, and the other is a pointer to the quality inspection folder of the level.

[0073] Specifically, first, the inspection system determines the overall hierarchical structure of the project based on the hierarchical information of the design project analyzed in the early stage, which provides guidance for the framework of the inspection tree. Then, the inspection system obtains the hierarchy to which each design sub-project belongs based on the environment variables and locates the path of the corresponding quality inspection folder. Next, the inspection system adds the node representing the hierarchical information to the framework of the inspection tree and establishes an association between the node and the quality folder.

[0074] In this way, while building the inspection tree, the hierarchical structure of the design project and the quality inspection folder are organized together. By integrating the two, the inspection tree contains both the hierarchical relationship of the project design and the inspection content corresponding to each level.

[0075] Through the inspection tree, when performing automated quality inspections, you can call the corresponding inspection content step by step according to the project hierarchy. This not only plays the role of project hierarchy information, but also takes advantage of the quality folder, organically combining the two to build an intelligent and automated hierarchical inspection solution.

[0076] S104. Inspect the chip front-end design project according to the quality inspection folders at each level in the inspection tree.

[0077] It should be noted that this step is mainly based on the inspection tree built in the early stage, and uses the tree structure to drive and execute hierarchical quality inspection of the chip front-end design project.

[0078] In step S103, the inspection system has constructed an inspection tree including all levels of the project. The tree nodes represent the inspection levels, and the pointer attributes of the nodes are associated with the corresponding quality inspection folders.

[0079] When performing quality checks, the inspection system can recursively traverse the nodes of the inspection tree, visit the inspection folder associated with each node in turn, call the inspection scripts or rules in the folder, and perform quality assessment on the design content at that level.

[0080] The specific technical implementation can be achieved through the following steps:

[0081] First, the inspection system can set an inspection starting level, which corresponds to a tree node in the inspection tree as the starting point of the recursive traversal. Then, the inspection system traverses the inspection tree according to a depth-first or breadth-first strategy. When a node is accessed, the folder pointer of the node is used to locate the actual quality inspection folder. Next, the inspection system loads the scripts, configuration files, etc. in the inspection folder, executes the inspection operations defined in the folder, analyzes and evaluates the design content of the sub-projects corresponding to the inspection folder, and generates an inspection report. After that, the child nodes of the current node are recursively accessed, and the inspection operation of the corresponding folder is repeatedly called. Finally, the above steps are repeated until all nodes of the inspection tree are traversed, that is, quality inspections at all levels are fully executed.

[0082] It is easy to understand that by automatically recursively traversing the inspection tree through a program, it is possible to replace manual configuration and execution of inspection operations layer by layer, thereby automating the hierarchical inspection process and greatly improving inspection efficiency.

[0083] Compared with linear inspection execution, this solution makes full use of the project hierarchy information reflected by the inspection tree data structure, which can organize the inspection steps in a more reasonable order and effectively avoid the problem of repeated inspections.

[0084] In addition, the solution also supports arbitrary adjustment of the inspection order to meet the needs of actual scenarios. The inspection tree decouples the inspection content and project level, making it more flexible.

[0085] In this embodiment, the quality inspection of the chip front-end design project is currently carried out in a fragmented and decentralized manner in the prior art. Different design levels and different local designs use independent inspection mechanisms, which result in problems of repeated inspection and missed inspection. Inspectors need to manually integrate a large amount of different inspection contents and configurations, and the degree of automation is low, so the front-end design quality inspections scattered at different design levels cannot be organically integrated to form a unified and automated inspection system, and thus the problem of how to organically integrate the front-end design quality inspections scattered at different design levels to form a unified and automated inspection system cannot be solved. This embodiment clearly defines the relationship between design levels through environment variables. The inspection folder contains the inspection content for the design of this level. The inspection tree integrates different design levels in the form of tree nodes. The child nodes contain corresponding inspection folders. Each design level node can be recursively traversed to automatically execute the inspection content in the inspection folder. The inspections of different levels are integrated through the inspection tree to form a unified inspection system, replacing the repetitive work of manually integrating inspections of different levels, realizing the automation of the inspection process, and effectively solving the problem of how to organically integrate the front-end design quality inspections scattered at different design levels to form a unified and automated inspection system, thereby achieving an improvement in the efficiency and level of quality inspection. Compared with the prior art, the solution provided by this embodiment realizes an automated and intelligent hierarchical inspection solution, saves a lot of manual inspection integration work, solves the problems of repeated inspections and omissions caused by the dispersion of inspection content, and improves the quality of front-end design inspections.

[0086] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. The method provided in the first embodiment is further described in more detail below. Figure 2 and Figure 3 , are two other flow charts of the inspection method of the chip front-end design in the embodiments of the present application.

[0087] It should be noted that step S103 can be implemented in the following ways:

[0088] A00 collects all the quality inspection folders of the chip front-end design project;

[0089] In this step, the inspection system needs to collect the quality inspection folders.

[0090] First, the checking system may first call a file traversal interface to recursively traverse the entire directory structure and all subfolders of the design project.

[0091] During the traversal process, the inspection system determines the name of each folder. If it matches the preset quality inspection folder name, such as "quality_check", the folder path is collected and stored in the collection list. After the traversal is completed, the inspection system can obtain the path collection of all scattered quality inspection folders in the design project. These folders may be distributed in different hierarchical directories of the project. It is also possible to determine whether it belongs to a quality inspection folder by containing specific marker files in the folder, such as containing config.txt to indicate a quality inspection folder.

[0092] After the quality check folders are collected, the inspection system needs to verify whether the number of folder lists obtained is correct to avoid omissions. In this way, all quality check folders in the project can be automatically collected through file traversal, replacing the uncertainty caused by manual collection.

[0093] A01 uses different quality folders as branch nodes of a check tree, and constructs a check tree according to the different quality folders, wherein the check tree includes a hierarchical structure corresponding to the hierarchical structure of the chip front-end design project;

[0094] In this step, the inspection system needs to build an inspection tree using the collected quality inspection folders.

[0095] The inspection system can create a new empty tree data structure to represent the inspection tree. Then it traverses the collected quality folder list, and adds a corresponding node to the tree every time it iterates to a quality folder path. The name of the new node can directly use the name of the iterated quality folder, and the node contains the folder path attribute. Repeat this iteration and addition operation until all quality folders in the list have nodes added to the inspection tree. Since quality folders correspond to different levels of the design project, the newly added nodes also reflect the project hierarchy. Finally, a hierarchical inspection tree structure with quality folders as nodes is formed. During the build process, the inspection system needs to verify whether the node name and content are normal to avoid build failure.

[0096] In this way, by directly utilizing the collected quality folder list, the corresponding inspection tree can be automatically constructed without manually defining the node names and levels.

[0097] It should be noted that different quality folders are used as branch nodes of the inspection tree, and the inspection tree is constructed according to the different quality folders. The inspection tree includes a hierarchical structure corresponding to the hierarchical structure of the chip front-end design project. This step may include the following contents;

[0098] Optionally, in general, different quality folders are used as branch nodes of the inspection tree, and the inspection tree is constructed according to different quality folders. The inspection tree includes the hierarchical structure steps corresponding to the hierarchical structure of the chip front-end design project, which can be implemented in the following manner:

[0099] A10 adds a general design quality folder in the project management warehouse of the chip front-end design project and adds a self-developed design tool quality folder in the process management warehouse of the chip front-end design project;

[0100] It should be noted that, in this embodiment, the project management warehouse is a code library for storing and managing various management documents of chip design projects, which may include various documents related to the project management process, such as project plans, task assignments, and meeting minutes. The process management warehouse is a code library for storing and managing chip design process scripts, which may include script codes for various aspects of the chip design process, such as synthesis, layout, simulation, and verification.

[0101] Under the top-level directory of the project management warehouse, the inspection system needs to programmatically add a folder named "General Design Quality Folder", which is a folder specifically used to collect and store common design specifications and standard documents in chip design projects. The general design quality folder can be used to store general normative documents such as chip design specifications and quality standards recognized by the company or industry. These documents establish general design and quality requirements that all designers need to follow. Under the top-level directory of the process management warehouse, the inspection system also needs to programmatically add a folder named "Self-developed Design Tool Quality Folder", which is a folder specifically used to collect and manage quality assessment scripts, test cases and other files of IC design tools and processes independently developed by the project team. The self-developed design tool quality folder can store script codes, test cases and other documents used to evaluate and inspect the functions, performance, quality and other aspects of the design tools and processes independently developed by the project team to ensure that these self-developed tools and processes meet quality requirements and will not have a negative impact on the design results.

[0102] The general design quality folder and the self-developed design tool quality folder are placed in the project management warehouse and the process management warehouse respectively instead of in the same warehouse. This is because the two folders target different objects, one is the general specification and the other is the self-developed tool. Separate storage is conducive to classification management.

[0103] To ensure the correct execution of the new folder operation, after checking that the system has added these two folders through the API or other program methods, verification is required, including verifying whether the folder path is correct, whether it has been successfully created, and whether the newly created folder is an empty folder. These verifications can be implemented through code to verify the correctness of the folder adding step.

[0104] Specifically, one possible implementation method is: the inspection system calls the file system API to programmatically add a new folder in the root directory of the project management warehouse and name it "General Design". Then call the create folder interface of the file system API, pass in the warehouse path and folder name parameters, and perform the folder creation operation. The inspection system reads the properties of the newly added folder to verify that its path is correct and the folder is empty.

[0105] Similarly, the inspection system calls the API to add a folder named "Self-developed design tool quality" in the root directory of the process management warehouse. Then the file system API is called again to create the execution folder and verify the correctness of the folder. At this point, an empty folder with the specified name is added to both warehouses to prepare for subsequent use as a special inspection folder.

[0106] A11 builds a check tree according to the quality check folder, the general design quality folder, the self-developed design tool quality folder and the chip front-end design project hierarchy.

[0107] It should be noted that on the basis of using quality inspection folders to build the inspection tree, since a general design quality folder and a self-developed design tool quality folder are newly added in this solution, when building the inspection tree, these two newly added folders need to be included at the same time to build a more comprehensive inspection tree structure.

[0108] In the inspection tree, in addition to the nodes representing different levels of the design project and the corresponding quality inspection folders, two additional special folder nodes need to be added.

[0109] The first node is defined as "General Design Check". The folder contained in this node is the general design quality folder, which means that this node is used to execute the check content in the general specification folder.

[0110] The second node is defined as "Self-developed design tool inspection". This node contains the self-developed design tool quality folder, indicating that this node is used to execute the inspection content in the self-developed tool folder.

[0111] The two newly added folder nodes should be at the same level as the folder nodes representing the design project hierarchy, that is, added to the data structure of the inspection tree in parallel. They should not be added as child nodes of other nodes.

[0112] In the code logic for building the inspection tree, you need to add judgment conditions to determine the read folder path. If it belongs to a general design quality folder or a self-developed design tool quality folder, add it to the inspection tree as an independent special folder node. Otherwise, process it according to the hierarchical structure.

[0113] The inspection tree constructed in this way will include inspection nodes for the design project level, as well as inspection nodes for general specifications and self-developed tools, to achieve a comprehensive quality assurance system.

[0114] Specifically, one possible implementation method is: when constructing the inspection tree, if it is detected that the read folder path belongs to the general design quality folder, a node named "General Design Inspection" is created, and the folder path is used as the pointer attribute of the node. If it is detected that the read folder path belongs to the self-developed design tool quality folder, a node named "Self-developed Design Tool Inspection" is created, and the folder path is used as the pointer attribute. For other folder paths, ordinary hierarchical nodes are created according to the project hierarchy. The final inspection tree data structure will contain two types of special inspection nodes and other hierarchical nodes. Special inspection nodes contain pointer attributes pointing to general and self-developed tool quality folders. When the inspection is executed, the corresponding inspection folders can be called through these nodes to implement general and self-developed tool inspections.

[0115] A12 checks the general inspection items in the project management warehouse through the general design quality folder in the inspection tree; checks the self-developed design tools of the chip front-end design project through the self-developed design tool quality folder in the inspection tree.

[0116] It should be noted that, in this embodiment, when constructing the inspection tree, the general design quality folder and the self-developed tool folder are added to the tree as independent special inspection nodes.

[0117] The general design quality folder can contain check rule scripts for general design standards and specifications, such as checking PIN naming specifications, signal naming specifications, etc.

[0118] When executing the inspection process, the inspection system can access the general design quality folder node, call the folder pointer in the node, locate the actual general design quality folder, and load the specification inspection rules to perform a standard inspection on the document. At the same time, the inspection system accesses the self-developed tool inspection node, loads the inspection script in the self-developed tool folder, and performs quality inspection on the self-developed tools used in the chip design project.

[0119] The quality folder of the self-developed design tool can contain test cases and scripts for the functions, performance indicators, etc. of the self-developed design tool.

[0120] The inspection system loads the inspection script in the general design quality folder, parses the rules defined in the script, and traverses the documents in the project management warehouse. At the same time, the inspection system can assess the self-developed tools on a specific verification platform based on the use cases and scripts for the functions and performance indicators of the self-developed design tools, and judge whether the quality meets the standards.

[0121] With the help of two special inspection nodes, the general design quality folder and the self-developed design tool quality folder, general standard inspection and independent tool inspection can be carried out at the same time, with more comprehensive inspection coverage.

[0122] In this embodiment, due to an obvious limitation of the quality inspection mechanism in the prior art, that is, the scope of the inspection is limited to the quality assessment of the specific design task content, and cannot cover the inspection of general design standards and the quality inspection of the design tools independently developed by the project team, resulting in some general specifications and standards not being effectively implemented, resulting in design quality problems, and the risk that some hidden quality defects in the independently developed tools may affect the design results. In response to this problem, this embodiment proposes an improvement plan, which includes two key steps: the first is to add a general design quality folder to the project management warehouse to collect general specification standard documents; the second is to add a self-developed design tool quality folder to the process management warehouse to store the quality inspection scripts of the independently developed tools. Then, when constructing the inspection tree, the two newly added folders are also included in the tree structure to form a tree-shaped inspection system that includes general specification inspections and self-developed tool inspections. In this way, the review of general specifications and quality inspection of independent tools can be automatically triggered when the inspection is performed, which effectively solves the problem of limited inspection scope in the existing technology, realizes the comprehensive expansion of the scope of quality inspection, and expands the coverage of inspection from a single design task to general standards and independent development tools, providing complete and systematic quality assurance, fundamentally improving the quality of front-end design and reducing the risk of problematic designs entering back-end verification.

[0123] Based on the first and second embodiments of the present application, in the third embodiment of the present application, the same or similar contents as those in the first or second embodiment can be referred to the above description, and will not be described in detail later. The method provided in the first embodiment is further described in more detail below. Figure 4 and Figure 5 , are two other flow charts of the inspection method of the chip front-end design in the embodiments of the present application.

[0124] It should be noted that:

[0125] The inspection project file is used to define the specific quality inspection contents. The specific implementation method is to record the inspection contents in the form of script files.

[0126] If you use Python scripts to define the inspection content, each inspection item is represented by a function. The function name indicates the name of the inspection item, and the function body implements the specific analysis and evaluation process of the inspection item. A complete inspection project file will contain multiple inspection functions, covering different quality evaluation items such as code specification inspection, layout rule inspection, and timing constraint inspection. This method of defining each inspection content in the form of a function makes it very simple and convenient to add and modify inspection items. You only need to add a function or modify the function body, without any other code changes. At the same time, each inspection content also maintains sufficient independence.

[0127] The configuration file is used to manage the inspection contents in groups. This can be achieved by using a configuration file similar to JSON format to define each inspection group. The configuration file will contain multiple configuration segments, each of which represents an inspection group. The segments field can be used to specify which inspection contents the group contains. For example, a required inspection group is configured to include code specification and timing constraint checks, and an optional inspection group includes layout rule checks. Adding new groups or modifying group members can be achieved by modifying the configuration file without changing the code.

[0128] The command line parameter file is used to define the dynamic parameters that need to be input when executing the check. Its implementation method also uses a configuration file in a JSON format to define parameters. The file can contain an input_params section, and then list the name, format, and other information of each parameter that needs to be input. For example, define a top-level module name parameter module_name that needs to be input, and the type is a string. When the check is executed, the dynamic parameters that need to be input are obtained by parsing the file, and then the actual input value is obtained from the command line to configure the check behavior in real time. Compared with fixed check content, the introduction of command line parameter files achieves flexibility.

[0129] It is easy to understand that the specific implementation methods of the three files can be, but are not limited to, script files or configuration files. Different files can play their respective roles in the inspection process and jointly promote automated inspection. The implementation of the three is simple and practical, which is conducive to later maintenance and upgrades.

[0130] Correspondingly, it should be noted that the checking of the chip front-end design project according to the quality inspection folders at each level in the inspection tree may include the following steps, as shown in the figure:

[0131] A20 defines the inspection parameter information that the inspection project file needs to obtain from the command line according to the received command line parameters through the command line parameter file;

[0132] In this step, the inspection system needs to use the command line parameter file to define the dynamic or static parameters that need to be input when the inspection is executed. The inspection system can load and parse the command line parameter file through the parsing module. Multiple command line parameters are defined in the file, and each parameter has attributes such as name and format.

[0133] For example, if the parameter module_name is defined to input the name of the top-level module to be checked, the checking system will parse and obtain the command line parameter set. Based on the parameter attributes, it will generate command line prompt text, parameter specifications and other information.

[0134] Before executing the inspection, the inspection system needs to request command line parameter input from the user according to the defined prompts. After the user enters the parameters, the inspection system will call the command line reading interface to obtain the parameter value and verify whether the value conforms to the defined format specification. Then the inspection system will organize the parameter name and value, generate a command line parameter map, and mark which parameters need to be used in the inspection project file.

[0135] In this way, the command line parameter template definition is obtained by parsing the file, and then the value actually input by the user is obtained, thereby realizing flexible command line interaction.

[0136] A21 adds the acquired information to the inspection item file;

[0137] After obtaining the command line input parameters, the inspection system needs to add the parameter values ​​to the inspection project file in the quality inspection folder. The inspection system can parse the project file and identify the variable placeholders in the file, such as: module_name. For each placeholder variable, find the corresponding key value in the command line parameter map and insert it into the position. After the parsing and replacement is completed, the inspection project file with the command line parameters added is obtained. In this way, the inspection project file can be flexibly configured through the command line parameters and the inspection logic can be adjusted.

[0138] A22 divides the inspection items in the inspection item file after adding the inspection parameter information into different groups through the configuration file;

[0139] In this step, the inspection system needs to use a configuration file to group the inspection contents in the inspection project file.

[0140] First, the configuration file defines multiple inspection groups according to the user's preset rules. Each group specifies the inspection contents through fields. The inspection system parses the configuration file and builds a mapping table of inspection groups and inclusion relationships. Then the inspection project file is parsed to identify all inspection content functions. According to the mapping relationship, the inspection content function is added to the corresponding inspection group. Finally, the grouping results of different inspection groups and the included inspection contents are formed. The inspection system needs to verify whether the grouping results are accurate to avoid abnormalities.

[0141] In this way, the inspection contents can be flexibly grouped and managed through the configuration file, which is convenient for subsequent classification execution.

[0142] A23 checks the inspection item files of different groups according to the quality inspection folders at each level in the inspection tree.

[0143] In this step, the inspection system can traverse the constructed inspection tree and access the quality inspection folder of each node. For each quality inspection folder, load the grouping results and inspection project files. The inspection system reads the configured inspection group execution order and iterates each inspection group in turn. For the current inspection group, find the inspection content function list corresponding to the group. Then call the inspection content functions in the list one by one, execute the inspection logic, and obtain the inspection results. And process other inspection groups and other inspection folders in turn.

[0144] Through group configuration, different quality folders can be configured with different inspection combinations to achieve customized inspection.

[0145] Correspondingly, optional, such as Figure 4 As shown, in general, building a check tree based on the quality check folder, the general design quality folder, the self-developed design tool quality folder and the chip front-end design project hierarchy can also be achieved in the following ways:

[0146] A30 adds corresponding YAML files to the quality folder, the general design quality folder, and the self-developed design tool quality folder of the sub-project in the project repository;

[0147] It should be noted that, in this embodiment, the YAML file is a structured configuration file format, which uses spaces, indents and separators to organize data and has the advantages of being easy to read and convenient for version control.

[0148] In this step, the inspection system needs to process three types of quality folders in the project warehouse one by one: the quality folders of each sub-project in the project warehouse, the general design quality folder, and the self-developed tool quality folder. For each type of quality folder, the inspection system needs to use a Python script to call the YAML module to generate an independent YAML configuration file for the current folder.

[0149] Specifically, for the sub-project quality folder, the generated YAML file needs to include information such as the project name, project design stage, design priority, etc.; for the general specification folder, the generated YAML file needs to include information such as the industry specification name, specification version, etc.; for the self-developed tool folder, the generated YAML file needs to include information such as the tool name, version, and development team.

[0150] The YAML files corresponding to the three types of folders have different contents and are used to describe the unique information of each folder. The inspection system needs to develop different code logic for each type of folder and generate a YAML file in a custom format, which cannot be simply reused.

[0151] After the YAML file is generated, the inspection system needs to call the file writing interface of the operating system to write the YAML files corresponding to each folder into the corresponding folder.

[0152] To ensure correctness, after the file is written, the inspection system needs to verify that the YAML file size is not empty and the content is not empty. If the verification fails, you need to regenerate the YAML file and write it.

[0153] The inspection system needs to loop through all quality folders in the project repository, and execute independent YAML generation and writing processes one by one until independent YAML configuration files are successfully written into the quality folders of each sub-project, the general design quality folder, and the self-developed tool quality folder in the project repository.

[0154] In this way, there is a YAML file containing folder-specific information under each quality folder, providing basic configuration for subsequent customized checks.

[0155] A31 builds a check tree according to the quality check folder, the general design quality folder, the self-developed design tool quality folder and the chip front-end design project hierarchy after the YAML file is added;

[0156] It should be noted that in the check tree construction process of this step, since the previous step has added the corresponding YAML configuration files to each quality check folder in the project repository, these YAML files need to be loaded and parsed at the same time when building the check tree to further enrich the information of the check tree.

[0157] Specifically, before building the inspection tree, the inspection system needs to traverse all quality inspection folders in the warehouse and read the contents of the YAML configuration file in each folder.

[0158] For each YAML file, the inspection system uses the YAML parsing module to parse out the project information defined in the file, including project name, phase, priority, specification version, etc. This information can be mapped to the metadata of the corresponding node in the inspection tree.

[0159] After parsing is completed, the inspection system starts to build the inspection tree data structure, and also builds tree nodes based on the project hierarchy.

[0160] However, after building each tree node, the inspection system needs to find the project and folder information corresponding to the node from the previously parsed YAML information and store this information in the metadata of the node.

[0161] For example, a node represents the inspection of sub-project A. After the node is built, the inspection system needs to find the project information of sub-project A in the YAML parsing result, such as project name, priority, etc., and bind it to the metadata of the node.

[0162] The inspection system needs to perform this YAML parsing and metadata binding operation on each quality inspection folder in the warehouse, and bind the parsed project information to the corresponding inspection tree node.

[0163] After completion, each node in the constructed inspection tree contains not only the folder path, but also the project information associated with the folder parsed in the YAML file through metadata.

[0164] When performing subsequent inspections, the system can directly access the metadata from the node, obtain the configuration of the corresponding project, and implement dynamic customized inspections.

[0165] The introduction and parsing of YAML files further enriches the information content of the inspection tree itself, supports verification based on project configuration, and avoids over-generalized inspection solutions.

[0166] Accordingly, checking the chip front-end design project according to the quality inspection folders at each level in the inspection tree includes:

[0167] A32 divides different groups in the corresponding configuration file into different severity levels through the YAML file;

[0168] If the severity level of the group is higher than a preset severity level, the inspection items in the group are inspected, and the preset severity level changes dynamically according to different design stages of the chip front-end design project.

[0169] It should be noted that, in this embodiment, before performing the quality check, the inspection system needs to first load the independent YAML configuration file corresponding to each quality check folder in the inspection tree.

[0170] From the YAML file, the inspection system can parse the group information of the configuration files in the corresponding quality inspection folder, such as code inspection, timing inspection, layout inspection and other groups.

[0171] The preset severity level corresponding to each group can be parsed from the YAML file. For example, the preset severity level of code inspection is "high" and the preset severity level of timing inspection is "medium". The inspection system then extracts the mapping relationship between these groups and severity levels and stores them in memory or database.

[0172] When performing quality checks, the inspection system can read the severity level threshold of the current design stage. For example, in stage one, only high severity inspection contents are checked.

[0173] For each inspection group, the inspection system compares its preset severity level with the current threshold. If it is higher than or equal to the threshold, the inspection is performed, otherwise it is skipped.

[0174] When the design phase switches, the severity threshold can be adjusted to dynamically control which checks are executed. With the help of YAML files and configuration files, different groups can have different severity levels to avoid executing duplicate and non-critical checks.

[0175] In this embodiment, since the inspection tree structure in the prior art is relatively static and cannot support dynamic customized inspections based on real-time project configuration, this embodiment proposes a technical solution of adding a YAML file in the quality folder and loading and parsing the YAML file when building the inspection tree. This effectively solves the problems of insufficient inspection tree information and rigid inspection process in the prior art, and thus realizes an intelligent inspection tree system that supports dynamic configuration.

[0176] This embodiment enriches the amount of information in the traditional inspection tree by adding a YAML file to the quality folder, and synchronously parsing and binding the project data in the YAML file when building the inspection tree, so that the inspection tree nodes are transformed from only containing project level information to also containing project stage information. The intelligent inspection tree constructed in this way supports customized quality inspection processes based on the real-time progress configuration of each project. When the project priority and severity level change, the inspection content can be adjusted dynamically to avoid over-generalized inspection schemes. Compared with the simple and static inspection tree structure in the prior art, the technical means in this embodiment realizes an intelligent and dynamic inspection tree system, which effectively improves the flexibility and intelligence of quality inspection, avoids duplication and non-critical inspections, and can effectively save verification time and costs.

[0177] After the step of constructing a check tree according to the quality check folder, the general design quality folder, the self-developed design tool quality folder, and the chip front-end design project hierarchy, the following steps may also be performed:

[0178] Based on the first, second and third embodiments of the present application, in the fourth embodiment of the present application, the same or similar contents as those of the above-mentioned embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 6 and Figure 7 , are two other flow charts of the inspection method of the chip front-end design in the embodiments of the present application.

[0179] In order to achieve efficient and systematic violation management and output mechanism, this application also provides the following implementation methods:

[0180] A40 adds a violation manager to each level of the inspection tree;

[0181] It should be noted that, in this embodiment, the violation manager is a functional module in the inspection system. When the inspection process is executed, the violation manager is responsible for marking and recording files that violate the design specifications. For each hierarchical node of the inspection tree, the inspection system will associate a corresponding violation manager. When performing a design inspection of the hierarchical node, the violation manager will run automatically. When the inspection finds that a certain file violates the specification, the violation manager will mark the file. And generate a violation record for the file in the inspection report. If there are many files, the violation manager can also count the number of violations of each specification, an overview of the violation content, etc. In this way, the violations found can be clearly recorded and managed.

[0182] The specific implementation methods of the violation manager may include but are not limited to the following: Use machine learning technologies such as natural language processing to train models to identify illegal content and automatically learn new violation patterns. Alternatively, develop a violation manager using a programming language, with built-in violation checking logic such as keyword matching and syntax analysis. Alternatively, build a violation pattern database that contains the characteristics of various violations. Query the database to determine violations during inspection. New violation patterns can be quickly expanded.

[0183] A41 marks the sub-project file violating the project rule as a violation file through the violation manager, and stores the violation file in a preset database when the check is completed;

[0184] It should be noted that, in this embodiment, before checking the chip front-end design project according to the quality inspection folders at each level in the inspection tree, the violation manager can add a violation mark to the file name or file attributes of the violation file by calling the file processing interface. The marking method can be to add a violation suffix to the file name, or to add a custom violation tag to the file attributes, etc. In this way, the source file already contains the violation mark information. After the inspection is completed, the violation manager also needs to store the files that generate violations in a preset database for centralized management. The database can be a relational database or a document database, etc., which supports the storage of the file content itself. The violation manager uploads the content of the obtained violation file to the specified table of the database. And add the attribute tag of the violation, and can also append the inspection rule information that generates the violation. In this way, the violation files and violation information can be uniformly stored in the database, which is convenient for subsequent management optimization.

[0185] It is easy to understand that in this embodiment, since the quality inspection mechanism in the prior art has problems with violation processing and insufficient output, this embodiment proposes a technical solution of adding a violation manager to the node of the inspection tree and using the violation manager to mark and output illegal content, which effectively solves the problem of disorderly scattered illegal content, no centralized storage and feedback in the prior art, and thus realizes an efficient and systematic violation management and output mechanism.

[0186] This embodiment adds a violation manager to the inspection tree node, which can mark the violation content in real time during the inspection process; and uses the violation manager to output the marked violation content to the specified database, forming an orderly centralized storage, management and feedback mechanism for violation content, solving the problem of disorderly scattered violation content in the prior art. This innovative design of the node-embedded violation manager and the manager-based marking output solution realizes efficient and systematic violation processing and feedback, which is their common beneficial effect.

[0187] In order to present the inspection results intuitively, this application also provides the following implementation methods:

[0188] A50 converts the inspection result obtained based on the inspection tree into a data table;

[0189] In this embodiment, after the hierarchical inspection is completed, the inspection system obtains all the inspection reports generated. In order to facilitate managers to intuitively understand and process the inspection results, the report needs to be converted into a table format. The inspection system can set the report conversion configuration, such as defining the header, data fields, etc. Then traverse and parse the result content in the inspection report, extract the required fields, and fill them into the corresponding row and column cells of the table. The fields may include the name of the illegal design file, the level it is in, the name of the illegal inspection rule, the details of the rule, etc. At the same time, the inspection system needs to process the logical correspondence between the fields, such as filling the violation results of different rules of the same file into the same row, etc. After the filling is completed, a data table of the hierarchical inspection results is formed.

[0190] A51 outputs the data table to the user for review.

[0191] In this embodiment, after the table generation in step S301 is completed, the inspection system can call the output module to output the table content to the user in a specified manner.

[0192] The output can be written to a file, displayed on an interface, or transmitted to a specified server. After obtaining the table, the user can view the various details of the inspection results in the table. Further inspection results review and design problem location can be performed based on the rich result data. The user can sort and filter the result data in the table to focus more on the core issues. Finally, a design review report is formed to complete the evaluation and optimization of this round of design.

[0193] It is easy to understand that in this embodiment, since the quality inspection results in the prior art are scattered in the reports of each design level, it is impossible to intuitively present the correspondence of the inspection results, and it is impossible to perform horizontal inspection result analysis. Therefore, this embodiment proposes a technical solution for converting the scattered inspection results into a hierarchical data table and outputting it, which effectively solves the problem of scattered and non-visual inspection results in the prior art, and thus realizes a centralized and visualized inspection result presentation mechanism.

[0194] This embodiment converts the inspection results distributed at each design level into tabular data according to the corresponding relationship, so that managers can clearly understand the inspection results and intuitively see the relationship between the results of different levels, effectively solving the problem of scattered results and difficult comparison in the prior art. At the same time, the tabular results support users to cross-search, sort and analyze hierarchical results, so as to understand design problems in a comprehensive horizontal way. Converting and outputting inspection results into tables realizes the centralization and visualization of results, allowing managers to understand and analyze inspection results more efficiently.

[0195] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned chip front-end design inspection method, and can solve the technical problem of how to organically integrate the front-end design quality inspections scattered at different design levels to form a unified, automated inspection system. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the chip front-end design inspection method provided by the above-mentioned embodiment, and will not be repeated here.

[0196] The present application also provides a computer program product, including a computer program, which implements the steps of the chip front-end design inspection method as described above when executed by a processor.

[0197] The computer program product provided by the present application can solve the technical problem of how to organically integrate the front-end design quality checks scattered at different design levels to form a unified, automated inspection system. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as the beneficial effects of the chip front-end design inspection method provided by the above-mentioned embodiment, which will not be elaborated here.

[0198] The present application provides a chip front-end design inspection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the chip front-end design inspection method in the above-mentioned embodiment one.

[0199] Reference below Figure 8 , which shows a schematic diagram of the structure of an inspection device for chip front-end design suitable for implementing the embodiment of the present application. The inspection device for chip front-end design in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The inspection device of the chip front-end design shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0200] like Figure 8As shown, the inspection equipment for chip front-end design may include a processing device 1001 (such as a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to the program stored in a read-only memory (ROM: Read Only Memory) 1002 or the program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the inspection equipment for chip front-end design are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the chip front-end design inspection device to communicate wirelessly or wired with other devices to exchange data. Although the chip front-end design inspection device with various systems is shown in the figure, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or provided instead.

[0201] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0202] The chip front-end design inspection device provided by the present application adopts the chip front-end design inspection method in the above-mentioned embodiment, which can solve the technical problem of how to organically integrate the front-end design quality inspections scattered at different design levels to form a unified and automated inspection system. Compared with the prior art, the beneficial effects of the chip front-end design inspection device provided by the present application are the same as the beneficial effects of the chip front-end design inspection method provided by the above-mentioned embodiment, and the other technical features in the chip front-end design inspection device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0203] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0204] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0205] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A chip front-end design inspection method, characterized in that: The automated inspection method for the chip front-end design comprises: According to the chip front-end design project hierarchy, add corresponding environment variables to each sub-project file; Add a corresponding preset quality check folder under the hierarchical path represented by each of the environment variables; Building a check tree according to the quality check folder and the chip front-end design project hierarchy; The chip front-end design project is checked according to the quality check folders at each level in the check tree.

2. The method according to claim 1, characterized in that The step of constructing a check tree according to the quality check folder and the chip front-end design project hierarchy specifically includes: Collect all the quality inspection folders of the chip front-end design project; Different quality folders are used as branch nodes of the inspection tree, and an inspection tree is constructed according to the different quality folders. The inspection tree includes a hierarchical structure corresponding to the hierarchical structure of the chip front-end design project.

3. The method according to claim 2, characterized in that The different quality folders are used as branch nodes of the inspection tree, and the inspection tree is constructed according to the different quality folders, wherein the inspection tree includes the hierarchical structure steps corresponding to the hierarchical structure of the chip front-end design project, including: In the project management warehouse of the chip front-end design project, a general design quality folder is added, and in the process management warehouse of the chip front-end design project, a self-developed design tool quality folder is added; An inspection tree is constructed according to the quality inspection folder, the general design quality folder, the self-developed design tool quality folder and the chip front-end design project hierarchy.

4. The method according to claim 3, characterized in that After the step of constructing the inspection tree according to the quality inspection folder, the general design quality folder, the self-developed design tool quality folder and the chip front-end design project hierarchy, the step further includes: Checking the general inspection items in the project management warehouse through the general design quality folder in the inspection tree; The self-developed design tool of the chip front-end design project is checked through the self-developed design tool quality folder in the inspection tree.

5. The method according to claim 4, characterized in that The quality inspection folder specifically includes: inspection project files, configuration files and command line parameter files; The inspection item file is a file containing different inspection items; The checking of the chip front-end design project according to the quality check folders at each level in the check tree includes: Defining the inspection parameter information that the inspection project file needs to obtain from the command line according to the received command line parameters through the command line parameter file; Adding the acquired information to the inspection project file; Dividing the inspection items in the inspection item file after adding the inspection parameter information into different groups through the configuration file; The inspection item files of different groups are inspected according to the quality inspection folders at each level in the inspection tree.

6. The method according to claim 5, characterized in that The step of constructing a check tree according to the quality check folder, the general design quality folder, the self-developed design tool quality folder and the chip front-end design project hierarchy also includes: Add corresponding YAML files to the quality folder, the general design quality folder, and the self-developed design tool quality folder of the sub-project in the project repository; Building a check tree according to the quality check folder, the general design quality folder, the self-developed design tool quality folder and the chip front-end design project hierarchy after adding the YAML file; Accordingly, checking the chip front-end design project according to the quality inspection folders at each level in the inspection tree includes: Using the YAML file, different groups in the corresponding configuration file are divided into different severity levels; If the severity level of the group is higher than a preset severity level, the inspection items in the group are inspected, and the preset severity level changes dynamically according to different design stages of the chip front-end design project.

7. The method according to claim 2, characterized in that The different quality folders are used as branch nodes of the inspection tree, and the inspection tree is constructed according to the different quality folders. After the inspection tree includes the hierarchical structure corresponding to the hierarchical structure of the chip front-end design project, it also includes: adding a violation manager to each level of the inspection tree; The sub-project files violating the project rules are marked as violation files by the violation manager, and the violation files are stored in a preset database when the check is completed.

8. The method according to claim 1, characterized in that The step of checking the chip front-end design project according to the quality folders at each level in the inspection tree comprises: Converting the inspection results obtained based on the inspection tree into a data table; The data table is output to the user for review.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the automated inspection method for chip front-end design according to any one of claims 1 to 8 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the automated inspection method for chip front-end design according to any one of claims 1 to 8 are implemented.

Images