A Method for Optimizing the SOC Development Process

Abstract

The present invention discloses an SOC development process, which is characterized by including: start stage: timeline and architecture preparation; execution stage: generating module files and developing UVM test cases; regression stage: developing templates and chip constraint conditions, netlist generation and convergence requirement judgment; final stage: completing STA, LVS, DRC, LEC, timing, IR Drop and physical inspections and conducting test judgments. The present invention provides an SOC development process that reduces mistakes in the chip design process, improves the success rate of tape-out and shortens the chip development cycle.

Description

Technical Field

[0001] The present invention relates to the field of integrated circuit manufacturing, and particularly to a method for optimizing the SOC development process. Background Art

[0002] At present, with the continuous progress of integrated circuit processes at home and abroad and the increasing demand in the IC market, the SOC technology centered on IP core reuse and software-hardware co-design has become a hot topic in the industry and has also achieved significant achievements. More and more SOC products are applied to various industries, such as automotive electronics, industrial control, and optical communication. Functions originally implemented by multiple chips can be integrated into a single chip through the SOC design method, saving costs, chip area, power consumption, etc. In addition, one of its characteristics is to reduce mistakes in the chip design process and improve the success rate of tape-out through a standardized method.

[0003] The second characteristic, the IP reuse technology, also shortens the chip development cycle. Most IPs are verified and mature modules that can be directly added to the SOC chip, reducing the error rate. Therefore, SOC design can utilize the design achievements accumulated in the early stage to accelerate the IC design process and alleviate the current situation of supply falling short of demand in the IC market.

[0004] The existing SOC chip design process is mainly divided into the following parts: IP development stage, IP verification stage, SOC development stage, SOC simulation stage, FPGA verification stage, synthesis stage, and physical design stage. Each stage involves different EDA tools. Each stage is independently developed and run by each team, and the handover and inspection between processes are done manually.

[0005] Currently, this development method has the following disadvantages: In the chip development process, especially when some bugs are found in the middle and late stages, a large number of personnel are still required to invest in the entire project development, and the cycle of the entire serial structure is very long. There is a lack of standardized management, and the integrity and standardization of documents are difficult to guarantee.

[0006] The core idea of the SOC design method proposed in this application is to standardize the design and development process of reusing IP cores. The design of reusing IP cores connects all IP modules together through a bus, reducing the difficulty of system design; the development standardization improves the correctness and timeliness of the design through process standardization and document standardization. Summary of the Invention

[0007] In order to overcome the problem of the long IC design cycle in the prior art, the present invention proposes a method for optimizing the SOC development process that reduces mistakes in the chip design process, improves the success rate of tape-out, and shortens the chip development cycle.

[0008] To achieve the above object, the present invention adopts the following technical solutions:

[0009] The technical solution adopted by the present invention to solve its technical problems is: an SOC development process optimization method, including:

[0010] Start stage: Prepare project files;

[0011] Execution stage: Generate module files and develop UVM test cases;

[0012] Regression stage: Develop constraints for templates and chips, generate netlists and judge convergence requirements;

[0013] Final stage: Complete STA, LVS, DRC, LEC, timing, IR Drop and physical checks and conduct test judgments.

[0014] Preferably, the start stage includes:

[0015] First, conduct project preparation, and the project preparation content includes the clock tree and architecture;

[0016] Then, generate preparation documents and technology library files, prepare general chip information of the main design files, and conduct main preparations for the UVM environment, behavioral modules, and basic verification test cases.

[0017] Preferably, the process of generating module files in the execution stage includes two stages. The process of the first stage includes: According to the preparation documents and technology library files in the start stage, complete the module files for the physical design process and the module files for the synthesis process.

[0018] The process of the second stage includes the following steps:

[0019] a1: According to the general chip information of the main design files in the start stage, complete the module files for the design process;

[0020] a2: Perform RTL coding for each module and complete the detection and stable version;

