Sanity checker for integrated circuits

The present invention relates generally to integrated circuit (IC) designs, and, more particularly, to layout-based circuit sanity checks.

As the feature size of integrated circuits (ICs or simply circuits) continues to shrink, more and more ICs with more complex designs, such as system-on-chip (SoC), can be packed into a given semiconductor die size. IC designs are increasingly relying upon computer-aided-design (CAD) tools for circuit designs, mask layouts, as well as sanity checks at all steps of the design process.

In fabrication of ICs, each processing step involving photolithography often uses a “mask”, which comprises a set of geometric patterns typically representing an addition or deletion of materials such as metal, polysilicon, or substrate in a finished IC. Through the photolithography, the patterns are made to the semiconductor substrate, which eventually become the IC.

If a mistake is made in a design, debugging the finished chip is very difficult and time consuming. Once “bugs” are found, a new revision of the IC design is generated, and there are certain inevitable revisions that have to be made to the masks as well. The cost for changing the mask nowadays is very expensive. Accordingly, circuit designers currently employ design checking tools to ensure the design is relatively “clean” with correct functionality and robustness for anticipated process variations.

A traditional gate level IC design flow follows. Firstly, designers create a set of schematic diagrams (or schematics for short) based on product requirements. Secondly, a SPICE (Simulation Program with Integrated Circuits Emphasis) netlist is generated from the schematic diagrams for running various simulations, such as timing and power, etc., on the design. A “netlist” is a file describing the connectivity of various instances and their attributes in a circuit design. Then, a layout is generated based on the set of schematic diagrams. The layout is a graphic drawing based on which mask layers can be produced. In design, a digitized representation of an image of a mask is commonly called a “mask layer” or simply a “layer”. Due to the complexity of the designs, CAD tools are used by engineers to produce a correct layout. In general, these CAD tools are called DRC/ERC (design rule check/electrical rule check) and LVS (layout vs. schematic). DRC/ERC checks layout's conformance and correctness to the requirements of a given process and LVS checks the layouts' conformance to the schematics.

However, the traditional gate level IC design flow has certain limitations such as SPICE models for simulation and mainly covers inter-die variations, and not intra-die variations. Intra-die variations cause difficulty in predicting circuit functionality of those dynamic circuits sensitive to any leakage with SPICE models. Sub-threshold leakage along with intra-die variations, which have become a serious problem as device channel length, threshold voltage and power supply voltage are scaling down. For a large SoC design, block interface circuitries are also not easy to check by SPICE simulation.

Accordingly, in a traditional gate level IC design flow, a fundamental assumption is that the schematic diagrams created by the designers are both functionally and electrically correct, and all the steps subsequent to the schematics are checked against the schematics for correctness. However, if the schematics have a logic error or tend to create excessive sub-threshold leakage, then all the DRC/ERC and LVS just cannot do anything about the error or the leakage. Unfortunately, the schematics are created by human beings, and in a large SoC design with millions of transistors, errors and oversights are almost inevitable.

Another issue is known as design marginality. Certain circuits, such as dynamic circuits and feedback-type circuits are more sensitive to process variations. Accordingly, robust designs for such circuits are even more critical.

Other high level designs, such as RTL (register transfer logic), employs logic synthesis and requires a person to create the circuit description. The building blocks of the high level design are still gate level circuits, and block interfaces are even more of a concern.

Accordingly, there is a need for an improved design sanity checker to help designers screen out problematic circuits due to human errors or oversights in an IC design.

The present invention discloses a method for sanity checking integrated circuit (IC) designs based on one or more predefined sub-circuits with at least one predefined checking criteria. The method comprises steps such as automatically reading one or more netlists, identifying one or more sub-circuits in the netlists isomorphic to at least one of the predefined sub-circuits, identifying one or more device parameters for sanity checking the identified sub-circuits, and comparing the identified device parameters against the predefined checking criteria.

The construction and method of operation of the invention, however, together with additional objectives and advantages thereof will be best understood from the following description of specific embodiments when read in connection with the accompanying drawings.

FIG. 1 is a block diagram illustrating a conventional circuit design work flow.

