A PDK development method based on Aether tool

Abstract

The present invention discloses a PDK development method based on Aether tool, including the following steps: preparation stage: prepare device development documents, process design documents, and device model files. Create empty files in DRC and LVS formats; development stage: edit CDF parameters, design symbols, develop Callbacks, develop Pycells, write DRC files, and write LVS files; verification stage: Callback verification, Pycell verification, netlist verification, DRC with PDK basic package verification, LVS with basic package verification, and return to the development stage for correction if problems are found. Finally, write a usage document to integrate PDK. The present invention can accelerate PDK development, while reducing errors in PDK design, reducing lengthy and repetitive operations in the development process, improving design flexibility, and increasing the selectivity of designers' EDA tools, which is conducive to enhancing the security of the local EDA industry.

Description

Technical Field

[0001] The present invention relates to the field of PDK development, and in particular to a PDK development method based on an Aether tool. Background Art

[0002] EDA tools can greatly improve the efficiency of chip design, so that the cost of chip design can be controlled within a reasonable range. Semiconductor IP, which is closely tied to EDA tools, has flourished along with the advancement of EDA tools. The rapid development of the domestic downstream application industry has provided a broad space for the growth of domestic EDA companies. However, the reality is that process design components Cadence PDK and ADS PDK have become almost the only choices for downstream manufacturers. The lack of choice means that there is a huge risk value in the domestic industrial chain. This method, in conjunction with design companies, can form a benign closed loop for the entire domestic EDA market.

[0003] In addition, the current mainstream PDK development method is that PDK development engineers obtain process information from process parameter files obtained from the factory, and engineers in each part complete the work independently, lacking coordination between the parts. Especially in the callback function and layout development method of PDK, for syntax errors in the code and even the effects that the code is to achieve, the software can only call PDK after the basic framework of PDK is built, and then the correctness of the code is verified. The verification process is cumbersome and complicated. During this period, some bugs were found, which required personnel to repeatedly check the numerous possible parts in the PDK toolkit, and rely on software prompts and experience to determine where the problem might be, which consumed a lot of time and energy. For developers with relatively little experience, it is difficult to determine where the problem is. Summary of the invention

[0004] In order to solve the deficiencies in the prior art, the present invention proposes a PDK development method based on the Aether tool developed by HuaDa JiuTian. The core idea is that through the cooperation between PBQ software and Aether tools, the grammatical correctness of the code and the integrity of the function can be judged in real time; through the cooperation and verification of the PDK basic package and DRC and LVS files, when faced with a problem, it can quickly decide which part to modify to become the optimal solution. It has the advantage of an overall architecture, improves the correctness of the design, and greatly shortens the development cycle.

[0005] In addition, the present invention aims to accelerate PDK development, increase the optional options of IC designers for EDA tools, reduce errors in PDK design, and eliminate the lengthy operations of traditional PDK development verification.

[0006] In order to achieve the above object, the present invention adopts the following technical solutions:

[0007] A PDK development method based on Aether tool includes the following steps:

[0008] S1. Preparation stage:

[0009] Obtaining files to be processed, the files including: a symbol for designing a device thumbnail and a device development document for developing a callback function callback, a process design document for writing a design rule check DRC file, and a device model file for schematic simulation;

[0010] Create the callback folder, src folder, and TF folder according to the device development document.

[0011] Customize the library name and create a folder named after the library;

[0012] Create two rule files for use with Argus software, where the first rule file is used for design rule checking DRC, and the second rule file is used for layout schematic matching checking LVS;

[0013] S2, Development Stage:

[0014] S2-1: Create a new ePDK project in the PBQ software; set the path parameters of the ePDK project as follows:

[0015] Set the library path to the path of the folder named after the library created in S1.

[0016] Set the callback function callback path to the path of the callback folder created in S1,

[0017] Set the source code path to the path of the src folder created in S1.

[0018] Set the technical file path to the TF folder created in S1;

[0019] After the path parameters are set, the PBQ software will automatically create an ePDK project;

[0020] According to the device development document in S1, write display.drf and techfile.tf in the ePDK project.

[0021] S2-2: Based on the device development documents and process design documents in S1,

[0022] In the PBQ software, call the Aether tool and draw the device symbol in the Aether tool.

[0023] S2-3: copy the symbol obtained in S2-2 into two, respectively named spectre and sdl, for generating spectre netlist and sdl netlist respectively; wherein the spectre netlist is used for schematic simulation, and the sdl netlist is used for LVS;

[0024] S2-4: Based on the device development documents and process design documents in S1,