[0021] a3: Judge whether the RTL coding is completed. If completed, enter the functional debugging step; if not completed, return to step a2.

[0022] Preferably, the development of UVM test cases includes the following steps:

[0023] b1: Generate files for testing functions according to the main preparation files of the UVM environment, behavioral modules, and basic verification test cases;

[0024] b2: Develop UVM test cases using the test chip module;

[0025] b3: Determine whether the verification design is completed. If it is completed, cooperate with the functional debugging to meet the convergence requirements; if not, return to step b2.

[0026] Preferably, the functional debugging step includes the following steps: Cooperate with the functional debugging to meet the convergence requirements.

[0027] Preferably, the regression stage includes the following steps:

[0028] c1: Develop the constraints (SYN, DFT, STA) of the module and the chip according to the module files in the physical design process and the module files in the synthesis process;

[0029] c2: Determine whether a netlist can be generated. If not, return to step c1; if so, proceed to step c3 and also cooperate with the netlist debugging to meet the convergence requirements;

[0030] c3: PNR, parasitic parameter extraction, and complete the post-simulation netlist;

[0031] c4: Determine whether a post-simulation netlist can be generated. If not, return to step c3; if so, cooperate with the post-simulation netlist debugging to meet the convergence requirements.

[0032] Preferably, the final stage includes the following steps:

[0033] d1: After the post-simulation netlist can be generated, start the next step;

[0034] d2: Complete STA, LVS, DRC, LEC, timing, IR Drop, and physical checks;

[0035] d3: Determine whether the boundary condition check passes. If it passes, end; if not, start the next step:

[0036] d4: Perform the ECO progress and then return to step d2.

[0037] Preferably, the final stage also includes a test judgment process, and the specific steps are as follows:

[0038] e1: After cooperating with the post-simulation netlist debugging to meet the convergence requirements, start the next step;

[0039] e2: Determine whether the regression test passes. If it passes, end; if not, return to step e1.

[0040] Preferably, the final stage also includes a test judgment process, and the specific steps are as follows:

[0041] f1: After cooperating with the functional debugging to meet the convergence requirements, start the next step;

[0042] f2: Determine whether the regression test passes. If it passes, end; if not, return to step f1.

[0043] Preferably, the last stage further includes a test judgment process, and the specific steps are as follows:

[0044] g1: Cooperate with the netlist debugging, and start the next step after meeting the convergence requirements;

[0045] g2: Determine whether the regression test passes. If it passes, end; if not, return to step g1.

[0046] Therefore, the present invention has the following beneficial effects: By means of a standardized method, mistakes in the chip design process are reduced, and the success rate of tape-out is improved. The IP reuse technology also shortens the chip development cycle. Most IPs are verified and formed modules, which can be directly added to the SoC chip, thus reducing the error rate. Therefore, SoC design can utilize the design achievements accumulated in the early stage to accelerate the IC design process and alleviate the current situation of supply falling short of demand in the IC market. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 It is a flow chart of the present invention

[0048] Figure 2 It is a flow chart of the constraint conditions of a physical development module and a chip of the present invention

[0049] Figure 3 It is a flow chart of the constraint conditions of a synthesis / static analysis development module and a chip of the present invention

[0050] Figure 4 It is a flow chart of a PNR, parasitic parameter extraction and post-simulation netlist of the present invention

[0051] Figure 5 It is a flow chart of completing STA, LVS, DRC, LEC, timing, IR Drop and physical inspection of the present invention

[0052] Figure 6 It is a flow chart of cooperating with function debugging of the present invention

[0053] Figure 7 It is a flow chart of cooperating with netlist debugging of the present invention

[0054] Figure 8 It is a flow chart of cooperating with post-simulation netlist debugging of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0055] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all of them. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely represents the selected embodiments of the present invention. In this application, when certain well-known technologies or conventional technical means in the art need to be applied, the applicant may not specifically elaborate in the text what kind of technical means the well-known technology or / and conventional technical means is, but it cannot be considered that this application does not meet the requirements of Paragraph 3, Article 26 of the Patent Law just because the technical means is not specifically disclosed in the text.