FIG. 2 is a block diagram illustrating a circuit design work flow incorporating a design sanity checker according to one embodiment of the present invention.

FIGS. 3A and 3B are block diagrams illustrating modules of a design sanity checker according to one embodiment of the present invention.

FIGS. 4A˜4D are schematic diagrams showing examples of problematic circuits that the sanity checker is intended to screen out.

The present disclosure provides a design sanity checker to help designers screen out problematic circuits due to human errors or oversights in an IC design.

FIG. 1 is a block diagram illustrating a conventional circuit design work flow 100 . Designers first create a set of schematic diagrams in step 110 . A netlist is then generated from the schematics by a schematic capturing tool in step 120 . The netlist is then used to conduct various kinds of SPICE simulations for checking function, timing and power, etc. of the circuit under design. The SPICE simulation result is fed back to the schematics to correct any mistake or further improve the circuit design. Finalized schematics are then used for generating a layout in step 140 . The layout is a graphical representation of an actual circuit and is used to generate a set of mask layers for producing physical chips in step 150 . To ensure that the layout meets all the design rules and electrical rules, a design rule checker/electrical rule checker (DRC/ERC) tool is run for the layout in step 160 , and any rule violation will be flagged. The layout also has to conform to the schematics. A layout vs. schematic (LVS) tool is used for that purpose, also shown in step 160 of FIG. 1 .

One of the shortcomings of the conventional circuit design work flow, as shown in FIG. 1 , is the lack of checking mechanism for the schematics themselves. The correctness of the schematics depends on the designers' knowledge and diligence, which is not always a sure thing.

FIG. 2 is a block diagram illustrating a circuit design work flow 200 incorporating a design sanity checker according to one embodiment of the present invention. The netlist generated from schematics is not only used to run SPICE simulation, but also to run design sanity checker in step 210 . Results from the design sanity checker 210 are then used to improve the schematics of step 110 .

Referring to FIG. 2 , design sanity checker 210 may also be implemented in another stage of the design flow. That is, after generating a netlist from the layout in step 220 , the design sanity checker 210 is run on the layout-generated netlist. It is understood that based on the requirements of various designs, the sanity checking can be done in either stages or both. One of the advantages of running design sanity checks is to screen out any user that caused design errors or oversights that can possibly occur during the design process; such design errors or oversights are almost inevitable in a large IC design.

FIG. 3A is a block diagram illustrating modules of a design sanity checker 300 according to one embodiment of the present invention. The design sanity checker 300 can be a software program for performing the sanity checking as in step 210 of FIG. 2 . A SPICE parser module 310 reads a SPICE netlist of various data structure and then organizes devices and their connections defined in the netlist into the design sanity checker's own data structure. A graphic construction module 320 associated with the SPICE parser module 310 generates a circuit representation into a schematic or layout format so that the design sanity checker results can be easily read, and error messages flagged. As schematics are normally drawn in hierarchical style, and so is the netlist generated thereof. However, in some cases, a flat netlist is more desirable for inspecting the circuit. In such a case, a flatten engine module 330 may be provided to transform the hierarchical netlist into a flat netlist. But in other cases, emphasis is placed on the interfaces between the cells within a large circuit, and then the hierarchical netlist may be preserved. An isomorphism engine 340 is provided to filter out predefined functional cells or sub-circuits, such as NAND and latches, etc. Here, the sub-circuits are referred to those circuits containing multiple transistors. A candidate net finder 350 is to group nets into different connection types, such as P-type metal-semiconductor-oxide (PMOS) transistor source/drain connection, PMOS gate connection, N-type metal-semiconductor-oxide (NMOS) source/drain connection or NMOS gate connection, etc. Within a type of connection, the nets can be further grouped into sub-groups according to the number of devices connected to a net. Primary input/output nets may be distinguished out as well. When the netlist is isomorphically organized according to functional sub-circuits, and all the nets are grouped, then user defined checking items 360 may be correctly carried out.