[0025] Select the device under the ePDK project in the PBQ software.

[0026] In the PBQ software, call the Aether tool and edit the device's CDF in the Aether tool to describe the parameters and parameter attributes of individual components and component libraries.

[0027] Add parameters and set properties for the device in the Aether tool;

[0028] S2-5: Based on the device development documents and process design documents in S1,

[0029] In the PBQ software, the callback function is developed using the Tcl language to avoid common errors;

[0030] S2-6: Use the Check Symbol function of the PBQ software to call the Aether tool, change the parameter value of the device in the Aether tool, and determine whether the effect of avoiding common errors described in S2-5 is achieved. If not, return to S2-5. If successful, go to S2-7;

[0031] S2-7: Based on the device development documents and process design documents in S1,

[0032] In the PBQ software, use Python language to develop the layout corresponding to the device

[0033] S2-8: Select the view layout function in the PBQ software, call the Aether tool, change the parameter value of the device in the Aether tool, and determine whether the layout meets the requirements of the device development document in S1. If not, return to S2-7. If so, proceed to the next step.

[0034] S2-9: Use the compilation function of PBQ software to compile the ePDK basic package;

[0035] S2-10: Using the Drstudio tool under Argus software,

[0036] Import the first rule file created in S1,

[0037] Writing a DRC code according to the process design document in S1 and storing it in the first rule file to form an updated first rule file;

[0038] The Drstudio tool has the function of judging whether the function selection meets the requirements. Use the above function to judge whether the function selection meets the requirements;

[0039] S2-11: Using the Drstudio tool under Argus software,

[0040] Import the second rule file created in S1,

[0041] According to the process design document in S1, the sdl netlist in S2-3 and the layout developed in S2-7, write LVS code and save it into the second rule file to form an updated second rule file;

[0042] The Drstudio tool has the function of judging whether the function selection meets the requirements. Use the above function to judge whether the function selection meets the requirements;

[0043] S3. Joint testing

[0044] S3-1: Load the PDK basic package obtained in S2-9 in the Aether tool, call in the device, perform netlist generation judgment, judge whether spectre outputs the spectre netlist normally, and whether the spectre netlist format meets the simulation requirements. If not, use the Tcl language to write the netlist function and return to step S2-4;

[0045] S3-2: Load the PDK basic package obtained in S2-9 in the Aether tool, call in the device, perform netlist generation judgment, and judge whether the sdl format netlist meets the netlist format required by the step S2-11. If not, use the tcl language to write the netlist function and return to step S2-4;

[0046] S3-3: Read the PDK basic package obtained in S2-9 in the Aether tool, build a test case, read the first rule file updated in S2-10 in the Argus software, perform a DRC test, and determine whether it meets the process document requirements in S1. If not, return to S2-10 for modification;

[0047] S3-4: Read the PDK basic package obtained in S2-9 in the Aether tool, build a test case, read the second rule file updated in S2-11 in the Argus software, perform LVS test, and determine whether it meets the process document requirements in S1. If not, return to S2-11 for modification;

[0048] S4: Put the following four parts into the same file directory to form a complete PDK package:

[0049] The device model file obtained in S1,

[0050] The PDK base package obtained in S2-9,

[0051] The first rule file updated in S2-10 is used as a DRC file;

[0052] The second rule file updated in S2-11 is used as the LVS file.

[0053] Preferably, in S2-5, after developing the function corresponding to the callback, the following steps are further included:

[0054] Use the compilation function of the PBQ software to determine whether there are any syntax errors. If there are any errors, they can be modified in the PBQ tool. If the compilation passes, enter S2-6.

[0055] Preferably, in S2-7, after developing the layout corresponding to the device, the following steps are further included:

[0056] Use the compilation function of the PBQ software to determine whether there are any syntax errors. If there are any errors, they can be modified in the PBQ software. If the compilation passes, enter S2-8.

[0057] Preferably, after S4, the following steps are also included:

[0058] S5: Write PDK usage documentation, LVS usage documentation, and DRC usage documentation.

[0059] The present invention has the following beneficial effects: through a standardized method, the errors in the PDK toolkit development process are reduced, the functional integrity is verified in real time, and the verification efficiency in the development process can be improved. At the same time, the verification method is combined, and when faced with a problem, it can quickly decide which part to modify as the optimal solution. It can increase the options of EDA tool IP on the market and reduce IC design costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 Flowchart of the present invention

