Magic Technology Files

Table of Contents

The Magic Technology File Manual
The Magic Toolkit Manual
Obtaining Technology Files for Magic
Distribution Technology Files
Format 28 Technology File Improvements
Format 29/30 Technology File Improvements
Format 31 Technology File Improvements
Format 32/33 Technology File Improvements
Format 34/35 Technology File Improvements
Writing Magic Technology Files
Tips on Writing Technology Files for Magic
Vendor-Specific Technology Files Availabls for Magic

The Magic Technology File Manual

The Magic Technology File Manual
This link is an HTML-format version of the technology file documentaion that comes with the Magic distribution. Completely revised and updated for Magic version 7.4 and technology file formats up to format 31. Also, the WRL extentions, which was previously part of the tutorials, has been merged into the Technology File Manual.

The Magic Toolkit Manual

The Magic Toolkit Manual
This link describes how to generate a process design kit (PDK), otherwise known as a toolkit, in Magic. Using SCMOS and other open-source technology files as examples, it describes various methods to make automatically generated parameterized cells and integrate these and other additional scripted processes into the Tcl-based Magic layout window.

Tech files for MOSIS-supported processes

Important update, September 2019: The SCMOS techfiles are no longer supported by MOSIS for TSMC processes, and the state of support for other foundries is in question as the SCMOS techfile repository is no longer available at MOSIS.

Because the files are open-source, I have copies of the repository tarballs, and can post them here in lieu of MOSIS/ISI. The current release of supported tech files is 2002a while the set that I have used for a long time myself is 2001a.

The last known release of tech files is 2002a. Note that these files are *NOT* distributed with the magic source because the whole set is something like 60MB. Magic comes with the standard "scalable cmos (scmos)" technology file, but the rules, which were originally formulated around a 2 micron fabrication technology, are largely obsolete. The 2002a set targets fabrication processes from 0.5 micron down to 180 micron, but is becoming of more and more limited use as fabrication processes move into deep sub-micron feature sizes, and rule sets get complicated enough that a "one size fits all" description is not easily obtainable.

The general idea of these SCMOS rule sets is that rules can be made that are more conservative than the exact foundry rules, but by being conservative, they can be scaled to different physical dimensions and still meet the basic DRC rules for processes that have similar features but different feature sizes. In some cases this works well, as there are numerous foundry processes that are derived directly from other processes by shrinking all dimensions proportionally, as allowed by advancement in the fabrication machinery. So, for example, there are 130nm processes that are exactly scaled-down equivalents of a 180nm process. If an SCMOS ruleset works for the 180nm process, then it will work for the 130nm process as well simply by scaling all dimensions. But, generally speaking, there are few such directly-scaled processes; each process is fine-tuned to the ability of the machinery that is used for the manufacture. In principle, one can always make rules that are conservative enough that they will generate valid output in any process. The question is how conservative do they have to be made, and how much are is wasted on the layout by applying those conservative rules, and how much performance is lost. For this reason, the SCMOS rulesets in the tarballs linked above only work for small ranges of processes that are (as mentioned above) largely just scaled versions of each other. Within those ranges, the SCMOS rules work well; outside of those ranges, the SCMOS rules become increasingly conservative compared to the foundry rules, and the better option is to redefine the SCMOS rules to better match the foundry process in that range.

The underlying principle of the SCMOS rules is to make every rule an integer multiple of some base dimension. Historically, that dimension was defined as 1/2 the minimum gate length, where the minimum gate length is what defines the process "feature size". So, for a 0.5 micron process, the minimum gate length is 0.5 microns, and the base dimension (which is called "lambda") is 0.25 microns. From that dimension, rules are formulated as the smallest integer value that is equal to or larger than the foundry rule (for the usual minimum value rules such as width and spacing; obviously, for other rules such as maximum width the SCMOS dimension must be smaller than the foundry rule). For the feature size range around 0.5 to 2 microns, which was the range for which the first SCMOS techfiles were made, the rules are: minimum gate length = 2 lambda, minimum metal width = 3 lambda, minimum diffusion width = 3 lambda, minimum contact size (cut + surrounding material) = 4 lambda, minimum poly to diffusion spacing = 1 lambda, and so forth. Since in Magic, wells and implants are generally implicit and auto-generated on output, those rules are not considered in the SCMOS dimensions. Instead, the SCMOS techfile will have different "output styles" for each target foundry, which may differently define the well and implant dimensions, but leaving the original layout the same.

The greatest benefit of SCMOS rules is that it allows designs to be "open sourced", since no exact foundry rules are exposed by the design layout. The drawback is that often the output manipulations involving wells and implants, which are not defined by SCMOS integer multiple dimensions, are foundry-proprietary and cannot be put in the SCMOS techfile itself. In that case, the only way to fabricate a chip designed with SCMOS rules is to pass it to an entity (such as MOSIS) that can apply a separate and proprietary techfile that can convert the SCMOS design to the proprietary foundry rules. Then the SCMOS rules and the open hardware designs only work to the extent that the entity continues to exist and support the SCMOS rules.

Magic keeps a set of search paths which it uses to find system files such as technology description files. Starting with Magic version 7.4, the default path setup is as follows (this is the result of typing the command "path"):

Search path for cells is "."
Cell library search path is "$CAD_ROOT/magic/scmos $CAD_ROOT/magic/tutorial"
System search path is ". $CAD_ROOT/magic/sys $CAD_ROOT/magic/sys/current"

The search directory entry "$CAD_ROOT/magic/sys/current/" provides a place to put the entire MOSIS technology file set without dumping everything into the magic/sys/ directory.

Note that Magic-7.4 uses the current value of the environment or Tcl variable $CAD_ROOT to determine the true search paths. Magic-7.4 defines $CAD_ROOT to comply with distributions expecting runtime files to be installed in /usr/share/. The value of $CAD_ROOT is nominally "/usr/local/lib" unless reassigned at compile time.

Prior to version 7.4, $CAD_HOME was set from the install prefix, nominally "/usr/local/", without the extra "/lib". $CAD_HOME is now unused. There is no particular reason to set either one as an environment variable. One should preferentially use the path command to change Magic's search paths (see below).

The recommended procedure is as follows:

1. cd to $(CAD_ROOT)/magic/sys (where $(CAD_ROOT) is the installation destination directory for runtime files; nominally /usr/local/lib/).
2. Backup the "current" subdirectory if you are updating an older version:
   mv current old
3. Download the tech file set 2002a.tar.gz.
4. Do gunzip current.tar.gz and tar xf current.tar (or, tar xfz current.tar.gz, if your tar command supports the -z option).
5. Rename the new library top-level directory to "current":
   mv 2002a current

You're ready to go! Usage is, for example (AMI 0.5):

magic -T SCN3ME_SUBM.30

With magic versions 7.2 and newer, compiled under the TCL interpreter, you can use the "technology manager" to view all the available technology files. Start magic with the TCL wrapper ( magic -w) and click on menu item "Options->Tech Manager". In the pop-up technology manager window, at the top where it says "Technology: scmos (version 8.2.8)" or similar, click on "scmos" to get a pull-down menu of availiable technology files. Technology files can also be loaded from the command line with the "tech load" command.

Note that magic's search path begins with "." (current working directory), so a modified version of a tech file may be placed in the layout directory and will take precedence over the official version. In addition, new directories can be added to the system search path using the command "path sys +new_path". For example,

path sys +/usr/local/lib/magic/sys/new

This command can be placed in the system ".magic" startup file to permanently add the directory to the system search path. The existing search path can be completely replaced by the command "path sys new_path". For instance,

path sys ". /usr/local/lib/magic/sys/current"

completely ignores the default tech files in the "sys" directory, and

path sys "/usr/local/lib/magic/sys /usr/local/lib/magic/sys/current"

disallows any tech files to be picked up from the current directory.

Acknowledgement: Thanks to Jeff Sondeen of MOSIS/ISI for generating and maintaining these technology files.

Distribution Technology Files

