CN114398852A - SOC development process - Google Patents

Abstract

The invention discloses an SOC development process, which is characterized by comprising the following steps: the starting stage is as follows: timeline and architecture preparation; an execution stage: generating a module file and developing a UVM test case; a regression stage: developing constraint conditions and netlist generation of a template and a chip and judging convergence requirements; and a final stage: complete STA, LVS, DRC, LEC, timing, IR Drop and physical checks and make test decisions. The invention provides an SOC development process which reduces errors in a chip design process, improves the success rate of chip flow and shortens the chip development period.

Description

SOC development process

Technical Field

The invention relates to the field of integrated circuit manufacturing, in particular to an SOC development flow.

Background

With the continuous progress of integrated circuit processes at home and abroad and the increasing demand of IC markets, the SOC technology taking IP core reuse and software and hardware collaborative design as the core becomes a hot point of the industry, and also has gained significant achievement, and more SOC products are applied to various industries, such as automobile electronics, industrial control, optical communication and other industries. The functions originally realized by a plurality of chips can be integrated on a single chip by an SOC design method, so that the cost, the chip area power consumption and the like are saved. In addition, one of the characteristics is that through a normative method, the errors in the chip design process are reduced, and the success rate of tape-out is improved.

The second IP reuse technology of the characteristic is that the chip development period is shortened, most of the IP is a verified molding module and can be directly added into the SOC chip, and the error rate is reduced, so that the SOC design can utilize the design achievement accumulated in the early stage, the IC design flow is accelerated, and the situation that the supply and demand are not met in the existing IC market is relieved.

The existing SOC chip design process is mainly divided into the following parts: the method comprises an IP development stage, an IP verification stage, an SOC development stage, an SOC simulation stage, an FPGA verification stage, a comprehensive stage and a physical design stage, wherein each stage relates to different EDA tools, each stage is independently developed by each team to independently develop scripts and independently run, and the processes are handed over and checked manually.

The current development method has the following disadvantages: in the chip development flow, especially when some bugs are found in the middle and later stages, a large amount of personnel is still required to invest in the whole project development, the period of the whole serial structure is very long, the standard management is lacked, and the integrity and the standardability of documents are difficult to guarantee.

The SOC design method provided by the application has the core idea that the design and development process standardization of the reuse IP core is realized, and all IP modules are connected together through a bus in the design of the reuse IP core, so that the difficulty of system design is reduced; the development standardization improves the design accuracy and the time effectiveness through flow standardization and document standardization.

Disclosure of Invention

In order to overcome the problem of long IC design period in the prior art, the invention provides an SOC development flow which reduces errors in a chip design process, improves the success rate of chip flow and shortens the chip development period.

In order to achieve the purpose, the invention adopts the following technical scheme:

the technical scheme adopted by the invention for solving the technical problems is as follows: an SOC development flow, comprising:

the starting stage is as follows: preparing a project file;

an execution stage: generating a module file and developing a UVM test case;

a regression stage: developing constraint conditions and netlist generation of a template and a chip and judging convergence requirements;

and a final stage: complete STA, LVS, DRC, LEC, timing, IR Drop and physical checks and make test decisions.

Preferably, the start phase comprises:

firstly, item preparation is carried out, and the item preparation content comprises a clock tree and a framework;

and then generating a preparation document and a technical library file, preparing chip general information of a main design file, and mainly preparing a UVM environment, a behavior module and a basic verification case.

Preferably, the process of generating the module file in the execution phase includes two phases, and the process in the first phase includes: and finishing the module file of the physical design process and the module file of the comprehensive process according to the preparation document and the technical library file in the initial stage.

The second stage process comprises the following steps:

a 1: completing a module file of a design process according to chip general information of the main design file in the initial stage;

a2, coding each module RTL, completing detection and stabilizing version;

a 3: judging whether RTL coding is finished or not, and if so, entering a function debugging step; if not, return to the step a 2.

Preferably, the developing UVM test cases includes the following steps:

b 1: generating a file for testing functions according to the UVM environment, the behavior module and the main preparation file of the basic verification case;

b 2: developing a UVM test case by using a test chip module;

b 3: whether the design is finished or not is verified, and if the design is finished, the convergence requirement is met by matching with function debugging; if not, return to step b 2.