[0061] Figure 2 The flowchart of the function of judging whether to write a netlist in the present invention DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present invention. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the invention claimed for protection, but only represents the selected embodiments of the present invention. In this application, when some of the known technologies or conventional technical means in the field need to be applied, the applicant may not specifically explain in the text what kind of technical means the known technology or / and conventional technical means are, but it cannot be considered that the application does not comply with the third paragraph of Article 26 of the Patent Law because the technical means are not specifically disclosed in the text.

[0063] Example: Figure 1 As shown, a PDK development method under the EDA tool Aether includes:

[0064] S1. Preparation stage:

[0065] Obtaining files to be processed from the factory, the files including: a symbol for designing a device thumbnail and a device development document for developing a callback function callback, a process design document for writing a design rule check DRC file, and a device model file for schematic simulation;

[0066] Prepare documents, including device development documents and process design documents;

[0067] Create the callback folder, src folder, and TF folder according to the device development document.

[0068] Customize the device library name and create a folder named after the device library name. The library folder name determines the device library name to which the device belongs when the PDK base package compiled by the PBQ software is imported into the Aether tool to call the device. Subsequent development cannot be changed. For example,

[0069] T_NPA25_001_v1.0 means version 001 of T's 0.25-micron GaN process device library. All created devices will be stored in the T_NPA25_001_v1.0 device library.

[0070] Create two rule files for use with Argus software, where the first rule file is used for design rule check DRC, and the second rule file is used for layout schematic matching check LVS, for example, named T_NPA25_drc_v1.0.rule and T_NPA25_lvs_v1.0.rule;

[0071] S2, Development Stage:

[0072] S2-1: Create a new ePDK project in the PBQ software; set the path parameters of the ePDK project as follows:

[0073] Set the library path to the path of the folder named after the library created in S1.

[0074] Set the callback function callback path to the path of the callback folder created in S1,

[0075] Set the source code path to the path of the src folder created in S1.

[0076] Set the technical file path to the TF folder created in S1;

[0077] After the path parameters are set, the PBQ software will automatically create an ePDK project;

[0078] According to the device development document in S1, write display.drf and techfile.tf in the ePDK project. display.drf and techfile.tf determine the display properties of the layout. display.drf is used to display the display shape and color of each defined layer. techfile.tf is used to define the name of each layer and give each layer a unique number.

[0079] S2-2: Based on the device development documents and process design documents in S1,

[0080] In the PBQ software, call the Aether tool and draw the device symbol in the Aether tool.

[0081] S2-3: copy the symbol obtained in S2-2 into two, respectively named spectre and sdl, for generating spectre netlist and sdl netlist respectively; wherein the spectre netlist is used for schematic simulation, and the sdl netlist is used for LVS;

[0082] S2-4: Based on the device development documents and process design documents in S1,

[0083] Select the device under the ePDK project in the PBQ software.

[0084] In the PBQ software, call the Aether tool and edit the device's CDF in the Aether tool to describe the parameters and parameter attributes of individual components and component libraries.

[0085] Add parameters and set properties for the device in the Aether tool;

[0086] S2-5: Based on the device development documents and process design documents in S1,

[0087] In the PBQ software, the callback function is developed using the Tcl language to avoid common errors;

[0088] Use the compilation function of the PBQ software to determine whether there are grammatical errors. If there are errors, they can be corrected in the PBQ tool. If the compilation passes, enter S2-6

[0089] S2-6: Use the check symbol function of the PBQ software to call the Aether tool, change the parameter value of the device in the Aether tool, and determine whether the effect of avoiding common errors described in S2-5 is achieved. If not, return to S2-5. If successful, go to S2-7;

[0090] S2-7: Based on the device development documents and process design documents in S1,

[0091] In the PBQ software, use Python language to develop the layout corresponding to the device

[0092] Use the compilation function of the PBQ software to determine whether there are grammatical errors. If there are errors, they can be corrected in the PBQ tool. If the compilation passes, enter S2-8

[0093] S2-8: Select the view layout function in the PBQ software, call the Aether tool, change the parameter value of the device in the Aether tool, and determine whether the layout meets the requirements of the device development document in S1. If not, return to S2-7. If so, proceed to the next step.

[0094] S2-9: Use the compilation function of PBQ software to compile the ePDK basic package;

[0095] S2-10: Using the Drstudio tool under Argus software,

[0096] Import the first rule file created in S1,

[0097] Writing a DRC code according to the process design document in S1 and storing it in the first rule file to form an updated first rule file;

[0098] The Drstudio tool has the function of judging whether the function selection meets the requirements. Use the above function to judge whether the function selection meets the requirements;

[0099] S2-11: Using the Drstudio tool under Argus software,