A number of technology files are included with the Magic distribution. These correspond to largely outdated processes, and so are of limited use. However, they are good for getting started with magic, working with the tutorials, classroom teaching, etc. They are compiled from multiple source files using a preprocessor, which occasionally fails for some reason or other (this is an issue with, for example, Solaris). So, the compiled distributions technology files are listed below and available for download. They normally reside in /usr/local/lib/magic/sys/.

Download here:

File	Technology	Feature Size (um)
scmos-sub.tech	HP CMOS26G and CMOS14B	0.8, 0.6
scmos-tm.tech	Scalable CMOS "tight metal" rules	1.2, 1.0, 0.7
scmosWR.tech	Scalable CMOS, no routes through wells	2.0, 1.6, 1.2
scmos.tech	Scalable CMOS	2.0, 1.6, 1.2
minimum.tech	A bare-minimum techfile	(undefined)

Format 28 Technology File Improvements

Magic Version 7.2 began improving the technology file in a number of different ways over the original "tech27" format. Here are the essential differences between Format 28 and format 27:

1. The format is no longer contained in the filename extension but is contained in the first section tech at the top of the file, in the syntax:

   format 28

   This statement tells magic which format it is dealing with, while the file itself always has the extension ".tech".

   Magic will look for files with the name ".tech27" in addition to files of name ".tech". For purposes of backwards-compatibility, the filename extension ".tech27" is equivalent to having the line "format 27" in the tech section of the file.
   
   

2. Sections cifinput, cifoutput, and extract allow an extension to the style line:
   
   

   style base_name variants variant_names,...

   Rather than declare, for instance, styles "lambda=0.09(p)", "lambda=0.09(c)", etc., all of which are mostly copies of one another, the base_name can be declared as "lambda=0.09" and the variant_names can be declared as "(p),(c),(cp),()". When processing the technology file, this statement will be expanded into four styles named, respectively, "lambda=0.09(p)", "lambda=0.09(c)", "lambda=0.09(cp)", and "lambda=0.09()".
   
   The lines following this declaration may be separated into blocks pertaining to one or more specific variants of the base style by adding the line:

   variant variant_names,...

   indicating, with a comma-separated list, one or more variants to which that block applied. All variants can be specified more conveniently with the wildcard symbol:

   variant *

   This method significantly reduces the size and complexity of most technology files, and makes them more readable at the same time.
   
   
3. The cifoutput section may include, at the bottom, a series of lines in the format:

   render cif_layer style height thickness

   These statements are used by the 3D-viewer window (Tcl/Tk plus OpenGL version of magic only) to display the CIF layers using styles from the display styles file (the same styles as are found 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).
   
   From magic revisions 7.2.65 and 7.3.13, the cifoutput section has a modified squares-grid function. This function has been in all magic versions, but previously has not been documented. Its use is becoming more important as processes get smaller. This function places contact cuts, but unlike the "squares" function, it places them exactly on the specified grid (default 1 CIF unit). This prevents contacts from being generated at half-unit. positions, which is critical if the internal magic units are equal to the minimum dimension allowed for mask geometry. The drawback of this method is that contact areas cannot be overlapped between subcells that are rotated with respect to one another, because the contact cuts may be offset and generate a cut area in the output that violates one or more design rules.

   The format of the squares-grid function is as follows:

   squares-grid border width spacing xgrid [ygrid]

   Where border, width, and spacing are defined as they are for the squares command. xgrid defines the grid in CIF units (default 1, which is 1 centimicron, or 1 nanometer if the "nanometers" keyword is used in the scalefactor line at the top of the output style). Magic will not place contact cuts at dimensions smaller than xgrid.

   squares-grid has another use, which is to generate interleaved contact arrays. This is necessary for some processes, especially in the definition of pads. In this use, xgrid and ygrid may differ, and typically both will be some multiple of the contact pitch (spacing + width). For example:

   layer CVA pad
   shrink 300
   squares-grid 0 50 300 350 1
   gds 20 0
   
   layer CVS pad
   shrink 300
   squares-grid 0 50 300 525 1
   gds 22 0
   
   

   generates interleaved columns of via1 and via2 contacts covering the pad area.
   
   From magic revision 3.7.81, there is now an operators slots that is complementary to the squares operator. A slot is essentially a squares operator that is asymmetric in the long and short dimensions of each processed tile. The syntax of the slots operator is as follows:

   slots sborder ssize ssep [ lborder [ lsize lsep [ offset ]]]

   where:

   sborder

   Is the amount to leave on the short tile side between the tile border and the slots.

   ssize

   Is the width of the slot in the narrow dimension.

   ssep

   Is the separation distance between slots.

   lborder

   Is the amount of space to leave on the long tile side between the tile border and the slots.

   lsize

   Is the length of the slot in the long dimension. If unspecified (along with the remaining options), the length is taken to be the full length of the tile minus lborder on each end.

   lsep

   Is the separation between slots in the long dimension of the tile.

   offest

   Is currently unimplemented; it is intended to force odd and even slots as counted across the tile short dimension to be offset from each other, as required by some vendor rules. This is like "squares-grid" in that it causes conflicts where tiles in different subcells overlap, and must be accompanied by a "no overlap" rule.

   Note that, like the "squares" operator, tiles that are not rectangular or that do not overlap exactly will cause errors in the output, and so such tiles should be accompanied in the technology file by drc rules "rect_only" and "exact_overlap".
   
   
4. The extract section may include a similar series of lines to that listed above, in the form:

   height layers height thickness

   Unlike in the cifoutput section, however, these height and thickness values have dimensions in lambda, and the height value is positive or negative relative to the substrate (e.g., diffusion and implant layers would have a negative value for height). Height is relative to the bottom of the layer, and thickness is measured in the positive z-direction from this base. The layer height and thickness are used by the extresis geometry command to produce physical geometry output for a field equation solver.
   
   
5. The extract section contact line has been modified. In addition to the usual syntax:

   contact layers size resistance

   it may additionally include border and separation (in lambda) to better match the physical layout as defined in cifoutput, so the number of contacts per contact area will be the same, and the correct overall resistance computed. The syntax of the extended contact definition is:

   contact layers size [border separation] resistance