[0056] Example: As Figure 1 shown, an SOC development process optimization method includes:

[0057] Start stage: Project file preparation;

[0058] First, project preparation is carried out. The content of project preparation includes the clock tree and architecture;

[0059] Project preparation includes the following steps: First, define the chip pin names; the AC timing parameters of each pin, and then complete the project architecture and individual sub-modules; then complete the project control registration; then complete the project verification function list; finally, organize it into a complete project schedule; and allocate the workload to each owner.

[0060] After project preparation is completed, prepare documents and technology library files, prepare the general information of the chip for the main design files, and conduct the main preparations for the UVM environment, behavioral modules, and basic verification test cases.

[0061] Execution stage: Generate module files and develop UVM test cases;

[0062] The process of generating module files includes two stages:

[0063] The process of the first stage includes: According to the preparation documents and technology library files in the start stage, complete the module files for the physical design process. Complete the module files for the synthesis process.

[0064] The process of the second stage includes the following steps:

[0065] a1: Complete the module files for the design process based on the general chip information in the main design document in the start-up phase. The specific process is as follows: First, complete the functions of the sub-modules according to the port design prompts, then complete the sub-module registration list in the design prompts, then complete the sub-module diagrams in the design document to clearly describe the module functions, and finally complete the detailed sub-modules in the design specification document.

[0066] a2: Perform RTL coding for each module and complete the detection and stable versions.

[0067] a3: Determine whether the RTL coding is completed. If it is completed, cooperate with functional debugging to meet the convergence requirements. If it is not completed, return to step a2.

[0068] Developing UVM test cases includes the following steps:

[0069] b1: Generate functional files for testing based on the main preparation files of the UVM environment, behavioral modules, and basic verification test cases.

[0070] b2: Develop UVM test cases using the test chip module.

[0071] b3: Determine whether the verification design is completed. If it is completed, enter the functional debugging step. Otherwise, return to step b2.

[0072] The functional debugging steps in step b3 and step a3 include the following steps: Cooperate with functional debugging to meet the convergence requirements. The functional debugging steps in step b3 and step a3 are run separately and independently of each other. The specific process of cooperating with functional debugging is as follows: As Figure 6 shown, first perform RTL regression verification, and finally perform new function and code testing.

[0073] Regression phase: Develop the constraints of the template and the chip, generate the netlist, and judge the convergence requirements. Specifically, it includes the following steps:

[0074] c1: Develop the constraints (SYN, DFT, STA) of the module and the chip based on the module files in the physical design process and the module files in the synthesis process. The specific process of developing the constraints of the module and the chip based on the module files in the synthesis process is as follows: As Figure 2 shown, first complete the script constraint code, then correct the errors violating the rules, then complete the implantation of the DFT module, and finally correct the errors violating the rules.

[0075] The specific process of developing the constraints of the module and the chip based on the module files in the physical design process is as follows: As Figure 3 shown, first complete the physical design script code, then check the warnings and fix the errors, then complete the entire physical design under limited conditions, and finally verify the CTS constraint conditions.

[0076] c2: Determine whether a netlist can be generated. If not, return to step c1; if so, proceed to step c3 and also perform netlist debugging to meet the convergence requirements. The specific process of netlist debugging is as follows: As Figure 7 shown, first perform gate-level and RTL regression verification, and finally perform functional and timing debugging.

[0077] c3: After PNR, parasitic parameter extraction, and post-simulation netlist completion; the specific process is as follows: As Figure 4 shown, first initialize PNR, then enter the CTS process, then enter the post-simulation CTS process, and finally enter the placement and routing process.

[0078] c4: Determine whether a post-simulation netlist can be generated. If not, return to step c3; if so, perform post-simulation netlist debugging to meet the convergence requirements. The specific process of post-simulation netlist debugging is as follows: As Figure 8 shown, first perform gate-level and RTL regression verification, then functional and timing debugging, and finally perform AMS testing based on the gate-level netlist.