[0100] Import the second rule file created in S1,

[0101] According to the process design document in S1, the sdl netlist in S2-3 and the layout developed in S2-7, write LVS code and save it into the second rule file to form an updated second rule file;

[0102] The Drstudio tool has the function of judging whether the function selection meets the requirements. Use the above function to judge whether the function selection meets the requirements;

[0103] S3: Joint Testing

[0104] S3-1: Load the ePDK basic package obtained in S2-9 in the Aether tool, call in the device, perform netlist generation judgment, judge whether spectre outputs the spectre netlist normally, and whether the spectre netlist format meets the simulation requirements. If not, use the tcl language to write the netlist function and return to step S2-4;

[0105] S3-2: Load the ePDK basic package obtained in S2-9 in the Aether tool, call in the device, perform netlist generation judgment, and judge whether the sdl format netlist meets the netlist format required by the step S2-11. If not, use the tcl language to write the netlist function and return to step S2-4;

[0106] S3-3: Read the ePDK basic package obtained in S2-9 in the Aether tool, build a test case, read the first rule file updated in S2-10 in the Argus software, perform a DRC test, and determine whether it meets the process document requirements in S1. If not, return to S2-10 for modification;

[0107] S3-4: Read the ePDK basic package obtained in S2-9 in the Aether tool, build a test case, read the second rule file updated in S2-11 in the Argus software, perform LVS test, and determine whether it meets the process document requirements in S1. If not, return to S2-11 for modification;

[0108] S4: Integrate the following four parts:

[0109] The device model file obtained in S1,

[0110] The PDK base package obtained in S2-9,

[0111] The first rule file updated in S2-10 is used as a DRC file;

[0112] The second rule file updated in S2-11 is used as the LVS file.

[0113] And write PDK usage documentation, DRC usage documentation, and LVS usage documentation to form a complete PDK package.

[0114] The PDK design and development method includes the following steps and methods:

[0115] 1. Device Model; 2. Symbol & View; 3. CDF (Component Description Format, component description format) & Callback; 4. Pcell (Parameterized Cell, parameterized cell); 5. Technology File (Technology File) PVRule (physical verification rule) file; 6. PDK verification; The content of PDK includes design rule file, electrical rule file, layout hierarchy definition file, SPICE simulation model, device layout and device custom parameters, etc. The present invention improves steps 3, 4, and 6, which is convenient for PDK developers, improves the standardization and convenience of the development process, saves development time, and improves accuracy.

[0116] Some abbreviations used in this application are as follows:

[0117] PDK: Process Design Kit

[0118] DRC: Design Rule Check

[0119] LVS: Layout Versus Schematics

[0120] Pcell: Parameterized Cell

[0121] CDF: Component Description Format

[0122] Aether: Aether is a complete mixed-signal IC design solution that includes tools such as Design Manager, Technology Manager, Schematic Editor, MDE, Layout Editor, and Schematic Driven Layout (SDL).

[0123] Argus: It is a software that collaborates with Aether, a full-custom IC design platform, and Skipper, a chip finishing layout integration platform, to help IC designers perform DRC (design rule check), LVS (layout-schematic matching check), ERC (electrical rule check), and LVL (layout-to-layout check).

[0124] PBQ: PBQ is a solution for developing various PDKs and ensuring PDK quality. Its main purpose is to accelerate PDK development and manage PDK projects efficiently, so that your design can be smooth and fast. It supports various PDK project management, technical file editing, code building and other functional compilation and automated quality assurance.

[0125] ePDK: short for Empyrean PDK, which means HuaDa Empyrean process design kit.

[0126] The above embodiments only list preferred specific technical solutions and technical means, and do not exclude that within the scope of the claims of the present invention, there are other alternative forms of equivalent technical means that can solve the technical problem, which should also be understood as the content required to be protected by the present invention.

Claims

