e by - virginia tech"flattening", "unflattening" and "user—defined...

155

Upload: others

Post on 28-May-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical
Page 2: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

AN INTERACTIVE DESIGN RULE CHECKER FOR INTEGRATED CIRCUIT

gLAYOUT·

E by„ y Kwanghyun Kim

äi Joseph G. Tront, Chairman

Electrical Engineering

(ABSTRACT)

An implementation of an interactive design rule checker is

described in this thesis. Corner—based design rule checking

_ algorithm is used for the implementation. Due to the local-

ity of checking mechanism of the corner-based algorithm, it

is suitable for hierarchical and interactive local design

rule checking. It also allows the various design rules to

be specified very easily.

Interactive operations are devised so that the design

rule checker can be invoked from inside the layout editor.

All the information about the violation, such as position,

type of violation, and symbol definition name are provided

in an interactive manner. In order to give full freedom to

the user to choose the scope of checking, three options,

"Flattening", "Unflattening" and "User—defined window" are

implemented in creating the database to be checked. The

"User—defined window" option allows hierarchical design rule

checking on a design which contains global rectangles. Using

Page 3: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

these three options, very efficient hierarchical checking can

be performed.

iii

Page 4: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

ACKNOWLEDGEMENTS

Acknowledgements iv

Page 5: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

TABLE OF CONTENTS

1.0 INTRODUCTION .................. 1

2.0 LAMBDA-BASED NMOS DESIGN RULES ......... 5

3.0 EXISTING DESIGN RULE CHECKING ALGORITHMS .... 19

3.1 Polygon Algebra Algorithm ............ 19

3.2 Raster-Scan Algorithm .............. 21

4.0 CORNER-BASED DESIGN RULE CHECKING ALGORITHM . . . 25

4.1 An Overview of the Corner—based Algorithm .... 25

4.2 Specification of NMOS Design Rules ....... 32

4.2.1 Context Pattern ............... 32

4.2.2 Spacing Rule Specification ......... 36

4.2.2.1 Single Layer Spacing Rule Specification . 36

4.2.2.2 Interlayer Spacing Rule Specification . . 43

4.2.3 Width Rule Specification .......... 57

4.2.4 Transistor Overhang Rule Specification . . . 61

4.2.5 Ion—implant Overhang Rule Specification . . . 75

4.2.6 Contact Cut Surrounding Rule Specification . 79

4.2.7 Butting Contact Rule Specification ..... 89

‘ 4.2.8 Buried Contact Rule Specification ...... 97

4.3 Corner Detection and Bit-Map Generation .... 105

4.4 A Limitation of the Corner—based DRC Algorithm 115

Table of Contents v

Page 6: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

5.0 IMPLEMENTATION OF CORNER-BASED DRC ALGORITHM . 117

5.1 Design Rule Checker .............. 117

5.1.1 Corner Detection and Bit-Map Generation . . 117

5.1.2 Corner Processing ............. 124

5.2 Interfacing DRC with ICICLE ......... 132

5.2.1 Database Creation for Hierarchical Design Rule

Checking .................... 132

5.2.2 Reporting of Design Rule Violations .... 136

6.0 RESULT .................... 139

7.0 CONCLUSION .................. 140

8.0 REFERENCES .................. 142

VITA ........................ 144

Table of Contents vi

Page 7: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

LIST OF ILLUSTRATIONS

Figure 1. Width and spacing rules for diffusion, polyand metal. ............... 9

Figure 2. Transistor overhang rule. ......... 10

Figure 3. Spacing and ion-implant overhang rule for de-pletion mode transistor. ......... 12

Figure 4. Contact surrounding rule. ......... 13

Figure 5. Spacing rule between transistor gate and con-tact cut. ................. 14

Figure 6. Butting contact. . U............ 16

Figure 7. Buried contacts. ............. 17

Figure 8. Spacing rule violation of metal in the 4l X 4Xwindow. .................. 22

Figure 9. Corners in the design. ........... 26

Figure 10. Spacing requirement on a metal box. .... 27

Figure ll. Spacing rule specification for four cornersof the metal box. ............. 29

Figure 12. Spacing rule violation between two metalboxes. .................. 30

Figure 13. Four quadrants around a corner. ...... 33

Figure 14. Five types of the context patterns. .... 34

Figure 15. Context pattern of a convex corner and theconstraint for the single layer spacing rule. 37

Figure 16. Spacing rule violation detected by two small"NOT M" constraints. ........... 38

Figure 17. Context pattern of a concave corner and theconstraint for the single layer spacing rule. 39

Figure 18. Spacing rule violation detected by the con-straint of a concave corner. ...... 40

list of illustrations vii

Page 8: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Figure 19. Spacing rule violation at a one-side corner. 41

Figure 20. A convex corner of diffusion and the corre-‘sponding constraint for poly for the inter-layer spacing rule. ............ 45

Figure 21. Specification of the interlayer spacing rulebetween poly and diffusion for the contextpatterns of poly. ............ 47

Figure 22. Specification of the interlayer spacing rulebetween poly and buried cut for the contextpatterns of poly. ............ 48

Figure 23. Specification of the interlayer spacing rulebetween poly and diffusion for the contextpatterns of diffusion. ......... 49

Figure 24. Specification of the interlayer spacing rule_ between diffusion and buried cut for the

context patterns of diffusion. ...... 50

Figure 25. Specification of the interlayer spacing rulefor the context patterns of buried cut. . . 51

Figure 26. Specification of the interlayer spacing rulebetween transistor gate and ion-implantationfor the context patterns of ion—implantation. 52

Figure 27. Specification of the interlayer spacing rulebetween transistor gate and ion-implantationfor the context patterns of transistor gate. 53

Figure 28. Specification of the interlayer spacing rulebetween transistor gate and contact cut todiffusion for the combined context patternsof diffusion and contact cut. ...... 54

Figure 29. Specification of the interlayer spacing rulebetween transistor gate and contact cut todiffusion for the context patterns of transis-tor gate. ................. 55

Figure 30. (a) Specification of the width rule for a con-vex corner.

(b) Specification of the width rule for a con-cave corner. ............. 58

Figure 31. Width rule violation at convex, concave andone-side corners. ............. 59

list of illustrations viii

Page 9: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Figure 32. Corner in a transistor. ......... 62

Figure 33. Combined context patterns of diffusion andpoly for a convex type context pattern ofdiffusion. ................ 64

Figure 34. Specification of the transistor overhang rulefor the combined context patterns of group (C)in Figure 33. .............. 66

Figure 35. Combined context patterns of diffusion and polyfor a one—side context pattern of diffusion. 67

Figure 36. Specification of the transistor overhang rulefor the combined context patterns in Figure36. .................... 68

Figure 37. Combined context patterns of diffusion and polyfor a concave type context pattern of diffu-sion. .................. 70

Figure 38. Specification of the transistor overhang rulefor the combined context patterns in Figure37. .................... 71

Figure 39. Combined context patterns of diffusion and polyfor the all-filled type context pattern of

· diffusion. ............... 72

Figure 40. Specification of the transistor overhang rulefor the combined context patterns in Figure39. ................... 73

Figure 41. Specification of the ion-implant overhang rule”

for the context patterns of the depletion modetransistor. ............... 76

Figure 42. Specification of the ion-implant overhang rulefor the context patterns of the depletion modetransistor. ............... 77

Figure 43. Contact cut. ............... 80

Figure 44. One-side and all-filled corners in the contactcut containing more than one rectangle. . . 81

Figure 45. A contact cut containing a concave corner. 82

Figure 46. Specification of the contact cut surroundingrule. ................. 83

list of illustrations ix

Page 10: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Figure 47. Specification of the contact cut surroundingrule. ................. 84

Figure 48. Specification of the contact cut surroundingrule. ................. 85

Figure 49. Specification of the contact cut surroundingrule. ................. 86

Figure 50. Contact cut surrounding rule violations de-tected at one-side corners. ....... 87

Figure 51. (a) Region which is specified by the contactcut surrounding rule in the butting con-tact.

(b) Butting contact. ....... 90

Figure 52. (a) Checking procedure for the poly-diffusionoverlap.

_ (b) Procedure for the butting contact rulechecking. .............. 92

Figure 53. Combined context patterns of cut, diffusionand poly at the corners of contact cut inthe butting contact. ........... 94

Figure 54. Constraints for the context patterns in Figure54 for the butting contact. ........ 95

Figure 55. Three configurations of the butting contactobtained by rotation of the configurationin Figure 51. ............... 96

Figure 56. Buried contacts. ............. 98

Figure 57. Procedure of the buried contact rule checking. 99

Figure 58. Specification of the buried contact rule forthe corner of buried cut with poly. .... 101

Figure 59. Specification of the buried contact rule forthe corners of only buried cut when a cornerof poly exists at left. .......... 102

Figure 60. Specification of the buried contact rule forthe corners of only buried cut when a cornerof diffusion exists at left. ....... 103

Figure 61. Specification of the buried contact rule forthe corners of only buried cut when no layerexists at left except buried cut. ..... 104

list of illustrations x

Page 11: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Figure 62. Two corners of a rectangle. ..... 107

Figure 63. (a) Two rectangles in the layout.(b) Database for two rectangles.(c) Two sort arrays in order of bottom and top

edge of two rectangles. ....... 111

Figure 64. Final bit—map and detected corners. . . . 114

Figure 65. A false violation detected in the spacing rulechecks. ................. 116

Figure 66. Grid on the scanning window. ....... 119

Figure 67. (a) A concave corner of metal.(b) Constraints for the width and spacing

rules in the scanning window. ..... 121

Figure 68. Overall flow of the design rule checker usingthe corner—based algorithm„ ..... 123

Figure 69. (a) Four numbers assigned to the four quad-rants around a corner.

(b) Sixteen pattern numbers for the 16 contextpatterns. .............. 125

Figure 70. Numbers for the expansion direction used inthe routine COUNT_PIXEL. ......... 127

Figure 71. Function COUNT_PIXEL. ......... 128

Figure 72. Spacing and width checks at a concave cornerof the poly layer using the routine COUNT_‘PIXEL. ................. 130

Figure 73. A linked list for the design rule errorreporting ................. 138

list of illustrations xi

Page 12: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

1.0 INTRODUCTION

Recent developments in Very Large Scale Integrated (VLSI)

circuit technology allow the manufacturing of complex VLSI

circuits containing 100,000 transistors, and it is projected

that the technology will support fabrication of a million

transistors in the near future. One of the key steps in the

VLSI circuit design procedure is to create a layout of dif-

ferent layers that comprise the circuit. The layout consistsh

of various geometric configurations to be patterned as layers

of different materials on the chip. The fabrication process

uses this layout as the description of the circuit.

On the layout, various geometric restrictions such as

minimum width, spacing and overlap between layers are placed.

These restrictions result in a set of geometric design rules,

' specific to a particular fabrication process. Since these

design rules originate directly from the nature of the fab-

rication process, it is extremely important to obey them

strictly so that (1) the design remains within the limitation

of the fabrication process and (2) the circuit description

is preserved in the fabrication process.

Although significant advances are being made in the de-

velopments of CAD tools to create layouts automatically, In-

tegrated Circuit (IC) design still heavily depends on manual

Introduction 1

Page 13: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

operations, especially in custom chip design. When the cir-

cuit complexity of a chip increases to the level of complex-

ity of a VLSI circuit, the probability of violating design

rules becomes significant. Additionally, it is almost im-

possible to check a circuit for the design rule errors manu-

ally. It is for this reason that a software to carry out

design rule checking, commonly referred to as a Design Rule

Checker (DRC), must be developed.

A DRC accepts a geometrical description of layout as an

input, typically in the form of a database, and produces an

indication of the design rule violation in the layout as an

output. In addition to this basic function of detecting vi-

olations, a DRC should have the following features to be an

efficient and effective tool in VLSI design.

1. Speed: Due to the complexity of a VLSI circuit, it takes

a fairly long time to carry out design rule checking on

even moderate size design. Therefore, the execution

speed of a DRC should be made as fast as possible.

2. Interactivity: Since, in general, a layout is created

interactively using interactive graphic editors, design

rule checking also should be accomplished in an interac-

tive manner, i.e, all the information about a design rule

Introduction 2

Page 14: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Vviolation should be displayed over the layout so that the

designer can correct any design rule violations easily.

3. Hierarchical nature: Due to the hierarchical nature of

the database created by many layout editors, design rule

checking becomes very efficient if it is carried out hi-

erarchically.

One drawback of the previous design rule checking algorithms

are their long execution time [12-15]. As a solution to thish

problem, Arnold [1] proposed a new design rule checking al-

gorithm, called the "Corner-based" algorithm, for "Manhattan

circuit". A Manhattan type circuit is a layout which con-

sists of only rectangles. In the corner-based algorithm,

each design rule is specified by the geometric patterns of

the corner and corresponding constraints which should be kept

at all corners having ‘the same geometric pattern. Here

"corner" means four corners of a rectangle as well as inter-

sections between rectangles. Since the design rule checking

is performed by processing only corners of the layout, this

algorithm can save much execution time compared to previous

design rule checking algorithms.

In this thesis, the corner-based algorithm and its im-

plementation are presented. Also the interfacing of the DRC

Introduction 3

Page 15: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

with. the integrated. circuit layout editor, called ICICLE

[17-18], is described.

Chapter 2 describes the X-based NMOS design rule given

by [3] and [4]. Chapter 3 reviews some existing design rule

checking algorithms. Chapters 4 and 5 describe the corner-

based algorithm and its implementation.

Introduction 4

Page 16: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

2.0 LAMBDA-BASED NMOS DESIGN RULES

As stated in chapter 1, design rules are certain geometrical

constraints given to the designer so that the geometrical

pattern of the design is preserved in the fabrication proc-

ess. These constraints are given in terms of minimum re-

quirements for line widths, spacings, extensions and overlaps

in various IC mask layers.

· Lambda-based NMOS design rules were developed by Mead &

Conway [3]. In this set of design rules, all the rules are

specified in terms of a length parameter called "X". Before

X-based design rules were developed, the design rules were

specified in terms of more than one parameter and absolute

physical dimensions were used for specifying the parameters

according to the target fabrication process. The permissible

minimum feature size of the fabrication process is becoming

smaller with advances in fabrication technology. This de-

creasing trend of the minimum feature size has caused some

problems in using the traditional design rules. For example,