Preferably, the function debugging step includes the steps of: and matching with function debugging, the convergence requirement is met.

Preferably, the regression phase comprises the following steps:

c 1: developing the constraint conditions (SYN, DFT, STA) of the module and the chip according to the module file of the physical design process and the module file of the comprehensive process;

c 2: judging whether the netlist can be generated or not, and if not, returning to the step c 1; if yes, performing step c3, and matching with netlist debugging to meet convergence requirement;

c 3: PNR, parasitic parameter extraction and finished simulation netlist;

c 4: judging whether the generated simulation netlist can be generated or not, and if not, returning to the step c 3; if so, the simulation netlist is debugged after matching, and the convergence requirement is met.

Preferably, the final stage comprises the steps of:

d 1: after the post-simulation netlist can be generated, starting the next step;

d 2: completing STA, LVS, DRC, LEC, timing, IR Drop and physical checks;

d 3: judging whether the boundary condition check passes, and if so, ending the process; if not, the next step is started:

d 4: an ECO schedule is made and then returns to step d 2.

Preferably, the final stage further comprises a test judgment process, and the specific steps are as follows:

e 1: after matching, the simulation netlist is debugged, and the next step is started after the convergence requirement is met;

e 2: judging whether the regression test passes or not, and if so, ending the test; if not, return to step e 1.

Preferably, the final stage further comprises a test judgment process, and the specific steps are as follows:

f 1: matching with function debugging, starting the next step after meeting the convergence requirement;

f 2: judging whether the regression test passes or not, and if so, ending the test; if not, return to step f 1.

Preferably, the final stage further comprises a test judgment process, and the specific steps are as follows:

g 1: matching with the netlist for debugging, and starting the next step after meeting the convergence requirement;

g 2: judging whether the regression test passes or not, and if so, ending the test; if not, return to step g 1.

Therefore, the invention has the following beneficial effects: through a standardized method, errors in the chip design process are reduced, and the success rate of tape-out is improved. The IP reuse technology also shortens the development period of the chip, most of the IP is a verified molding module, and the IP can be directly added into the SoC chip, so that the error rate is reduced, the SoC design can utilize the design results accumulated in the early stage, the IC design flow is accelerated, and the situation that the supply and demand are not met in the existing IC market is relieved.

Drawings

FIG. 1 is a flow chart of the present invention;

FIG. 2 is a flow chart of constraints for a physical development module and chip in accordance with the present invention;

FIG. 3 is a flowchart of the constraint conditions of a development module and chip for integrated/static analysis in accordance with the present invention;

FIG. 4 is a flow chart of a simulation netlist after parasitic parameter extraction and completion of PNR according to the present invention;

FIG. 5 is a flow chart of the present invention for performing STA, LVS, DRC, LEC, timing, IR Drop and physical checks;

FIG. 6 is a flow chart of a coordination function debugging process according to the present invention;

FIG. 7 is a flowchart of a netlist debugging method of the present invention;

FIG. 8 is a flowchart illustrating debugging of a post-fit simulated netlist according to the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be described clearly and completely with reference to the accompanying drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all embodiments of the present invention. All other embodiments, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, are within the scope of the present invention. Thus, the following detailed description of the embodiments of the present invention, presented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. In the present application, when it is necessary to apply the known technology or the conventional technology in the field, the applicant may have the case that the known technology or/and the conventional technology is not specifically described in the text, but the technical means is not specifically disclosed in the text, and the present application is considered to be not in compliance with the twenty-sixth clause of the patent law.

Example (b): as shown in fig. 1, an SOC development process includes:

the starting stage is as follows: preparing a project file;

firstly, item preparation is carried out, and the item preparation content comprises a clock tree and a framework;

the project preparation comprises the following steps: firstly, defining the name of a chip pin, exchanging a timing parameter by each pin, then finishing a project architecture and an independent sub-module, and then finishing project control registration; then completing a project verification function list; and finally, arranging the project progress into a complete project progress, and distributing the workload to each owner.

After the project preparation is finished, generating a preparation document and a technical library file, preparing chip general information of a main design file, and mainly preparing a UVM environment, a behavior module and a basic verification case.

An execution stage: generating a module file and developing a UVM test case;

the process of generating the module file comprises two stages:

the first stage process comprises: and completing the module file of the physical design process according to the preparation document and the technical library file in the initial stage. And completing the module file of the comprehensive process.

The second stage process comprises the following steps:

a 1: completing a module file of a design process according to chip general information of the main design file in the initial stage; the specific process is as follows: firstly, completing the function of the sub-modules according to the port design prompt, then completing the sub-module registration list in the design prompt, then completing the sub-module diagram in the design document, clearly describing the function of the module, and finally completing the detailed sub-modules in the design description document.

a2, coding each module RTL, completing detection and stabilizing version;

a 3: judging whether RTL coding is finished or not, and if so, matching with function debugging to meet the convergence requirement; if not, return to the step a 2.

The development of the UVM test case comprises the following steps:

b 1: generating a functional file for testing according to the UVM environment, the behavior module and the main preparation file of the basic verification case;

b 2: developing a UVM test case by using a test chip module;

b 3: judging whether the design is finished or not, and entering a function debugging step if the design is finished; return to step b 2.

The function debugging steps in step b3 and step a3 include the steps of: and matching with function debugging, the convergence requirement is met. The function debugging steps in step b3 and step a3 are respectively and independently executed. The specific process of matching function debugging is as follows: as shown in fig. 6, RTL regression verification is performed first, and finally new functions and code tests are performed.

A regression stage: developing constraint conditions and netlist generation of a template and a chip and judging convergence requirements; the method specifically comprises the following steps:

c 1: developing the constraint conditions (SYN, DFT, STA) of the module and the chip according to the module file of the physical design process and the module file of the comprehensive process; the specific process of developing the constraint conditions of the module and the chip according to the module file of the integrated process is as follows: as shown in FIG. 2, the script constraint code is completed first, then the error violating the rules is corrected, then the implantation DFT module is completed, and finally the error violating the rules is corrected.

The specific process of developing the constraint conditions of the module and the chip according to the module file of the physical design process is as follows: as shown in FIG. 3, the physical design script code is completed first, then the warning and repair errors are checked, then the entire physical design is completed under limited conditions, and finally the CTS constraints are verified.

c 2: judging whether the netlist can be generated or not, and if not, returning to the step c 1; if yes, performing step c3, and matching with netlist debugging to meet convergence requirement; the specific process of debugging the matched netlist is as follows: as shown in fig. 7, gate level and RTL regression checks are performed first, and finally function and timing debug is performed.

c 3: PNR, parasitic parameter extraction and finished simulation netlist; the specific process is as follows: as shown in fig. 4, the PNR is initialized first, then the CTS flow is entered, then the post-simulation CTS flow is entered, and finally the layout and wiring flow is entered.

c 4: judging whether the generated simulation netlist can be generated or not, and if not, returning to the step c 3; if so, the simulation netlist is debugged after matching, and the convergence requirement is met. The specific process of debugging the simulated netlist after the matching is as follows: as shown in FIG. 8, gate level and RTL regression checks are performed first, then functional and timing debug, and finally AMS testing is performed on the basis of the gate level netlist.

And a final stage: complete STA, LVS, DRC, LEC, timing, IR Drop and physical checks and make test decisions. The method specifically comprises the following steps:

d 1: after the post-simulation netlist can be generated, starting the next step;

d 2: completing STA, LVS, DRC, LEC, timing, IR Drop and physical checks; the specific process of the step d2 is as follows: as shown in fig. 5, the LEC file is created first, the GDS and netlist files are exported after LEC check, the MMMC SDC file is exported after LVS check, the MMMC SDC file is verified by STA, then the rule checks such as DRC, ERC, etc. are passed, then the power consumption check is performed, and then the d2 step is ended. After the power consumption check is finished, an ECO flow is performed,

d 3: judging whether the boundary condition check passes, and if so, ending the process; if not, the next step is started:

d 4: an ECO schedule is made and then returns to step d 2. According to specific situations, when engineering modification is needed, the ECO step is carried out, and when the engineering modification is not needed, the ECO step can be skipped, and the step d2 is directly returned.

The final stage also comprises three test judgment processes, and whether the regression test of the matched simulation netlist, the matched function debugging and the matched netlist is passed or not is judged respectively.

Whether the regression test for the debugging of the matched simulation netlist passes the judgment specific steps is as follows:

e 1: after matching, the simulation netlist is debugged, and the next step is started after the convergence requirement is met;