[0079] Final stage: Complete STA, LVS, DRC, LEC, timing, IR Drop, and physical checks and perform test judgment. Specifically, it includes the following steps:

[0080] d1: After the post-simulation netlist can be generated, start the next step;

[0081] d2: Complete STA, LVS, DRC, LEC, timing, IR Drop, and physical checks; the specific process of step d2 is as follows: As Figure 5 shown, first create an LEC file, perform LEC checks, then export GDS and netlist files, perform LVS checks, then export the MMMC SDC file, perform STA verification, then perform checks according to rules such as DRC and ERC, then perform power consumption checks, and then end step d2. After the power consumption checks are completed, an ECO process will be performed.

[0082] d3: Determine whether the boundary condition check passes. If it passes, end; if not, start the next step:

[0083] d4: Perform the ECO process and then return to step d2. According to the specific situation, when engineering modifications are required, perform the ECO step; when engineering modifications are not required, the ECO step can also be skipped and directly return to step d2.

[0084] The final stage also includes three test judgment processes, respectively judging whether the regression tests for post-simulation netlist debugging, functional debugging, and netlist debugging pass.

[0085] The specific steps for judging whether the regression test for post-simulation netlist debugging passes are as follows:

[0086] e1: After post-simulation netlist debugging and meeting the convergence requirement, start the next step;

[0087] e2: In the case of regression, make a pass judgment. If it passes, end; if not, return to step e1.

[0088] The specific steps for judging whether the regression test for functional debugging passes are as follows:

[0089] f1: After functional debugging and meeting the convergence requirement, start the next step;

[0090] f2: In the case of regression, make a pass judgment. If it passes, end; if not, return to step f1.

[0091] The specific steps for judging whether the regression test for netlist debugging passes are as follows:

[0092] g1: After netlist debugging and meeting the convergence requirement, start the next step;

[0093] g2: In the case of regression, make a pass judgment. If it passes, end; if not, return to step g1.

[0094] In the SOC design and development process, the following 7 major steps and methods are included

[0095] 1. Chip packaging seal information specification; 2. Project reference template; 3. Project plan template; 4. Layout-related inspection items; 5. Process SOP; 6. Chip development output file template; 7. Project stage management template. The present invention improves the 5th step among them, and then in cooperation with the existing other 6 processes in SOC design and development, the SOC design and development can be completed, achieving the standardization and completeness of the design process, saving design time and increasing the success rate of tape-out.

[0096] Among them, the project reference template and the chip development output file template have the following files:

[0097] 1. Market Requirement Document, 2. Debugging Report, 3. Project Plan Document, 4. EVT-DVT Report Format, 5. Packaging Solution, 6. System Requirement Document (SRD), 7. FT Test Plan (for power chips), 8. Technical Feasibility Report, 9. Reliability Report, 10. Simulation PDR-CDR-FDR Review Report, 11. MVT Report, 12. Design Hints, 13. Process Flow Chart, 14. Final Layout Design GDS Report, 15. Process SOP, 16. Record Sheet, 17. Procurement and Stock Preparation Plan, 18. PCB&EVK Schematic Diagram, 19. Procurement and Stock Preparation Plan, 20. Encapsulation Solution, 21. Test Specification.

[0098] In Step 5, the process SOP in the process includes the digital front-end design specification and the digital front-end verification specification. The following is an example to illustrate the contents included in the digital front-end design specification and the digital front-end verification specification:

[0099] I. Digital Front-End Design Specification:

[0100] 1. Writing Specification, 2. Naming Specification, 3. Code Comment Specification, 4. Asynchronous Logic Processing, 4.1. Asynchronous Reset Synchronization, 4.2. Asynchronous Reset Synchronization in Multiple Clock Domains, 4.3. Asynchronous Logic Cross-Domain Rule, 5. Standard Logic Unit.