FIG. 3B shows exemplary sub-modules of the user defined checking items module 360 according to one embodiment of the present invention. Driving strength calculator sub-module 362 calculates the driver size vs. driver loading. If a driver size is too small for a loading, signal transitions will take too long, both timing and active power consumption may cause problems. Leakage strength calculator sub-module 364 calculates a worst case leakage path. If the value of the worst case leakage path exceeds a user defined value, the design sanity checker 300 will report an error for that leakage path. A Pass and dynamic gate finder sub-module 366 picks out pass gates and dynamic gates, which are very sensitive to leakage. The device sizes in these sub-circuits are also defined by the user. Any violation of the user defined device sizes will be picked out by the design sanity checker 300 . A loop finder 368 may be provided to find feedback circuits and to check if there is any data contention problem. A cell boundary interface finder 370 is for checking specifically at cell boundary interfaces. The cell boundary interfaces have their own sets of rules, which are also defined by the user.

FIG. 4A shows an exemplary sub-circuit 400 of a PMOS transistor 410 and a NMOS 412 . If the channel width of the PMOS transistor 410 is Wp=0.2 um, while a channel width of the NMOS transistor 412 is Wn=30 um, then the PMOS transistor 410 is too weak to pull up the strong pull down NMOS transistor 412 , and will have problems during signal transition. If P/N ratio is already defined by the user in the driving strength calculator module 362 , the design sanity check can screen out this problematic sub-circuit 400 .

FIG. 4B is an exemplary sub-circuit 420 for demonstrating how to calculate minimum driving strength and maximum leakage strength. A driving strength of PathA can be represented by

D_PathA = 1 L_P1 W_P1 + L_P2 W_P2 ,

where L and W stands for a channel length and a channel width of a transistor, respectively. So, L_P 1 stands for the channel length of the PMOS transistor P 1 , and W_P 1 stands for the channel width of the PMOS transistor P 1 , and so on and so forth. Then the minimum driving strength of the PMOS side of the sub-circuit 420 can be obtained from MIN (PathA, PathB, PathC). The minimum driving strength of the NMOS side of the sub-circuit 420 can be obtained from MIN(PathD, PathE).

Referring to FIG. 4B again, a leakage strength of the PMOS transistors P 2 and P 3 can be expressed as

W_P2 L_P2 + W_P3 L_P3 .

The maximum leakage strength of NMOS transistors N 1 and N 2 can be expressed as

MAX ⁡ ( W_N1 L_N1 + W_N2 L_N2 ) .

A leakage strength of the PMOS side of the sub-circuit 420 can be expressed as MAX(((P 2 +P 3 ), P 1 )+P 4 ). Similarly, a leakage strength of the NMOS side of the sub-circuit 420 can be expressed as MAX((MAX(N 1 , N 2 )+N 3 ), N 4 ).

The user may provide a value for either the minimum driving strength or the maximum leakage strength. If any sub-circuit has a driving strength or a leakage strength that exceeds the provided value, then the design sanity checker 300 will flag an error message for the violation of the provided value.

FIG. 4C is a schematic of a dynamic gate 440 . Design sanity check for the dynamic gate 440 includes comparing ratios of the largest NMOS transistor in the N-logic block 446 to the smallest PMOS 442 .

FIG. 4D is a schematic of a circuit 460 containing a feedback inverter 466 . Data contention can be a problem if the devices contained therein are not sized correctly. The loop finder sub-module 368 shown in FIG. 3B is intend to screen out this kind of feedback circuit. Referring to FIG. 4D , design sanity checking can be done on the following ratios:

W_P1 W_N2

for pull-up strength, and

W_N1 W_P2

for pull-down strength.

Again, the user can provide a value for these ratios, the design sanity checker search for any violation in the entire circuit, and flag an error message if it found any violation.

The above illustration provides many different embodiments or embodiments for implementing different features of the invention. Specific embodiments of components and processes are described to help clarify the invention. These are, of course, merely embodiments and are not intended to limit the invention from that described in the claims.

Although the invention is illustrated and described herein as embodied in one or more specific examples, it is nevertheless not intended to be limited to the details shown, since various modifications and structural changes may be made therein without departing from the spirit of the invention and within the scope and range of equivalents of the claims. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the invention, as set forth in the following claims.