This HTML manual corresponds to Magic version 7.4 and technology formats up to and including 31. This manual is equivalent to the manual "Magic Maintainer's Manual #2" that comes with the Magic source distribution. The tutorial "WRL Extentions to the Magic Technology File" has been merged into this document.
Introduction
Downloads and Installation
Command-Line Invocation
Technology File Format Overview
Tech section
Version section
Planes section
Types section
Contact section
Aliases section
Styles section
Compose section
Connect section
Cifoutput section
Cifinput section
Lef section
Mzrouter section
Drc section
Extract section
Wiring section
Router section
Plowing section
Plot section
Conditionals, File Inclusions, and Macro Definitions
Magic Tutorial #1: Getting StartedYou should also read at least the first, and probably all four, of the papers on Magic that appeared in the ACM IEEE 21st Design Automation Conference, and the paper "Magic's Circuit Extractor", which appeared in the ACM IEEE 22nd Design Automation Conference. The overview paper from the DAC was also reprinted in IEEE Design and Test magazine in the February 1985 issue. The circuit extractor paper also appeared in the February 1986 issue of IEEE Design and Test magazine.
Magic Tutorial #2: Basic Painting and Selection
Magic Tutorial #6: Design-Rule Checking
Magic Tutorial #8: Circuit Extraction
Magic Tutorial #9: Format Conversion for CIF and GDS
Commands introduced in this manual:
path, tech, *watch
Macros introduced in this manual:
(None)
Changes since Magic version 7.4:
Changes since Magic version 7.2:
Changes since Magic version 6.5:
Magic is a technology-independent layout editor. All technology-specific information comes from a technology file. This file includes such information as layer types used, electrical connectivity between types, design rules, rules for mask generation, and rules for extracting netlists for circuit simulation.
This manual describes the use, contents, and syntax of Magic's technology file format, and gives hints for building a new one or (more typically) rewriting an existing one for a new fabrication process. References to specific files in the Magic distribution assume that your current working directory is the Magic source top-level directory.
Typically, there is a different technology file for each fabrication process supported by Magic. Scalable technologies, which are (within limits) independent of feature size, will typically have one technology file for all processes supporting the same set of lambda-based (scalable) DRC rules. That said, modern technologies (post-1980's, more or less) tend to be more restrictive in their design rules, and consequently not scalable. This is particularly true of processes which push the envelope on feature sizes.
The Magic source distribution is packaged with a "standard" set of scalable SCMOS rules, which is the technology loaded by default. Default settings are for 1psymm technology, which is out of date. However, the variety and availability of processes means that the "definitive" set of technology files is prohibitively large to be included with the Magic source. In addition, process refinements generally require technology file updates on a regular basis. Because of this, the basic collection of technology files is handled by the MOSIS foundation, not by the Magic development team. This collection represents all processes which are available for fabriction through the MOSIS foundation. Most other vendors have proprietary process specifications, requiring tool maintainers to write their own technology files or modify an existing one to match the proprietary process.
The standard technology file set can be downloaded from an FTP server at the MOSIS foundation. These files are regularly updated, but there is usually a symbolic link called "current" to the most recent stable revision. The download URL is the following:
ftp://ftp.mosis.edu/pub/sondeen/magic/new/beta/current.tar.gz
Assuming that the install destination for magic is /usr/local, this file should be put either in /usr/local/lib/magic/sys or (preferably) in /usr/local/lib/magic/sys/current. Other destinations may be used, if the system search path is appropriately specified on startup (see Section 3, below).
The technology file collection is in tarred, gzipped format, and should be installed with the following commands:
cd /usr/local/lib/magic/sys/current
gunzip current.tar.gz
tar xf current.tar
Once unpacked, these files are ready to be used in Magic.
You can run Magic with a different technology by specifying the -Ttechfile flag on the command line you use to start Magic, where techfile is the name of a file of the form techname.tech, searched for in one of the following directories (listed by search order):
tech load filename -noprompt [-nooverride]
A technology file is organized into sections, each of which begins with a line containing a single keyword and ends with a line containing the single word end. If you examine one of the Magic technology files in the installation directory ${CAD_ROOT}/magic/sys/, e.g., scmos.tech, you can see that it contains the following sections:
tech
version
planes
types
styles
contact
aliases
compose
connect
cifoutput
cifinput
lef
mzrouter
drc
extract
wiring
router
plowing
plot
These sections must appear in this order in all technology files. Every technology file must have all of the sections, although the sections need not have any lines between the section header and the end line.
Historically, technology files were written in a C-language context which was processed by the C preprocessor. This allows the use of C-language comments ("/* ...*/") and the use of preprocessing definitions ("#define ...") and conditionals ("#ifdef ...#endif"). The technology files were generated from a Makefile with the preprocessor constructs used to generate different sections of the technology file at different lambda scales. The decreasing use of scalable processes, however, has made this method largely obsolete, and the standard collection of technology files from MOSIS does not use them at all. Technology files are now written in their final form, not in preprocessed form. Information regarding preprocessor constructs is not included below, but can of course be obtained from the manual pages for the preprocessor itself (gcc or cpp). But also note that the use of C preprocessors for processing text files other than source code is now generally discouraged in favor of using a macro definition processor like m4 (see the manual page for m4 for details). On the other hand, macro definition processors are almost universally despised, so many preprocessor functions have been written into the technology file syntax.
The default scmos set of technology files included with the Magic distribution is still processed via the C preprocessor. Preprocessed files have the extension ".tech.in". Technology files written specifically for Magic version 7.3 tend to make use of additional features of the technology file syntax that subsume most of the functions of the C preprocessor and M4 processor normally used to generate technology files.
Each section in a technology file consists of a series of lines. Each line consists of a series of words, separated by spaces or tabs. If a line ends with the character " ", the " " is ignored and the following newline is treated as an ordinary blank. For example,
width allDiff 2 \
"Diffusion width must be at least 2"
is treated as though it had all appeared on a single line with no intervening " ". On the other hand, for the purposes of tracking errors in technology file input, the technology file parser treats these as separate lines, so that when magic reports an error on a specific line of the technology file, it will agree with the line numbering of the editor used to edit the file.
Comments may be embedded in the technology file. Magic's technology file parser will ignore all text beginning with the character # through the end of the line.
The rest of this part of the manual will describe each of the technology file sections in turn.
Magic stores the technology of a cell in the cell's file on disk. When reading a cell back in to Magic from disk, the cell's technology must match the name of the current technology, which appears as a single word in the tech section of the technology file. See Table 1 for an example.
Historically, most technologies were named scmos, largely for compatibility reasons. Magic version 7.4 has the command option "load -force" to force an attempt to load a layout drawn in one technology into a magic session using a different technology. Thus, the practice of naming all technologies scmos is highly discouraged, and meaningful names (e.g., a foundry process name) should be used.
Versions of magic prior to 7.2 embedded the format version of the technology in the file name, e.g., scmos.tech27. The last format version to use this syntax, 27, is still accepted as a valid filename extension. Many technology files still use this notation, including (at the time of writing) the collection from MOSIS. Now the format is declared inside the tech section.
If the "format version" line is missing, then the version is assumed to be 27. Otherwise, the compatible format version should be stated in this line. Magic version 6.5, 7.0, and 7.1 use format 27. The stable distribution version 7.4 uses format 31.
version version-stringThe version-string is not used in any meaningful way by Magic but should be used by technology file maintainers as a way to provide version control over technology file modifications.
description description-string [\
more-description]
The description-string is also not used in any meaningful way by Magic but will be printed to the terminal output and in the Technology Manager window display, and should be used as a sanity check on the technology currently in use for a project. The description may contain multiple lines of text if each line up to but not including the last end with a backslash ("\") character.
Both the version and description strings are retained by Magic and may be queried with the command "tech version".
The planes, types, and contact sections are used to define the layers used in the technology. Magic uses a data structure called corner-stitching to represent layouts. Corner-stitching represents mask information as a collection of non-overlapping rectangular tiles. Each tile has a type that corresponds to a single Magic layer. An individual corner-stitched data structure is referred to as a plane.
Magic allows you to see the corner-stitched planes it uses to store a layout. We'll use this facility to see how several corner-stitched planes are used to store the layers of a layout. Enter Magic to edit the cell maint2a. Type the command *watch active demo. You are now looking at the active plane. Each of the boxes outlined in black is a tile. (The arrows are stitches, but are unimportant to this discussion.) You can see that some tiles contain layers (polysilicon, ndiffusion, ndcontact, polycontact, and ntransistor), while others contain empty space. Corner-stitching is unusual in that it represents empty space explicitly. Each tile contains exactly one type of material, or space.
You have probably noticed that metal1 does not seem to have a tile associated with it, but instead appears right in the middle of a space tile. This is because metal1 is stored on a different plane, the metal1 plane. Type the command :*watch metal1 demo. Now you can see that there are metal1 tiles, but the polysilicon, diffusion, and transistor tiles have disappeared. The two contacts, polycontact and ndcontact, still appear to be tiles.
The reason Magic uses several planes to store mask information is that corner-stitching can only represent non-overlapping rectangles. If a layout were to consist of only a single layer, such as polysilicon, then only two types of tiles would be necessary: polysilicon and space. As more layers are added, overlaps can be represented by creating a special tile type for each kind of overlap area. For example, when polysilicon overlaps ndiffusion, the overlap area is marked with the tile type ntransistor.
Although some overlaps correspond to actual electrical constructs (e.g., transistors), other overlaps have little electrical significance. For example, metal1 can overlap polysilicon without changing the connectivity of the circuit or creating any new devices. The only consequence of the overlap is possibly a change in parasitic capacitance. To create new tile types for all possible overlapping combinations of metal1 with polysilicon, diffusion, transistors, etc. would be wasteful, since these new overlapping combinations would have no electrical significance.
Instead, Magic partitions the layers into separate planes. Layers whose overlaps have electrical significance must be stored in a single plane. For example, polysilicon, diffusion, and their overlaps (transistors) are all stored in the active plane. Metal1 does not interact with any of these tile types, so it is stored in its own plane, the metal1 plane. Similarly, in the scmos technology, metal2 doesn't interact with either metal1 or the active layers, so is stored in yet another plane, metal2.
Contacts between layers in one plane and layers in another are a special case and are represented on both planes. This explains why the pcontact and ndcontact tiles appeared on both the active plane and on the metal1 plane. Later in this section, when the contacts section of the technology file is introduced, we'll see how to define contacts and the layers they connect.
The planes section of the technology file specifies how many planes will be used to store tiles in a given technology, and gives each plane a name. Each line in this section defines a plane by giving a comma-separated list of the names by which it is known. Any name may be used in referring to the plane in later sections, or in commands like the *watch command indicated in the tutorial above. Table 2 gives the planes section from the scmos technology file.
Magic uses a number other planes internally. The subcell plane is used for storing cell instances rather than storing mask layers. The designRuleCheck and designRuleError planes are used by the design rule checker to store areas to be re-verified, and areas containing design rule violations, respectively. Finally, the mhint, fhint, and rhint planes are used for by the interactive router (the iroute command) for designer-specified graphic hints.
There is a limit on the maximum number of planes in a technology, including the internal planes. This limit is currently 64. To increase the limit, it is necessary to change MAXPLANES in the file database/database.h.in and then recompile all of Magic as described in "Maintainer's Manual #1". Each additional plane involves additional storage space in every cell and some additional processing time for searches, so we recommend that you keep the number of planes as small as you can do cleanly.
[-]plane names
Each type defined in this section is allowed to appear on exactly one of the planes defined in the planes section, namely that given by the plane field above. For contacts types such as pcontact, the plane listed is considered to be the contact's home plane; in Magic 7.3 this is a largely irrelevant distinction. However, it is preferable to maintain a standard of listing the lowest plane connected to a contact as it's "home plane" (as they appear in the table).
The minus sign ("-") in front of the plane name is a special convention introduced in Magic version 7.5, that causes layers to be "locked" on startup. A locked layer cannot have its paint geometry changed. This is a useful feature for locking down part of a design, such as a sea-of-gates design where planes below some designated metal layer are prefabricated and cannot be changed. Layer locking prevents inadvertent changes to these layers. Layer locking and unlocking can also be done from the command-line or a startup script, which is probably more useful for a per-design specification of locked layers.
The names field is a comma-separated list of names. The first name in the list is the "long" name for the type; it appears in the .mag file and whenever error messages involving that type are printed. Any unique abbreviation of any of a type's names is sufficient to refer to that type, both from within the technology file and in any commands such as paint or erase.
Magic has certain built-in types as shown in Table 4. Empty space (space) is special in that it can appear on any plane. The types error_p, error_s, and error_ps record design rule violations. The types checkpaint and checksubcell record areas still to be design-rule checked. Types magnet, fence, and rotate are the types used by designers to indicate hints for the irouter.
There is a limit on the maximum number of types in a technology, including all the built-in types. Currently, the limit is 256 tile types. To increase the limit, you'll have to change the value of TT_MAXTYPES in the file database/database.h.in and then recompile all of Magic as described in "Maintainer's Manual #1". Because there are a number of tables whose size is determined by the square of TT_MAXTYPES, it is very expensive to increase TT_MAXTYPES. Magic version 7.2 greatly reduced the number of these tables, so the problem is not as bad as it once was. Most internal tables depend on a bitmask of types, the consequence of which is that the internal memory usage greatly increases whenever TT_MAXTYPES exceeds a factor of 32 (the size of an integer, on 32-bit systems). Magic version 7.3 further alleviates the problem by reducing the number of "derived" tile types that magic generates internally, so that the total number of types is not much larger than the number declared in the types section. Magic-7.4 only generates extra types for pairs of stackable contact types. For a typical process, the number of these derived stacked contact pairs is around 15 to 20.
The declaration of tile types may be followed by a block of alias declarations. This is similar to the "macro" definitions used by preprocessors, except that the definitions are not only significant to the technology file parser, but extend to the user as well. Thus the statement "alias metalstack m1,m2,m3" may be a convenient shorthand where metal layers 1, 2, and 3 appear simultaneously, but the end-user can type the command "paint metalstack" and get the expected result of all three metal layers painted. The alias statement has the additional function of allowing backward-compatibility for technology files making use of stackable contacts (see below) with older layouts, and cross-compatibility between similar technologies that may have slight differences in layer names.
Important: The alias declarations in the types section are allowed for backwards compatibility. However, it should be noted that since contacts are not defined until after the "types" section, the wildcard character "*" cannot be used in alias defitions that appear in the "types" section. If you want to use the wildcard definitions, put all aliases into the (separate) "alias" section (see below).
Each line in the contact section begins with a tile type, base, which is thereby defined to be a contact. This type is also referred to as a contact's base type. The remainder of each line is a list of non-contact tile types that are connected by the contact. These tile types are referred to as the residues of the contact, and are the layers that would be present if there were no electrical connection (i.e., no via hole). In Table 5, for example, the type pcontact is the base type of a contact connecting the residue layers polysilicon on the active plane with metal1 on the metal1 plane.
In Magic-7.3 and above, any number of types can be connected, and those types may exist on any planes. It is the duty of the technology file developer to ensure that these connections make sense, especially if the planes are not contiguous. However, because Magic-7.3 handles stacked contacts explicitly, it is generally better to define contacts only between two adjacent planes, and use the stackable keyword (see below) to allow types to be stacked upon one another. The multiple-plane representation exists for backward compatibility with technology files written for versions of Magic prior to 7.3. Stackable contacts in older technology files take the form:
contact pc polysilicon metal1
contact m2c metal1 metal2
contact pm12c polysilicon metal1 metal2
In Magic version 7.3, the above line would be represented as:
contact pc polysilicon metal1
contact m2c metal1 metal2
stackable pc m2c pm12c
where the third line declares that contact types m2c and pc may be stacked together, and that type name "pm12c" is a valid alias for the combination of "pc" and "m2c".
Each contact has an image on all the planes it connects. Figure 1 depicts the situation graphically. In later sections of the technology file, it is sometimes useful to refer separately to the various images of contact. A special notation using a slash character ("/") is used for this. If a tile type aaa/bbb is specified in the technology file, this refers to the image of contact aaa on plane bbb. For example, pcontact/metal1 refers to the image of the pcontact that lies on the metal1 plane, and pcontact/active refers to the image on the active plane, which is the same as pcontact.
 |
In several places in the technology file you'll need to specify groups of tile types. For example, in the connect section you'll specify groups of tiles that are mutually connected. These are called type-lists and there are several ways to specify them. The simplest form for a type-list is a comma-separated list of tile types, for example
poly,ndiff,pcontact,ndc
The null list (no tiles at all) is indicated by zero, i.e.,
0
There must not be any spaces in the type-list. Type-lists may also use tildes ("~") to select all tiles but a specified set, and parentheses for grouping. For example,
~(pcontact,ndc)
selects all tile types but pcontact and ndc. When a contact name appears in a type-list, it selects all images of the contact unless a "/" is used to indicate a particular one. The example above will not select any of the images of pcontact or ndc. Slashes can also be used in conjunction with parentheses and tildes. For example,
~(pcontact,ndc)/active,metal1
selects all of the tile types on the active plane except for pcontact and ndc, and also selects metal1. Tildes have higher operator precedence than slashes, and commas have lowest precedence of all.
A special notation using the asterisk ("*") is a convenient way to abbreviate the common situation where a rule requires the inclusion of a tile type and also all contacts that define that tile type as one of their residue layers, a common occurrence. The notation
*metal1
expands to metal1 plus all of the contact types associated with metal1, such as ndc, pdc, nsc, m2c, and so forth.
Note: in the CIF sections of the technology file, only simple comma-separated names are permitted; tildes and parentheses are not understood. However, everywhere else in the technology file the full generality can be used. The "*" notation for inclusion of contact residues may be present in any section.
Because the "alias" statement in the "types" section is disallowed from containing wildcard characters, a separate section has been added to the technology file (starting from Magic version 7.5.56), allowing aliases to be defined after the "contacts" section has been declared, and therefore able to use both the "*" wildcard character and the stacked contact alias names defined in the "contacts" section. The syntax is as follows:
alias_name type_listThe alias_name can be any valid name but must be unique (i.e., it cannot shadow an existing type name). The type_list is a comma-separated list of types that may contain contact names, contact aliases, the "*" wildcard character, or any other valid notation for a type list. It may also contain other alias names provided that they are defined before they are used.
Once defined, alias names may be used anywhere in the technology file, and they may be used in commands from the command line.
Magic can be run on several different types of graphical displays. Although it would have been possible to incorporate display-specific information into the technology file, a different technology file would have been required for each display type. Instead, the technology file gives one or more display-independent styles for each type that is to be displayed, and uses a per-display-type styles file to map to colors and stipplings specific to the display being used. The styles file is described in Magic Maintainer's Manual #3: "Styles and Colors", so we will not describe it further here.
Table 6 shows part of the styles section from the scmos technology file. The first line specifies the type of style file for use with this technology, which in this example is mos. Each subsequent line consists of a tile type and a style number (an integer between 1 and 63). The style number is nothing more than a reference between the technology file and the styles file. Notice that a given tile type can have several styles (e.g., pcontact uses styles #1, #20, and #32), and that a given style may be used to display several different tiles (e.g., style #2 is used in ndiff and ndcontact). If a tile type should not be displayed, it has no entry in the styles section.
It is no longer necessary to have one style per line, a restriction of format 27 and earlier. Multiple styles for a tile type can be placed on the same line, separated by spaces. Styles may be specified by number, or by the "long name" in the style file.
The semantics of Magic's paint operation are defined by a collection of rules of the form, "given material HAVE on plane PLANE, if we paint PAINT, then we get Z", plus a similar set of rules for the erase operation. The default paint and erase rules are simple. Assume that we are given material HAVE on plane PLANE, and are painting or erasing material PAINT.
These rules apply for contacts as well. Painting the base type of a contact paints the base type on its home plane, and each image type on its home plane. Erasing the base type of a contact erases both the base type and the image types.
It is sometimes desirable for certain tile types to behave as though they were "composed" of other, more fundamental ones. For example, painting poly over ndiffusion in scmos produces ntransistor, instead of ndiffusion. Also, painting either poly or ndiffusion over ntransistor leaves ntransistor, erasing poly from ntransistor leaves ndiffusion, and erasing ndiffusion leaves poly. The semantics for ntransistor are a result of the following rule in the compose section of the scmos technology file:
compose ntransistor poly ndiff
Sometimes, not all of the "component" layers of a type are layers known to magic. As an example, in the nmos technology, there are two types of transistors: enhancement-fet and depletion-fet. Although both contain polysilicon and diffusion, depletion-fet can be thought of as also containing implant, which is not a tile type. So while we can't construct depletion-fet by painting poly and then diffusion, we'd still like it to behave as though it contained both materials. Painting poly or diffusion over a depletion-fet should not change it, and erasing either poly or diffusion should give the other. These semantics are the result of the following rule:
decompose dfet poly diff
The general syntax of both types of composition rules, compose and decompose, is:
compose type a1 b1 a2 b2 ...
decompose type a1 b1 a2 b2 ...
The idea is that each of the pairs a1 b1, a2 b2, etc comprise type. In the case of a compose rule, painting any a atop its corresponding b will give type, as well as vice-versa. In both compose and decompose rules, erasing a from type gives b, erasing b from type gives a, and painting either a or b over type leaves type unchanged.
|
Contacts are implicitly composed of their component types, so the result obtained when painting a type PAINT over a contact type CONTACT will by default depend only on the component types of CONTACT. If painting PAINT doesn't affect the component types of the contact, then it is considered not to affect the contact itself either. If painting PAINT does affect any of the component types, then the result is as though the contact had been replaced by its component types in the layout before type PAINT was painted. Similar rules hold for erasing.
A pcontact has component types poly and metal1. Since painting poly doesn't affect either poly or metal1, it doesn't affect a pcontact either. Painting ndiffusion does affect poly: it turns it into an ntransistor. Hence, painting ndiffusion over a pcontact breaks up the contact, leaving ntransistor on the active plane and metal1 on the metal1 plane.
The compose and decompose rules are normally sufficient to specify the desired semantics of painting or erasing. In unusual cases, however, it may be necessary to provide Magic with explicit paint or erase rules. For example, to specify that painting pwell over pdiffusion switches its type to ndiffusion, the technology file contains the rule:
paint pdiffusion pwell ndiffusion
This rule could not have been written as a decompose rule; erasing ndiffusion from pwell does not yield pdiffusion, nor does erasing pdiffusion from ndiffusion yield pwell. The general syntax for these explicit rules is:
paint have t result [p]
erase have t result [p]
Here, have is the type already present, on plane p if it is specified; otherwise, on the home plane of have. Type t is being painted or erased, and the result is type result. Table 7 gives the compose section for scmos.
It's easiest to think of the paint and erase rules as being built up in four passes. The first pass generates the default rules for all non-contact types, and the second pass replaces these as specified by the compose, decompose, etc. rules, also for non-contact types. At this point, the behavior of the component types of contacts has been completely determined, so the third pass can generate the default rules for all contact types, and the fourth pass can modify these as per any compose, etc. rules for contacts.
For circuit extraction, routing, and some of the net-list operations, Magic needs to know what types are electrically connected. Magic's model of electrical connectivity used is based on signal propagation. Two types should be marked as connected if a signal will always pass between the two types, in either direction. For the most part, this will mean that all non-space types within a plane should be marked as connected. The exceptions to this rule are devices (transistors). A transistor should be considered electrically connected to adjacent polysilicon, but not to adjacent diffusion. This models the fact that polysilicon connects to the gate of the transistor, but that the transistor acts as a switch between the diffusion areas on either side of the channel of the transistor.
The lines in the connect section of a technology file, as shown in Table 8, each contain a pair of type-lists in the format described in Section 8. Each type in the first list connects to each type in the second list. This does not imply that the types in the first list are themselves connected to each other, or that the types in the second list are connected to each other.
| ||||||||||||||||||||||||||||||||||||||||||
Because connectivity is a symmetric relationship, only one of the two possible orders of two tile types need be specified. Tiles of the same type are always considered to be connected. Contacts are treated specially; they should be specified as connecting to material in all planes spanned by the contact. For example, pcontact is shown as connecting to several types in the active plane, as well as several types in the metal1 plane. The connectivity of a contact should usually be that of its component types, so pcontact should connect to everything connected to poly, and to everything connected to metal1.
The layers stored by Magic do not always correspond to physical mask layers. For example, there is no physical layer corresponding to (the scmos technology file layer) ntransistor; instead, the actual circuit must be built up by overlapping poly and diffusion over pwell. When writing CIF (Caltech Intermediate Form) or Calma GDS-II files, Magic generates the actual geometries that will appear on the masks used to fabricate the circuit. The cifoutput section of the technology file describes how to generate mask layers from Magic's abstract layers.
|
From the 1990's, the CIF format has largely been replaced by the GDS format. However, they describe the same layout geometry, and the formats are similar enough that magic makes use of the CIF generation code as the basis for the GDS write routines. The technology file also uses CIF layer declarations as the basis for GDS output. So even a technology file that only expects to generate GDS output needs a "cifoutput" section declaring CIF layer names. If only GDS output is required, these names may be longer and therefore more descriptive than allowed by CIF format syntax.
The technology file can contain several different specifications of how to generate CIF. Each of these is called a CIF style. Different styles may be used for fabrication at different feature sizes, or for totally different purposes. For example, some of the Magic technology files contain a style "plot" that generates CIF pseudo-layers that have exactly the same shapes as the Magic layers. This style is used for generating plots that look just like what appears on the color display; it makes no sense for fabrication. Lines of the form
style name
are used to end the description of the previous style and start the description of a new style. The Magic command cif ostyle name is typed by users to change the current style used for output. The first style in the technology file is used by default for CIF output if the designer doesn't issue a cif style command. If the first line of the cifoutput section isn't a style line, then Magic uses an initial style name of default.
Each style must contain a line of the form
scalefactor scale [nanometers|angstroms]
that tells how to scale Magic coordinates into CIF coordinates. The argument scale indicates how many hundredths of a micron correspond to one Magic unit. scale may be any number, including decimals. However, all units in the style description must be integer. Because deep submicron processes may require CIF operations in units of less than one centimicron, the optional parameter nanometers declares that all units (including the scale parameter) are measured in units of nanometers. Likewise, the units may all be specified in angstroms. However unlikely the dimensions may seem, the problem is that magic needs to place some objects, like contacts, on half-lambda positions to ensure correct overlap of contact cuts between subcells. A feature size such as, for example, 45 nanometers, has a half-lambda value of 22.5 nanometers. Since this is not an integer, magic will complain about this scalefactor. This is true even if the process doesn't allow sub-nanometer coordinates, and magic uses the squares-grid statement to enforce this restriction. In such a case, it is necessary to declare a scalefactor of 450 angstroms rather than 45 nanometers.
Versions of magic prior to 7.1 allowed an optional second (integer) parameter, reducer, or the keyword calmaonly. The use of reducer is integral to CIF output, which uses the value to ensure that output values are reduced to the smallest common denominator. For example, if all CIF values are divisible by 100, then the reducer is set to 100 and all output values are divided by the same factor, thus reducing the size of the CIF output file. Now the reducer is calculated automatically, avoiding any problems resulting from an incorrectly specified reducer value, and any value found after scale is ignored. The calmaonly keyword specified that the scale was an odd integer. This limitation has been removed, so any such keyword is ignored, and correct output may be generated for either CIF or Calma at all output scales.
In addition to specifying a scale factor, each style can specify the size in which chunks will be processed when generating CIF hierarchically. This is particularly important when the average design size is much larger than the maximum bloat or shrink (e.g, more than 3 orders of magnitude difference). The step size is specified by a line of the following form:
stepsize stepsize
where stepsize is in Magic units. For example, if you plan to generate CIF for designs that will typically be 100,000 Magic units on a side, it might make sense for stepsize to be 10000 or more.
Each style can specify the minimum grid spacing on which a process will allow geometry to be generated. By default, there is no limit. When a limit is set, Magic cannot rescale its internal grid to a value that is either lower than, or not a multiple of, the grid limit. Normally, when geometry read from a CIF, GDS, or database file is smaller than the internal grid, magic rescales its grid to accomodate the input. The gridlimit sets a limit on how much the grid can be scaled down to avoid the possibility of Magic being able go generate CIF or GDS output that is off-grid. The grid limit is specified by a line of the following form:
gridlimit value
where the value is in the same units as other dimensions in the definition for the style (i.e., centimicrons or nanometers, as specified in the scalefactor statement).
Finally, each style can specify several options affecting the behavior of the output. Currently, there are two options available. These may be specified one at a time, or all in the same statement, with options separated by space.
options calma-permissive-labels
options grow-euclidean
The option "grow-euclidean" changes the algorithm for the "grow" and "shrink" operations. With this option set, non-Manhattan edges are grown to the minimum amount necessary to satisfy the grow amount while still having corner points land on-grid. When this option is not set, non-Manhattan edges are expanded (or shrunk) in both directions by the amount specified. This allows all tiles to be grown or shrunk independently of each other, leading to a much simpler and faster algorithm.
The main body of information for each CIF style is a set of layer descriptions. Each layer description consists of one or more operations describing how to generate the CIF for a single layer. The first line of each description is one of
layer name [layers]
templayer name [layers]
These statements are identical, except that templayers are not output in the CIF file. They are used only to build up intermediate results used in generating the "real" layers. In each case, name is the CIF name to be used for the layer. If layers is specified, it consists of a comma-separated list of Magic layers and previously-defined CIF layers in this style; these layers form the initial contents of the new CIF layer (note: the layer lists in this section are less general than what was described in Section 8; tildes and parentheses are not allowed). If layers is not specified, then the new CIF layer is initially empty. The following statements are used to modify the contents of a CIF layer before it is output.
After the layer or templayer statement come several statements specifying geometrical operations to apply in building the CIF layer. Each statement takes the current contents of the layer, applies some operation to it, and produces the new contents of the layer. The last geometrical operation for the layer determines what is actually output in the CIF file. The most common geometrical operations are:
or layers
and layers
and-not layers
grow amount
shrink amount
bloat-or layers layers2 amount layers2 amount ...
squares size
squares border size separation
Some more obscure operations are:
grow-grid amount
bloat-max layers layers2 amount layers2 amount ...
bloat-min layers layers2 amount layers2 amount ...
bloat-all layers layers2
squares-grid border size separation x y
slots border size separation
slots border size separation border_long
slots border size separation border_long size_long sep_long [offset]]
bbox [top]
The operation or takes all the layers (which may be either Magic layers or previously-defined CIF layers), and or's them with the material already in the CIF layer. The operation and is similar to or, except that it and's the layers with the material in the CIF layer (in other words, any CIF material that doesn't lie under material in layers is removed from the CIF layer). And-not finds all areas covered by layers and erases current CIF material from those areas. Grow and shrink will uniformly grow or shrink the current CIF layer by amount units, where amount is specified in CIF units, not Magic units. The squares-grid operator grows layers non-uniformly to snap to the grid spacing indicated by amount. This can be used to ensure that features fall on a required minimum grid.
The three "bloat" operations bloat-or, bloat-min, and bloat-max, provide selective forms of growing. In these statements, all the layers must be Magic layers. Each operation examines all the tiles in layers, and grows the tiles by a different distance on each side, depending on the rest of the line. Each pair layers2 amount specifies some tile types and a distance (in CIF units). Where a tile of type layers abuts a tile of type layers2, the first tile is grown on that side by amount. The result is or'ed with the current contents of the CIF plane. The layer "*" may be used as layers2 to indicate all tile types. Where tiles only have a single type of neighbor on each side, all three forms of bloat are identical. Where the neighbors are different, the three forms are slightly different, as illustrated in Figure 12.3. Note: all the layers specified in any given bloat operation must lie on a single Magic plane. For bloat-or all distances must be positive. In bloat-max and bloat-min the distances may be negative to provide a selective form of shrinking.
 |
In retrospect, it's not clear that bloat-max and bloat-min are very useful operations. The problem is that they operate on tiles, not regions. This can cause unexpected behavior on concave regions. For example, if the region being bloated is in the shape of a "T", a single bloat factor will be applied to the underside of the horizontal bar. If you use bloat-max or bloat-min, you should probably specify design-rules that require the shapes being bloated to be convex.
The fourth bloat operation bloat-all takes all tiles of types layers, and grows to include all neighboring tiles of types layers2. This is very useful to generate marker layers or implant layers for specific devices, where the marker or implant must cover both the device and its contacts. Take the material of the device and use bloat-all to expand into the contact areas.
An important geometric operation for creating contact cuts is squares. It examines each tile on the CIF plane, and replaces that tile with one or more squares of material. Each square is size CIF units across, and squares are separated by separation units. A border of at least border units is left around the edge of the original tile, if possible. This operation is used to generate contact vias, as in Figure 3. If only one argument is given in the squares statement, then separation defaults to size and border defaults to size/2. If a tile doesn't hold an integral number of squares, extra space is left around the edges of the tile and the squares are centered in the tile. If the tile is so small that not even a single square can fit and still leave enough border, then the border is reduced. If a square won't fit in the tile, even with no border, then no material is generated. The squares operation must be used with some care, in conjunction with the design rules. For example, if there are several adjacent skinny tiles, there may not be enough room in any of the tiles for a square, so no material will be generated at all. Whenever you use the squares operator, you should use design rules to prohibit adjacent contact tiles, and you should always use the no_overlap rule to prevent unpleasant hierarchical interactions. The problems with hierarchy are discussed in Section 12.6 below, and design rules are discussed in Section 15.
 |
The squares-grid operator is similar to squares and takes the same arguments, except for the additional optional x and y offsets (which default to 1). Where the squares operator places contacts on the half-lambda grid, the squares-grid operator places contacts on an integer grid of x and y. This is helpful where manufacturing grid limitations do not allow half-lambda coordinates. However, it is necessary then to enforce a "no-overlap" rule for contacts in the DRC section to prevent incorrect contacts cuts from being generated in overlapping subcells. The squares-grid operator can also be used with x and y values to generate fill geometry, or to generate offset contact cut arrays for pad vias.
The slots operator is similar to squares operator, but as the name implies, the resulting shapes generated are rectangular, not (necessarily) square. Slots are generated inside individual tiles, like the squares operator, so each slots operation is separately oriented relative to the tile's long and short edges. Separate border, size, and separation values can be specified for the short and long dimensions of the tile. This operator can be used in a number of situations:
Note that the slots operator comes in three different forms with different numbers of arguments. With only three arguments (short side description only), the slots operator creates stripes that extend to the edge of the tile. With four arguments (short side description plus long side border dimension only), the slots operator create stripes that extend to the edge of the tile, with an appropriate border spacing at each end. In these two cases, the slots have variable length that is set by the size of the tile. In the final form, all short and long side dimensions are declared. The generated slots are of fixed size, and like the squares operator, their positions will be adjusted to center them on the tile. The offset is intended to let each row of slots be offset from the previous one by a fixed amount, but is currently unimplemented and has no effect.
The bbox operator generates a single rectangle that encompasses the bounding box of the cell. This is useful for the occasional process that requires marker or implant layers covering an entire design. The variant bbox top will generate a rectangle encompassing the bounding box of the cell, but will only do so for the top-level cell of the design.
There is an additional statement permitted in the cifoutput section as part of a layer description:
labels Magiclayers
This statement tells Magic that labels attached to Magic layers Magiclayers are to be associated with the current CIF layer. Each Magic layer should only appear in one such statement for any given CIF style. If a Magic layer doesn't appear in any labels statement, then it is not attached to a specific layer when output in CIF.
Each layer description in the cifoutput section may also contain one of the following statements:
gds gdsNumber gdsType
calma gdsNumber gdsType
Although the format is rarely referred to as "Calma" anymore, the keyword is retained for backwards compatibility with format 27 (and earlier) files.
This statement tells Magic which layer number and data type to use when the gds command outputs GDS II Stream format for this defined CIF layer. Both gdsNumber and gdsType should be positive integers, between 0 and 63. Each CIF layer should have a different gdsNumber. If there is no gds line for a given CIF layer, then that layer will not be output by the "gds write" command. The reverse is not true: every generated output layer must have a defined CIF layer type, even if the foundry only supports GDS format. In such case, the CIF layer name may violate the restrictive 4-character format required by the CIF syntax specification, and may be used to provide a reasonable, human-readable descriptive name of the GDS layer.
 |
Hierarchical designs make life especially difficult for the CIF generator. The CIF corresponding to a collection of subcells may not necessarily be the same as the sum of the CIF's of the individual cells. For example, if a layer is generated by growing and then shrinking, nearby features from different cells may merge together so that they don't shrink back to their original shapes (see Figure 5). If Magic generates CIF separately for each cell, the interactions between cells will not be reflected properly. The CIF generator attempts to avoid these problems. Although it generates CIF in a hierarchical representation that matches the Magic cell structure, it tries to ensure that the resulting CIF patterns are exactly the same as if the entire Magic design had been flattened into a single cell and then CIF were generated from the flattened design. It does this by looking in each cell for places where subcells are close enough to interact with each other or with paint in the parent. Where this happens, Magic flattens the interaction area and generates CIF for it; then Magic flattens each of the subcells separately and generates CIF for them. Finally, it compares the CIF from the subcells with the CIF from the flattened parent. Where there is a difference, Magic outputs extra CIF in the parent to compensate.
Magic's hierarchical approach only works if the overall CIF for the parent ends up covering at least as much area as the CIFs for the individual components, so all compensation can be done by adding extra CIF to the parent. In mathematical terms, this requires each geometric operation to obey the rule
Op(AB)
Op(A)
The operations and, or, grow, and shrink all obey this rule. Unfortunately, the and-not, bloat, and squares operations do not. For example, if there are two partially-overlapping tiles in different cells, the squares generated from one of the cells may fall in the separations between squares in the other cell, resulting in much larger areas of material than expected. There are two ways around this problem. One way is to use the design rules to prohibit problem situations from arising. This applies mainly to the squares operator. Tiles from which squares are made should never be allowed to overlap other such tiles in different cells unless the overlap is exact, so each cell will generate squares in the same place. You can use the exact_overlap design rule for this.
The second approach is to leave things up to the designer. When generating CIF, Magic issues warnings where there is less material in the children than the parent. The designer can locate these problems and eliminate the interactions that cause the trouble. Warning: Magic does not check the squares operations for hierarchical consistency, so you absolutely must use exact_overlap design rule checks! Right now, the cifoutput section of the technology is one of the trickiest things in the whole file, particularly since errors here may not show up until your chip comes back and doesn't work. Be extremely careful when writing this part!
|
Another problem with hierarchical generation is that it can be very slow, especially when there are a number of rules in the cifoutput section with very large grow or shrink distances, such that magic must always expand its area of interest by this amount to be sure of capturing all possible layer interactions. When this "halo" distance becomes larger than the average subcell, much of the design may end up being processed multiple times. Noticeably slow output generation is usually indicative of this problem. It can be alleviated by keeping output rules simple. Note that basic AND and OR operations do not interact between subcells, so that rules made from only these operators will not be processed during subcell interaction generation. Remember that typically, subcell interaction paint will only be generated for layers that have a "grow" operation followed by a "shrink" operation. This common ruleset lets layers that are too closely spaced to be merged together, thus eliminating the need for a spacing rule between the layers. But consider carefully before implementing such a rule. Implementing a DRC spacing rule instead may eliminate a huge amount of output processing. Usually this situation crops up for auto-generated layers such as implants and wells, to prevent magic from auto-generating DRC spacing violations. But again, consider carefully whether it might be better to require the layout engineer to draw the layers instead of attempting to auto-generate them.
At the end of each style in the cifoutput section, one may include render statements, one per defined CIF/GDS layer. These render statements are used by the 3-D drawing window in the OpenGL graphics version of magic, and are also used by the "cif see" command to set the style painted. The syntax for the statement is as follows:
render cif_layer style_name height thickness
The cif_layer is any valid layer name defined in the same cifoutput section where the render statement occurs. The style_name is the name or number of a style in the styles file. The names are the same as used in the styles section of the technology file. height and thickness are effectively dimensionless units and are used for relative placement and scaling of the three-dimensional layout view (such views generally have a greatly expanded z-axis scaling). By default, all layers are given the same style and a zero height and thickness, so effectively nothing useful can be seen in the 3-D view without a complete set of render statements.
In addition to writing CIF, Magic can also read in CIF files using the cif read file command. The cifinput section of the technology file describes how to convert from CIF mask layers to Magic tile types. In addition, it provides information to the Calma reader to allow it to read in Calma GDS II Stream format files. The cifinput section is very similar to the cifoutput section. It can contain several styles, with a line of the form
style name
used to end the description of the previous style (if any), and start a new CIF input style called name. If no initial style name is given, the name default is assigned. Each style must have a statement of the form
scalefactor scale [nanometers]
to indicate the output scale relative to Magic units. Without the optional keyword nanometers, scale describes how many hundredths of a micron correspond to one unit in Magic. With nanometers declared, scale describes how many nanometers correspond to one unit in Magic.
Like the cifoutput section, each style consists of a number of layer descriptions. A layer description contains one or more lines describing a series of geometric operations to be performed on CIF layers. The result of all these operations is painted on a particular Magic layer just as if the user had painted that information by hand. A layer description begins with a statement of the form
layer magicLayer [layers]
In the layer statement, magicLayer is the Magic layer that will be painted after performing the geometric operations, and layers is an optional list of CIF layers. If layers is specified, it is the initial value for the layer being built up. If layers isn't specified, the layer starts off empty. As in the cifoutput section, each line after the layer statement gives a geometric operation that is applied to the previous contents of the layer being built in order to generate new contents for the layer. The result of the last geometric operation is painted into the Magic database.
The geometric operations that are allowed in the cifinput section are a subset of those permitted in the cifoutput section:
or layers
and layers
and-not layers
grow amount
shrink amount
In these commands the layers must all be CIF layers, and the amounts are all CIF distances (centimicrons, unless the keyword nanometers has been used in the scalefactor specification). As with the cifoutput section, layers can only be specified in simple comma-separated lists: tildes and slashes are not permitted.
When CIF files are read, all the mask information is read for a cell before performing any of the geometric processing. After the cell has been completely read in, the Magic layers are produced and painted in the order they appear in the technology file. In general, the order that the layers are processed is important since each layer will usually override the previous ones. For example, in the scmos tech file shown in Table 10 the commands for ndiff will result in the ndiff layer being generated not only where there is only ndiffusion but also where there are ntransistors and ndcontacts. The descriptions for ntransistor and ndcontact appear later in the section, so those layers will replace the ndiff material that was originally painted.
Labels are handled in the cifinput section just like in the cifoutput section. A line of the form
labels layers
means that the current Magic layer is to receive all CIF labels on layers. This is actually just an initial layer assignment for the labels. Once a CIF cell has been read in, Magic scans the label list and re-assigns labels if necessary. In the example of Table 10, if a label is attached to the CIF layer CPG then it will be assigned to the Magic layer poly. However, the polysilicon may actually be part of a poly-metal contact, which is Magic layer pcontact. After all the mask information has been processed, Magic checks the material underneath the layer, and adjusts the label's layer to match that material (pcontact in this case). This is the same as what would happen if a designer painted poly over an area, attached a label to the material, then painted pcontact over the area.
No hierarchical mask processing is done for CIF input. Each cell is read in and its layers are processed independently from all other cells; Magic assumes that there will not be any unpleasant interactions between cells as happens in CIF output (and so far, at least, this seems to be a valid assumption).
If Magic encounters a CIF layer name that doesn't appear in any of the lines for the current CIF input style, it issues a warning message and ignores the information associated with the layer. If you would like Magic to ignore certain layers without issuing any warning messages, insert a line of the form
ignore cifLayers
where cifLayers is a comma-separated list of one or more CIF layer names.
Calma layers are specified via calma lines, which should appear at the end of the cifinput section. They are of the form:
calma cifLayer calmaLayers calmaTypes
The cifLayer is one of the CIF types mentioned in the cifinput section. Both calmaLayers and calmaTypes are one or more comma-separated integers between 0 and 63. The interpretation of a calma line is that any Calma geometry whose layer is any of the layers in calmaLayers, and whose type is any of the types in calmaTypes, should be treated as the CIF layer cifLayer. Either or both of calmaLayers and calmaTypes may be the character * instead of a comma-separated list of integers; this character means all layers or types respectively. It is commonly used for calmaTypes to indicate that the Calma type of a piece of geometry should be ignored.
Just as for CIF, Magic also issues warnings if it encounters unknown Calma layers while reading Stream files. If there are layers that you'd like Magic to ignore without issuing warnings, assign them to a dummy CIF layer and ignore the CIF layer.
This section defines a mapping between magic layers and layers that may be found in LEF and DEF format files. Without the section, magic cannot read a LEF or DEF file. The LEF and DEF layer declarations are usually simple and straightforward (as they typically define metal layers only), so often it will suffice to insert a plain vanilla lef section into a technology file if one is missing. The lef section was introduced in technology file format 28, and is therefore absent from all .tech27 technology files. All of the statements in the lef section have the same format:
layer magic-type lefdef-type ...
cut magic-type lefdef-type ...
route|routing magic-type lefdef-type ...
obstruction magic-type lefdef-type ...
obstruction magic-type1,magic-type2 lefdef-cut-type ...
masterslice magic-type lefdef-type ...
overlap magic-type lefdef-type ...
ignore lefdef-type ...
Each statement defines a mapping between a Magic layer type magic-type and one or more type names lefdef-type (space-separated) that might be encountered in a LEF or DEF file. The different command names all refer to different type classes defined by the LEF/DEF specification. For most purposes, it is only necessary to use the layer statement. If the magic type is a contact type, then the layer statement is equivalent to specifying cut; otherwise, it is equivalent to route.
Note the special case of "obstruction" in which the magic tile type is a comma-separated list of exactly two types. Because magic contacts are normally defined as existing on the two metal planes they connect, rather than existing on a separate plane in-between, there may not be a correct way do define a via layer obstruction. In such a case, it may be helpful to define the LEF layer as corresponding to the two residue types that define the layers connected by the contact type.
The "ignore" keyword tells Magic to ignore the LEF layer types listed. Any geometry found defined on ignored layers will be discarded without comment. This can be useful, for example, to ignore geometry on the poly or active layers when one does not expect to route on the active plane.
Table 11 is a typical lef section for a 5-metal technology, which encompasses the most commonly used layer names found in LEF and DEF files.
|
This section defines the layers and contacts available to the Magic maze router, mzrouter, and assigns default costs for each type. Default widths and spacings are derived from the drc section of the technology file (described below) but can be overridden in this section. Other mzrouter parameters, for example, search rate and width, can also be specified in this section. The syntax and function of the lines in the mzrouter section of the technology file are specified in the subsections below. Each set of specifications should be headed by a style line. Routelayer and routecontact specifications should precede references to them.
The mzrouter is currently used in two contexts, interactively via the iroute command, and as a subroutine to the garouter (gate array router) for stem generation. To permit distinct parameters for these two uses, the lines in the mzrouter section are grouped into styles. The lines pertaining to the irouter should be preceded by
style irouter
and those pertaining to the garouter should be preceded by the specification
style garouter
Other styles can be specified, but are currently not used. Table 12 shows the mzrouter section from the scmos technology.
Layer lines define the route-layers available to the maze router in that style. They have the following form:
layer type hCost vCost jogCost hintCost
Here type is the name of the tiletype of the layer and hCost, vCost, jogCost and hintCost, are non-negative integers specifying the cost per unit horizontal distance, cost per unit vertical distance, cost per jog, and cost per unit area of deviation from magnets, respectively. Route layers for any given style must lie in distinct planes.
Versions of Magic beginning with 7.5.35 define the cost functions beyond the horizontal and vertical length costs as optional (defaulting to 1, the minimum cost), and add an additional cost value, the overCost. The overCost defines the cost of routing directly over an adjacent routing layer. A high value for overCost will tend to prevent the maze router from placing routes directly over other pins, thus preventing those pins from being routed. It will also tend to force the maze router to river route (route on a single layer) to a greater extent than otherwise, and avoid long paths with one signal directly on top of another, which exacerbates crosstalk problems. The layer syntax for magic 7.5.35 and higher is given below.
layer type hCost vCost [jogCost [hintCost [overCost]]]
Contact lines specify the route-contacts available to the mzrouter in the current style. They have the following form:
contact type routeLayer1 routeLayer2 cost
Here type is the tiletype of the contact, routeLayer1 and routeLayer2 are the two layers connected by the contact, and cost is a nonnegative integer specifying the cost per contact.
It may be desirable to have a layer or contact available to the maze router, but default to off, i.e., not be used by the mzrouter until explicitly made active. Route-types (route-layers or route-contacts) can be made to default to off with the following specification:
notactive route-type ...[route-typen]
The search rate, width, and penalty parameters can be set with a specification of the form:
search rate width penalty
Here rate and width are positive integers. And penalty is a positive rational (it may include a decimal point). See the irouter tutorial for a discussion of these parameters. (Note that penalty is a "wizardly" parameter, i.e., it is interactively set and examined via iroute wizard not iroute search). If no search line is given for a style, the overall mzrouter defaults are used.
Appropriate widths for route-types are normally derived from the drc section of the technology file. These can be overridden with width specifications of the following form:
width route-type width
Here width is a positive integer.
Minimum spacings between routing on a route-type and other types are derived from the design rules. These values can be overridden by explicit spacing specifications in the mzrouter section. Spacing specifications have the following form:
spacing routetype type1 spacing1 ...[typen spacingn]
Spacing values must be nonnegative integers or NIL. The special type SUBCELL can be used to specify minimum spacing to unexpanded subcells.
The design rules used by Magic's design rule checker come entirely from the technology file. We'll look first at two simple kinds of rules, width and and spacing. Most of the rules in the drc section are one or the other of these kinds of rules.
The technology file can contain several different specifications of DRC rules. Each of these is called a DRC style. Different styles may be used for fabrication at different feature sizes, or for other purposes. For example, some rules have a large "halo" (area of interaction surrounding an edge) that causes Magic's design rule checker to run very slowly, because it has to search large areas and often flatten large sections of hierarchical layout before it can perform each check. It is good practice to split the DRC deck into "quick and dirty" and "comprehensive" styles. The "quick and dirty" style will run interactively and catch most common design rule errors right away. The "comprehensive" style can be run occasionally to catch more obscure errors. Although Magic's design rule checker is very clever about checking only areas that have changed in a layout, certain actions, such as instancing a large subcell, or copying a large amount of paint, will require a complete set of checks. When these sort of actions cause Magic to run noticeably slower, it's time to consider splitting up the DRC deck.
The method of specifying styles in the drc section is very similar to the way it is done in the cifoutput and cifinput sections. The DRC deck can contain several styles, with a line of the form
style name
used to end the description of the previous style and start the description of a new style. The Magic command drc style name is typed by users to change the current style used for output. The first style in the technology file is used by default for DRC checking if the designer doesn't issue a drc style command. If the first line of the drc section isn't a style line, then Magic uses an initial style name of default.
Each style must contain a line of the form
scalefactor scale [reducer]
that tells how to scale DRC coordinates into Magic coordinates. The argument scale indicates how many DRC (distance) units correspond to one Magic unit. The argument reducer allows scalefactors to be represented as fractions represented by the integer ratio (scale / reducer). Note that both DRC units and magic's internal coordinate system are in dimensionless units. The scalefactor is designed to allow users to describe DRC distances in convenient values such as nanometers. However, it must be remembered that the DRC units are then only nanometers with respect to some output scale defined by the active cifoutput style. The most important property of the use of the DRC scale is that it allows DRC values to be specified in units that are finer than Magic's internal grid. Magic scales each DRC unit relative to it's internal scale, and if the internal scale is changed at any time, all DRC units are re-interpreted relative to the new scale. For example, if the scale value is 10, and the DRC deck declares the minimum width of metal1 paint to be 35, then the actual DRC distance of 3.5 internal units will be rounded up to 4. Therefore, a metal1 line 3 units wide is in error, but one 4 units wide is correct. If the internal database is then made finer by a factor of two using the "scalegrid 1 2" command, then the new DRC distance will be (3.5 * 2 =) 7 units, and is not rounded.
scale and the optional reducer must be integers. All distance units in the DRC deck also must be integers.
The minimum width of a collection of types, taken together, is expressed by a width rule. Such a rule has the form:
width type-list width error
where type-list is a set of tile types (see Section 8 for syntax), width is an integer, and error is a string, enclosed in double quotes, that can be printed by the command drc why if the rule is violated. A width rule requires that all regions containing any types in the set types must be wider than w in both dimensions. For example, in Table 14, the rule
width nwell 6 "N-Well width must be at least 6 (MOSIS rule #1.1)"
means that nwells must be at least 6 units wide whenever they appear. The type-list field may contain more than a single type, as in the following rule:
width allDiff 2 "Diffusion width must be at least 2 (MOSIS rule #2.1)"
which means that all regions consisting of the types containing any kind of diffusion be at least 2 units wide. Because many of the rules in the drc section refer to the same sets of layers, the #define facility of the C preprocessor is used to define a number of macros for these sets of layers. Table 13 gives a complete list.
All of the layers named in any one width rule must lie on the same plane. However, if some of the layers are contacts, Magic will substitute a different contact image if the named image isn't on the same plane as the other layers.
The second simple kind of design rule is a spacing rule. It comes in four flavors: touching_ok, touching_illegal, surround_ok, and corner_ok. The first three adjacency flavors use the following syntax:
spacing types1 types2 distance adjacency error
The first adjacency class, touching_ok, does not prohibit types1 and types2 from being immediately adjacent. It merely requires that any type in the set types1 must be separated by a "Manhattan" distance of at least distance units from any type in the set types2 that is not immediately adjacent to the first type. See Figure 16.2 for an illustration of Manhattan distance for design rules. (Note that Euclidean distance measurements for design rules can be enabled using the command "drc euclidean on".) As an example, consider the metal1 separation rule:
spacing allPoly allPoly 2 touching_ok \
"Polysilicon spacing must be at least 2 (MOSIS rule #3.2)"
 |
This rule is symmetric (types1 is equal to types2), and requires, for example, that a pcontact be separated by at least 2 units from a piece of polysilicon. However, this rule does not prevent the pcontact from touching a piece of poly. In touching_ok rules, all of the layers in both types1 and types2 must be stored on the same plane (Magic will substitute different contact images if necessary).
| ||||||||||||||||||||||||||||||
TOUCHING_OK SPACING RULES DO NOT WORK FOR VERY LARGE SPACINGS (RELATIVE TO THE TYPES INVOLVED). See Figure 6 for an explanation. If the spacing to be checked is greater than the width of one of the types involved plus either its self-spacing or spacing to a second involved type, touching_ok spacing may not work properly: a violation can be masked by an intervening touching type. In such cases the rule should be written using the edge4way construct described below.