e 2: judging whether the regression is passed under the condition of regression, and if the regression is passed, ending; if not, return to step e 1.

The method is characterized in that whether the regression test is passed or not by matching with the function debugging is judged as follows:

f 1: matching with function debugging, starting the next step after meeting the convergence requirement;

f 2: judging whether the regression is passed under the condition of regression, and if the regression is passed, ending; if not, return to step f 1.

The method for judging whether the regression test is passed or not by matching with the netlist debugging comprises the following specific steps:

g 1: matching with the netlist for debugging, and starting the next step after meeting the convergence requirement;

g 2: judging whether the regression is passed under the condition of regression, and if the regression is passed, ending; if not, return to step g 1.

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

1. The information of the chip encapsulation seal is standard; 2. an item reference template; 3, project plan template; 4. checking items related to the layout; 5. a process SOP; 6. a chip develops an output file template; 7. project phase management templates. The invention improves the 5 th step, and can complete the SOC design and development by matching with other 6 processes of the existing SOC design and development, thereby achieving the standardization and completeness of the design process, saving the design time and improving the flow sheet and success rate.

The project reference template and the chip development output file template comprise the following files:

1. market demand documents, 2, debugging reports, 3, project plan documents, 4, EVT-DVT report formats, 5, packaging schemes, 6, system demand documents SRD, 7, FT test schemes (for power chips), 8, technical feasibility reports, 9, reliability reports, 10, simulation PDR-CDR-FDR review reports, 11, MVT reports, 12, design prompts, 13, process flow tables, 14, final layout design GDS reports, 15, process SOP, 16, record tables, 17, procurement and stock plans, 18, PCB & EVK schematic diagrams, 19, procurement and stock plans, 20, packaging schemes, 21, test specifications.

In step 5, the flow SOP includes a digital front end design specification and a digital front end verification specification, and the contents included in the digital front end design specification and the digital front end verification specification are illustrated as follows:

firstly, designing a digital front end standard:

1. writing specification, 2, naming specification, 3, code annotation specification, 4, asynchronous logic processing, 4.1, asynchronous reset synchronization, 4.2, multi-clock domain asynchronous reset synchronization, 4.3, asynchronous logic cross-domain rule, 5 and standard logic unit.

The module naming specification of the digital front end design specification is as follows:

the first level (hier 1) is fixed to the digital top level ending with _ digtop; the second level (hier 2) is a submodule level top level and is named differently according to different projects; the third layer and above (equal to or more than hier 3) is a sub-module internal lower-level module, the name of the sub-module at the second layer is added behind the item name and is separated from the item name by underlining (_), and then the sub-modules with more than three layers are named by using the function of the current module. IP block designations are prefixed by xy and function, and are separated by an underline (_), for example: xy _ i2c _.

Second, digital front end verification specification

1. The SystemVerilog (SystemVerilog is a simulation language) code specification comprises (1) a writing specification, (2) a naming specification, (3) a code implementation and (4) a code annotation;

2. a base class file;

3. standard modeling language (UML): (1) usage graph, (2) class graph, (3) sequence graph, (4) communication graph, (5) state graph, (6) activity graph, and (7) packet graph;

4. appendix.

Some of the abbreviated english words contemplated by this application are annotated as follows:

STA: static Timing Analysis (STA)

RTL: register Transfer Level (Register Transfer Level)

SYN: synthesis (full name synthesis)

DFT: design For testability (Design For Test)

UVM: digital IC verification software

And (4) LVS: layout verification (LVS is called Layout Versus schema)

DRC: design rule checking (full name design rule check)

LEC: formal verification (Logic Equisalence Checking)

IR Drop: resistance drop

ECO: engineering amendment (full name Engineering Change Order)

TCL: scripting language

CTS: clock tree synthesis (full name clock tree synthesis)

PNR: PNR tool

AMS: mixed signal circuit simulator

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

MMMC: MMMC analysis tool of Innovus software

SDC: constraints (full name Synopsys Design Constraints)

ERC: electrical Rule Check (known as Electrical Rule Check)

And (3) SOP: standard operation process (named as standard operating procedure)

SRD: system requirement document (called system require document)

FT: functional testing

EVT: engineering Verification (full name Engineering Verification Test)