6. The extract section has an expanded ability to define device types for extraction. The original statement "fet ..." is still accepted for backwards compatibility. In addition, however, there are a number of devices that can be defined. These are:
   
   

   device mosfet model gate_types sd_types subs_types subs_node_name [perim_cap [area_cap]]

   A MOSFET device. Notes on arguments:

   • model must match a SPICE simulation model name, if this file will be extracted into a SPICE netlist.
   • If subs_types is the keyword "None", then no substrate node will be extracted, and the substrate node name will be subs_node_name. Note that in the Tcl/Tk version of magic, subs_node_name can be a Tcl variable name (beginning with "$"). Variable substitution will be made prior to writing the extract file. For example, the substrate name can be "$VSS", and set to match a layout where the ground node is named "Gnd" by doing:

     set VSS Gnd

     on the command line prior to extraction. Although this may not be as reliable as drawing explicit p- and n-wells around all devices, it does allow the extracted substrate to be matched to the name of the power or ground network.

   
   

   device capacitor model top_types bottom_types [perim_cap] area_cap

   A drawn capacitor. Notes on arguments:

   • model may either be a SPICE simulation model name, or the keyword "None". If None, then the SPICE capacitor format

     Cidx node1 node2 value

     will be produced by exttospice, and the value of the capacitor is computed and written to the extraction file. Otherwise, the SPICE semiconductor capacitor format

     Cidx node1 node2 model L=length W=width

     is used. In this case, it is expected that the capacitance per unit area and perimeter unit length is defined by the device model, and the proper units of length and width will be extracted into the SPICE deck.
   • Tile types top_types must be defined on the same plane as bottom_types, like gates of a transistor device. This is perhaps non-intuitive; however, it should be remembered that the overlap of types on two different planes is always extracted as a parasitic capacitor.
   • If model is "None", then area_cap is required, because capacitors are usually defined as a layer type in a single plane. Thus, the extract section has no way to specify the overlap capacitance between the top and bottom types of the capacitor. value, like other area capacitance values in the extract section, is given in attofarads per square lambda.

   
   

   device resistor model resist_types term_types

   A drawn resistor. Notes on arguments:

   • model may either be a SPICE simulation model name, or the keyword "None". If None, then the SPICE resistor format

     Ridx node1 node2 value

     will be produced by exttospice, and the value of the resistor is computed and written to the extraction file. Otherwise, the SPICE semiconductor resistor format

     Ridx node1 node2 model L=length W=width

     is used. In this case, it is expected that the resistance per square is defined by the device model, and the proper units of length and width will be extracted into the SPICE netlist.
   • The resistor is defined by magic layer types resist_types, with the endpoints defined by the connection of this material to term_types. Terminal tile types term_types must be on the same plane as resist_types; e.g., diffusion on the active plane cannot be used as a terminal for an nwell resistor defined on the well plane (a simple solution is just to define the nwell resistor type as existing on the active plane).
   • When model is None, resistance is defined by the statement resist elsewhere in the extract section, where it is given in milliohms per square for the layer type or types in resist_types.

   
   

   device bjt model base_types emitter_types collector_types

   A bipolar junction transistor (BJT). Notes on arguments:

   • model must match a SPICE simulation model name, if this file will be extracted into a SPICE netlist.

   
   

   device diode model pos_types neg_types

   A diode. Notes on arguments:

   • model must match a SPICE simulation model name, if this file will be extracted into a SPICE netlist.

   
   

   device subcircuit model gate_types [term_types [subs_types]]

   A generic subcircuit. This is designed to be used in cases where a foundry provides SPICE models where devices such as transistors or capacitors are called as subcircuits, because the subcircuit defines additional parasitics that are not captured by the device model. The SPICE output from a device subcircuit device will be a call

   Xidx gate_node src_node drn_node [subs_node] model L=length W=width

   Notes on arguments:

   • model must match a SPICE simulation model name, if this file will be extracted into a SPICE netlist.
   • subs_types is optional and determines whether the subcircuit will have 3 or 4 arguments.

   In general, the "port label" method of defining subcircuits is preferred over the device subcircuit method, especially if the geometry of the device is fixed.

   device rsubcircuit model id_types term_types

   A resistor-like subcircuit. This is designed to be used in cases where a foundry provides SPICE models where devices such as resistors are called as subcircuits, because the subcircuit defines additional parasitics that are not captured by the standard device model. The SPICE output from a device rsubcircuit device will be a call

   Xidx term1_node term2_node model L=length W=width

   Note that this is exactly the same as the call for device subcircuit, except that the id_types layers are identifiers only, and do not represent nodes to be output. The output nodes are the terminals, as would be expected of a resistor device. Length and width are also output, as they would be for a semiconductor resistor model.

   
   
7. The plot section accepts entries for the PostScript and PNM styles. These are the two most useful styles. Style PostScript is generally best to use for small layouts, and produces an output which matches the magic layout. PNM is generally best to use for large layouts, as it produces little detail but is very good at interpolating at the sub-pixel level. plot pnm now requires no information in the technology file, but will default to the colors used in the layout. However, for the best result, it may be helpful to tweak individual layer rendering styles and colors.
   
   
   • style postscript
     has three separate sections defining, respectively, 1) stipple patterns, 2) colors, and 3) how these patterns and colors should be applied for each magic layer.
     
     

     idx pattern

     Defines a stipple pattern number idx which has a 16-by-16 bit pattern. pattern is 8 hexidecimal words of 8 digits each. Note that, for instance,

     1 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

     is required to define a solid color in the plot section. However, the actual PostScript output is smart enough to use a solid color instead of a stipple pattern in this case.
     
     

     idx C M Y K

     Defines a color number idx which has color constituents C M Y K in the cmyk colorspace. Each color constituent is 0 to 255 inclusive.
     
     

     types cidx pidx

     Maps a pattern and a color two one or more magic layer types, in the comma-separated list types. Value cidx always refers to one of the predefined colors. Value pidx may refer to one of the bit patterns, or it may be the value "B" indicating that an outline (boundary) should be drawn, or it may be the value "X" indicating that the type should contain a contact cross. Note that types may be repeated on multiple lines, just like the styles section. Thus,

     m2c,pad,glass 14 B
     pad,glass 14 11
     m2c 14 13

     Puts an outline in color 14 (black) around via, pad, and overglass, additionally filling pad and glass with pattern 11 (in black) and via in pattern 13 (also in black).

     
     
   • style pnm

     draw layer

     Indicates that a layer should be drawn verbatim. The layer will output in the same style as drawn in magic.
     
     

     map layer layer1 [layer2...]

     Indicates that a layer should be drawn with a substitution or combination of another layer or other layers.

Format 29/30 Technology File Improvements

Magic Versions 7.2.58 and 7.3.4 introduce techfile format 29, a version with a greatly simplified notation based on a few observations about magic technology files (see below). Magic 7.3.34 introduces one major change requiring an update of the format number to format 30.

The downloads below are as follows:

"convert1.c" is a (very simple) conversion program that converts format-27 technology files (.tech27) to format 29. The primary purpose is to convert technology files for magic-7.2 to the magic-7.3 format with stacked contacts. It removes the stacked contact types from the file as native types, replacing them as aliases for "stackable" types in the "contacts" section, and cleans up the other sections accordingly. Note that this is a relatively unintelligent converter. One of the things it misses is the more subtle aspects of reading stacked contact types in the "cifinput" section. The contact layers in the "cifinput" section need to be cleaned up by hand. The main purpose of "convert" is to modify Jeff Sondeen's technology files to use the stacked contact methods. Compilation is a simple matter of "cc convert1.c -o convert" and should work on any system. The usage is "convert <old_techfile> [<new_techfile>]" where the extension (".tech27") is required on the name "<old_techfile>". If "<new_techfile>" is omitted, the new filename will be the same as the old filename with ".tech27" changed to ".tech" (the new naming convention).

"scmos8m.tech" and "scmos9m.tech" are general-purpose technology files for processes having 8 and 9 metal layers, respectively. These tech files have been made for testing and instructional purposes only, and do not match any specific foundry process. However, they demonstrate the relative readability of the new format 29, and can be used as a starting point for generating vendor-specific technology files. The update on January 25, 2006, adds a "lef" section to each file to make them usable as template technologies for reading LEF- and DEF-format files.

The (tcsh) shell script "gdsquery.sh" and associated skeleton technology file "gdsquery.tech" show how to wrap magic in a shell script, both as a batch process and interactively, and performs the very useful function of reading and displaying any GDS data file. It does this first by loading a technology file with no GDS layers defined for input, reading the GDS file (provided as the first argument to the gdsquery.sh script), and parsing the error output for all layer types encountered in the input. Then, it generates a simple technology file defining all of these GDS layers and mapping them to magic layers and planes (one layer per plane, so no unwanted interaction occurs). It then generates a short script containing the commands needed to load and view the GDS file. With an optional second argument ("view"), the script launches magic interactively and runs the script that loads and views the file. Note that the technology file gdsquery.tech is included with the magic distribution, and so it should not be necessary to download it. Script usage is "gdsquery.sh gds_filename [view]" where the option "view" launches magic to view the GDS file. Without the view option, the script only generates a technology file "gdstemp.tech" that can be used to read the GDS file.

The (tcsh) shell script "cifquery.sh" works exactly like the script gdsquery.sh (see above), except that it is used to parse a CIF file for all layers used and generate a technology file "ciftemp.tech" that can be used to read the CIF file.

"gdsquery.sh" was updated November, 2006, to better handle GDS layers with multiple data types. This also makes use of the new OS command-line option "-norcfile". Otherwise, the presence of a ".magicrc" file that automatically loads a technology will interfere with attempts by "gdsquery" to use its own generated technology file.

Download here:

File	Description	Size	Date
gdsquery.sh	Script to auto-generate a techfile for GDS viewing	(2.4KB)	November 7, 2006
gdsquery0.sh	Script to auto-generate a techfile for GDS viewing (original)	(2.4KB)	November 20, 2005
cifquery.sh	Script to auto-generate a techfile for CIF viewing	(2.4KB)	January 25, 2006
gdsquery.tech	techfile for quick GDS checks	(0.4KB)	November 20, 2005
techfile converter	Format 27 to 29/30 conversion	(3.5KB)	July 2, 2004
scmos8m.tech	Generic 8-metal tech, Format 30	(41.7KB)	January 25, 2006
scmos9m.tech	Generic 9-metal tech, Format 30	(43.3KB)	January 25, 2006

Some observations about magic technology files leading to the changes in format 30:

1. The MOSIS technology files typically have anywhere from five to ten different "cifinput" and "cifoutput" styles. Because scalability is practically a thing of the past, these styles all correspond to the same lambda value, and so they end up being minor variants of one another. Typically, there is a variant "(p)" accepting p-well layout, and "(c)" accepting generic contacts, and combinations "(cp)" (p-wells and generic contacts) and "()" (neither p-wells nor generic contacts). So there is a huge amount of redundancy, and any changes to the techfile require tediously copying the change to each of the input and/or output styles. And these sort of changes are quite common, such as changing the GDS layer mapping to match a specific vendor's map.

   Format 30 allows the cifinput and cifinput sections to introduce a new style with the following format (for example):

   style scmos0.18 variants (p),(c),(pc),()

   Indicating that this style section covers four different styles named, respectively, "scmos0.18(p)", "scmos0.18(c)", "scmos0.18(pc)", and "scmos0.18()", respectively.

   The different style variants share most of the rules in the style section. For portions of the style section that pertain to one or more variants, the syntax (for example):

   variant (p),(pc)

   introduces a section of the style that pertains only to variants "scmos0.18(p)" and "scmos0.18(pc)". To end the variant-specific section, use the wildcard:

   variant *

   to indicate that all code following the line pertains to all variants. Code immediately following the "style" line is assumed to pertain to all variants until noted otherwise.

   This syntax change greatly increases the readability of magic technology files, greatly reduces their size, and makes it much easier to introduce a simple variant of a CIF input or output style.

Some observations about magic technology files leading to the changes in format 29:

1. Most of the space in magic technology files are taken up by lists of layers. Traditionally, these were supposed to be declared as macros in a technology "master file", and shoved through a preprocessor (again, traditionally, this was the C preprocessor cpp. However, this use of the C preprocessor for general-purpose text file processing has been deprecated in favor of the m4 preprocessor). The result of preprocessing was a mostly unreadable technology file. This was not helped by the fact that all comments were stripped out by the preprocessor.

   By version 6.5.1, the tech file parser at least had the ability to skip over comment lines beginning with '#'. However, the long lists of layers spewed out by the macro processing continued to make unreadable files. A close look at these lists reveals that, by far, the majority consist of a layer plus a bunch of contacts which connect to that layer. In the contact definitions, the layer is called a residue of the contact. That is, the way magic defines contacts, if the contact cut were removed, the residue layers would be what remained. Magic retains the information about residues in its layer definitions.

   Therefore, one obvious simplification is to define a specific notation to represent, by expansion, the union of a layer and all the contact types which have that layer as a residue.

   This notation has been added to tech format 29 as *layer.
   
   