if the minimum feature size of the target fabrication process

is changed during the design period of a chip, that design

becomes obsolete. Moreover, since each process has its own

specific characteristics, an IC designed for particular

process may not be fabricable by other processes.

Lambda-based NMOS Design Rules 5

Page 17: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Lambda-based design rules can solve these kinds of

problems since only one dimensionless parameter "X" is used

for specifying the all NMOS design rules. In other words,

since the layout is designed on X, it can be fabricated byl

any process although the physical value of X varies depending

on the process.

The parameter X is defined as the minimum feature size

which can be fabricated by the process. This definition of

X can be interpreted in two ways:

1. Bound on the deviation of the feature size on the wafer

2. Misalignment of the mask from its original position

With these two interpretations of X, we can consider the

following situation that may occur in the fabrication proc-

ess. Suppose that an edge of a feature in one layer at a

design has deviated by lX, and one edge in another layer is

shifted by 1X due to the misalignment of that layer from its

original position. In this case, the original separation

between two edges increases by 2X. The fabricated chip can-

not perform the intended function if the original separation

is critical to its proper functioning. For this reason, any

feature should be at least 2X wide, and the separation be-

tween two features is also at least 2X to maintain the re-

Lambda-based NMOS Design Rules 6

Page 18: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

lationship between different features. From these basic

premises, Mead & Conway specified all the NMOS design rules

in terms of X as follows.

For polysilicon (poly) regions, basic 2X width and

spacing rules are adopted directly since there is no other

factor which has to be considered.

Diffusion regions need a udnimum separation 1X wider

than the basic 2X spacing requirement. Since the depletionI

region is formed outside the diffusion region, if two sepa-

rated diffusion regions are placed too close, then their de-

pletion regions will overlap and current can flow through the

overlapped depletion region. The basic width requirement of

2X is enough for proper functioning.

There is also a spacing requirement between pbly and

diffusion regions even though the two layers cannot be con-

nected unintentionally. If unrelated poly and diffusion

layers are overlapped accidentally, unwanted capacitance is

formed and the diffusion region is reduced since diffusion

region cannot be formed underneath a poly region. However,

since these two factors are not fatal in the proper func-

tioning of the design, only 1X spacing requirement is given

between two layers.

Lambda-based NMOS Design Rules 7

Page 19: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

For metal regions, a 3X width and 3X spacing are re-

quired. Metal layer is patterned last among all the layers

and covers the other layers which are already patterned.

Therefore, this layer has much more non-uniform terrain to

cover compared to the other layers. For reliable covering,

one more X is added to both the basic width and spacing re-

quirements. The width and spacing rules for above three

layers are shown in Figure 1.

When a diffusion region and a poly region are overlapped

to form a MOS transistor, two unwanted geometrical config-

urations can be formed. If the diffusion region does not

cross the poly region completely, the drain or source region

of the transistor is not formed. If the poly region does not

reach the end of the diffusion region, the drain and source

of the transistor will be shorted. To prevent both cases, a

requirement of the 2X extension of poly and diffusion from

the boundary of the transistor gate region is given as shown

in Figure 2.

In the depletion mode transistor, if the channel between

drain and source is not filled completely with ion-implant,

a small part of the channel will operate as an enhancement

mode transistor. To avoid this, a 1.5X extension of ion-

implant is required beyond the boundary of the gate region

as shown in Figure 3. Moreover, to prevent other nearby en-

Lambda-based NMOS Design Rules 8

Page 20: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Z S SZ S SZ S SZ S SZ S S

lalglnllßlälDIFFUSIONEmmen.

Page 21: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

D

§ä¢i¢i¢i¢i¢i¢i¢i¢§Ä%•!•!•!•!•!•!•!•!‘\IÄ

§ mßmsxom

Figure 2. Transistor overhang rule.

Lambda-based NMOS Design Rules 10

Page 22: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

hancement mode transistor from operating as a depletion mode

transistor, a 1.5X spacing requirement between ion—implant

and unrelated transistor gate is given. This rule is also

shown in Figure 3.

The purpose of a contact cut is to connect the metal

with either poly or diffusion region. To form the proper

connection, the two different regions ( 'metal & poly' or

'metal & diffusion' ) should be placed within the contact cut

window. This allows the metal to reach the poly or diffusion'

region on the silicon wafer through the contact cut window.

To ensure a proper connection, it is required that lX of

metal AND (poly OR diffusion) surround the contact cut on all

sides. It is also required that the basic ZX width and

spacing requirements be followed during placement of the

contact cut window. These rules are shown in Figure 4.

When drain or source of a transistor is connected to a

metal region xising a contact cut, ZX separation between

transistor gate region and contact cut is required. If the

contact cut window is placed very near the transistor gate

region, drain or source of the transistor may be connected

to the gate of the same transistor in the fabrication proc-

ess. This spacing rule between transistor gate and contact

cut is shown in Figure 5.

Lambda-based NMOS Design Rules ll

Page 23: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

· I1.5

7 II·ww ‘Q•:•:•:•a

\I-„__-I ßImA

I=0I.Y

§ DIFI-'USION

Figure 3. :gäei$:1;;uixr;;;;;g§•overhang rule for de-

Lambda-based NMOS Design Rules 12

Page 24: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

I1I2 I1! I1I2 I1! I1I2 I1!I I—— I ' 1 VI 0A

I CUTI 2I I 2I

Figure 4. Contact cut surrounding rule.U

Lambda-based NMOS Design Rules 13

Page 25: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

|2VgIA

Y§ Ä W\ | CUTk äkä

é

Figure 5. Spacing rule between transistor gate and con-tact cut.

Lambda-based NMOS Design Rules 14

Page 26: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

There are two kinds of constructs used to connect the

diffusion and poly regions. Cne is the "butting contact" and

the other is the "buried contact". In a butting contact, the

connection between the diffusion and the poly layer is made

using an ordinary contact cut window. The same method as in

the pure contact cut is used in this contact, and then the

surroundings requirements of the contact. window are also

given to the butting contact. In addition to the sur-

roundings requirements, to make sure of the connection be-

tween <iiffusion and poly region, ll overlap is requiredu

between poly and diffusion reigon. Figure 6 shows the con-

figuration of the butting contact.

For a buried contact, the first step in making a con-

nection is to remove the thin oxide layer between poly and

diffusion layer. This necessitates an additional masking step

to remove the thin oxide layer. This buried contact rule is

not specified in the Mead & Conway NMOS design rules. Al-

though the same configuration is used in general, the minimum

distance requirement is slightly different depending on the

fabrication process. Since the silicon broker used by VPI &

SU and many others is MOSIS, we will describe the buried

contact rules which have been prescribed by MOSIS [4].

There are three confiqurations for buried contacts as

shown in Figure 7. In this figure, the configuration (a) and

Lambda·based NMOS Design Rules 15

Page 27: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

I 6

I4__ Q Pow

Ivv

I ___ 4 Q METFIL_?I CUT

I1 I 2 I1 I1 I1 I

Figure 6. Butting contact.

La.mbda—based NMOS Design Rules 16

Page 28: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

buried cut

diffusion

w

——7 :•:•:•¤Q2 \2LL2

Alglalal l2l2!2! |2|2|2|(a) (lo) (c)

Figure 7. Buried contacts.

Lambda-based NMOS Design Rules 17

Page 29: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

(b) are used for straightforward connections and (c) is used

for pu11—up transistor compaction. There are two require-

ments for a buried contact. First, the buried cut window

should be 6X wide and 6X long to provide enough space for

connecting diffusion and poly. Second, the poly-diffusion

overlap should be at least 2X X 2X square and this square

should be placed at the center of the buried contact window

as shown in Figure 7.

Due to the potability of the X-based design rules, the

development of the DRC software has been accelerated. In the

next chapter, we will introduce two most commonly used DRC

algorithms.

Lambda-based NMOS Design Rules 18

Page 30: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

3.0 EXISTING DESIGN RULE CHECKING ALGORITHMS

Among the existing design rule checking (DRC) algorithms, two

algorithms have been used most commonly. One is Polygon Al-

gebra algorithm and the other is Raster—scan algorithm. In

this chapter, we will describe these two algorithms briefly.

3.1 POLYGON ALGEBRA ALGORITHM

[Most of the running DRC in industry have been developed based

on this polygon algebra algorithm [12-15]. In this algo-

rithm, the smallest entity is a polygon and each mask layer

is treated as a collection of polygons. An algebra is de-

fined to manipulate and combine the layers. This algebra in-

cludes various operations such as growing and shrinking

polygons on single layers, merging of all intersecting

polygons, intersection, union and difference of layers and

so on. Using this algebra, all kinds of design rules can be

checked. For example, a typical way to perform a spacing

rule check is to grow each polygon by half of the minimum

spacing and then to look for intersecting polygons. In the

worst case, the number of comparisons needed to determine all

polygon intersections is proportional to the square of the

number of polygons. For the rules in which the transistor

Existing Design Rule Checking Algorithms 19

Page 31: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

gate is involved, one additional layer "transistor" is de-

rived using the polygon algebra:

transistors = poly AND diffusion.

Using the algebra outlined above, design rule violations are

found by a sequence of operations on the original and derived

layers.

A strong merit of this method is its use of algebraic

operations. Using these algebraic operations, any design

rule set can be specified very easily. Even complex rules

may be described in a straightforward manner, although they

may require long sequences of operations.

Polygon algebra algorithm has several drawbacks. First,

the entire layout is treated as a single entity: all oper-·

ations should be performed on the entire layout and cannot

be applied to small areas of the design. Therefore, if the

design is large, execution time will be very long. Since some

operations need comparisons, if the size of the design is

doubled, the execution time may increase four times in the

worst case. Recent design rule checking algorithms reduce

the number of comparisons by using sorting and windowing

techniques [10]. Secondly, this algorithm requires a large

amount of storage due to the creation of many intermediate

Existing Design Rule Checking Algorithms 20

Page 32: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

layers when multilayer checking* is jperformed. Moreover,

since this database is maintained on disk, frequent accesses

to disk make the processing slow. If the design is large,

this problem becomes very severe.

As we see in the above, polygon algebra algorithm has a

drawback in its slow speed. Therefore, if we consider the

trend of increasing chip complexity, this algorithm may not

be applicable to the complex design of the future.

I3.2 RASTER—SCAN ALGORITHM

The raster5scan algorithm is proposed by Baker [7] and can

be used only for Manhattan type circuits. The basis for the

algorithm is that all the basic design rules are local, in

that they are only minimum widths and spacings. For this

algorithm, the layout is represented on a ) grid. Each

pixel, a 1) X 1) square on a grid, contains one bit which

represents the existence of the layer at that position for

each layer. Since the maximum width and spacing requirement

is 3) (for metal), a 4) X 4) window will view sufficient in-

formation so as to allow for detecting the width and spacing

rule violations. Shown in Eügure 8 is one example of a

spacing rule violation on metal in the 4) X 4) window.

Existing Design Rule Checking Algorithms 21

Page 33: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

M M M M

M M M M

Figure 8. Spacing rule violation of metal in the 4). X4A window.

Existing Design Rule Checking Algorithms 22

Page 34: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Design rule checking is accomplished by moving the win-

dow over the layout, in the horizontal and vertical direc-

tion. Multilayer rule checking is performed i11 a similar

manner. For example, if four pixels in the center of the

window are all contact cut, then the whole 4X X 4X window

should be filled with 'metal AND poly' or 'metal AND dif-

fusion' to meet the minimum surroundings requirements speci-

fied in the design rules of Chapter 2.

In the raster—scan algorithm, design rules are specifiedl

in two ways: using tables and using special purpose code.

For example, two tables are constructed for the width checks.

One table is for the 3A width check and the other is for the

2X width check. There are two entries in the table. One

entry is a number which represents the layer arrangement in

the 4l X 4X window. The other entry is a bit indicating

whether or not that arrangement of the layer violates the

width rule. Since there are 2" possible arrangements of a

layer in the window, 8K bytes of memory are necessary to

store one table if a memory address is used to image a layer

arrangement in the window. In this table, 1 means that the

layer arrangement of the window does not represents a design

rule error and O means it does.

The special purpose code is constructed for multilayer‘

checking. Because the number of possible windows is so large

Existing Design Rule Checking Algorithms 23

Page 35: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

if mutilayer interaction is considered, the table look-up

technique requires large memory space. Special purpose coding

eliminates this need for large memory.

The raster-scan algorithm has the following limitations.

First, since the knowledge of design rules is embedded in the

tables and special purpose code, when the design rules are

changed, the tables and special purpose code must be rewrit-

ten. Moreover, if the new design rule set requires a window

larger than 4l X 4l, it becomes very expensive to examine all

possible windows. If the window size is increased to öl, it

is almost impossible to apply the raster-scan algorithm. The

second limitation is that the entire layout is scanned by the

window. This causes execution time to be wasted if the lay-

out area contains some empty regions.

Compared to the raster-scan algorithm, another technique

of DRC called "Corner—based" algorithm has following advan-

tages. First, the corner—based algorithm is much easier to

specify the design rules, and it requires less memory space

than the raster-scan algorithm. Second, since design rule

checking is accomplished by' checking the local geometric

constraints, it is faster than the raster-scan algorithm

which scans the entire layout. We will see the reasons for

these advantages when the corner-based algorithm is discussed

in Chapter 4.

Existing Design Rule Checking Algorithms 24

Page 36: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

4.0 CORNER-BASED DESIGN RULE CHECKING ALGORITHM

4.1 AN OVERVIEW OF THE CORNER-BASED ALGORITHM

The basis for the corner-based DRC algorithm comes from the

fact that all geometrical design rules of the IC layout can

be specified as constraints on the presence or absence of

layers in the neighborhood of corners of a layout. It must

be assumed that the entire layout consists only of rectan-I

gles. Here the corner refers to the four corners of a rec-

tangle and intersections between other rectangles as shown

in Figure 9. The specification of the design rules by con-

straints can be explained as follows.

Consider the metal box in Figure 10. To satisfy the 3l

spacing rule of Chapter 2, there should not be an unrelated

metal box within the region bounded by dashed lines. We ob-

serve that the regions R1, R2, R3, R4 have the corners Cl,

C2, C3, C4 respectively, and the layer arrangement around

each corner is distinct. Thus, the spacing requirements for

the region R1, R2, R3, R4 can be specified as the constraints