1. A PDK development method based on Aether tool, characterized in that: The following steps are involved: S1. Preparation stage: Obtaining files to be processed, the files including: a symbol for designing a device thumbnail and a device development document for developing a callback function callback, a process design document for writing a design rule check DRC file, and a device model file for schematic simulation; Create the callback folder, src folder, and TF folder according to the device development document. Customize the library name and create a folder named after the library; Create two rule files for use with Argus software, where the first rule file is used for design rule checking DRC, and the second rule file is used for layout schematic matching checking LVS; S2, Development Phase: S2-1: Create a new ePDK project in the PBQ software; set the path parameters of the ePDK project as follows: Set the library path to the path of the folder named after the library created in S1. Set the callback function callback path to the path of the callback folder created in S1, Set the source code path to the path of the src folder created in S1. Set the technical file path to the TF folder created in S1; After the path parameters are set, the PBQ software will automatically create an ePDK project; According to the device development document in S1, write display.drf and techfile.tf in the ePDK project; S2-2: Based on the device development documents and process design documents in S1, In the PBQ software, call the Aether tool and draw the device symbol in the Aether tool; S2-3: copy the symbol obtained in S2-2 into two, named spectre and sdl respectively, spectre is used to generate a spectre netlist, and sdl is used to generate an sdl netlist; wherein the spectre netlist is used for schematic simulation, and the sdl netlist is used for LVS; S2-4: Based on the device development documents and process design documents in S1, Select the device under the ePDK project in the PBQ software. In the PBQ software, call the Aether tool and edit the device's CDF in the Aether tool to describe the parameters and parameter attributes of individual components and component libraries; Add parameters and set properties for the device in the Aether tool; S2-5: Based on the device development documents and process design documents in S1, In the PBQ software, the callback function is developed using the Tcl language to avoid common errors; S2-6: Use the Check Symbol function of the PBQ software to call the Aether tool, change the parameter value of the device in the Aether tool, and determine whether the effect of avoiding common errors described in S2-5 is achieved. If not, return to S2-5. If successful, go to S2-7; S2-7: Based on the device development documents and process design documents in S1, In the PBQ software, use Python language to develop the layout corresponding to the device; S2-8: Select the view layout function in the PBQ software, call the Aether tool, change the parameter value of the device in the Aether tool, and determine whether the layout meets the requirements of the device development document in S1. If not, return to S2-7. If so, proceed to the next step. S2-9: Use the compilation function of PBQ software to compile the ePDK basic package; S2-10: Using the Drstudio tool under Argus software, Import the first rule file created in S1, Writing a DRC code according to the process design document in S1 and storing it in the first rule file to form an updated first rule file; The Drstudio tool has the function of judging whether the function selection meets the requirements. Use the above function to judge whether the function selection meets the requirements; S2-11: Using the Drstudio tool under Argus software, Import the second rule file created in S1, According to the process design document in S1, the sdl netlist in S2-3 and the layout developed in S2-7, write LVS code and save it into the second rule file to form an updated second rule file; The Drstudio tool has the function of judging whether the function selection meets the requirements. Use the above function to judge whether the function selection meets the requirements; S3. Joint testing: S3-1: Load the PDK basic package obtained in S2-9 in the Aether tool, call in the device, perform netlist generation judgment, judge whether spectre outputs the spectre netlist normally, and whether the spectre netlist format meets the simulation requirements. If not, use the Tcl language to write the netlist function and return to step S2-4; S3-2: Load the PDK basic package obtained in S2-9 in the Aether tool, call in the device, perform netlist generation judgment, and judge whether the sdl format netlist meets the netlist format required by the step S2-11. If not, use the tcl language to write the netlist function and return to step S2-4; S3-3: Read the PDK basic package obtained in S2-9 in the Aether tool, build a test case, read the first rule file updated in S2-10 in the Argus software, perform a DRC test, and determine whether it meets the requirements of the process design document in S1. If not, return to S2-10 for modification; S3-4: Read the PDK basic package obtained in S2-9 in the Aether tool, build a test case, read the second rule file updated in S2-11 in the Argus software, perform LVS test, and determine whether it meets the requirements of the process design document in S1. If not, return to S2-11 for modification; S4. Put the following four parts into the same file directory to form a complete PDK package: The device model file obtained in S1, The PDK base package obtained in S2-9, The first rule file updated in S2-10 is used as a DRC file; The second rule file updated in S2-11 is used as the LVS file.

2. A PDK development method based on Aether tool as claimed in claim 1, characterized in that: In S2-5, after developing the function corresponding to the callback, the following steps are also included: Use the compilation function of the PBQ software to determine whether there are any syntax errors. If there are any errors, they can be modified in the PBQ tool. If the compilation passes, enter S2-6.

3. A PDK development method based on Aether tool as claimed in claim 2, characterized in that: In the S2-7, after the layout corresponding to the device is developed, the following steps are also included: Use the compilation function of the PBQ software to determine whether there are any syntax errors. If there are any errors, they can be modified in the PBQ software. If the compilation is successful, enter S2-8.

4. A PDK development method based on Aether tool as claimed in claim 3, characterized in that: After S4, the following steps are also included: S5. Write the PDK usage documentation, LVS usage documentation, and DRC usage documentation respectively.

Images