2. The "check plane" entry in the edge4way rule is the only option to appear after a "why" statement, and there is no reason for it, since it is very easy for the parser to check if all "OK types" are in a different plane than the triggering edge. So I have implemented that check, meaning that the "check plane" argument is unnecessary in all cases. It may be present (backward compatibility), in which case it is used as a sanity check (a warning is posted if the plane doesn't match the plane of "OK types") but is otherwise ignored.
3. DRC sections are largely unreadable due to the limited use of the more readable statements such as "width" and "spacing" in favor of the more general, but much more unreadable "edge4way" statement. However, a survey of technology files suggests that most "edge4way" statements fall into a handful of categories which are more easily understood if they are simply shadowed by equivalent commands with a clearer syntax.

   This notation has been added to tech format 29 in the form of three new DRC section statements:
   
   

   surround X Y dist presence why

   Types Y must surround types X by distance dist. This comes in two flavors, depending on the value of presence: When presence is absence_illegal, then types Y must always be present when types X are present. When presence is absence_ok, types X may exist outside of types Y without error, but where they coincide, type Y must overlap X by the amount dist.
   
   Example:
   surround glass pad 67 absence_illegal \
   "pad overlap of overglass < 67 (Mosis #10.3)"
   
   

   overhang X Y dist why

   Types X must overhang type Y by the amount dist. This rule is used for endcaps and other extensions. It flags the complete absence of types X, but does not prohibit the use of X as a bridge (that is, with types Y on either side of X, which will generally be covered by a separate spacing rule, and which may have a different spacing requirement).
   
   Example:
   overhang *poly,rp nfet,pfet 3 \
   "Poly overhang of Transistor < 3 (Mosis #3.3)"
   
   

   rect_only X why

   Types X must be rectangular. This is generally used by all contact types to ensure that the CIF/GDS output rules can generate the contact cuts reliably. This rule also prohibits the presence of bends or notches in a layer type.
   
   Example:
   rect_only pc/a "Contact not rectangular (Magic rule)"
   
   

4. Technology files are made extremely messy by the use of declared stacked contact types. In magic versions 7.2 and earlier, this is not only syntactically messy, but it leads to horribly inefficient memory usage, processing, and even then is not able to represent all possible combinations of stacked contacts (a maximum of three layers can be contacted by a declared stacked contact type, e.g., m123contact.

   Magic version 7.3 greatly simplifies this in the best possible way, by fixing all of the above-stated problems while allowing complete backward-compatibility with the original notation and usage. The new usage is of course preferred when creating a new tech file. In a technology file designed for use with magic version 7.3, it is generally undesirable to declare any contact to connect more than two planes. Where contacts are allowed to stack, the statement stackable should be used in the contacts section of the technology files. Rules for the use of the stackable statement are as follows:
   
   

   stackable

   Declares that all contact types defined prior to this statement should be stackable. The technology file parser will determine which contact types meet the requirements of being stackable; that is, for each pair of contact types, the types must share at least one plane, and each type must connect at least one plane that is not connected by the other (example: pc and via. They share the metal1 plane, but the active plane is unique to pc, and the metal2 plane is unique to via. Therefore, these types are potentially stackable).

   Note that stackable will not generate new types for stacking types already declared, and contact types which may not stack can be defined after the stackable statement.
   
   

   stackable X

   A more narrower definition than the first use, this declares that X may stack with any previously-defined contact type for which stacking is legal (see above).
   
   

   stackable X Y [Z ...]

   The most narrow definition, this declares that type X may be stacked with types Y, Z, and any other types declared on the line (in a space-separated list of individual contact types). No other stacks will be allowed except those which are declared.
   
   

5. The styles section of the technology file previously contained one style per line, listing the magic layer name and the number of a style with which it should be rendered. To make this more readable, format 29 allows this section to have a magic layer name followed by a space-separated list of styles with which it will be rendered. In addition, the styles may be specified by name instead of by number, which is both easier to understand and ultimately, more portable.
   
   The format of the styles section is completely backwardly compatible with earlier techfile formats.

Format 31 Technology File Improvements

The most recent push in Magic version 7.3 is to implement all the useful things previously handled by the C preprocessor (or more recently, the m4 processor). This was partially accomplished earlier with the ability to handle comment lines, and the "variants" keyword in format 30. Format 31 is defined by magic version 7.3, revision 59, and includes the following capabilities:

1. The types section may, after defining all of the tile types, define type-mask aliases in the form:

   alias alias_name tile_type,...

   where alias_name is a unique name, and tile_type is a comma-separated list of already-defined tile types or already-defined aliases. In all subsequent sections, the name alias_name may be substituted for the list of tile types. Typically, this is used as a convenience to define groups of tiles such as "allMetal1" or "allPoly" or "allContacts". It decreases the size a and complexity of the technology file, but done properly, also allows new types to be added to the technology with a minimum of effort.
   
   Alias definitions replace the equivalent macro definitions originally used to generate technology files using either the C preprocessor or m4 processor.
   
   Revision 66 of magic-7.3 extended the use of alias names to layer names encountered in input ".mag" files, and to paint and erase commands. Because the aliases can specify a list of types, this provides an alternative to the "alias" mechanism in the "contact" section. For example, in the "types" section, the statement:

   alias pm12c pc,via

   causes both types pc and via to be painted when type pm12c is painted, or is encountered in an input file. Unlike the contact aliases, only one name can be specified at a time. Thus, in the above example, "pm12contact" would require a separate alias statement.
   
   The primary intended use for the "alias" statement outside of the technology file is to help maintain compatibility between different technologies. If technology A declares high-voltage n-diffusion to be type "hvndiff" but technology B declares it to be a combination of "ndiff" and "hvimplant", then the statement:

   alias hvndiff ndiff,hvimplant

   Allows layout designed in technology A to be read into technology B (However, note that this statement is not reflexive!).
2. The line:

   include filename

   may appear on any line in the technology file, and will automatically insert the contents of file filename. This file must have the same suffix as the top-level technology file and must exist in the same search path. In may contain only lines that are syntactically consistent with the point at which the file is included; for example, it cannot redefine sections that have already been parsed in the top-level file. Included files are best used to define sections that are shared among several technologies.
   
   Calls to include may be nested.
3. A new CIF/GDS boolean operator was added in revision 72 of magic-7.3. This operator has the form:

   bloat-all types1 types2

   This operator first includes all material of types1. Then, it searches the boundary of tiles of type types1 for neighboring tiles of types2. It continues the search on neighbors until all connected tiles of types types2 have been found and include. This operator is useful for generating implant masks that include all of a particular type, when there is no other discerning marker for that type. For example, say that type "hvnfet" is a high voltage n-type MOSFET, but that the "thickox" GDS layer must cover all n-diffusion connected to the HV transistor, and may not cross a diffusion border. Previously, it would be necessary to define types "hvndiff" and "hvndc", etc., to ensure that all connected diffusion is covered by "thickox" in the GDS output. This can be avoided by defining the "thickox" layer in the cifoutput section of the technology file as:

   bloat-all hvnfet ndiff,ndc

   This greatly simplifies the technology file by having the layer "hnvfet" as the only distinguishing marker of a high-voltage transistor, without requiring extra layers "hvndiff" et al.
4. A new CIF/GDS boolean operator was added in revision 74 of magic-7.3. This operator has the form:

   bbox [top]

   The operator does not take any magic layer types as arguments. It should be the first operator for the CIF/GDS type (see the example below). When encountered, the CIF/GDS generator routine creates a rectangle of the same size as the cell definition bounding box.

   The optional argument top indicates that the layer should be drawn for the top-level cell but not for any subcells. This is mostly a convenience, but one should be aware, when using it, of the difference between starting up magic with a loaded subcell (which magic then believes to be a top-level cell), vs. starting up magic with the top-level cell and then loading the same subcell (which magic then believes is not a top-level cell).

   An example use of the bbox operator to generate a layer encompassing an entire chip is illustrated below:

   layer BULK
   bbox top
   grow 30
   calma 60 0

   This use avoids the necessity of creating a separate magic layer which then gets in the way of all selection operations. Why foundries require layer definitions like this is beyond me, but they do.

   Another use for the bbox operator is to generate fill patterns on the top level of the chip. A temporary layer can be grown around all layers in a plane, and subtracted from bbox using the and-not operator. The patterns can then be generated with the squares-grid function. Use of the -grid form is required (with the full five arguments) to ensure minimum spacing between fill patterns at tile boundaries.

Format 32/33 Technology File Improvements

From November, 2006, I have introduced a number of changes that essentially complete the list of things I wanted to do to simplify the Magic technology file format to something that is easy for non-experts to write and develop. The differences between formats 30 and 33 are summarized below:

New "aliases" section

Format 30 allowed alias names to be defined for layer types or groups of layers types, using the statement "alias" in the "types" section of the techfile. The major problem with this was that the "types" section necessarily comes before the "contact" section, so that the "*" wildcard character that includes all contact types to which the layer prefixed with "*" belongs as a residue can't be used. Also, any alias names for stacked contact types (in the "stackable" statement) can't be used. This was corrected by introducing a new section, the "aliases" section, that comes after the "contact" section. Aliases are defined in a simple format:

alias alias_name types_list

where alias_name is a unique name that cannot shadow any existing layer type name or alias, and types_list is a comma-separated list of magic layers types and/or previously defined aliases.

Changes to the "extract" section

lambda value

The value can now be a non-integer value. lambda defines the scalefactor between internal units and centimicrons. Some processes like 65nm have sub-centimicron scale values, and can now be represented properly in the output. It should match the "scalefactor" value used in the "cifoutput" section. This scalefactor is used when "ext2spice" or "ext2sim" converts parasitic capacitance values to physical units in the netlist file output. If the "units microns" statement is used (see below), then it also defines the scalefactor used to convert parasitic area and perimeter capacitance values in the rest of the extract section.

units microns

Traditionally, all parasitic capacitance units have been interpreted as attoFarads per lambda for perimeter capacitance and attoFarads per lambda-squared for area capacitance. By adding the statement "units microns", all capacitances will be interpreted as attoFarads per micron and attoFarads per micron-squared, respectively. The scalefactor given by the "lambda" statement determines the conversion factor between microns and Magic's internal (lambda) units.

defaultareacap layers plane [subplane] value

This defines the parasitic capacitance to substrate for layers in layers, restricted to the plane plane. If subplane is specified, it represents the topmost plane in which all layers should be treated as equivalent to the substrate. Normally, this would be the "well" plane, indicating that capacitance to wells (nwell, pwell) should be the same as capacitance to substrate, and that all layers in all planes between plane and subplane should be considered "shielding" types that reduce the coupling capacitance to substrate by the amount overlapped. The subplane plane is typically not specified for well and diffusion area capacitance. Diffusion area capacitance is typically specified separately for N and P types, with types on the well plane ignored (since most Magic techfiles auto-generate the well types and consider them to be optional).

defaultperimeter layers plane [subplane] value

Defines the perimeter capacitance for a layer. The capacitance value is in attoFarads per micron or lambda instead of microns-squared or lambda-squared; otherwise, the arguments are the same as the defaultareacap statement.

defaultsidewall layers plane value

Defines the coupling capacitance between the types in layers on the plane defined by plane. value is in attoFarads per lambda or micron (see "units" statement, above). This is equivlent to the the "sidewall" statement, but assumes that layers defines all geometry in the plane. This is valid under most circumstances.

defaultoverlap layers1 plane1 layers2 plane2 value

Defines the area capacitance between layers on two different planes. This is equivalent to the "overlap" statement, except that it uses the planeorder statements to automatically determine the planes that are between plane1 and plane2. All material in these planes is considered to be shielding.

defaultsideoverlap layers1 plane1 layers2 plane2 value

Defines the perimeter capacitance between overlapping layers on two different planes. This is equivalent to the "sideoverlap" statement, except that it uses the planeorder statements to automatically determine the planes that are between plane1 and plane2. All material in these planes is considered to be shielding. The defaultsideoverlap statement also generates the capacitance values for the reflexive case "layers2 plane2 layers1 plane1".

contact value

Contact cut dimensions are no longer used. If present, according to the syntax of earler techfile formats, they are ignored. Instead, the values defined in the "cifoutput" section that inform Magic how to generate contact cuts are used.

Changes to the "drc" section

style stylename [variants variantlist]

This is exactly the same form as "cifinput", "cifoutput", and "extract" sections, and allows different DRC rules to apply under different circumstances, with the command "drc style stylename" used to switch between them. Likewise, the variantlist defines different style variants which share some portion of the rules.

scalefactor value

Each DRC style may declare a scalefactor. This scalefactor is a positive integer and indicates by what factor all distance values in the DRC rules are scaled up relative to the database (lambda) units. This can be used to specify DRC distances in some physical measure like nanometers or centimicrons. When DRC distances are finer than the database minimum spacing, the rules are rounded up or down as appropriate to the given rule. If the internal grid spacing is changed (e.g., with the "scalegrid" command), the rules are all re-evaluated in the context of the new internal grid spacing. The point of doing this is to allow vendor-specific rules to be copied directly from a design rule manual into the Magic techfile, but continue to allow SCMOS-like layout using a lambda grid.

spacing types1 types2 distance surround_ok why

The surround_ok option extends the spacing command (with the same syntax) to allow rules such as "N-diffusion in n-well spacing to unrelated n-well edge". It checks the spacing from types1 to types2. However, if types1 is surrounded by types2, then checks are only made from the end of the overlapping types2 out to length distance.

spacing types1 types2 distance corner_ok layers3 why

This is a convenience function that duplicates an edge4way rule defining the common case of a spacing from one layer to another when the two types may intersect, such as at a device. For example, it can be used to define the spacing between active and polysilicon, while allowing the two to intersect to form a transistor. layers3 is (are) the type(s) formed by the intersection of layers in types1 and types2.

extend layers1 layers2 distance why

This is a variation on the overhang rule, and implements the situation where (like overhang) layers1 must be at least distance long when extending outward from layers2, but (unlike overhang) it is legal for layers2 not to be bounded by layers1. For example, one would use "overhang ndiff nfet" to define the minimum length of a transistor source or drain, because type "nfet" must always be bounded by diffusion (or poly, which is another "overhang" rule). One would use "extend nfet ndiff" to define the minimum length of a transistor, because type "ndiff" may exist without being bounded by a transistor type.

Changes to the "lef" section

obs type1,type2 lef_type...

A special case of the obs statement that allows two Magic layers types to be declared. This is used for a lef_type that defines a cut type. Since standard Magic contact types define a contact area to be filled in with cuts using a generation rule, there is no real equivalent obstruction type to match a LEF obstruction for a LEF cut type. This statement will create obstruction layers on the two residue layers of the contact type.

ignore lef_type...

This tells Magic to ignore all geometry in a LEF file that is defined by the LEF types in the list lef_type.

Changes to the "cifoutput" section

gridlimit value

This defines the minimum allowed grid for geometry output from Magic (in CIF, GDS, or the database). When this option is set, no geometry finer than value (in the units set by the scalefactor statement, that is, either centimicrons or nanometers) will be generated. In addition, input of CIF or GDS data that is off-grid will be snapped to the grid (and the grid will not be automatically rescaled), and the "scalegrid" command will fail if the requested scale would be finer than the limit set by gridlimit. Note that the internal grid is limited to not only value, but also integer multiples of value. For example, a grid of (3/2)*value is prohibited since it would generate geometry on absolute coordinates that are not at multiples of value, even though the grid spacing is larger than value.

Changes to the "mzrouter" section

layer layer hCost vCost jogCost hintCost overCost

The maze router route layer definition has been expanded to include one extra cost factor, the overCost. The overCost is the cost of placing a route over top another layer. This helps prevent the maze router from making points of contact to another route or pin inaccessible (a more effective strategy is to place fence or obstruction layers above all unrouted pins, but the overCost is helpful when there is no a priori knowledge about unrouted nets).

Below is a downloadable general-purpose template for a non-specific 0.18 micron process.

File	Technology	Feature Size (um)
sample6m.tech	1 poly, 6 metal	0.18um (180nm)

Format 34/35 Technology File Improvements

Changes to the "cifoutput" section

scalefactor scale angstroms

Values in the section may be given in units of angstroms.

options see-no-vendor and options no-errors

Determines behavior of the "cif see" and "cif paint" commands.

bridge

New cifout operator that bridges gaps in implant layers

close

New cifout operator that closes holes in layers

net

New cifout operator that handles net connectivity.

boundary

New cifout operator that turns a FIXED_BBOX cell boundary into an output layer.

mask-hints

New cifout operator that allows manual patching of layers

labels ... port|noport

Extended handling of labels and label layer attachments for distinguishing port labels vs. non-port labels.

Changes to the "cifinput" section

labels ... text|port|sticky|cellid

Extended handling of labels for ports, and other features.

copyup

New cifinput operator that helps deal with layers describing a device being split into multiple overlaid cells.

boundary

New cifinput operator that does the opposite of the cifoutput operator of the same name.

Changes to the "drc" section

angles

New rule handling layer restrictions at specific angles.

off_grid

New rule handling the rare case where off-grid vertexes can be generated by magic during GDS output.

% substitutions in "why" rules

This method allows rule distances to change when the lambda value is changed.

option wide-width-inclusive

This DRC option determines the behavior of distances specified with the "widespacing" rule.

Changes to the "extract" section

substrate

The substrate keyword allows a set of layers to be defined as identifying the substrate, including "space", and allows types to be defined that shield the substrate (such as deep nwell or isolated substrate marker regions).

defaultsidewall ... cap offset

Added new offset value to the sidewall cap value to improve modeling.

Device model types None, Ignore, and Short

These special device model names are used to force extraction of non-semiconductor devices or ignore certain structures that would otherwise be extracted as a device.

Subcircuit device parameter names

This new method allows subcircuit types to be given named parameters representing such extractable features as device length, width, terminal area and perimeter, position, substrate, or resistance or capacitance value. Multipliers and offset corrections in the resulting values are also supported. Parameter limits for specific extracted device names is also supported.

Antenna rule definitions

Added an entire subsection syntax for defining antenna rules.

Writing Magic Technology Files

Writing technology files is easy enough with format 33 to make a short tutorial possible. Any technology file writing is a dedicated undertaking and will require some substantial effort to test, debug, revise, and refine, but this is true of any technology definition, regardless of the EDA program and file format. Properly and sensibly defining a new technology is an inherently difficult process.

1. First, start with a shell technology file, one closely matched to the process, if possible. The example file sample6m.tech will be used here as an example of a recent format (format 33) file. As noted above, this technology file does not match any specific process and contains no proprietary foundry information, but is reasonably convenient to fill with values from a foundry design rule and process specification manuals.

2. One of your first concerns will be whether you want to generate lambda-based rules or micron-based rules. With lambda-based rules, all layout is done on a lambda grid, where lambda is usually (but not necessarily) equal to the smallest feature size of the process. The term "lambda" comes from the use in mathematics to define a dimensionless unit. The whole idea behind using the dimensionless units of lambda is the foundation of "scalable CMOS", in which any layout drawn in lambda units can be sized to any process by setting the scale factor between lambda units and physical units prior to writing CIF or GDS (both of which require physical units, since they go directly to the physical process mask). Unfortunately, processes have never really been perfectly scalable, and as feature sizes get smaller and smaller, layouts become less and less scalable.

   The technology file format 33 can be written pretty much independently of the choice of dimensioned or dimensionless units. For this reason, I suggest selecting a lambda based on the usual rule of 2 lambda = 1 minimum gate length, and letting Magic handle the rest.

   For most modern processes, working on a lambda grid will work well for some design rules, and not so well for others. This can waste a lot of layout space, particularly if a common layer like metal1 happens to end up with a minimum dimension which is just a fraction of a micron larger than the size of the next integer lambda boundary. One can either accept the conservative sizing, or use the "scalegrid" command along with the "snap internal" command to switch between the more convenient lambda-based design grid and a finer grid.

   Lambda-based rules are what magic has traditionally used, and layout is generally much, much easier to draw on a lambda grid. However, it is possible in magic versions 7.2 and 7.3 to define all layout on a fine grid, but by default draw on a much larger grid. However, magic's grid is always in dimensionless units, and the translation to physical dimensions is always declared when specifying a style for reading or writing CIF and GDS. Still, it is often convenient to think of the magic grid as being in units of, say, 100 nanometers, on the assumption that there is only one scale factor allowed when converting CIF, GDS, or LEF/DEF input to the magic database or converting the magic database to CIF, GDS, or LEF/DEF output. For most modern processes, this is a valid assumption; the process scales so poorly that a new technology file is required for each new feature size.

3. You will need to consider how to define the planes and types. Keep in mind that the fewer planes and types, the better. With Magic version 7.3 (and newer) there is no need for separate via planes as is used in some of the existing tech27 files. The usual style is one plane for well, one for active, one for each metal routing layer, and one for oxide (overglass).

   Types generally differ from CIF/GDS layers in that N-types and P-tyes are declared separately, high-voltage and low-voltage types are declared separately, and the select and implant masks which otherwise differentiate these types are not defined at all, except when reading or writing CIF/GDS.

   Likewise, resistors and capacitors are generally defined as separate types, and the implant or blocking masks which define them are not defined. The resistor and capacitor types are then used in preference to "marker" boundary layers.

   The layers in the template technology file are a good starting point. They do not define the more complicated (and often optional) types such as resistor and capacitor devices, and high-voltage devices, but these are pretty easy to add incrementally, especially when type aliases are used (see below).

4. The contact section is the next to define after planes and types. An important consideration is how you will define contacts. Magic can handle contacts in two ways. The traditional method is to define contacts by area, and use a contact cut generation rule to place contact cuts when writing output. This has the benefit that one does not have to worry about drawing and manipulating individual contact cuts during layout. The drawback is that the design of the technology file becomes considerably more complicated. For reason of the convenience when doing layout, Magic's composite (rule-based automatic cut generation) form of contacts is useful, and preferred. When generating DRC rules for the technology file, you will need to keep in mind the difference between the distance to the composite contact type and the distance to the actual contact cut.

   If you use standard Magic automatic contact cut generation, determine what is the minimum overlap of material on each side of the contact. If they differ, you must decide whether ease of creating layout or fidelity to the vendor rules is more important; you can either define the contact as the size of the type with the smallest overlap (and require a specific surround amount of the other layer in the DRC rules), or you can define the contact as the size of the type with the largest overlap (and assume a liability of extra material of the other overlapping type for each contact generated).

   In the contact section, you only need to declare each contact type followed by the two types of material that the contact type connects. At the end of the section, add the statement stackable, and all legally stackable contact types will be automatically generated. Note that stackable generates stacked types for all contact types already defined; thus, if some contact types may not be stacked in a process, they may be defined after the stackable statement. The stacked contact handling also means that you do not need to worry about the "home plane" of contacts. Generally, though, the convention is to define the contact in the "types" section as existing on the plane of its lowest residue type. For instance, type via is defined on plane metal1, while type polycontact is defined on plane active, and so forth.

5. The alternative for handling contacts is to explicitly define each contact cut type and use "surround" DRC rules for each type that overlaps the cut. Each contact cut can either be on its own plane or be on the plane of one of the materials. Be aware of the difficulty of specifying DRC rules for these cases. For contact types that contact multiple layers (such as diffusion and poly contacts), it will be necessary to use "surround ... absence ok" rules to allow different types of material to overlap the contact.

   Important: When drawing cuts explicitly, do not define contacts in the "contacts" section. Only define the connectivity to other layers using the statements in the "connect" section.

6. Define aliases for all the important layer groups, such as all layers with metal1, all n-type diffusion, all polysilicon layers, all resistor types, all non-resistor types, etc. These alias definitions go in the "aliases" section, right after the "contact" section.

7. The styles section used to be utterly obscure, but I have effected changes which now make it easy to create. Now, each magic type may appear on one line, followed by a space-separated list of styles. The styles may be specified by name, corresponding to the names defined in the system ".dstyle" file. Most of the style names are things like "ndiffusion" or "contact_X'es". Note that the more types are applied to a layer, the slower it will render. Note that styles are rendered in the order they appear in the ".dstyle" file, not the order they appear in the technology file. It may be necessary to experiment with this section to get the result you want.

   It is now much easier than before to define new styles in the ".dstyle" file. There is no limit to the number of styles that can be defined, and styles may be added anywhere in the list. Note, however, that each new layout style must be added to the section "layout_styles" and again in "pale_styles" (the style used when a layer is in a cell not being edited). For completeness, new style names should be reflected in all of the system style files, which at the moment includes the Pseudocolor graphics styles (mos.7bit.dstyle), TrueColor graphics styles (mos.24bit.dstyle), and OpenGL graphics styles (mos.OpenGL.dstyle). "Pale" styles are usually the same as the regular layout styles except the color is lighter, or it uses a sparser stipple pattern, which has the same effect of making the layer color look lighter, or paler, when the layer is not in the current edit cell.

   The styles section should necessarily include entries for error_p, error_s, and error_ps; otherwise, DRC errors will not show up on the layout. Normally these entries are set to the usual value "error_waffle".

8. The compose section allows changes to magic's paint and erase tables. These tables are perhaps the most fundamental concept in magic after the idea of corner stitching. Generally, these tables are set up automatically and do the right thing. In particular, magic-7.3 sets up very complicated paint and erase tables for contacts, which are better than in previous versions. For instance, if a via is inside the cursor box, "erase m1" will leave metal2, and "erase m2" will leave metal1, and "erase via" will leave nothing. Likewise, contacts in a stack can be erased without disturbing the other contacts in the stack.

   There are usually only two reasons to add entries to the compose section. The first is for devices, and ensures that, for instance, polysilicon drawn over ndiff will result in layer "nfet", instead of erasing the ndiff and replacing it with poly (which would be the default behavior, because they both exist on the same plane, and magic doesn't have any understanding of composite layers other than what ends up here in the compose section). This includes other, non-device composite types like pads. The second reason is to allow a simple painting method for wholesale type changes. That is, the compose rules can be set up such that painting nwell over N-type devices will turn them into P-type devices, and painting pwell over P-type devices will turn them into N-type devices. This method makes it quicker to design complementary logic.

9. The connect section has been made much simpler by the introduction of the asterisk notation. Magic already understands connectivity between planes as defined by the contacts. This section declares which types connect electrically to one another in a single plane. A type and all its contacts can be defined very simply with the asterisk notation. For example,

   *m1 *m1

   declares that metal1 and all contacts which connect to metal1 are electrically connected. Other than the "*type *type" notation, the connect section should declare how diffusion types connect to each other (such as ndiff and psd, if abutment is allowed by the process), and how electrical connectivity should be determined across devices (e.g., poly, pfet, and nfet should all be electrically connected).

   Note, however, that electrical connectivity should be prohibited between terminals of a device. That is, pfet should not connect to pdiff, and rp (polysilicon resistor) should not connect to poly, if these types (pfet and rp) appear as devices in the tech files's extract section.

10. The cifoutput section must necessarily work in tight combination with the drc section to produce correct layout. It works best to start with a single style and make sure it works before attempting any others. Usually, only one output style will suffice. The most important line in the section is scalefactor, which determines the physical scale of the layout. If the scale is large enough that no dimension is smaller than 0.1 micron (1 centimicron), then the scale can be written, for example:

    scalefactor 9

    to set 1 magic lambda unit equals 9 centimicrons (90 nanometers), which is correct for so-called 0.18 micron processes. On the other hand, if you want to draw on a 10 nanometer grid, then the line would be:

    scalefactor 1

    However, if parts of the layout which are generated as opposed to drawn are smaller than a 10 nanometer grid (for instance, contact cuts which are 25 nanometers by 25 nanometers), then it will be necessary to list all dimensions in the cifoutput section in nanometers instead of centimicrons, and the line would be:

    scalefactor 10 nanometers

    It is even possible to set the scalefactor to a fractional value, such as:

    scalefactor 6.5

    for a 0.13 micron process. However, all values in the cifoutput section must be integer, and as it is unlikely that all output dimensions will be integer centimicrons in this case, the notation "scalefactor 65 nanometers" is almost certainly preferred.

    If you are using the Magic rule-generated contact cuts, these generation rules must be defined here in the "cifoutput" section. Rules for generating contact cuts from drawn contact areas are embedded in this section using the "squares" statements.

    Important: The contact cut rules will always center cut arrays inside a given tile. Centering will necessarily create geometry at half the internal grid spacing. If possible, use an internal grid that is twice the minimum allowed grid. That way, cuts can always be centered and still be legally on the minimum allowed grid. If that is not feasible, then you will have to declare the DRC rule "no-overlap" for each contact type. Otherwise, overlapping subcells may snap contact cuts to different grid points, creating overlapping cuts that violate the cut exact-width rule.

    The cifoutput section is best described by the Maintainer's Manual number 2. The wildcard asterisk notation again makes for a cleaner representation, allowing statements such as:

    layer CMF *m1
    labels *m1
    calma 49 0

11. All the same rules and regulations apply to the cifinput section as they do for the cifoutput section. Again, see the Maintainer's Manual number 2 for a detailed description.

12. I recommend ignoring the mzrouter, garouter, wiring, plowing, and router sections empty or default at first. You can fill them in later after everything else works correctly.

13. The drc section is by far the most complicated part of the technology file, and the most difficult to get correct. The type aliases help greatly to make the DRC section simple and easy to generate. General statements such as the metal1 width rule can be succinctly stated as:

    width allm1 50 \
    "Metal1 width < 0.5um"
    

    Be sure to use the "scalefactor" statement at the top of the DRC section. With the right scalefactor, most rules can be copied directly from the vendor DRC manual, using the appropriate rule statement. Most common rules will not require much effort. If you use Magic's contacts with automatically-generated cuts, then you will need to make sure that rules involving contact cuts add or subtract the minimum overlap amount as defined by the boundary value in the cifoutput "squares" statement for the associated cut type.

    Choosing the right DRC rule is always important. Some of the more obscure edge4way rules have been recast in a simplified syntax. This includes the statements surround, overhang, and rect_only, as well as specific options to traditional rules such as "spacing" to handle common situations.

14. The extract section is improved by the introduction of new device types and the ability to specify groups of layer types with the type aliases and default rules when declaring area, overlap, and perimeter capacitances. Device models have been improved such that types can be declared as MOSFETs, BJTs, resistors, capacitors, and diodes. These devices avoid the problem of earlier "fet" constructs in that they produce the expected device in the final netlist (e.g., SPICE) file, along with an actual value.

    Be sure to use the "lambda" and the "units microns" statements, and the "default" parasitic capacitance rules (e.g., "defaultareacap" and "defaultperimeter"). Define groups of types on each plane in the aliases section. Then, creating the extract section should be a simple matter of copying values out of the electrical specification manual for the foundry process.

15. Check the technology file against example layouts, correct, and iterate to completion.

16. When everything above is complete and working satisfactorily, finish up the optional sections (mzrouter, wiring, plot, etc.) to complete a first draft of the tech file.

Tips on Writing Magic Tech Files

Lately, fabrication processes seem to change about as often as I design chips, which means that writing tech files takes up proportionately more of my time. I would like to write a "techfile preprocessor" or "rule compiler" sometime, but for now, a list of tips should be helpful.

The following tips are provided by Erik Peterson (erik@yanntek.com) and posted with his permission. To a large extent, the techfile formats 29-33 attempt to alleviate the need to use a preprocessor by defining statements and constructs that implement macros ("alias") and conditional blocks ("variant"). In addition, the need for the DRC macros has been largely replaced by adding more convenient drc commands ("surround", "overhang", "extend", etc.).

"When I'm writing techfiles, I find it impossible to get everything right as I get close to the end of transcribing a foundry's DRC booklet. So, I use the preprocessor as much as I can to macro everything: rules AND layer combinations. I like to macro rules too, that way they all line up when you are trying to figure out what rules are written/ignored/redundant etc., etc. Anyhow... my drc.xx sections tend to look like this:

	...
	ECHK(4.2.1,Active,6,Active to Poly1 spacing must be at least 6)
	SCHK(4.2.1,Poly1,Active,6,TOK)
	/*   4.2.4      NOT USED */
	/*   4.2.5      NOT USED */
	/*   4.2.6      UNABLE TO CHECK: antenna rule! */
	...
	...
	

Anyhow. Here is my drc-macro section (doesn't include all the cool cifout-boolean extensions; I wrote this in the dark ages). Until I get a rule-compiler (!), this is one of the ways I keep myself from screwing everything up."

techfile macros

Here are some more helpful tips for writing technology files from me (Tim), gleaned from years of experience:

1. The "cifinput" section should always have a "fallback" type for all boolean operations. That is, the operations

   layer A B
   and C

   will fail if type B exists in the input without type C present. In this case, failure means that real geometry in the input file disappeared, and cannot be seen in the magic layout. A better representation is:

   layer D B
   
   layer A B
   and C

   In this case, GDS type B is translated into magic layer D everywhere. Then, all cases of B coincident with C are translated into magic layer A, overwriting occurrences of layer D (this assumes that magic types A and D are defined on the same plane, and that there are no special rules declared for painting A on top of D; the default rule for types on the same plane is: A painted on D causes A to replace D.
   
   Example:

   layer genericcontact CCC
   grow 20
   gds 23 0
   
   layer polycontact CCC
   grow 20
   and CMF
   and CPG
   gds 23 0

2. Alternatively, if you are unsure what is in your input GDS file, you may want to define a new technology that represents each GDS layer exactly, and defines a separate plane for each layer. This kind of technology file is useless for doing layout, but very helpful for viewing GDS input.
3. Do not use the "contact X'es" style (style #32) for contacts which contain non-Manhattan geometry; magic draws one "X" per tile, which works fine for square contacts, which only have one tile per contact. Nonmanhattan geometry breaks contacts up into many tiles, so the drawn "X's" get very messy. Use "contact_waffle" (style #33) instead for these types.
4. If you need to read in non-Manhattan contacts and/or contact cuts, and write them out again, consider rewriting the technology file so that it defines contact cuts exactly (that is, the cifinput section does not use "grow" when reading contacts, does not "and" with any layers, and the cifoutput section does not use "squares"). Defining contact cuts exactly makes layout more tedious, but it ensures there will be no mistakes when writing non-Manhattan contacts back out to a GDS stream.
5. DRC rules involving large distances slow down Magic because they require Magic to check interactions between subcells over large areas. Put rules such as pad rules and maximum metal width rules in a DRC style "variant". Run the fast, basic ruleset continuously, and run the slow, variant ruleset only occasionally, as the need arises.
6. Add more complex layers and definitions (such as resistors, capacitors, high-voltage devices, etc.) incrementally, after the essential rules and layers have been defined and tested.
7. While you work on a technology file, create example layouts matching the vendor design rules for each type. Periodically confirm that errors appear when design rules are violated, and that no errors appear when they are not. You can use the "cif see" command to look at automatically-generated layers such as implants, wells, and contact cuts. As long as you do not add or remove planes or types, you can make corrections to the tech file, then use the "tech load" command to read in the changes and check them for accuracy (for DRC errors, you will need to do "drc check" to force a re-evaluation after loading the revised technology file). The easiest, fastest way to update the technology file is the command "tech load [tech filename] -noprompt".

Vendor-Specific Technology Files Created for Magic

The following is a partial list of vendor-specific technology files that I have created. These are not available for general distribution but can possibly be obtained with permission from the vendor (i.e., confirmation from the vendor that an NDA is in place between the two parties). Note that no distribution method is in place yet with any of the listed vendors, but if there is apparent interest in these technology files, I will make an attempt to get some procedures put into place.

• AMIS C5X (0.5 micron)
• AMIS 350 (0.35 micron)
• Chartered Semiconductor (0.13 micron)
• IBM 0.18 (7RF)
• Jazz Semiconductor SBC35QTX (0.35 micron SiGe process)
• Jazz Semiconductor SBC18PT (0.18 micron SiGe process)
• TSMC (90 nanometer 1P9M)
• X-FAB XC-10 (1.0 micron high voltage)
• X-FAB XC-35 (0.35 micron thick top metal)

email:

Last updated: January 5, 2024 at 9:42pm