on the corners C1, C2, C3, C4 respectively, as shown in Fig-

ure ll. As we see in Figure 11, a spacing constraint is de-

termined by a geometric layer arrangement around the corner.

This geometric arrangement will be called a "context pattern"

Corner-based Design Rule Checking Algorithm 25

Page 37: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

I! 3r

ßß ¢ Q- =>=/„H HL „I! I ‘

° ° 0 camuza

Figure 9. Corners in the design.

Corner—based Design Rule Checking Algorithm 26

Page 38: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

I" 7 7 77 7 7 7 7 7 7 7 7 77 7 7 ‘l

1 II II 1‘·: : V ' — : : g'

I 31. 1 31. EI 1

1 R6 ' · R8 :11

1- — — . *· — *11 II ll 11 R3 1131- R7 31-11 R4 1L .„ ... JL, — .. ... .. .. .. .— .„ ..11. .. .. J

Figure 10. Spacing requirement on a metal box.

Corner-based Design Rule Checking Algorithm 27

Page 39: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

of the corner· under· consideration. in, the later chapters.

Since the constraints in Figure 11 cannot check the space

requirements for the region R5, R6, R7, R8, it might seem

that more constraints are necessary. However, if there is a

metal box in these regions, the violation can be detected by

the constraint on the corner of the box which resides in

these regions as shown in Figure 12. The constraints of the

spacing rule for other context patterns will be explained in

the next section.

In similar manners, all Mead & Conway design rules can

be specified with context patterns and constraints. Thus,

the actual design rule violations are detected by checking

constraints given to the corner. In order to check the con-

straint, the position and context pattern of the corner must

be known. Therefore, detecting a design rule violation is

performed by the following three steps.

1. Corner detection

2. Context pattern identification

3. Constraint checking

We can now see why corner—based algorithm performs ef-

ficient design rule checks. Since the number of context pat-

Corner—based Design Rule Checking Algorithm 28

Page 40: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

CONTEXT -CONSTRRLNTCORER PHTTERN

(IF) (THENB

!NOT M NOT M 1:

C1 I a Norm ä —NOT M / D Norm

D 3L

NOT M NOT M 1:F- ‘ NOT . °C2 NOT „ *

”‘ —Nora D

D NormNOT M

NOT .C3 NOT ml NOT M 3L ME

1. 1.

. . D/ NOT M tvorn

C4 § Nor m 1.NOT M NOT M

•..1.

. UU : @.°EL

Figure 11. Spacing rule specification for four cornersof the metal box.

Corner-based Design Rule Checking Algorithm 29

Page 41: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

V_° _ “' “ * " * — *1Z ;— 1F7:

.. R5 -1 ¤C1 , '° ° .AI .4 C2

C3 ‘C4

@ spacing rule violation

spacigng rule constraint

Figure 12. Spacing rule violation between two metalboxes.

Corner—based Design Rule Checking Algorithm 30

Page 42: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

terns is much less than the number of 4 X 4 matrices (2") ,

design rule specification is much simpler than that in the

raster-scan method. Moreover, since the design rule checker

already knows the positions of the corners, it can be intel-

ligent enough not to perform the rule checking in empty re-

gions, while the raster—scan method checks the entire layout.

Corner-based Design Rule Checking Algorithm 31

Page 43: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

4.2 SPECIFICATION OF NMOS DESIGN RULES

4.2.1 CONTEXT PATTERN

In the previous section, we defined "context pattern" as the

geometric pattern of the layout around a "corner". Since it

is assumed that the entire layout consists of only rectan-

gles, there should be a vertical edge and a horizontal edge

at every corner. Thus, layers around the corner can be con-

sidered as lying in a four quadrant plane with the origin at

the corner as shown in Figure 13. This means that there are

15 possible context patterns for one layer. Hence, for a

single layer rule specification, 15 constraints should be

specified. Also, a rule for more than one layer should

specify constraints for· all possible combinations of the

context patterns of each layer. These 15 context patterns

can be divided into 5 groups based on the similarity of pate

terns as shown in Figure 14. This similarity can make it

easy to specify the design rules because the constraints for

one group of context patterns can be obtained by finding just

one constraint and rotating it.

As an example, consider the metal spacing rule con-

straints in Figure 11. Notice that all four corners have

convex type context patterns. The three constraints on cor-

ners C2, C3, C4 can be found by rotating the constraint of

Corner-based Design Rule Checking Algorithm 32

Page 44: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

1 — 11 1 11

1 3* 113 4 1F 1 1 1

>x< CORNER

Figure 13. Four quadrants around a corner.

Corner—based Design Rule Checking Algorithm 33

Page 45: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

(a) convex type

II %I I%ll %I I%

(b) one—side type

I% ßl %% %%

(C) COTICBVB T.}/[J6

l% %!

(d) plaid type '

fe) all-filled

Figure 14. Five types of the context patterns.

Corner-based Design Rule Checking Algorithm 34

Page 46: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

C1 by 90, 180, 270 degrees, respectively. We will represent

each group of context patterns in Figure 14 by a single con-

text pattern and specify a single constraint for each group.

The name given to each group will be used to represent all

the context patterns in the group. The corner of any context

pattern will be described by the type of that context pat-

tern, e.g., the corner in a convex type context pattern will

be called a convex corner.

The size of the context pattern window should be deter-u

mined based on the basic unit of the layout. Since one-half

X is the basic unit of the layout editor being used, ICICLE,

the size of the context pattern is determined as 1X X 1X

square, i.e., two 0.SX X 0.5X boxes on each side of the con-

text pattern.

Corner-based Design Rule Checking Algorithm 35

Page 47: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

4.2.2 SPACING RULE SPECIFICATION .

4.2.2.1 SINGLE LAYER SPACING RULE SPECIFICATION

Single layer spacing rules indicate the required xninimum

distance between two separate regions on the same layer. In

this section, we will specify the constraints of this rule

for each type of context pattern.

The single layer spacing rule for a convex type corner,

shown before in Figure 10, is repeated in Figure 15. Note

the two small "NOT M" constraints. The reason for these con-

straints will be explained through following example. Con-

sider three metal boxes in which some edges have the same

x-coordinate or same y-coordinate shown in Figure 16. As

marked in Figure 16, these three boxes are violating the

single layer spacing rule. However, since the bottom edges

of box A and B have the same y-coordinate and the left side

edges of box B and C have same x-coordinate, these violations

cannot be detected by the big "NOT M" constraint. To detect

this kind of spacing rule violation, two small "NOT M" con-

straints are necessary.

Figure 17 represents the constraint due to the single

layer spacing rule for a concave corner. This constraint is

used to detect the spacing rule violation in Figure 18.

Corner—based Design Rule Checking Algorithm 36

Page 48: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

context _pattgpm COI"IST,I"äIV'1J('.

IF THEN21.61. D

I"_

'|'— “_“—”'I

1 g 1 1‘ V I ä I NOT I1 .1 1 IDIFI ILHYER I1 O 1 1’‘‘‘°1

OT LHYER IQ1.........1 GI

ID : minimum spacing requirement

(metal :3L, poIy,di¥¥uison,cut 2 EL)

Figure 15. Context pattern of a convex corner and theconstraint for the single layer spacing rule.

Corner-based Design Rule Checking Algorithm 37

Page 49: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

'

2 IFI

B

IVIETIZII.IVIETHL

._.ÄÄÄi§§iħ1i'!e::2:_1I2? I_ :z: NOT gQ Ü: I I

2:2 I•€ : IMETFIL :2; g

SPHCING RULE \/IOLHTION

Figure 16. Spacing rule violations detected by two small"NOT M" constraints.

Corner-based Design Rule Checking Algorithm 38

Page 50: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

context _constraintpattern

Al g i

D Q minimum spacing requirement(metal: 3L, di¥¥usion,poIy,cut: BL)

Figure 17. Context pattern of a concave corner and theconstraint for the single layer spacing rule.

Corner-based Design Rule Checking Algorithm 39

Page 51: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

metal metal

7777•‘•‘•‘¢•••<

OQQQ•*•‘•‘6••••_____.

metal

I 1 I

spacing rule violation

Figure 18. Spacing rule violation detected by the con-straint of a concave corner.

Corner-based Design Rule Checking Alqorithm 40

Page 52: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

M M}. .."‘°l.”. IA A A A._I

norn III I I__ norn '/ I ‘

Ä 4l _ _ I

M M Äl

M

><one—-side type corner

?spacing rule violationÄ

Figure 19. Spacing rule violation at a one—side corner.

Corner-based Design Rule Checking Algorithm 41

Page 53: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

A one-side corner is generated when two rectangles are

connected i41 parallel as shown in Figure 19. If there is a

spacing rule violation at this type of corner, this violation

also will be detected at convex or concave corner as shown

in Figure 19. This is due to the characteristics of

Manhattan circuits. In the box configuration of the above

example, the fact that the rectangles are rectilinear assures

that if they are separated widely enough at the end points,

then they do not violate the design rules at any point along

their lengths. Therefore, the single layer spacing rule need

not be checked at a one-side corner. y

A violation can be reported without checking any con-

straint if a plaid corner is found since the very existence

of such a corner is a spacing rule violation. For the context

pattern in which all four quadrants are filled, we cannot

identify any separation. Therefore, a constraint is not

necessary.

As the foregoing analysis explains, the single layer

spacing rule places constraints on only eight of the fifteen

possible context patterns. It should be noted that this is

much simpler than the spacing rule specification of the

raster-scan method._

Corner—based Design Rule Checking Algorithm 42

Page 54: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

4.2.2.2 INTERLAYER SPACING RULE SPECIFICATION

Five interlayer spacing requirements of the Memd & Conway

design rules are given in Table 1.

Table 1. Interlayer spacing rule.

V_'__—'"—'_"—"_"_'_'T_—”_——'“_“—7

I LAYERS I MINIMUM II I SPACING II I REQUIREMENTII I I

IIPoly & Diffusion I lX I

I Buried-Cut & I ZX II Diffusion I I

I Buried—Cut & Poly I 2X I

I TR-gate & I 1.5X II Ion-implant I I

I TR-gate & Cut to I ZX II diffusion I IL........................L............J

The only difference, with respect to the nature of the con-

text patterns and constraints, between the single layer and

interlayer spacing rule is that more than one layer is in-

volved. Therefore, the same constraints as in the single

layer spacing rules can be used for specifying interlayer

spacing rules with proper changes of layer types and minimum

Corner-based Design Rule Checking Algorithm 43

Page 55: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

distances. For example, the spacing rule between the poly

and diffusion for a convex corner of diffusion can be speci-

fied by the constraint on poly as shown in Figure 20. The

example shows that this constraint is same as the constraint

in Figure 15 except for the layer type and the minimum dis-

tance.

To check the interlayer spacing rule for transistor

gates, we also need to give special attention to the MOS

transistor gates besides different layer types and minimum

distances. Since two layers are involved in the MOS tran-

sistor gate, the overlap between diffusion and poly should

be considered as a single layer to specify the spacing rule

for the transistor gate by similar constraints as in single

layer spacing rule. In other words, if a corner with poly-

diffusion overlap is found, the context pattern of the over-

lap should be identified first. Then, the corresponding

constraint on the contact cut and ion-implant should be

checked. If the constraint is specified for the poly-

diffusion overlap, i.e., if a corner of cut to diffusion or

an ion-implant corner is found, the poly-diffusion overlap

should be searched in the constrained region.

Using the above ideas, all the interlayer spacing rules

can be specified as shown in Figure 21 - Figure 29.

Figure 21 and Figure 22 show the constraints on diffusion and

Corner-based Design Rule Checking Algorithm 44

Page 56: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

contextpattern constraint

IF THEN21.61. 11.

Not Not T T'’'''”

>„ I

6111 diff T E ' NOT 'Q I I .1dw1 ' '

J' Immm NOT I ä I

TOIYI

1 1;;1 NOT poly 1;L-—.... .. .1

Figure 20. A convex corner of diffusion and the corre-sponding constraint of poly layer for theinterlayer spacing rule.

Corner-based Design Rule Checking Algorithm 45

Page 57: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

buried cut for the poly context patterns. If a diffusion

corner which is involved neither transistor nor buried cut

is found, the interlayer spacing rule for poly and buried cut

should be checked. Figure 23 and Figure 24 show the specifi-

cation for this case.

For the buried cut corner, the constraints on diffusion

and poly should be checked as shown in Figure 25. Note that

the first quadrant of the top context pattern of buried cut

is empty. This indicates the "don't care" condition, i.e.,

this context pattern represents either convex or plaid type

context pattern.

As stated in Chapter 2, to prevent an enhancement mode

transistor from working as a depletion mode transistor, there

is a l.5X spacing rule between transistor gate region and

ion-implant. Figure 26 and Figure 27 show the specification

of this rule. The interlayer spacing rule between transistor

gate and cut to diffusion can be specified as Figure 28 and

Figure 29.

As we see in these figures, the constraints are speci-

fied for only convex and concave type of context patterns due

to the same reason, i.e., rectilinearity of the Manhattan

circuit and the spacing rule violations of plaid type cor-

ners, as in the single layer spacing rules. However, as

Corner-based Design Rule Checking Algorithm 46

Page 58: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

TF . THEN.ä;5I; IL

Not Not T T “’°’’T_ I 9- I I

P¤ IY PO I Y T I TE I NOT I_I I TO I Ii

IOÜ IY I I- I d I IOIO I¤=·~¤ NOT I 2 I Imov pOIy I. -

->I<________II I—I

I I NOT d I¥1'·‘

I.L------—¤

IF I. TI-IEN

pOIyNOTEND

0I · IUI