[0101] The module naming specification of the digital front-end design specification is as follows:

[0102] The first level (hier 1) is fixed as the digital top layer ending with _digtop; the second level (hier 2) is the top layer at the sub-module level, named differently according to different projects; the third level and above (≥hier3) are the lower-level modules inside the sub-module. Append the second-level sub-module name after the project name, separate it from the project name with an underscore (_), and then name the sub-module above the third level with the current module function. The IP module naming uses xy and the function as the prefix, separated by an underscore (_), for example: xy_i2c_*.v.

[0103] II. Digital Front-End Verification Specification

[0104] 1. SystemVerilog (SystemVerilog is a simulation language) code specification: (1) Writing specification, (2) Naming specification, (3) Code implementation, (4) Code comment;

[0105] 2. Basic class files;

[0106] 3. Standard Modeling Language (UML): (1) Use case diagram, (2) Class diagram, (3) Sequence diagram, (4) Communication diagram, (5) State diagram, (6) Activity diagram, (7) Package diagram;

[0107] 4. Appendix.

[0108] Some abbreviated English terms involved in this application are annotated as follows:

[0109] STA: Static Timing Analysis (the full name is static timing analysis, STA)

[0110] RTL: Register Transfer Level (the full name is Register Transfer Level)

[0111] SYN: Synthesis (the full name is synthesis)

[0112] DFT: Design For Test (the full name is Design For Test)

[0113] UVM: Digital IC verification software

[0114] LVS: Layout Versus Schematics (LVS full name is Layout Versus Schematics)

[0115] DRC: design rule check (the full name is design rule check)

[0116] LEC: Logic Equivalence Checking (the full name is Logic Equivalence Checking)

[0117] IR Drop: Resistance voltage drop

[0118] ECO: Engineering Change Order (the full name is Engineering Change Order)

[0119] TCL: A scripting language

[0120] CTS: clock tree synthesis (the full name is clock tree synthesis)

[0121] PNR: PNR tool

[0122] AMS: A mixed-signal circuit simulator

[0123] GDS: The most commonly used graphic data description language file format in integrated circuit layout design

[0124] MMMC: MMMC analysis tool of Innovus software

[0125] SDC: Synopsys Design Constraints (the full name is Synopsys Design Constraints)

[0126] ERC: Electrical Rule Check

[0127] SOP: standard operating procedure

[0128] SRD: system require document

[0129] FT: Functional Test

[0130] EVT: Engineering Verification Test

[0131] Design verification at the initial stage of product development. The designer conducts initial test verification on the designed samples, including general functional tests and safety regulations tests.

[0132] Generally, RD (Research & Development) conducts comprehensive verification on the functions of the samples. Since they are samples, there may be more problems and the tests may need to be carried out several times.

[0133] DVT: Design Verification Test

[0134] MVT: Mass Verification Test

[0135] FT: Functional Test

[0136] PCB: Printed circuit board

[0137] EVK: evaluation kit

[0138] PDR: pre-design review

[0139] CDR: current design review

[0140] FDR: final design review.

[0141] The above embodiments only list the preferred specific technical solutions and technical means. It does 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 problems, and it should also be understood as the content protected by the present invention.

Claims