And (5) design verification at the initial stage of product development. The designer performs initial test verification on the designed sample, including general function test and safety test,

generally, RD (Research & Development) is used to fully verify the functions of the sample, because the sample may have many problems and the test may be performed several times.

DVT: design Verification (Design Verification Test)

MVT: mass production Verification (Mass Verification Test)

FT: functional testing

PCB: printed circuit board (full name as Printed circuit board)

EVK: evaluation suite (evaluation kit)

PDR: front simulation design review (full name pre-design review)

CDR staged simulation (full-name current design review)

FDR post simulation design review (collectively referred to as final design review).

The above embodiments only exemplify preferred specific technical solutions and technical means, and do not exclude the scope of the claims of the present invention, and other alternatives to the technical means that can solve the technical problems should be understood as the contents of the claims of the present invention.

Claims (10)

1. An SOC development process, characterized by comprising:

the starting stage is as follows: preparing a project file;

an execution stage: generating a module file and developing a UVM test case;

a regression stage: developing constraint conditions and netlist generation of a template and a chip and judging convergence requirements;

and a final stage: complete STA, LVS, DRC, LEC, timing, IR Drop and physical checks and make test decisions.

2. The SOC development process of claim 1, wherein the start-up phase includes:

firstly, item preparation is carried out, and the item preparation content comprises a clock tree and a framework;

and then generating a preparation document and a technical library file, preparing chip general information of a main design file, and mainly preparing a UVM environment, a behavior module and a basic verification case.

3. An SOC development process according to claim 1 or 2, wherein the process of generating module files in the execution phase comprises two phases:

the first stage process comprises: according to the preparation document and the technical library file in the starting stage, finishing the module file of the physical design process and the module file of the comprehensive process;

the second stage process comprises the following steps:

a 1: completing a module file of a design process according to chip general information of the main design file in the initial stage;

a2, coding each module RTL, completing detection and stabilizing version;

a 3: judging whether RTL coding is finished or not, and if so, entering a function debugging step; if not, return to the step a 2.

4. The SOC development process of claim 1, wherein developing UVM test cases comprises the steps of:

b 1: generating a functional file for testing according to the UVM environment, the behavior module and the main preparation file of the basic verification case;

b 2: developing a UVM test case by using a test chip module;

b 3: judging whether the design is finished or not, and entering a function debugging step if the design is finished; if not, return to step b 2.

5. An SOC development process according to claim 3 or 4, wherein the function debugging step comprises the steps of: and matching with function debugging, the convergence requirement is met.

6. The SOC development process of claim 1, wherein the regression phase includes the steps of:

c 1: developing constraint conditions of the module and the chip according to the module file of the physical design process and the module file of the comprehensive process;

c 2: judging whether the netlist can be generated or not, and if not, returning to the step c 1; if yes, performing step c3, and matching with netlist debugging to meet convergence requirement;

c 3: PNR, parasitic parameter extraction and finished netlist;

c 4: judging whether the generated simulation netlist can be generated or not, and if not, returning to the step c 3; and if so, debugging the matched netlist to meet the convergence requirement.

7. The SOC development process of claim 1, wherein the final stage comprises the steps of:

d 1: after the post netlist can be generated, starting the next step;

d 2: completing STA, LVS, DRC, LEC, timing, IR Drop and physical checks;

d 3: judging whether the boundary condition check passes, and if so, ending the process; if not, the next step is started:

d 4: the ECO flow is performed and then returns to step d 2.

8. The SOC development process of claim 1, wherein the final stage further includes a test judgment process, comprising the steps of:

e 1: debugging the netlist after matching, and starting the next step after meeting the convergence requirement;

e 2: judging whether the regression test passes or not, and if so, ending the test; if not, return to step e 1.

9. The SOC development process of claim 1, wherein the final stage further includes a test judgment process, comprising the steps of:

f 1: matching with function debugging, starting the next step after meeting the convergence requirement;

f 2: judging whether the regression test passes or not, and if so, ending the test; if not, return to step f 1.

10. The SOC development process of claim 1, wherein the final stage further includes a test judgment process, comprising the steps of:

g 1: matching with the netlist for debugging, and starting the next step after meeting the convergence requirement;

g 2: judging whether the regression test passes or not, and if so, ending the test; if not, return to step g 1.

Images