(Nor IIIIII P Y . _I NOT I

po I y po I y I _; I :·'.FIND I=II«I1;I I I

°‘' TT Icwor dwncwor dII¤¢> · >I<

’ I.. .....—.I

context . _ _I

„ 7

pattern CCJI’IS‘IlI";II"IT, .

Figure 21. Specification of the interlayer spacing rulebetween poly and diffusion for the contextpatterns of poly.

Corner—based Design Rule Checking Algorithm 47

Page 59: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

IF TI-IEN

Ia.sL _ jI._ _ _ INot Not T T Tpoly ·poly i Icél NOT I

lml mp¤Iy I lvl BUR Immm NOT _ lol I

mo? mm pOIy I--I_,

I Lw - als- JE

IF I. THEN

pwv

Iwt(NOTbur) · ·I NOT I

poly poly ‘ „ I URlg

nwm emu I I B I

Context Y constralntpatternT

Figure 22. Specification of the interlayer spacing rulebetween poly and buried cut for the contextpatterns of poly.

Corner-based Design Rule Checking Algorithm 48

Page 60: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

IF 1 · I T1-1po Y I EN diffgsi; it

wor woi ' * """"1 >„ 1 1

diff diff ¢ I 6 I NOV I ‘

(IHI

I O- 1 1:1u I I I- I po I IFIND NOT _ 1 Q 1 1‘"°* P°‘Y’

diff“ ‘ ‘>'<‘‘—‘——I

1 1-II 1 wot poiy 1§I L _ ... .. —

- ... J

IF I. THEN

dIII w0T -.-1B-mm I”

(WT P¤IY) · ·I I' diff diff ~ 1 I 1;'

awo awo 1 PO Y 11 1

I><—·————1

context .t

_pattepn cons

PaintFigure23. Specification of the interlayer spacing rulebetween poly and diffusion for the contextpatterns of diffusion.

Corner—based Design Rule Checking Algorithm 49

Page 61: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

IF _ TI-IEN

2;61. _ _ EL II moi moi I I Idiff diff ' Iäl NOT IJI Idiff

I I I,. I BURIN

RND NOT I I O I I(NOT bur) diffLD

I L 201 - 66 - I6

IF I. THEN

d"*wm'mm_ I I(NOT bu?) · .

I I

diff diff I I-1BLIR

‘“FIND FIND I I I‘N°T b“"’ (NOT bum §< I

_.____J

context I t_

tIOa.I’t6I,,_I,I COVIS I"äIV7 -

Figure 24. Specification of the interlayer spacing rulebetween diffusion and buried cut for thecontext patterns of diffusion.

Corner·based Design Rule Checking Algorithm 50

Page 62: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Ip THEN2.61. EL- _ _

Nor I;I“““IEUR . I §I ¤¤t R¤Iy I

DIIUm'IEI _ I

EUR _ I E I not d1¥¥ IEUR 1.-IJ

lnotpRNDnotd|‘*°I1. .. .. - I- -

— J N

IF'_ THENNOT

I21.. R

V““’'" ’"EU ·EUR I I not poly I

I

I I R}

EUR · I not di?? IEUR _ I I

I><—·—--—··

_iontext . .° . constra1ntpattern

Figure 25. Specification of the interlayer spacing rulefor the context patterns of buried cut.

Corner-based Design Rule Checking Algorithm 51

Page 63: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

IF THEN

I6.61. 21.„ .. 1* T TTTTTTTT

NUTI '°' '_ · 1 ä 1 NOT ~ 1

ION II§I:p¤1yn1~1¤ d1¢„¤>Iä„

11~·P1.1=m NOT I ~ I I ‘

1 110I .NQIii%PPLa

IF I. THEN «

ION I 21.I'"***“*

7IMPLFINT NOT I I II I NOT IION ION

'. . 'äI(p¤1y FIND daf?) I

I IMPLHNT 11«1=1.m~1T I II I

I><——-—-—J

context . I_

I. ‘ C OFT S 1^ E1 1 VTpattern

Figure 26. Specification of the interlayer spacing rulebetween transistor gate and ion-implantationfor the context patterns of ion-implantation.

Corner-based Design Rule Checking Algorithm 52

Page 64: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

IF „ THENatst 21.

Not Not [EI'I

(P FIND D) (P FIND D) ‘[

ä I I

I I IJdiff

IIE; tem BND diff)

IN

QND NOT I I O I IpO~Iy (PFNDD) I_$<_______I—I

Lw ;<=.¤w¤2>J§

IF I. TI-IEN

I ff NOT 2L. mm

’ ‘_ <I=• mu ¤> _ I I

diff diff It _t BND In Idnwm nwm

I°“ “‘I

pwv .01 °' '

I><———--—J

context . t _pättörm cons raint „

Figure 27. Specification of the interlayer spacing rulebetween transistor gate and ion-implantationfor the context patterns of transistor gate.

Corner—based Design Rule Checking Algorithm 53

Page 65: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

IF I THEN

:6.61. atI" T TTTTTTT'!NOT NOT ISI I

. cut_ _cut ‘ I? I NOT IIIE-Ifpoly

GNDI:INDNOT I I O I Icut cut L3><——————4J

LNQTllTPPLa

IF I. TI-IEN

wi?NormmI I Icut cut ' ‘

I NOT II

di?-F diffOl' Immm mmm 1· ’

1cut cut ‘ I . I

I

‘ ><--——--Jcontext . _ _

I· . VT I^ I I"I -pattern CO St a

Figure 28. Specification of the interlayer spacing rulebetween transistor gate and contact cut todiffusion for the combined context patternsof diffusion and contact cut.

Corner·based Design Rule Checking Algorithm 54

Page 66: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

IF 1 THEN

B;_5L _ ILSI;mot mot — T T T

11¤ emu m 11= mu ¤> · 1 1NOTT

1I-! .I

I I I"?di·F+“11.1ion—implant1”'

FIND NOT _ 1 O 1 1po T Y <1= mmm m ,_ E>1<_______;

1 mm‘1 1ö1.........1 W

T I IF I. THEN

dI¥‘F NOT r__‘f'—___nEND <1¤ FND m I I

emu emu I IpoIY pol §<·____—*!

context . Ü t intSV‘

pattern CO Ö

Figure 29. Specification of the interlayer spacing rulebetween transistor gate and contact cut todiffusion for the context patterns oftransistor gate.

Corner—based Design Rule Checking Algorithm 55

Page 67: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

mentioned above, there are two exceptions for the context

patterns of the ion-implant and buried cut because there is

no single layer spacing rule for the buried cut and ion-

implant. For other context patterns, the constraints can be

obtained by rotation of the constraints in these figures.

Corner—based Design Rule Checking Algorithm 56

Page 68: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

4.2.3 WIDTH RULE SPECIFICATION

The width rule is the requirement for the minimum width of a

layer. Identification of the end points of a rectangle is

the key to specify this constraint. The width rule con-

straints for five different types of corners are as follows.

For convex type corners, the layer should be extended l

by the minimum width in the direction from the corner towards

the interior of the rectangle. This is because a convex typeA

context pattern indicates that the corner is the end point

of the rectangle. Thus, for a convex corner, the width rule

can be specified as shown in Figure 30(a). Plaid corners are

not checked for the width rule errors because they are al-

ready in violation of the spacing rule. L

Since there are three end points in the concave type

corners, all the three end points should be extended into the

interior of the rectangle in order to satisfy the minimum

width requirement. Figure 30(b) shows the constraint for the

concave type corner.

In case of one—side corners, we do not need to specify

the constraints for the same reason as in the spacing rule

specification, i.e., since the entire layout consists of only

rectangles, if the width of a layer is satisfies the minimum

Corner-based Design Rule Checking Algorithm 57

Page 69: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

context constraintpattern -

TF

(al

context constraintpattern

xr mmZBL D

V

ä 1I .

mt

(b)

D 2 minimum wiuth requirement

(metal 1 El., di·F+'usi:zn,poly,cut · EL)

Figure 30. (a) Specification of the width rule for aconvex corner. (b) Specification of the widthrule for a concave corner.

Corner—based Design Rule Checking Algorithm 58

Page 70: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

I I I.„ -- _ - e ^ A 1

I—"&?I”—*”—ä'i“

I1 1 I 1EL 1 metal I l I Imetal II I 1 I 1

__ I

_ I1 I 1 I * * — ‘I

metal

ELC) one—side corner\\ convex corner//I

concave corner

I:] minimum width requirement (3L)

width rule violation

Figure 31. Width rule violations at convex, concave andone-side corners.

Corner—based Design Rule Checking Algorithm 59

Page 71: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

width requirement at the end points, then the width at any

point between the end points is also satisfactory. In other

words, width rule violation at any one-side corner can be

detected at the convex or concave corner. Figure 31 is one

example of a width rule violation at a one-side corner.

Since the all-filled corner does not contain any end

point, the constraint for the width rule is not necessary.

Consequently, only eight constraints are necessary to specify

the width rule.

Corner—based Design Rule Checking Algorithm 60

Page 72: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

4.2.4 TRANSISTOR OVERHANG RULE SPECIFICATION

The transistor overhang rule is defined as the necessary ex-

tension of the poly and diffusion around the transistor (TR)

gate region. The constraints for poly and diffusion should

be determined based on the boundary ofla TR gate region.

To explain the TR overhang rule specification, the most

common geometric configuration is shown in Figure 32. As we

see in this example, two features must be considered in orderU

to specify the TR overhang rule. One is the direction of the

extension of poly and diffusion and the other is the type of

the layer which should be extended. The direction of the

extension should be determined based on the boundary of the

TR gate region. The layer type should be same as the layer

which forms the border line with the TR gate region. In other

words, if poly is abutted to the TR gate region, poly should

be extended in the opposite direction to where the TR gate

region exists. On the other hand, diffusion is abutted,

diffusion should be extended. Considering these two things,

TR overhang rule can be specified by following approach.

Since two layers are involved in the TR overhang rule,

in order to specify the constraints, all possible combined

context patterns of poly and diffusion should be found first.

There are 15 possible context patterns for one layer at a

Corner-based Design Rule Checking Algorithm 61

Page 73: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

/*LEL ;\b‘•‘;‘•‘;°•‘;‘•‘;*•‘;‘¢‘ÖOOÖOOOOOOOQQOOOOOOOOOOO _•‘•‘•‘•‘•‘•‘•‘•‘•‘•‘•‘•*•!•!•2•t•t•2•!•I•t•2•t4%‘•°•°•‘•‘•‘•°•‘•‘•‘•‘§QOOOOOOOOOOOOOOOOOOOOOOO&!•!•I•Z•!•2•2•!•!•t•!¢6°•‘•°•°•‘•°•‘•‘•°•‘•‘•*§•‘•°•‘•‘•°•°•‘•‘•°•°•*\

II E LLL_F,F . .d 1 1.1 s 1 0n

N EE L YO C0 rT1 8 r‘ L

Figure 32 . Corners in a transistor .

Corner-based Design Rule Checking Algorithm 62

Page 74: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

single corner. Thus, there are 15 possible combined context

patterns of poly layer for one context pattern of diffusion.

Figure 33(b) shows the 15 combined context patterns for the

one convex type context pattern of diffusion in the

Figure 33(a).

The 15 combined context patterns are divided into three

groups according to the following characteristics. Group (A)

contains context patterns which have no overlap between poly

and diffusion. Thus, these context patterns cannot be con-U

sidered as transistors, and TR overhang rule checking is un-

necessary. However, all these context patterns violate the

interlayer spacing rule between poly and diffusion. There-

fore, the interlayer spacing rule violation should be re-

ported. In group (B) and (C) context patterns, there is at

least one overlapped quadrant. Since there exists a vacant

quadrant which is abutted to the overlapped quadrant (i.e.,

TR gate region) in the context patterns of group (B), these

context patterns already violate the TR overhang rule.

Therefore, for the context patterns included in group (B),

TR overhang rule error can be reported without checking any

constraint. On the other hand, the context patterns of group

(C) have the possibility of forming legal transistors. Thus,

for these context patterns, constraints need to be specified.

Figure 34(a) shows the constraints for the context patterns

of group (C).

Corner-based Design Rule Checking Algorithm 63

Page 75: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

llßl(a)

§ §§ l§ !§ ll §l §lS¤ ßl %§ ül (S äl Sgroup (H)

an um nn nußl S %‘I S äl° group (B)

§‘!*

group (C)

Y

§ r¤¤‘>/(b)

diffusion

‘Figure 33. Combined context patterns of diffusion and

poly for a convex type context pattern ofdiffusion.

Corner-based Design Rule Checking Algorithm 64

Page 76: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

For the other three convex type context patterns of the

diffusion, all the possible combined context patterns can be

obtained by rotating the combined context patterns in

Figure 33 by 90,-180, 270 degrees as mentioned earlier. As

a result, all possible combined context patterns can be di-

vided into three groups and the necessary constraints can be

obtained. Figure 34(b), (c), (d) show the legal context

patterns and corresponding constraints obtained by rotation.

For the context patterns obtained by combining polyA

context patterns with a one—side type context patterns of

diffusion, the TR overhang rule can be specified using an

approach similar to the one for a convex diffusion corner

described above. As the first step, the 15 combined context

patterns for a one-side diffusion corner of Figure 35(a) are

divided into three groups shown in Figure 35(b). By the

reasoning used in a convex diffusion corner, group (A) con-

text patterns contain the interlayer spacing rule errors and

all group (B) context patterns violate the TR overhang rule.

Only group (C) patterns can form legal transistors.

Figure 36 shows the corresponding constraints for these legal

patterns. Again, by rotation we can find the combined con-

text patterns and constraints for the other three one—side

context patterns of diffusion.

Corner-based Design Rule Checking Algorithm 65

Page 77: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

· COMBINEDc01~1T1:xT 1=>1=1TTs;12>1~1 CONSTRHINT

(IF') (THEN)

OR 2*-ezeää k$:é& OL *—

_ L(a)

OR 21.§I ää 2

(b)

2L

OR EL.ÜS Nä 21.L

(c)

Y‘

2L

_ ÄattI

- (dl

ß di·F+‘1.1si0n

p¤W

Figure 34. Specification of the transistor overhangrule for the combined context patterns ofgroup (C) in Figure 33.

Corner-based Design Rule Checking Algorithm 66

Page 78: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

%Ißl(a)

ZS MI S MS MS

group (H)

)Ag MS MI

group (B)

M. :·°§S MS

group (C)

r=¤‘v

tb)

di?-Fusion

Figure 35. Combined context patterns of diffusion andpoly for a one-side context pattern of dif-fusion.

Corner-based Design Rule Checking Algorithm 67

Page 79: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

comsxwsmcowraxr PRTTERN cowsramxmr

cxrn crmsmn

ELr' 2Ldl EL

2L

Qßägll 2L ‘2L2L

L

2L¤¤" ‘ L ‘\

~:4Ä IL Ä

di+°+“Lasion ooly

Figure 36. Specification of the transistor overhangrule for the combined context patterns inFigure 35.

Corner—based Design Rule Checking Algorithm 68

Page 80: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Using the same approach, we can get the legal combined

context patterns and corresponding constraints for the con-

cave type context patterns of diffusion. Figure 37 shows one

concave type context pattern of diffusion and the corre-

sponding 15 combined context patterns. The constraints for

the legal combined context patterns are shown in Figure 38.

Three more sets of constraints can be found by rotation.

If the four quadrants are filled with diffusion, there

are 15 combined patterns. These 15 patterns can be divided

'into five groups in Figure 39 based on the overlap pattern.

Notice that the single layer spacing rule of poly layer is

already violated in two plaid type overlap patterns. Thus,

these plaid type overlap patterns cannot be considered as

legal transistors. Figure 40 shows the constraints for one

combined pattern in each group. The constraints for other

combined patterns can be found by rotation of the constraints

in Figure 40. If all four quadrants are overlapped as in

Figure 39(e), the constraint is not necessary because this

context pattern does not contain the boundary of the gate

region.

Since two plaid type context patterns of diffusion con-

tain the spacing rule violation, no combined context pattern

can be considered as a legal transistor. Moreover, this

spacing rule violation will be detected by the single layer

Corner·based Design Rule Checking Algorithm 69

Page 81: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

%läß(a)

‘<;—> $6 W•_ V V Y ‘[ V * ·v

group (H)

wu ßl @%% üß Zffß :¤ äßgroup (B)

xx %läeiß

cc) Wgroup ääg poly

Y(F)Ä diffusion

Figure 37. Combined context patterns of diffusion andpoly for a concave type context pattern ofdiffusion.

Corner-based Design Rule Checking Algorithm 7O

Page 82: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

comamsmCONTEXT PHTTERN c0N5TRnIN7

cm m-uam

{2L

2LL

@ §EL@ di-Ffusion § poly

Figure 38. Specification of the transistor overhangrule for the combined context patterns inFigure 37.

Corner—based Design Rule Checking Algorithm 71

Page 83: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

' r r ' r v“ ewAQ Aw naß6* 's'€ ' VQA EZ

9 convex type overlapvv rv pwßv V 'vwwZZw ZH ww

one—side type overlap

·’¢‘·>'@‘ \"•:•·'QW V9:} \‘(

COTIC BVS T,}/pö overl ap

[

'~"1\'4 Vs:wA Emplaid type overlap

$¥*$._

all-filled overlap

% diffusion § poly

Figure 39. Combined context patterns of diffusion andpoly for the all-filled type context patternof diffusion.

Corner-based Design Rule Checking Algorithm 72

Page 84: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

COMBINEDCONTEXT PRTTERN CONSTRHINT

(IF)(THEN)OZ

2Lsezeü EL 2L

LCOTÜVGX OVG? Ü ap

ELv">~' >6¤sEZE IL ,

O!’ÜG"S Ü dG OVG? Ü ap

2LV§' V

äziäääCOFÜCBVG OVG? Ü ap -

6 = $#66 Y ·A A A OVÜß

pg | y

Figure 40. Specification of the transistor overhangrule for the combined context patterns inFigure 39.

Corner—based Design Rule Checking Algorithm 73

Page 85: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

spacing rule checking. Therefore, it is not necessary to

check the TR overhang rule for the combined context patterns

with these plaid type context patterns.

As shown above, many combined context patterns do not

need to be checked. Thus, TR overhang rule can be specified

very easily by grouping and rotation.

Corner—based Design Rule Checking Algorithm 74

Page 86: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

4.2.5 ION—IMPLANT OVERHANG RULE SPECIFICATION

The ion-implant overhang rule states the requirement for

the minimum extension of the ion-implant beyond the TR gate

region for proper depletion mode transistors. In order to

make a proper depletion mode transistor, a proper enhancement

mode transistor should first be formed. If the TR overhang

rule is violated, ion-implant overhang has no meaning because

the gate region which is referenced to build the ion-implant

overhang may be incorrect. In other words, when the designer

·corrects the TR overhang rule error, TR gate region can be

changed and ion-implant should be changed based on the TR

gate region. Therefore, it can be said that it is not nec-

essary to check the ion-implant rule for an illegal transis-

tor. It means that we do not need to specify the constraints

for illegally combined context patterns of poly and dif-

fusion.

For legal combined context patterns, if the ion-implant

layer is found at a corner, it indicates a depletion mode

transistor. The constraints for the ion—implant overhang

rule can be specified in a manner similar to the TR overhang

rule. Since the ion-implant overhang rule should be speci-

fied based on the TR gate region, the overlapped context

pattern is used for specifying the constraints. Figure 41

and Figure 42 shows the constraints for each type of over-

Corner-based Design Rule Checking Algorithm 75

Page 87: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

com-textconstraintpattern ‘

IFTHEN

RRNDD (P OR D) 1.51.FIND FIND

I I

1=>1=1~¤¤ Pmmn ion-impiant 1-ELFIND GND

I I

IF THEN

1.5L

1.5L

ion-implant*";"'Lä¤ <1= 012 mN_ HNÜ 1.61.L I

P HND D

(PFDSDDJIIion—·imp1antFigure

41. Specification of the ion-implant overhangrule for the context patterns of depletionmode transistors.

Corner—based Design Rule Checking Algorithm 76_

Page 88: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

context t . tP 1.pattern COÜS ä NIF THEN

@5*- 1.*51..(Poem „(PORD)<R|WNE) cewm ewm E

. Q- _I Iion—implant

xsl-

PFNDD (Poem: LBND HND gI I

ion—implant @-*31-

IFTHEN

Ls;PFWÜD (Poem:BND HND ISLI- I ° ion—imp}ant

PSVEQD WÄSDD ion—impiantastI I ·

Figure 42. Specification of the ion—implant overhangrule for the context patterns of depletionmode transistors.

Corner—based Design Rule Checking Algorithm 77

Page 89: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

lapped context patterns. The entire set of constraints can

be found by rotating these constraints. If four quadrants are

covered with poly—diffusion overlap and ion-implant exist at

the corner, these four quadrants should be covered with ion-

implant region.

Corner-based Design Rule Checking Algorithm 78

Page 90: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

4.2.6 CONTACT CUT SURROUNDING RULE SPECIFICATION

Since the contact cut has a particular shape as shown in

Figure 43, rule specification can be much simpler in spite

of the presence of three layers. In Figure 43, we imme-

diately note that all corners of a contact cut are convex

corners. If the contact cut is made by connecting two or more

small contact cuts, one-side or all-filled corners can exist

as shown in Figure 44. Although a contact cut which contains

the concave type corner is legal as in Figure 45, this kindu

of contact cut wastes chip area. Thus, if a concave contact

cut is found, it is better to warn the designer to correct

the shape of the contact cut. From this point of view, we

can say that only convex, one-side and all-filled contact cut

corners are legal. For these three legal context patterns,

constraints can be specified as in Figure 46 - Figure 49.

In context patterns of Figure 47, the reason for the

specification "NOT-POLY AND DIFF" and "POLY AND NOT-DIFF" is

to distinguish a pure contact cut from a butting contact.

As we know, there are four one-side type corners in the

butting contact and both layers, poly and diffusion, exist

at these four corners as shown in Figure 51 in the next sec-

tion. Moreover, if a contact cut corner without poly or

diffusion is found, a surrounding rule violation should be

reported.

Corner-based Design Rule Checking Algorithm 79

Page 91: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

$ contact cut\;O•¢•¢4\

metal mu(di·F·F OR poly)

Figure 43. Contact cut.‘

Corner—based Design Rule Checking Algorithm 80

Page 92: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

X one——side corner

O all-·Filled corner

Figure 44. One—side and all—filled corners in the con-tact cut containing more than one rectangle.

Corner—based Design Rule Checking Algorithm 81

Page 93: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Z contact cut

N metal RND(di¥¥ OR poly)

Figure 45. A contact cut containing a concave type cor-ner.

Corner-based Design Rule Checking Algorithm 82

Page 94: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

contextpattern = constraint

IF THEN‘ a.s•. IL —

NOT NOT .DIPF DIPFCUT CUT ‘

DND DDD éCUT NOT METRL METPL

CU' DIPF DIPF JDDD DDD Q

ME-ITD!. METFIL

a.sL IL

POLY POLY

l BND QND PI

METPL METPL

POL POLY äBND BND _

METPL METPL

Figure 46. Specification of the. contac.t.cut surroundingrule.

Corner-based Design Rule Checking Algorithm 83

Page 95: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

contextpattern - constralnt

IF THEN

CUT Not ° d111 Git? T1:1ND GND GND 6.61.<¤'“=“°*P CUT metal.TB„ig:é—ä]CUTd. . F . .NOT 11- d 1 1-·FGND GND GND 6.61.(D FND MIT P) ‘ __T______ ____ __

CU·T metal metal

6.6t 1L

IF — THEN

cut — _ TÜ ° TTEND

NO' poly po 1 yGND GND 6.61.

"”°*”° ·CUTmetal.CUTNot p¤lv p„1y

GND(P N NOT m CUT GNDF GND 6. 61.metal metal _ ‘

6.61. 1L

Figure 47. Specification of the contact cut surroundingrule.

Corner-based Design Rule Checking Algorithm 84

Page 96: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

IF THEN

c mu mr ¤ NOTV

CL]. NOTCUT .

OR ERROR

NOTCUT

CUTC PND PUTDmu

nor p °CUT

Figure 48. Specification of the contact cut surroundingrule.

Corner—based Design Rule Checking Algorithm 85

Page 97: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

contextpattern = constralnt

IF THEN

_ d1¥¥ d1+¥CUT CUT ewm mmm mst

metal metal

_ _ di+¥ d1¥¥CUT CUT QND QND Z. EL

metal metal

a6L ast

OR

. poly polyHND RND a.s».

metal .etalpmv pwyEND FIND 21.sx.

metal metal

.5L @.5L

Figure 49. Specification of the contact cut surroundingrule.

Corner-based Design Rule Checking Algorithm 86

Page 98: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

I" *‘ ‘

*'‘

* *' * * "II II SL II I

BLß _

I II II IL L •—„ „—„ L .. .— L L — ..| .

I:] contact cutl_l

meatl BND diff

% surrounding rule violation_

Figure 50.. Contact cut surrounding rule violations de-tected at one-side corners.

Corner-based Design Rule Checking Algorithm 87

Page 99: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

The constraints described above are sufficient to detect

the errors in larger contact cuts. Suppose that there is a

61 X 6k contact cut in which some area is not covered by metal

and diffusion properly as shown in Figure 50. Since, the

metal layer is disconnected, the one-side type corners marked

with }{ will be created. Thus, these surrounding rule vio-

lation can be detected by the constraints shown in

Figure 47. Consequently, all kinds of surrounding rule vio-

lations for contact cut can be detected.

Corner-based Design Rule Checking Algorithm 88

Page 100: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

4.2.7 BUTTING CONTACT RULE SPECIFICATION V

The butting butting contact rule can be divided into two

parts. The first is the surrounding requirement as in the

pure contact cut while the second is an overlap requirement

between poly and diffusion. For the surrounding requirement,

the constraints in Figure 46 - Figure 49 in the contact cut

surrounding rule can be used to detect all the surrounding

rule violations since this requirement is same as the sur-

rounding requirement for the pure contact cut. The shaded'

region in Figure 51(a) indicates the area which is covered

by the constraints of the pure contact cut. Within the un-

shaded region, which is not covered by the surrounding con-

straint, a set of proper constraints should be specified for

all the eight corners marked with Xs and circles in

Figure 5l(b).

In Figure 5l(b), poly—diffusion overlaps are found at

the corners marked with circles. The overlap between poly

and diffusion also exists in the transistor gate region. To

distinguish between two cases, the contact cut is searched

within the region which is a 1.5X X 1.5l square extended from

the corner of poly—diffusion overlap. If the overlap is

identified as the part of the butting contact, the butting

contact rule checking should be performed. Otherwise, the

transistor overhang rule will be performed. Due to the pe-

Corner—based Design Rule Checking Algorithm 89

Page 101: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

ILSLI :1..sLI QL

1I I

I° I

. . Z 4?s\E covere n y _ 4¤~~SUPPOUVTCIIVIQ VUIB

~«.>(' 1 1 1 1'

1 1 1 1,11.I 2L ·1Ll 2Ldi·FI'·“usion

Illcontact cut ä} I2

(b) butting contact

Figure 51. (a) Region which is specified by the contactcut surrounding rule. (b) Butting contact.

Corner·based Design Rule Checking Algorithm 90

Page 102: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

culiar configuration of the butting contact, the type of the

contact cut context pattern of the corner at which three

layer overlaps should be one-side at the corners marked with

Xs in Figure 51(b). In other words, if the overlap between

poly and diffusion is identified as part of the butting con-

tact and the overlap pattern is not one-side, then there must

be violation of the butting contact rule. This is also true

for vertically placed butting contacts. If the overlap pat-

tern is one-side, a check for overlap requirement of the

butting contact will be carried out at the corners marked

'with circles in Figure 51. The design rule checking proce-

dure for a corner with poly-diffusion overlap is summarized

as Figure 52(a).

If' a corner contains poly, diffusion and contact cut

like the corners marked with circles, it indicates the butt-

ing contact. If the butting contact overlap is made properly,

the context pattern of the contact cut should be one-side.

Other types of contact cut corners should be reported as the

butting contact rule violation. If the contact cut corner

has the one-side type context pattern at circled corners, the

combination of three context patterns should be one of the

four rows in Figure 53 for the proper overlap of the butting

contact. Figure 54 shows the constraints for these four

context patterns. These constraints are made to cover the

area which is not covered by the surrounding constraints.

Corner-based Design Rule Checking Algorithm 91

Page 103: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

IF poly AND diffusion AND not_cut AND not_buried THENckeck_butting_contact_or_not; ‘

.IF butting_contact THEN

_ check_butting_contact_rule;ELSE

check_transistor_overhang_rule;END IF

END IF

(a). Rule checking procedure for the corner ofpoly—diffusion overlap.

IF poly AND diffusion AND contact_cut THENIF contact_cut_pattern_<> one_side THEN

report_butting_contact_error; ·ELSE

IF combined_pattern_of_poly_diffusion_cut=legal THENcheck_the_constraint;

ELSEreport_butting_contact_rule_error;

END IF _END IF

END IF

(b). Procedure for the butting contact rule check-ing.

Figure 52. (a) Checking procedure for the poly-diffusion overlap. (b) Procedure for thebutting contact rule checking.

Corner—based Design Rule Checking Algorithm 92

Page 104: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

The above butting contact checking procedure for the corner

where three layers exist is be summarized as Figure 52(b).

For the other three butting contact configurations shown in

Figure 55, the similar constraints can be obtained by rotat-

ing the constraints of Figure 54.

Corner·based Design Rule Checking Algorithm 93

Page 105: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

I

34I

corner contact cut diffusion poly

aß ä3 tllläl Z"al äk

3 ä3 Wßl

oäFigure53. Combined context patterns of cut, diffusionand poly at the corners of contact cut in thebutting contact.

Corner-based Design Rule Checking Algorithm 94

Page 106: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

length unit v nambdafw I ccrncr

constraint

corner contact cut diffusion pony metal

2 1

1 I 11 1 @1 11 1 1 1 1

1 1 11 H1 @1 @11

2 I

3 1 I 12 1 I 1

1 1 1 1 11 1

I 11 1@Ü E ‘

Figure 54. Constraints for the context patterns in Fig-ure 54 for the butting contact.

Corner-based Design Rule Checking Algorithm 95

Page 107: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Figure 55. Three configurations of the butting contactobtained by rotation of the configuration inFigure 51.

Corner-based Design Rule Checking Algorithm 96

Page 108: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

4.2.8 BURIED CONTACT RULE SPECIFICATION

As described in Chapter 2, there are three types of valid

buried contacts as shown in Figure 56. In these three types

of buried contacts, the type of context patterns for the

buried cut at any corner is one of three types: convex,

one-side and all-filled. Even if the buried cut square con-

sists of more than one rectangle, the corner type should be

one of the above three types. Therefore, if any other type

of context pattern for a buried cut is found, a rule vio-A

lation is reported without checking any constraints. In

spite of this simplification, there are many corners to be

checked in one buried contact. If all of these corners are

checked, it will take a long time to process all the corners.

To solve this problem, one context pattern for buried cuts

is selected so that all the requirements of a buried contact

can be checked at one corner.

Since all buried contacts are bounded by 6X X 6X buried

cut square, the upper right corner exists in any buried con-

tact. Based on this, the buried contact rule checking can

be represented as Figure 57. Since different configurations

can be generated by rotating each configuration in

Figure 56, the total number of allowable configurations is

10. Each of these possible configurations must be consid-

ered. Among these ten configurations, there are two config-

Corner-based Design Rule Checking Algorithm 97

Page 109: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

I:] buried cut

% diffusion

wÄ s¤¤W_

' —--—-_-__—•---—-

‘PV'V* YEWl"Q

°'°''°'''•••<VX!}{III »•••«_._ L A;:¥:¥:éL _______ L

WI—

IWI_______ ÄIEIEIEI

Figure 56. Buried centacts.

Corner—based Design Rule Checking Algorithm 98

Page 110: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

IF buried_cut THENIF type_of_context_pattern =

( convex OR one_side OR all_fil1ed ) THENIF context_pattern represents upper_right_corner

THENburied_contact_rule_checking;

END IF · ·ELSE

report_buried_contact_rule_error; ·END IF

END IF -

Figure 57. Procedure for the buried contact rule check-ing.

Corner-based Design Rule Checking Algorithm 99

Page 111: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

urations that can be identified using the context pattern of

the upper right corner. This is because only these two con-

figurations have poly at the upper right corner of the buried

cut square as shown in Figure 58. The other eight config-

urations have no layer except buried cut at this corner.

Therefore, if no layer is found at this corner, it indicates

one of the other eight configurations. Constraints for the

right-corner-checkable configurations are given in

Figure 58.

For the other eight configurations, if all eight possi-

ble configurations are checked, it will also take much exe-

cution time. One way to reduce the number of configurations

to be checked is to inspect the other corner. For example,

if there exists a poly at the corner ZX to the left of the

upper right corner of the buried cut square, the number of

possible configurations is reduced to three as shown in Fig- '

ure 59. Constraints for this group of configurations are

given in Figure 59. Therefore, if the requirement of one of

these three configurations is met, then it represents a valid

buried contact. If none of these three requirements is met,

a rule violation should be reported. If a diffusion layer

is found at the position ZX to the left of the upper right

corner, it represents one of three configurations in

Figure 60. For the case that there is no layer except buried

cut at this position, it should be one of two configurations

Corner-based Design Rule Checking Algorithm 100

Page 112: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

context · constraint

pattern ®°"°* paay I:] bwIF THEN _

V vv/ gzg;./%:4' ••§

lälBUR NovHND OR

§ä¢i¢t¥:¢‘¥iääezzäl%

Figure 58. Specification of the buried contact rule forthe corner of buried cut with poly.

Corner-based Design Rule Checking Algorithm 101

Page 113: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Contextpattern ISOTTTpony.

nr man

NOTBR ' *

· bw n }•.•.zLnot pony

EUR' OR

4BNDR@+3LäOR

V

POLY?I•I•I•I•é Y R%+!•Z•2•t•2•§\X

_2 L >.Q.•.•.6.Q.•.1L

%lÄ

Figure 59. Specification of the buried contact rule forthe corners of only buried cut when a cornerof poly exists at left.

Corner-based Design Rule Checking ·Algorithm 102

Page 114: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Context constralnt

pattern Sd"?polyIF

THENgr V~¤l ä.BUR **0**V 5%%

· bu, A¢0!0!Q 4moNorRSIpfllyOR

X

RND 4

ORY A

Ä F'DIF. 7 ägIäl. vÜ Y

524*7 X. ,„ 04

Amro

Figure 60. Specification of the buried contact rule forthe corners of only buried cut when a cornerof diffusion exists at left.

Corner-based Design Rule Checking Algorithm 103

Page 115: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Context constralnt

pattern ®d"°l° poly I:} bur

IF THEN

NOTBUR ‘bur

.BND. NOTno1 poly

.BND BUR ‘¤o1

-

RND OR

YburFlND_

not poly

BND-.p 1 z +X—2L

Figure 61. Specification of the buried contact rule forthe corners of only buried cut when no layerexist at left except buried cut.

‘Corner-based Design Rule Checking Algorithm 104

Page 116: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

in Figure 61. Constraints for each of these group of con-

figurations are shown in Figure 60 and Figure 61. Using this

grouping technique, all ten configurations can be covered.

4.3 CORNER DETECTION AND BIT-MAP GENERATION

To apply the constraints specified in the previous sections,

we must know the position of each corner and where a layer

exists. Since the constraints are specified locally, only

local information for layout is needed. By locally we meanL

the small area of the design, i.e., the maximum area of the

constrained region is 61 X 6 X in the buried contact rule.

Although there are many ways to represent the layout, a lay-

out bit-map as used in the raster-scan method is appropriate

for a representation of the local area of the layout. In this

section, we will describe the algorithm for corner detection

and layout bit·map generation.

Since it is assumed that the entire layout consists of

only* rectangles, the only available information for each

rectangle zis two coordinates (i.e., the lower left corner

(xl,yl) and the upper right corner (xu,yu)) as shown in Fig-

ure 62. These two coordinates contain two kinds of informa-

tion as follows:

Corner-based Design Rule Checking Algorithm 105

l

Page 117: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

(Xu,yu)

(X ] ,y] )

Figure 62. Twe coordinates of a rectangle.

Corner-based Design Rule Checking Algorithm lO6

Page 118: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

1. Coordinates of the four corners of the rectangle, i.e.,

<xl„yl), (x¤„yl)„ (xu,yl>, <x¤,y¤)-

2. Existence of layer in the interval [xl,xu] from yl to yu.

Using this information, corner· detection and the bit-map

generation, which are static two dimensional problems, can

be translated to dynamic one dimensional problems [2].

A static two dimensional problem can be translated to a

'dynamic one dimensional problem as explained below. Consider

a horizontal line below the bottom edge of a rectangle. We

will call this line a "scanning line". As the scanning line

is moved upward, it will coincide with the bottom edge of the

rectangle and then the top edge of the rectangle. Since we

know the position (y-coordinate) of the scanning line, we can

detect the coordinates of the lower two corners of the rec-

tangle when the scanning line coincides with the bottom edge

of the rectangle. To generated the bit-map, a set of inter-

vals ,called ACTIVE_SET, along the x-axis is retained until

the scanning line reaches the end of design. When the scan-

ning line hits the bottom edge of a rectangle, the interval

[xl,xu] will be inserted to the ACTIVE_SET. Existence of a

certain interval in the ACTIVE_SET shows the presence of a

certain layer within that interval. Similarly, the coordi-

nates of the top two corners of the rectangle can be detected

Corner-based Design Rule Checking Algorithm 107

Page 119: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

when the scanning line coincides with the top edge of the

rectangle. When the top edge is hit by the scanning line,

the interval [x1,xu] will be deleted from the ACTIVE_SET be-

cause the layer no longer exists within the present scanning

line context. To find intersections between rectangles, each

time an interval is inserted to and deleted from the

ACTIVE_SET, the intersecting points are searched between all ·

the intervals in the set and the new interval. This is be-

cause intersections of two rectangles exist only at the bot-

tom or top edge of one of the two rectangles.

The procedure given above is summarized in the following

algorithm. Assume that the minimum x and y coordinates of

the layout are (0,0).

1. Sort the rectangles in order of the y—coordinates of the

bottom edge and also in order of y-coordinates of the top

edge. During the sorting, find the maximum x—coordinate

"xmax" and maximum y-coordinate "ymax" of the entire

layout;

2. FOR i:= 0 to ymax—l DO

FOR j:= 0 to xmax·1 DO

BIT_MAP[i,j] :=0; { initialize the BIT_MAP }

3. ACTIVE_SET :=empty_set;4.

CORNER_SET := empty_set;

5. FOR scanning_bar := 0 TO ymax DO BEGIN

Corner-based Design Rule Checking Algorithm 108

Page 120: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

a. FOR each rectangle with yl = scanning_bar DO BEGIN

1) insert (xl,yl) and (xu,y1) to the CORNER_SET;

2) find the intersection between the interval

[xl,xu] and all the intervals in the active set

and if it exists, insert the intersection to the

CORNER_SET;3)

insert the interval [xl,xu] into ACTIVE_SET;

4) END;

b. FOR each rectangle with yu = scanning_bar DO BEGIN

1) insert (xl,yu) and (xu,yu) to the CORNER_SET;E

2) find the intersection between the interval

[xl,xu] and all the intervals in the ACTIVE_SET

and if it exists, insert the intersection to the

CORNER_SET;

3) delete the interval [xl,xu] from the ACTIVE_SET;

4) END;

c. FOR each interval in the ACTIVE_SET DO

l) FOR i:= xl to xu—1 DO BEGIN

BIT_MAP[scanning_bar,i] := l;

d. END;

To see how this algorithm works, we will apply the above

algorithm to the layout which consists of two rectangles

shown in Figure 63(a) and will trace the algorithm step by

step. Suppose that coordinates of the two rectangles are

stored in the array as in Figure 63(b). Numbers which cor-

Corner—based Design Rule Checking Algorithm 109

Page 121: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

respond to the steps of the algorithm are shown as ——() at

the end of each operation.O

1. First two sort arrays will be produced according to the

order of y—coordinates of the top edge and bottom edge

of the rectangle as shown in Figure 63(c). xmax = 4,

ymax = 4 —- (1)

2. BIT_MAP[i,j] = 0 (1=0..3, j=0..3) -— (2)

3. AcT1vE_sET = { 1 —— (3)

4. CORNER_SET = { } -- (4)

5. scanning_bar = O —— (5)

•box[low_sort[1]].yl = scanning_bar, do FOR loop --

(5.a)

— CORNER_SET = {(1,0),(3,0)} -— (5.a.1)v

— NO intersection —- (5.a.2)

— AcT1vE_sET = {[1,311 -- (s.a.3)•

box[low_sort[2]].yl ¢ scanning_bar, skip FOR loop --

(5.a)

• box[up_sort[1]].yu ¢ scanning_bar, skip FOR loop --

(5.b)

•BIT_MAP[O,1] = 1, BIT_MAP[0,2] =1 -- (5.c)

6. scanning_bar = 1 ·— (5)

• box[1ow_sort[2]].y1 = scanning_bar, do FOR loop --

(5-a1

- CORNER_SET={(l,0), (3,0), (0,1), (4,1)} —·

(5.a.l)

Corner-based Design Rule Checking Algorithm 110

Page 122: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

(2,41

array of rectangie 1 Boxcm

(4 2) index xl yi xu yu1 11112 6 1 4 2.

(1,61

(ay (b)

LON_SORT_HRRHY UP_SORT_RRQHYindex box key index box key

1

—_

1 12 2 2 1

<<=)

Figure 63. (a) Two rectangles in the layout. (b) Data-base for two rectangles. (c) Two sort ar-rays in order of bottom and top edge of tworectangles.

Corner·based Design Rule Checking Algorithm lll

Page 123: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

— find intersecting point between [0,4] and [1,3]

—>CORNER_SET={(1,0), (3,0), (0,1), (4,1), (1,1),

(3,1)} —· (5.a.2)

— AcT1vE_sET = {[1,3],[O,4]} —· (5.a.3)•

box[up_sort[1]].yu # 1 —>skip FOR loop -- (5.b)•

BIT_MAP[1,i] = 1 (i=1..2), BIT_MAP[1,i] = 1 (i=0..3)

—- (5.c)

7. scanning_bar = 2 —— (5)

•box[up_sort[1]].yu = 1 -> do FOR loop -- (5.b)

— CORNER_SET={(1,0), (3,0), (0,1), (4,1), (1,1),

(3,1), (0,2), (4,2)} -- (5 b-1)— find intersecting point between [0,3] and [1,3]

->CORNER_SET={(1,0), (3,0), (0,1), (4,1), (1,1),

(3,1), (0,2), (4,2), (1,2), (3,2)} —- (5-b-2)h— AcT1vE_sET = {[1,3]} -- (5.b.c)

•BIT_MAP[2,i] = 1 (i=1..2) —- (5.c)

8. scanning_bar = 3 —— (5)

•box[up_sort[2]]].yl ¢ 3 -> skip FOR loop —— (5.b)

• BIT_MAP[3,i] = 1 (i=1..2) -- (5.c)

9. scanning_bar = 4 -- (5)

• box[up_sort[2]].yl = 4 —> do FOR loop —- (5.b)

— CORNER_SET = {(1,0), (3,0), (0,1), (4,1), (1,1),

(3,1), (0,2), (4,2), (1,2), (3,2), (1,4), (3,4)}

(5.b.1)

— NO intersections -- (5.b.2)

— AcT1vE_sET = { } -- (5 b.3)

Corner-based Design Rule Checking Algorithm 112

Page 124: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

10. scanning_bar=5 > ymax ·> END.

As shown in Figure 64, the final BIT_MAP represents the ori-

ginal layout and the final CORNER_SET contains all the cor-

ners of the two rectangles.I

In fact, if we consider the complexity of a VLSI circuit

. layout, it requires too much memory space to save all the

corners and the bit-map of an entire layout as in the aboveu

example. Since local areas of the layout are used i11 order

to identify context patterns and check the constraint, we do

not need to save the entire bit—map. Actual implementation

of this algorithm will be treated in the next chapter.

Corner-based Design Rule Checking Algorithm 113

Page 125: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

Y

4lIl 1 E3 I 1 1 I2 1 1 I 1

1 Q l 1 @Q X 1

Q 1 2 3 4

(4,1),(1,1),(3,l),

(B,2),(4,2),(l,2),3,2)

(1,4),(3,4)}

Figure 64. Final bit—map and detected corners.

Corner—based Design Rule Checking Algorithm 114

Page 126: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

4.4 A LIMITATION OF THE CORNER-BASED DRC ALGORITHM y

The Corner-based algorithm has a limitation in its ability

to perform spacing rule checks. Since the rule checking

ldepends only on local layout information, the connectivity

of layout cannot be considered. Due to the lack of this

connectivity information, false errors can be reported during

the spacing rule checking. For example, consider three metal

rectangles connected together as shown in Figure 65. The

corner marked with an X is one of the convex corners. When1

the corresponding constraint is applied, a spacing rule vio-

lation will be reported. However, the two rectangles A and

B are connected by the third rectangle C thus, the spacing

rule violation has no meaning and it should not be reported.

This kind of false error can occur in all kinds of spacing

rule checks. To solve this problem, information on the cir-

cuit connectivity as produced by a circuit extractor is

necessary. Circuit extraction is beyond the scope of this

thesis and as such the implemented DRC system will suffer

this minimal shortcoming.

Corner-based Design Rule Checking Algorithm 115

Page 127: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

POLY (FI) Ar_ 21. _Q.5L 3. >_I I ¤.I E321_1 NOT P 1,.11 1

[email protected] P

POLY (B)

Ü false spacing rule violation

Figure 65. A false violation detected in the spacingrule checks.

Corner—based Design Rule Checking Algorithm 116

Page 128: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

5.0 IMPLEMENTATION OF CORNER—BASED DRC ALGORITHM

5.1 DESIGN RULE CHECKER

5.1.1 CORNER DETECTION AND BIT-MAP GENERATION

As described in the previous chapter, each time the scanning

bar hits the bottom or top edge of a rectangle the corners

on the scanning bar are detected. Obviously, these cornersh

have the same y—coordinates. To check the design rules for

these corners, the bit—map for the local area of layout is

necessary since the constraints are specified for a local

area. To determine the size of window in which the bit map

should be generated, the following two things should be con-

sidered. First, if the size of the design is nk X mk, the

width of the window should be nk allowing a corner can exist

at any position on the scanning bar. Second, in the NMOS

design rule set, the maximum distance requirement is 6k (in

the buried contact rule). Thus, 6k is sufficient to check

possible the constraints. Therefore, to check the con-

straints of all corners on the scanning bar we need a bit-map

window of nk X 6k. Moreover, since the corners are detected

while the scanning bar moves upward, the window also should

move whenever the scanning bar moves. In other words, the

scanning window with a size of nk X 6k will scan the entire

Implementation of Corner·based DRC Algorithm 117

Page 129: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

layout from bottom to top and the bit-map within this scan-

ning window should be available all the time.

- Since this DRC software is written for ICICLE package ,

0.5X, which is the basic unit of ICICLE, is used as the unit

of the grid of bit-map. Based on this grid unit, the window

size is determined as 2n X 13 in actual implementation. To

implement the scanning window, 13 arrays in which each array

has 2n bit elements are used as in Figure 66. Each bit in

the array is set to 1 or O according to the existence of a

layer in that position. Since there are six layers in NMOS

layout, six scanning windows are necessary to represent all

layers.

ILine 13 in the scanning window plays the role of scan-

ning bar. As a result, whenever line 13 hits the top or

bottom edge of any rectangle, corner detection and bit-map

generation will be performed by the algorithm in the previous

chapter. The generated bit-map is stored in the 13th array.

When the scanning window moves upward by 1 unit, the ith ar-

ray is copied into the (i—1)th array. In this manner, the

bit-map within the scope of scanning window is available all

the time.

When a corner is detected by the scanning-bar, it is

located on the scanning bar, i.e., line 13 of the scanning

Implementation of Corner-based DRC Algorithm 118

Page 130: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

18

IIIII_________

i8 IIIII____-____H

IIIII-________

18

IIIII_________

8 IIIII_________8

IIIII________

7 IIIII_________8

IIIII_________

8

IIIII_________

4

IIIII_____—___

8 IIIII_________8

IIIII_________

1 IIIII__---____1 2 .„.,.... an

Figure 66. Grid on the scanning window.

Implementation of Corner-based DRC Algorithm 119

Page 131: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

window. However, in order to check the several constraints

at once, the corner should be located on line 8 of the scan-

ning window. The reason is as follows.

Suppose that one convex type metal corner is detected

as shown in Figure 67. This type of metal corner has 3A

minimum width rule constraint as well as the 3X spacing rule

constraint. In order to be able to check these two con-

straints simultaneously, the bit-map of region 3k above and

3X below from the corner should be available. Figure 67

shows that this is possible when the corner is on line 8 of

the scanning window. Therefore, the corner which is detected

by line 13 should be stored until the corner is located on

line 8 by the moving scanning window. For this reason, three

stacks are assigned to each line from line 13 to line 8 be-

cause there are three kinds of corners, i.e., bottom—edge,

top-edge and intersection corner, according to where they

exist in a rectangle. In the bottom-edge and top—edge corner

stacks, each element in the stack is a key of rectangle. An

element of intersection corner stack is the exact x-

coordinate of the intersection corner. The stacks are also

copied into the stacks of next line when the scanning window

moves upward. Therefore, the constraint checking will be

performed on the corners only in the stacks on line 8.

Implementation of Corner-based DRC Algorithm 120

Page 132: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

a.s¤. 3L

13—

| T IT2—

IN IIIHIIMI IITI NOT N Il O

9

_

Z · I8 ____„ I7 M0« M INOT N O — 77

5 —/9—

N NOT N " n l3_

1-2 A

BL —1

Fiqure 67. (a) A concave corner of the metal layer.(b)Constraints for the width and spacing rulesin the scanning window.

Implementation of Corner-based DRC Algorithm 121

Page 133: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

There is one exception to this scanning scheme which is

invoked for buried—contact rule checking. As explained in

the previous chapter, buried contact rule checking is applied

for only one particular context pattern, i.e., the context

pattern which represents the upper right corner of the buried

cut square. If this type of buried cut corner is detected

on line 13, the bit—map of the whole buried contact is al-

ready available in the scanning window since the edge which

is coincides by the scanning bar is the top edge of the buried

square. Consequently, the constraint for the buried cut

corner can be applied at line 13. If the buried cut corner

is checked at line 8 as in the corners of other layers, we

need a larger sized bit-map, i.e., more memory space is nec-

essary.

All of the above actions can be summarized algorith-

mically as in Figure 68. This pseudo code shows the overall

program flow of the design rule checker. Note that the de-

sign rule checking for the entire layout is accomplished by

repeated operation of corner detection, bit—map generation

and corner processing while the scanning window is scanning

the entire design. In the next subsection we will discuss the

implementation of the corner processing.

Implementation of Corner—based DRC Algorithm 122

Page 134: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

TYPErectangle = RECORD . ~

1ayer,x1;y1;xu,yu z integer ;END;

VARbox e array!no_of_rectran1ges] of rectanle;

BEGINinitia1ize_bit_map;corner_stack_initielization;top_sort_stack := sort( t¤p_edge;box );bottom_sort_stack e= sort( bottom_edge;box );

FOR scanning_bar := ymin TO ymax + 5 DO BEGINtop_corner_stack_13 := empty;bottom_corner_stack_13 := empty;intersection_corner_stack_13 := empty;

ägéää box! TOP(bottom_sort;stack) ].y1 = sc•nning_bar DObox_key := TOP(bottom_sort_stack);PUSH(box_key; bott0m_corner_stack_15);POP (bottom_sort_stack);END;

box! TOP(top_sort_stack) ].yu = scanning_bar DObox_key := TOP(t¤p_sort_stack);

A

PUSH(box_key, top_corner_stack_15)§POP(top_sort_stack);END;

de1ete_from_ACTIVE_SET( t¤p_corner_stack_15 );insert_to_ACTIVE_$ET( bottom_corner_stack_15 ); .find_intersections( intersection_c¤rner_st•ck_13 );bit_map_generation( ACTIVE_$ET;map_array_13 );

corner_processing_f¤r_buried_contact_ru1e_ch•cking(corners_at_1ine_13);corner_processing_for_ru1e_checking( corners_at_1ine_8 );

FOR i «= 2 to 13 DObit_map_array_i-1 •= bit_map_array_i;

FOR i == 9 to 13 DO BEGINbottom_corner_stack_i·1 := bottom_corner_stack_i;top_corner_stack_i-1 z= top_c¤rner_stack_i;ängerseciton_corner_stack_i-1z= intersection_corner_stack_i;

zum °END.

Figure 68. Overall flow of the design rule checker usingthe corner-based algorithm.

Implementation of Corner-based DRC Algorithm 123

Page 135: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

5.1.2 CORNER PROCESSING

In the corner processing procedure, actual design rule

checking is performed by the identification of context pat-

tern and constraints rule checking. The first step is the

identification of the context pattern. Since there are four

quadrants, i.e., four pixels, around a corner, all 15 possi-

ble context patterns can be represented as 4-bit binary num-

bers. Because each pixel is already represented by one bit

depending on the existence of a layer, the 4-bit binary num-

ber can be extracted directly from the bit-map. For conven-

ience of coding, this 4-bit binary number is converted to the

decimal number as shown in Figure 69(a). This number will

be called "pattern number" in the remainder of this chapter.

Figure 69(b) shows the pattern numbers of all 16 context

patterns. In the above manner, six pattern numbers for six

layers will be found at each corner.

After the calculation of the pattern numbers, corre-

sponding constraints will be checked. As described in Chap-

ter 4, all the constraints are specified for a certain

bounded region and the requirement is the presence or absence

of certain layer(s) on that bounded region. These con-

straints can also be represented as number codes. Since each

pixel of the bit-map represents the existence of a layer and

the size of the pixel (0.51 X 0.51) is known, the area of a

Implementation of Corner-based DRC Alqorithm 124

Page 136: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

E iQ

2 E

3 Q2 2

(a)

EE ä % % @ %Iß I%6 1 2 3 4 5 6 ?

II Il I% I% %I %I %% %%%I %% %I %% %l %%%I89 IG ll 12 13 14 15(lo)

Figure 69. (a) Four numbers assigned to the four quad-rants around a corner.(b) Sixteen patternnumbers for 16 context patterns.

Implementation of Corner—based DRC Algorithm 125

Page 137: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

bounded region can be represented as a number of pixels,

e.g., the area of 2X X 2) square is 16 pixels. Therefore,

constraints can be checked by counting the number of l's or

the numbers of 0's within the bounded region. To specify a

bounded rectangle in the bit-map, we need the width and

length of the bounded rectangle, the position of the corner,

the direction of expansion, and the layer type. All the pa-

rameters except the direction of expansion can be determined

directly by the constraint. The direction of expansion

should be determined according to the context pattern. For

the specification of the direction of expansion, one number

is assigned. to each corner of a rectangle as shown in

Figure 70. A routine called "COUNT_PIXELS", shown in

Figure 70, is written for counting the number of pixels con-

taising 1 within a rectangle whose boundary is specified by ·

the four parameters mentioned above.

The following example shows how a constraint is speci-

fied and checked using COUNT_PIXEL. Suppose that there are

two poly boxes which violate the spacing rule and we want to

check the spacing rule and width rule at the corner X as shown

in Figure 72. Since the "pattern number" of the corner X is

8 (refer to Figure 69), the spacing and width rule checking

can be represented as follows.

I

Implementation of Corner-based DRC Algorithm 126

Page 138: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

3

ÜFigure70. Numbers representing the expansion directionused in the routine COUNT_PIXEL.

Implementation of Corner-based DRC Algorithm 127

Page 139: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

FUNCTION count_pixel (layer: bit_map;corner_x,corner_y,width,length,expansion_direction: integer): integer;

BEGIN

CASE expansion_direction OF

1: lower_bound:= corner_y;left_bound:= corner_x;

2: lower_bound:= corner_y;left_bound:= corner_x·width;

3: lower_bound:= corner_y—length;left_bound:= corner_x;

4: lower_bound:= corner_y—length;left_bound:= corner_x-width;

zum { cAsE 1 .I

count_pixel:= O;FOR y:= lower_bound TO lower_bound+length-1 DO

FOR x:= left_bound TO left_bound+width-1 DOcount_pixe1:= count_pixe1 + layer[x,y];

END;

Figure 71. Function COUNT_PIXEL.

Implementation of Corner-based DRC Algorithm 128

Page 140: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

IF poly_pattern_no = 8 THEN

BEGIN

space_area := COUNT_PIXEL(poly,x,y,4,4,1);-- (1)

+COUNT_PIXEL(poly,x,y,4,1,2);-· (2)

+COUNT_PIXEL(po1y,x,y,1,4,2);-· (3)

IF space_area ¢ 0 THEN -—-—---Ä-----—-—-—-·--(4)

report_error(space_po_po,x,y);——-—--——-—-—(5)

width_area := COUNT_PIXEL(poly,x,y,4,4,4);--—(6)

IF width_area ¢ 16 THEN ——-———·-—--—------——-(7)

Ereport_error(width_po,x,y);e—--—--—---———-(8)

END;

In the above code, line (1), (2), (3) specify the region R1,

R2, R3, respectively using the parameters in COUNT_PIXEL.

Since there is xu: poly layer in R2 and R3, the value of

COUNT_PIXEL is O. However, there is one pixel inside the R1

(shaded pixel in Figure 72), thus, the final value of the

"space_area" will be 1. Therefore, the spacing rule vio-

lation will be reported as expected. Since the number of

poly pixels in the region specified in line (7) is 16, the

width rule constraint is satisfied. In this manner, all the

constraints can be specified as number of pixels.

In the actual implementation, the poly pattern number,

poly bit-map and required spacing distance are passed to the

Implementation of Corner—based DRC Algorithm 129

Page 141: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

ELI I I_I' "I“ 'I " ·IPOILYI

2 5L - V_'—

7_ EL

r.-·r· —I- J —

I I I I _

I II

I I R1 IIRBIII

I II _I „ I _' ———-———I

I I I R2 I Ü- 5L%¤Iv. EL

2L ' V 'IE47“

.. L. -I... .I - _I I I

EL

Figure 72. Spacing and width rule checks at a convexcorner of poly using the routine COUN'1'_PIXEL.

Implementation of Corner-based DRC Algorithm 130

Page 142: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

spacing rule checking routine so that this routine can be

used for spacing rule checking for other layers.

Implementation of Corner—based DRC Algorithm 131

Page 143: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

5.2 INTERFACING DRC WITH ICICLE

5.2.1 DATABASE CREATION FOR HIERARCHICAL DESIGN RULE

CHECKING ~ ·····—

In creating a database on which design rule checking will be

performed, the structure of the design should be taken into

account. ICICLE, to which this DRC is interfaced, generates

a layout which has a hierarchical structure. In general, a

tree structure layout is generated. A primitive element of

this hierarchical structure is a symbol definition, usually

called a "cell". A symbol definition is composed of a group

of rectangles and/or reference to other symbol definitions.

_

Due to the inherent regularity* of ‘VLSI layouts, one

symbol definition generally is used many times. Therefore,

if design rule checking is performed hierarchically, i.e.,

each repeated symbol definition by a call is checked only

once, much execution time can be saved compared to the

"flattening" method. Here "flattening" means the expanding

all the calls to the lower level symbol definitions in the

hierarchy.

In hierarchical design rule checking, interaction be-

tween symbol definitions is a major problem because design

rule can be violated between definitions even if each indi-

Implementation of Corner-based DRC Algorithm 132

Page 144: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

vidual definition has no inherent design rule violation. In

most of VLSI layouts, connections between symbol definitions

are made only at the boundary regions of the symbol defi-

nitions. To perform a check on the interaction between de-

finitions, we need information on rectangles which reside at

only boundary of the lower level symbol definitions. This,

of course, is provided that rule checking for lower level

definitions have already been performed. On the other hand,

if there is a rectangle which penetrates a lower level defi-

nition, we need information on all the rectangles which areI

involved in the connection with the penetrating box from

different symbol definitions.

There can be a case where flattened design rule checking

is suitable in spite of the hierarchical structure of the

layout. For example, the flattening method is very useful

in checking design rules for a PLA, since the PLA consists

of a number of small cells and there are many rectangles

penetrating. In this case, a flattened DRC will be much more

efficient.

To make it possible to check the design rules for all

three cases, one module called "drc_data_base" is added to

ICICLE. This module creates a database according to the op-

tion chosen by the user. The options are "Flattening", "Un-

flattening" and "User-defined-window". If a designer chooses

Implementation of Corner—based DRC Algorithm 133

Page 145: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

the "Flattening" option for a leaf cell in a tree hierarchy

or in a definition like a PLA, a database will be created

containing all the rectangles which belong to that symbol

definition and all the expanded calls of the symbol defi-

nitions.

For the case where interaction exists only in the

boundary of the definitions, the "Unflattening" option should

be used. If this option is chosen, a database is created by

following manner. First, all the rectangles of the defi-

nition which is called by the user will be put into the da-

tabase. After that, rectangles ,which reside in the boundary

regions, of the calls which are called by directly from the

current editing definition are put into the database. Here

the boundary region is defined as a symbol definition bound-

ing box shrunk by 4X. In other words, the bounding box of each

call is shrunk by 4X and all the rectangles which reside

outside the shrunk bounding box are put into the database.

Here 4X is used based on the contact cut and maximum spacing

requirement. For this reason, it is recommended that buried

or butting contact not be used in the connection between de-

finitions.

When the rectangles penetrate the lower level defi-

nition, the "User-defined window" should be used. To specify

an area to be checked, the designer defines a window with the

Implementation of Corner-based DRC Algorithm 134

Page 146: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

two points, (xmin,ymin) and (xmax,ymax). This window is ex-

panded by 31 in order to check all possible spacing rule er-

rors. After the expansion, all the rectangles inside the

expanded window, i.e., the region which is bounded by

(xmin—6,ymin—6) and (xmax+6,ymax+6), will be put into the

_ database. Obviously, this window should contain all the

rectangles which are involved in the connection around the

penetrating box.

Using three options given above, hierarchical designu

rule checking can be performed in the following 1nanner.

First, check the design rules of the leaf cell using the

"Flattening" option. If there is a design rule violation,

it should be corrected before checking the other definitions.

After leaf cells are checked, design rule can be checked for

upper level definitions using the "Unflattening" option or

"User—defined window" option depending on the existence of

the penetrating rectangles.

Once the database is created, it will be passed to the

design rule checking routine. Design rule checking is per-

formed on this database using the sequence explained in the

previous section.

1

i

Implementation of Corner-based DRC Algorithm 135

Page 147: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

5.2.2 REPORTING OF DESIGN RULE VIOLATIONS

Typically, design rule checking is performed in batch mode.

‘ In this situation, it is very difficult for the designer to

correct the design rule errors as the design evolves.

Therefore, the design rule checking should be performed

interactively during the design of a layout and the operation

of DRC should be compatible with the IC layout editing sys-

tem. Basically, there are two requirements for an interac-

tive design rule checker. First, it should be easy to invoke

the design rule checker inside the layout editor. Second,

the information about the design rule error should be pro-

vided in such a way that the designer can correct any design

rule errors easily.

The information necessary for the designer to easily

correct a design rule error includes information on the po-

sition of the corner containing the error and the type of

design rule error which has occurred. When ICICLE is being

used, the name of the symbol definition which has the invalid

corner is useful to the designer. This is because it is not

allowed to edit the called definition during editing the

calling definition. To provide these kinds of information

about a design rule error, a linked list, shown in

Figure 73, is constructed during corner processing. If a

corner containing a design rule error is found, all the in-

Implementation of Corner—based DRC Algorithm 136

Page 148: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

formation about the corner will be passed to the error re-

porting routine. These passed parameters will be stored in

a linked list structure shown in Figure 73. If there is no

design rule error, the head of the list called

"drc_error_list" will be left as NULL. After the processing

of all of corners is finished, the pointer "drc_error_list"

is passed to the error displaying routine. This error dis-

playing routine displays a marker at invalid corners on the

screen. Moreover, if the designer identifies a marked corner

by positioning the cursor at that corner, this routine will

display the definition name and types of design rule errors

found. If there is no design rule error, an appropriate

message will be displayed on the screen. In the above man-

ner, the designer can get all the information about design

rule violations and correct the violations very easily.

Implementation of Corner-based DRC Algorithm 137

Page 149: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

drc_error_l ist

krdlIX1 Y HI “

l X2 ya kind2 kindl

Ya EHI W><,,y, : oosition of the corner containing errordi r symbol definition index

kind i : type of design rule error

Figure 73. A linked list for design rule error report-ing.

Implementation of Corner-based DRC Algorithm · 138

Page 150: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

6,0 RESULT

The DRC program is written in the C programming language.Q

It contains about 3,000 lines of code and comments. This

software has been tested under VAX—11/785 using the students'

designs which were developed in a VLSI design course at VPI

& SU. As expected, the false violations are detected in the

spacing rule checks when particular configurations of inter-

connected rectangles are used. These false violations , when

recognized, should not cause the user_too much difficulty.

In order to allow the DRC to be used interactively with

ICICLE, a few commands are added to ICICLE [19]. Most users

are very happy with the interactive operations. Moreover,

it was found that the name of the symbol definition provided

in the error reporting is very useful to the user when cor-

recting design rule error. The implementation of the three

options for creating database to be checked was also very

successful. With these three options, very efficient design

rule checking could be performed. Especially, the "User-

defined window" option makes hierarchical design rule check-

ing possible for the design containing the penetrating box.

result 139

Page 151: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

7.0 COHCLUSION

We have presented an implementation of an interactive design

rule checker for IC layout. The DRC uses what is known as the

corner—based algorithm for rule checking.

The corner-based algorithm was selected due to the ease

with the specification of various design rules, locality

property and its relatively fast speed compared to the ex-U

isting algorithms. One limitation of this algorithm is the

detection of the false violation in the spacing rule checks.

However, this limitation is tolerable if we consider the ex-

pensive computation for the connectivity checking as used in

polygon algebra algorithm.

In interfacing the design rule checker with the layout

editor, ICICLE, interactive operations were designed so that

the DRC can be invoked inside the layout editing mode. For

ease of correction of the detected design rule violations,

all of the information about the violation, such as position,

type of violation, and symbol definition name are provided

in an interactive manner.

In creating the database used in checking, three options

are implemented in order to allow for effective hierarchical

conclusion 140

Page 152: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

design rule checking. Due to the locality property of the

checking scheme, the corner—based algorithm is appropriate

for incremental design rule checking. However, an incre-

mental DRC could not be easily implemented because of the

structure of the layout database in ICICLE. To construct the

incremental design rule checker, the database should be con-

structed based on the position of rectangles. Moreover,

since all the rectangles of the layout are stored in a linear

list in ICICLE, it takes a lot of time to access the rectangle

in the end of the list.

Concerning the problems mentioned above, we feel that

the data structure of the layout database should be deter-

mined based on the characteristics the CAD tools to be used.

This means that consideration must be given to CAD tools

which will be used in conjunction with the layout editor and

DRC such as a circuit extractor, router'etc. The software

designer must be aware of the overall CAD tool scheme in

which the layout database will be used.

} conclusion 141

Page 153: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

8.0 REFERENCES

1. Arnold, M.H. and Ousterhout, J.K., "Lyra: A New Approachto Geometrical Layout Rule Checking," Proc. 19th DesignAutomation Conf., 1982, pp. 530-536.

2. Wilcox, P., Rombeck, M. and Caughey, D.M., "Design RuleVerification Based on One Dimensional Scans," Proc. 15thDesign Automation Conf., 1978, pp. 285-289.

3. Mead, C.A. and Conway, L.A., Introduction to VLSI sys-tems, Reading: Addison-Wesley, 1980.

4. Privite communication with MOSIS, 1984.

5. Ullman, J.D., Computational Aspects of VLSI, Computer_ Science Press, 1983.

6. Lyon, R.F., "Simplified Design Rules for VLSI Layouts,"VLSI Design, First Quarter 1981, pp. 54-59.

7. Baker, C.M. and Terman, C., "Tools for Verifying Inte-grated Circuits Designs," Lambda, Fourth Quarter 1980,pp. 22-30.

8. Whitney, T., "A Hierarchical Design—Rule Checking Algo-rithm," VLSI Design, First Quarter 1981.

9. Baird, H.S., "Fast Algorithms for LSI Artwork Analysis,"Proc. 14th Design Automation Conf., 1977, pp. 303-311.

10. McCaw, C.R., "Unified Shapes Checker—A Checking Tools forVLSI,", Proc. 16th Design Automation Conf., 1979, pp.81-87.

11. Losleben, P. and Tompson, K., "Topological Analysis forVLSI Circuits," Proc. 16th Design Automation Conf., 1979,pp. 461-473.

12. Lindsay, B.W. and Preas, B.T., "Design Checking andAnalysis of H3 Mask Designs," Proc. 13th Design Auto-mation Conf., 1976, pp. 301-308.

13. Rosenberg, L.M. and Benbassat, C., "CRITIC: An Integratedl

Circuit Design Rule Checking Program," Proc. 11th DesignAutomaiton Workshop, 1974, pp. 14-18.

} References 142

Page 154: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

14. Hoglund, I. and Berg, H., "LSI Circuit Design," ComputerAided Design, 1976, Vol. 18, No. 3., pp. 165-174.

15. Yoshida, K., Mitshuhash, T., Nakada, Y. Chiba, N., Ogita,K. and Nakatsuka, S., "A Layout Checking System forLarge Scale Integrated Circuits," Proc. 14th Design Au-tomation Conf., 1977, pp. 322-330.

16. Taylor, G.S. and Ousterhout, J.K., "MAGIC's IncrementalDesign Rule Checker," Proc. 21st Design Automation Conf.,1984, pp 160-165.

17. Iacaponi, M.J, "ICICLE : An interactive Color IntegratedCircuit Layout Editor," VPI & SU Dept. of Electrical Eng.internal document, 1983.

18. Iacaponi, M.J., "ICICLE User's manual," VPI & SU Dept.of Electrical Eng. internal document, 1983.

19. Kim, K., "ICICLE-DRC User's Manual," VPI & SU Dept. ofElectrical Engineering internal document, 1985.

20. Aho, A.V., Hopcroft, J.E. and Ullman, J.D., The Designand Analysis of Computer Algorithms, Reading: Addison-Wesley, 1974.

k

References 143

Page 155: E by - Virginia Tech"Flattening", "Unflattening" and "User—defined window" are implemented in creating the database to be checked. The "User—defined window" option allows hierarchical

E

The author was born 1956 in Seoul, Korea. He

graduated from Choongang High School in Seoul and received a

B.S. degree in Electronic Engineering from Sogang University

in 1978. Since 1978, he has worked with the Agency for De-

fense Development, which is the only research institute for

national defense in Korea, for five years. He has been in-

volved in the project for Missile Guidance & Control SystemU

Design. In the Fall of 1983, he _enrolled in Virginia

Polytechnic Institute & State University, Department of

Electrical Engineering in order to pursue a Master of Science

in Electrical Engineering. His area of interest is Design

Automation of VLSI Circuits.

l

Vita 144