1. A method for optimizing the SOC development process, characterized in that It includes: Start-up phase: Prepare project documents; among which, project preparation includes completing the project verification function list. After the project preparation is completed, preparation documents and technical library files are generated; Execution phase: Generate module files and develop UVM test cases; among which, the process of the first phase in the process of generating module files includes: According to the preparation documents and technical library files in the start-up phase, complete the module files for the physical design process and the module files for the synthesis process; Regression phase: Develop the constraints of the template and the chip, generate the netlist and judge the convergence requirements; The regression phase includes the following steps: c1: Develop the constraints of the module and the chip according to the module files of the physical design process and the module files of the synthesis process; The specific process of developing the constraints of the module and the chip according to the module files of the physical design process is as follows: First, complete the physical design script code, then check for warnings and fix errors, then complete the entire physical design under limited conditions, and finally verify the CTS constraints; The specific process of developing the constraints of the module and the chip according to the module files of the synthesis process is as follows: First, complete the script constraint code, then correct the errors violating the rules, then complete the implantation of the DFT module, and finally correct the errors violating the rules; Final phase: Complete STA, LVS, DRC, LEC, timing, IR Drop and physical checks and conduct test judgments; It includes the following steps: d1: After the post-simulation netlist can be generated, start the next step; d2: Complete STA, LVS, DRC, LEC, timing, IRDrop and physical checks; The specific process of step d2 is as follows: First, create an LEC file, pass the LEC check, then export the GDS and netlist files, pass the LVS check, then export the MMMC SDC file, pass the STA verification, then check through the DRC and ERC rules, then conduct a power consumption check, and then end step d2; After the power consumption check is completed, the ECO process will be carried out; d3: Judge whether the boundary condition check passes. If it passes, end; if it does not pass, start the next step; d4: Conduct the ECO progress, and then return to step d2; According to the specific situation, when engineering modifications are required, conduct the ECO step, and when engineering modifications are not required, the ECO step can also be skipped and directly return to step d2.

2. The method for optimizing the SOC development process according to claim 1, characterized in that The start-up phase includes: First, conduct project preparation, and the project preparation content includes the clock tree and architecture; Then generate preparation documents and technical library files, prepare the general information of the chip for the main design files, and conduct the main preparations for the UVM environment, behavioral modules, and basic verification cases.

3. The method for optimizing the SOC development process according to claim 2, characterized in that In the process of generating module files in the execution phase, the process of the second phase includes the following steps: a1: According to the general information of the chip in the main design files in the start-up phase, complete the module files for the design process; a2: Perform RTL coding for each module, and complete the detection and stable version; a3: Judge whether the RTL coding is completed. If it is completed, enter the function debugging step; if it is not completed, return to step a2.

4. The method for optimizing the SOC development process according to claim 1, characterized in that the development The UVM test cases include the following steps: b1: Generate a functional file for testing based on the main preparation files of the UVM environment, behavioral modules, and basic verification test cases; b2: Develop UVM test cases using the test chip module; b3: Determine whether the verification design is completed. If it is completed, proceed to the functional debugging step; if not, return to step b2.

5. The method for optimizing the SOC development process according to claim 3 or 4, characterized in that the function The debugging step includes the following steps: Collaborate with functional debugging to meet the convergence requirements.

6. The method for optimizing the SOC development process according to claim 1, characterized in that The regression phase also includes the following steps: c2: Determine whether a netlist can be generated. If not, return to step c1; if so, proceed to step c3 and also collaborate with netlist debugging to meet the convergence requirements; c3: PNR, parasitic parameter extraction, and the final netlist; c4: Determine whether a post-simulation netlist can be generated. If not, return to step c3; if so, collaborate with post-netlist debugging to meet the convergence requirements.

7. The method for optimizing the SOC development process according to claim 1, characterized in that The final phase also includes a test judgment process, and the specific steps are as follows: e1: Collaborate with post-netlist debugging and start the next step after meeting the convergence requirements; e2: Determine whether the regression test passes. If it passes, end; if not, return to step e1.

8. The method for optimizing the SOC development process according to claim 1, characterized in that The final phase also includes a test judgment process, and the specific steps are as follows: f1: Collaborate with functional debugging and start the next step after meeting the convergence requirements; f2: Determine whether the regression test passes. If it passes, end; if not, return to step f1.

9. The method for optimizing the SOC development process according to claim 1, characterized in that The final phase also includes a test judgment process, and the specific steps are as follows: g1: Collaborate with netlist debugging and start the next step after meeting the convergence requirements; g2: Determine whether the regression test passes. If it passes, end; if not, return to step g1.

Images