1%---------------------------------------------------------------------------- 2% Magic Maintainer's Manual #2 3%---------------------------------------------------------------------------- 4 5\NeedsTeXFormat{LaTeX2e}[1994/12/01] 6\documentclass[letterpaper,twoside,12pt]{article} 7\usepackage{epsfig,times,pifont} 8 9\setlength{\textwidth}{8.5in} 10\addtolength{\textwidth}{-2.0in} 11\setlength{\textheight}{11.0in} 12\addtolength{\textheight}{-2.0in} 13\setlength{\oddsidemargin}{0in} 14\setlength{\evensidemargin}{0pt} 15\setlength{\topmargin}{-0.5in} 16\setlength{\headheight}{0.2in} 17\setlength{\headsep}{0.3in} 18\setlength{\topskip}{0pt} 19 20\def\hinch{\hspace*{0.5in}} 21\def\starti{\begin{center}\begin{tabbing}\hinch\=\hinch\=\hinch\=\hinch\=\kill} 22\def\endi{\end{tabbing}\end{center}} 23\def\ii{\>\>\>} 24\def\I{\hinch} 25\def\II{\I\I} 26\def\vns{\vspace*{-0.05in}} 27\def\mytitle{Magic Maintainer's Manual \#2: The Technology File} 28\def\q{\special{ps:(") show}\hspace*{0.6em}} 29\def\grt{\hspace*{0.3em}\special{ps:(>) show}\hspace*{0.3em}} 30\def\bk{\special{ps:/bksp 2 string def bksp 0 92 put bksp show}\hspace*{0.4em}} 31\def\vbar{$|$} 32 33\newcommand{\micro}{\Pifont{psy}m} 34\newcommand{\ohms}{\Pifont{psy}W} 35 36%---------------------------------------------------------------------------- 37 38\begin{document} 39 40\makeatletter 41\newcommand{\ps@magic}{% 42 \renewcommand{\@oddhead}{\mytitle\hfil\today}% 43 \renewcommand{\@evenhead}{\today\hfil\mytitle}% 44 \renewcommand{\@evenfoot}{\hfil\textrm{--{\thepage}--}\hfil}% 45 \renewcommand{\@oddfoot}{\@evenfoot}} 46\newcommand{\ps@mplain}{% 47 \renewcommand{\@oddhead}{}% 48 \renewcommand{\@evenhead}{}% 49 \renewcommand{\@evenfoot}{\hfil\textrm{--{\thepage}--}\hfil}% 50 \renewcommand{\@oddfoot}{\@evenfoot}} 51\makeatother 52\pagestyle{magic} 53\thispagestyle{mplain} 54 55 56\begin{center} 57 {\bfseries \Large \mytitle} \\ 58 \vspace*{0.5in} 59 {\itshape Walter Scott} \\ 60 \vspace*{0.25in} 61 Special Studies Program \\ 62 Lawrence Livermore National Laboratory \\ 63 P.O. Box 808, L-270 \\ 64 Livermore, CA 94550 \\ 65 \vspace*{0.25in} 66 {\itshape John Ousterhout} \\ 67 \vspace*{0.25in} 68 Computer Science Division \\ 69 Electrical Engineering and Computer Sciences \\ 70 University of California \\ 71 Berkeley, CA 94720 \\ 72 \vspace*{0.25in} 73 {\itshape (Updated by others, too.)} \\ 74 \vspace*{0.25in} 75 This manual corresponds to Magic version 7.4 76 and technology format 30 77\end{center} 78\vspace*{0.25in} 79 80{\noindent\bfseries\large Tutorials to read first:} 81\starti 82 \> Magic Tutorial \#1: Getting Started \\ 83 \> Magic Tutorial \#2: Basic Painting and Selection \\ 84 \> Magic Tutorial \#6: Design-Rule Checking \\ 85 \> Magic Tutorial \#8: Circuit Extraction \\ 86 \> Magic Tutorial \#9: Format Conversion for CIF and Calma 87\endi 88\noindent You should also read at least the first, and probably all four, 89of the papers on Magic that appeared in the {\itshape ACM IEEE 21st 90Design Automation Conference}, and the paper ``Magic's Circuit Extractor'', 91which appeared in the {\itshape ACM IEEE 22nd Design 92Automation Conference}. The overview paper from the 93DAC was also reprinted in {\itshape IEEE Design and Test} magazine in 94the February 1985 issue. 95The circuit extractor paper also appeared in the 96February 1986 issue of {\itshape IEEE Design and Test} magazine. 97 98{\noindent\bfseries\large Commands introduced in this manual:} 99\starti 100 \> path 101 \> tech 102 \> *watch 103\endi 104 105{\noindent\bfseries\large Macros introduced in this manual:} 106 107\starti 108 \> {\itshape (None)} 109\endi 110 111{\noindent\bfseries\large Changes since Magic version 7.2:} 112\begin{itemize} 113\item Support for stacked contacts. 114\item ``variants'' option for the cifinput, cifoutput, and extract 115 sections, allowing an efficient description of different 116 styles having minor variations. 117\item Supports names for layer drawing styles in addition to the usual 118 numbers. 119\item Section name {\bfseries images} duplicates the {\bfseries contacts} 120 section, allowing a less-restrictive definition of images that 121 exist, like contacts, on multiple planes. 122\item Support for multi-line technology descriptions. 123\item ``include'' statement to divide technology files into parts. 124\item ``alias'' statements to replace the original cpp-style macros 125\item Support for {\itshape angstroms} in the scalefactor line of 126 cifinput and cifoutput. 127\item Additional DRC types ``surround'', ``overhang'', and ``rect\_only''. 128\item Additional cifoutput operators ``slots'' and ``bloat-all''. 129\item Additional cifoutput statement ``render'' for 3-D information 130\item Asterisk syntax for layers that expands to the layer and all of 131 the contacts containing that layer as a residue. 132\item The technology file syntax for the PNM format was changed in 133 magic 7.3.56, and the {\bfseries plot pnm} command will 134 use a default style derived from the layout styles if no 135 section is present in the technology file. 136\end{itemize} 137 138{\noindent\bfseries\large Changes since Magic version 6.5:} 139\begin{itemize} 140\item Moved technology format from the filename to the ``tech'' section 141\item Added subdirectory searching to the path search for technology files. 142\item Support for technology file re-loading after Magic starts up, and 143 support for re-loading of individual sections of the technology 144 file. 145\item Scalefactors can now be any number whatsoever, for both CIF and GDS. 146 For example, a scalefactor of 6.5 corresponds to a 0.13 micron 147 process. 148\item A parameter {\itshape nanometers} has been added to the scalefactor 149 specification for both cifinput and cifoutput sections. This 150 parameter declares that all numbers in the style description are 151 in nanometers instead of centimicrons. 152\item The {\itshape calmaonly} parameter to the scalefactor specification is 153 deprecated (ignored if found). 154\item The scale reducer parameter is deprecated (generated automatically, 155 and ignored if found in the techfile). 156\item The magic grid spacing is no longer assumed to be equal to the process 157 lambda. It may be rescaled with the ``scalegrid'' command, and CIF 158 and Calma reads may alter the value of magic units per lambda. 159\item Support for PNM and PostScript graphics in the ``plot'' section. 160\item Full support for bipolar junction transistors, capacitors, and 161 resistors with the ``extract'' section keyword ``device'' 162\item Support for three-dimensional modeling and geometry extraction 163\item Support for the DRC widespacing rule 164\item Handling of contacts in the extraction section is capable of 165 matching the CIF output section by specifying border, size, 166 and spacing. 167\end{itemize} 168 169\vspace*{0.25in} 170\section{Introduction} 171 172Magic is a technology-independent layout editor. 173All technology-specific information comes from a 174{\itshape technology file}. This file includes such information 175as layer types used, electrical connectivity between types, 176design rules, rules for mask generation, and rules for 177extracting netlists for circuit simulation. 178 179This manual describes the use, contents, and syntax of Magic's 180technology file format, and gives hints for building a new one or 181(more typically) rewriting an existing one for a new fabrication 182process. References to specific files in the Magic distribution 183assume that your current working directory is the Magic source 184top-level directory. 185 186\section{Downloads and Installation} 187 188Typically, there is a different technology file for each fabrication 189process supported by Magic. Scalable technologies, which are 190(within limits) independent of feature size, will typically have 191one technology file for all processes supporting the same set of 192lambda-based (scalable) DRC rules. 193That said, modern technologies (post-1980's, more or less) tend to 194be more restrictive in their design rules, and consequently not 195scalable. This is particularly true of processes which push the 196envelope on feature sizes. 197 198The Magic source distribution 199is packaged with a ``standard'' set of scalable SCMOS rules, which 200is the technology loaded by default. Default settings are for 2011\,{\micro}m technology, which is out of date. However, the 202variety and availability of processes means that the ``definitive'' 203set of technology files is prohibitively large to be included 204with the Magic source. In addition, process refinements generally 205require technology file updates on a regular basis. Because of 206this, the basic collection of technology files is handled by the 207MOSIS foundation, not by the Magic development team. This 208collection represents all processes which are available for 209fabriction through the MOSIS foundation. Most other vendors have 210proprietary process specifications, requiring tool maintainers to 211write their own technology files or modify an existing one to 212match the proprietary process. 213 214The standard technology file set can be downloaded from an FTP 215server at the MOSIS foundation. These files are regularly 216updated, but there is usually a symbolic link called ``current'' 217to the most recent stable revision. The download URL is the 218following: 219 220\starti 221 \> {\ttfamily\bfseries ftp://ftp.mosis.edu/pub/sondeen/magic/new/beta/current.tar.gz} 222\endi 223 224Assuming that the install destination for magic is 225{\bfseries /usr/local}, this file should be put either in {\bfseries 226/usr/local/lib/magic/sys} or (preferably) in {\bfseries 227/usr/local/lib/magic/sys/current}. Other destinations may 228be used, if the system search path is appropriately specified 229on startup (see Section~\ref{commandline}, below). 230 231The technology file collection is in tarred, gzipped format, 232and should be installed with the following commands: 233 234\starti 235 \ii {\ttfamily\bfseries cd /usr/local/lib/magic/sys/current} \\ 236 \ii {\ttfamily\bfseries gunzip current.tar.gz} \\ 237 \ii {\ttfamily\bfseries tar xf current.tar} 238\endi 239 240Once unpacked, these files are ready to be used in Magic. 241 242\section{Command-Line Invocation} \label{commandline} 243 244You can run Magic with a different technology by 245specifying the {\bfseries -T}{\itshape techfile} flag on the command 246line you use to start Magic, where 247{\itshape techfile} is the name of a file of the form 248{\itshape techname}{\bfseries .tech}, searched for in one 249of the following directories (listed by search order): 250\begin{enumerate} 251 \item The current directory 252 \item The library directory /usr/local/lib/magic/sys 253 \item The library directory /usr/local/lib/magic/current 254\end{enumerate} 255This search order is not fixed and can be altered by the command 256{\bfseries path sys}, which may be redefined in the system or 257user {\bfseries .magic} startup script file. In addition, the 258startup script may load a new techfile, regardless of what was 259specified on the command line, or may load a new techfile provided 260that one has not been specified on the command line (the 261{\bfseries -nooverride} option. The {\bfseries -noprompt} switch 262causes the technology to be loaded without first prompting the 263user for confirmation. 264 265\starti 266 \ii {\bfseries tech load} {\itshape filename} {\bfseries -noprompt} 267 [{\bfseries -nooverride}] 268\endi 269 270\section{Technology File Format Overview} 271 272A technology file is organized into sections, each of which 273begins with a line containing a single keyword 274and ends with a line containing the single word {\bfseries end}. 275If you examine one of the Magic technology files in the 276installation directory 277{\bfseries \$}\{{\bfseries CAD\_HOME}\}{\bfseries /lib/magic/sys/}, 278{\itshape e.g.}, {\bfseries scmos.tech}, 279you can see that it contains the following sections: 280 281\starti 282 \ii {\bfseries tech} \\ 283 \ii {\bfseries planes} \\ 284 \ii {\bfseries types} \\ 285 \ii {\bfseries styles} \\ 286 \ii {\bfseries contact} \\ 287 \ii {\bfseries compose} \\ 288 \ii {\bfseries connect} \\ 289 \ii {\bfseries cifoutput} \\ 290 \ii {\bfseries cifinput} \\ 291 \ii {\bfseries mzrouter} \\ 292 \ii {\bfseries drc} \\ 293 \ii {\bfseries extract} \\ 294 \ii {\bfseries wiring} \\ 295 \ii {\bfseries router} \\ 296 \ii {\bfseries plowing} \\ 297 \ii {\bfseries plot} 298\endi 299 300These sections must appear in this order in all technology files. 301Every technology file must have all of the sections, although the sections 302need not have any lines between the section header and the {\bfseries end} line. 303 304Historically, technology files were written in a C-language context which 305was processed by the C preprocessor. This allows the use of C-language 306comments (``{\bfseries /*} \dots {\bfseries */}'') and the use of 307preprocessing definitions (``{\bfseries \#define} \dots'') and 308conditionals (``{\bfseries \#ifdef} \dots {\bfseries \#endif}''). 309The technology files were generated from a Makefile with the preprocessor 310constructs used to generate different sections of the technology file 311at different lambda scales. The decreasing use of scalable processes, 312however, has made this method largely obsolete, and the standard 313collection of technology files from MOSIS does not use them at all. 314Technology files are now written in their final form, not in preprocessed 315form. Information regarding preprocessor constructs is not included below, 316but can of course be obtained from the manual pages for the preprocessor 317itself ({\bfseries gcc} or {\bfseries cpp}). But also note that the use 318of C preprocessors for processing text files other than source code is 319now generally discouraged in favor of using a macro definition processor 320like {\bfseries m4} (see the manual page for {\bfseries m4} for details). 321On the other hand, macro definition processors are almost universally 322despised, so many preprocessor functions have been written into the 323technology file syntax. 324 325The default {\bfseries scmos} set of technology files included with the 326Magic distribution is still processed via the C preprocessor. Preprocessed 327files have the extension ``{\bfseries .tech.in}''. 328Technology files written specifically for Magic version 7.3 tend to 329make use of additional features of the technology file syntax that 330subsume most of the functions of the C preprocessor and M4 processor 331normally used to generate technology files. 332 333Each section in a technology file consists of a series of lines. 334Each line consists of a series of words, separated by spaces or tabs. 335If a line ends with the character ``{\bk}'', the ``{\bk}'' is ignored 336and the following newline is treated as an ordinary blank. 337For example, 338 339\starti 340 \ii {\bfseries width allDiff 2 {\bk}} \\ 341 \ii\> {\itshape {\q}Diffusion width must be at least 2{\q}} 342\endi 343 344is treated as though it had all appeared on a single line 345with no intervening ``{\bk}''. On the other hand, for the purposes 346of tracking errors in technology file input, the technology file 347parser treats these as separate lines, so that when magic reports 348an error on a specific line of the technology file, it will agree 349with the line numbering of the editor used to edit the file. 350 351Comments may be embedded in the technology file. Magic's technology 352file parser will ignore all text beginning with the character 353{\bfseries \#} through the end of the line. 354 355The rest of this part of the manual will describe 356each of the technology file sections in turn. 357 358\section{Tech section} 359 360Magic stores the technology of a cell in the cell's file on disk. 361When reading a cell back in to Magic from disk, the cell's 362technology must match the name of the current technology, 363which appears as a single word in the {\bfseries tech} section 364of the technology file. See Table~1 for an example. 365 366\begin{table}[ht] 367 \begin{center} 368 \begin{tabular}{|l|} \hline 369 {\bfseries tech} \\ 370 format 30 \\ 371 scmos \\ 372 {\bfseries end} \\ \hline 373 \end{tabular} 374 \caption {{\bfseries Tech} section} 375 \end{center} 376 \label{tech} 377\end{table} 378 379The name of the technology declared in the {\bfseries tech} 380section is meaningful to Magic, whereas the name of the file 381itself is not. Typically the name of the file will be the 382same as the name of the technology, to avoid confusion, but 383this need not be the case. 384 385Versions of magic prior to 7.2 embedded the format version 386of the technology in the file name, {\itshape e.g.}, 387{\bfseries scmos.tech27}. The last format version to use 388this syntax, 27, is still accepted as a valid filename 389extension. Many technology files still use this notation, 390including (at the time of writing) the collection from MOSIS. 391Now the format is declared inside the {\bfseries tech} 392section. 393 394\section{A short tutorial on ``corner stitching''} 395 396The {\bfseries planes}, {\bfseries types}, and {\bfseries contact} sections 397are used to define the layers used in the technology. 398Magic uses a data structure called {\itshape corner-stitching} to represent 399layouts. Corner-stitching represents mask information 400as a collection of non-overlapping rectangular {\itshape tiles}. 401Each tile has a type that corresponds to a single Magic layer. 402An individual corner-stitched data structure is referred to as a {\itshape plane}. 403 404Magic allows you to see the corner-stitched planes it uses to store a layout. 405We'll use this facility to see how several corner-stitched planes 406are used to store the layers of a layout. 407Enter Magic to edit the cell {\bfseries maint2a}. 408Type the command {\bfseries *watch active demo}. 409You are now looking at the {\bfseries active} plane. 410Each of the boxes outlined in black is a tile. 411(The arrows are {\itshape stitches}, but are unimportant to this discussion.) 412You can see that some tiles contain layers 413(polysilicon, ndiffusion, ndcontact, polycontact, and ntransistor), 414while others contain empty space. 415Corner-stitching is unusual in that it represents empty space explicitly. 416Each tile contains exactly one type of material, or space. 417 418You have probably noticed that metal1 does not seem to have 419a tile associated with it, but instead appears right in the middle 420of a space tile. 421This is because metal1 is stored on a different plane, the {\bfseries metal1} plane. 422Type the command {\bfseries :*watch metal1 demo}. 423Now you can see that there are metal1 tiles, 424but the polysilicon, diffusion, and transistor tiles have disappeared. 425The two contacts, polycontact and ndcontact, still appear to be tiles. 426 427The reason Magic uses several planes to store mask information 428is that corner-stitching can only represent non-overlapping rectangles. 429If a layout were to consist of only a single layer, such 430as polysilicon, then only two types of tiles would be necessary: 431polysilicon and space. 432As more layers are added, overlaps can be 433represented by creating a special tile type for 434each kind of overlap area. 435For example, when polysilicon overlaps 436ndiffusion, the overlap area is marked with the tile type 437ntransistor. 438 439Although some overlaps correspond to actual electrical constructs 440(e.g., transistors), other overlaps have little electrical significance. 441For example, metal1 can overlap polysilicon without changing the 442connectivity of the circuit or creating any new devices. 443The only consequence of the overlap is possibly a change in 444parasitic capacitance. 445To create new tile types for all possible overlapping combinations of metal1 446with polysilicon, diffusion, transistors, etc. 447would be wasteful, since these new overlapping combinations 448would have no electrical significance. 449 450Instead, Magic partitions the layers into separate planes. 451Layers whose overlaps have electrical significance must be 452stored in a single plane. 453For example, polysilicon, diffusion, and their overlaps (transistors) 454are all stored in the {\bfseries active} plane. 455Metal1 does not interact with any of these tile types, so it is stored 456in its own plane, the {\bfseries metal1} plane. 457Similarly, in the scmos technology, metal2 doesn't interact with either 458metal1 or the active layers, so is stored in yet another plane, {\bfseries metal2}. 459 460Contacts between layers in one plane and layers in another are a special 461case and are represented on {\itshape both} planes. 462This explains why the pcontact and ndcontact 463tiles appeared on both the 464{\bfseries active} plane and on the {\bfseries metal1} plane. 465Later in this section, when the {\bfseries contacts} section of the 466technology file is introduced, we'll see how to define contacts 467and the layers they connect. 468 469\section{Planes, types, and contact sections} 470 471The {\bfseries planes} 472section of the technology file specifies how many planes will be 473used to store tiles in a given technology, and gives each plane 474a name. 475Each line in this section 476defines a plane by giving a comma-separated 477list of the names by which it is known. 478Any name may be used in referring to the plane in later 479sections, or in commands like the 480{\bfseries *watch} command indicated in the tutorial above. 481Table~\ref{planes} gives the {\bfseries planes} section from the 482scmos technology file. 483 484\begin{table}[ht] 485 \begin{center} 486 \begin{tabular}{|l|} \hline 487 {\bfseries planes} \\ 488 well,w \\ 489 active,diffusion,polysilicon,a \\ 490 metal1,m1 \\ 491 metal2,m2 \\ 492 oxide,ox \\ 493 {\bfseries end} \\ \hline 494 \end{tabular} 495 \caption{{\bfseries Planes} section} 496 \label{planes} 497 \end{center} 498\end{table} 499 500Magic uses a number other planes internally. 501The {\bfseries subcell} 502plane is used for storing cell instances rather than storing 503mask layers. 504The {\bfseries designRuleCheck} and {\bfseries designRuleError} 505planes are used by the design rule checker to store 506areas to be re-verified, and areas containing design rule 507violations, respectively. 508Finally, the {\bfseries mhint}, {\bfseries fhint}, and {\bfseries rhint} planes are 509used for by the interactive 510router (the {\bfseries iroute} command) for designer-specified graphic hints. 511 512There is a limit on the maximum number of planes in a technology, 513including the internal planes. This limit is currently 64. 514To increase the limit, it is necessary to change {\bfseries MAXPLANES} 515in the file 516{\bfseries database/database.h.in} and then recompile all 517of Magic as described in ``Maintainer's Manual\ \#1''. Each additional 518plane involves additional storage space in every cell and some additional 519processing time for searches, so we recommend that you keep the number 520of planes as small as you can do cleanly. 521 522The {\bfseries types} section identifies the technology-specific 523tile types used by Magic. 524Table~\ref{types} gives this section for the scmos technology file. 525Each line in this section is of the following form: 526 527\starti 528 \ii {\itshape plane names} 529\endi 530 531Each type defined in this section is allowed to appear on exactly 532one of the planes defined in the {\bfseries planes} section, namely 533that given by the {\itshape plane} field above. 534For contacts types such as {\bfseries pcontact}, the plane 535listed is considered to be the contact's {\itshape home} plane; 536in Magic 7.3 this is a largely irrelevant distinction. However, 537it is preferable to maintain a standard of listing the lowest plane 538connected to a contact as it's ``home plane'' (as they appear in 539the table). 540 541\begin{table}[ht] 542 \begin{center} 543 \begin{tabular}{|ll|} \hline 544 {\bfseries types} & \\ 545 active & polysilicon,red,poly,p \\ 546 active & ndiffusion,green,ndiff \\ 547 active & pdiffusion,brown,pdiff \\ 548 metal1 & metal1,m1,blue \\ 549 metal2 & metal2,m2,purple \\ 550 well & pwell,pw \\ 551 well & nwell,nw \\ 552 active & polycontact,pcontact,pc \\ 553 active & ndcontact,ndc \\ 554 active & pdcontact,pdc \\ 555 metal1 & m2contact,m2c,via,v \\ 556 active & ntransistor,nfet \\ 557 active & ptransistor,pfet \\ 558 active & psubstratepcontact,ppcontact,ppcont,psc,ppc,pwc,pwcontact \\ 559 active & nsubstratencontact,nncontact,nncont,nsc,nnc,nwc,nwcontact \\ 560 active & psubstratepdiff,psd,ppdiff,ppd,pohmic \\ 561 active & nsubstratendiff,nsd,nndiff,nnd,nohmic \\ 562 metal2 & pad \\ 563 oxide & glass \\ 564 {\bfseries end} & \\ \hline 565 \end{tabular} 566 \caption{{\bfseries Types} section} 567 \label{types} 568 \end{center} 569\end{table} 570 571The {\itshape names} field is a comma-separated list of names. 572The first name in the list is the ``long'' name for the type; 573it appears in the {\bfseries .mag} file and whenever error messages involving 574that type are printed. 575Any unique abbreviation of any of a type's names is sufficient 576to refer to that type, both from within the technology file 577and in any commands such as 578{\bfseries paint} or {\bfseries erase}. 579 580Magic has certain built-in types as shown in Table~\ref{builtins}. 581Empty space ({\bfseries space}) 582is special in that it can appear on any plane. 583The types {\bfseries error{\_}p}, {\bfseries error{\_}s}, and {\bfseries error{\_}ps} 584record design rule violations. 585The types {\bfseries checkpaint} and {\bfseries checksubcell} 586record areas still to be design-rule checked. 587Types {\bfseries magnet}, {\bfseries fence}, and {\bfseries rotate} are the types 588used by designers to indicate hints for the irouter. 589 590\begin{table}[ht] 591 \begin{center} 592 \begin{tabular}{|l|l|} \hline 593 Tile type & Plane \\ \hline\hline 594 space & {\itshape all} \\ 595 error{\_}p, EP & designRuleError \\ 596 error{\_}s, ES & designRuleError \\ 597 error{\_}ps, EPS & designRuleError \\ 598 checkpaint, CP & designRuleCheck \\ 599 checksubcell, CS & designRuleCheck \\ 600 magnet, mag & mhint \\ 601 fence, f & fhint \\ 602 rotate, r & rhint \\ \hline 603 \end{tabular} 604 \caption{Built-in Magic types} 605 \label{builtins} 606 \end{center} 607\end{table} 608 609There is a limit on the maximum number of types in a technology, including 610all the built-in types. Currently, the limit is 256 tile types. 611To increase the limit, you'll have to 612change the value of {\bfseries TT{\_}MAXTYPES} in the file 613{\bfseries database/database.h.in} and then recompile all 614of Magic as described in ``Maintainer's Manual\ \#1''. 615Because there are a number of tables whose size is determined by 616the square of {\bfseries TT{\_}MAXTYPES}, it is very expensive to increase 617{\bfseries TT{\_}MAXTYPES}. Magic version 7.2 greatly reduced the 618number of these tables, so the problem is not as bad as it once was. 619Most internal tables depend on a {\itshape bitmask} of types, the 620consequence of which is that the internal memory usage greatly 621increases whenever {\bfseries TT{\_}MAXTYPES} exceeds a 622factor of 32 (the size of an integer, on 32-bit systems). 623Magic version 7.3 further alleviates the problem by reducing the 624number of ``derived'' tile types that magic generates internally, 625so that the total number of types is not much larger than the number 626declared in the {\bfseries types} section. Magic-7.4 only generates 627extra types for pairs of stackable contact types. For a typical 628process, the number of these derived stacked contact pairs is 629around 15 to 20. 630 631The declaration of tile types may be followed by a block of alias 632declarations. This is similar to the ``macro'' definitions used 633by preprocessors, except that the definitions are not only significant 634to the technology file parser, but extend to the user as well. Thus 635the statement ``{\bfseries alias metalstack m1,m2,m3}'' may be a convenient 636shorthand where metal layers 1, 2, and 3 appear simultaneously, but 637the end-user can type the command ``{\bfseries paint metalstack}'' and 638get the expected result of all three metal layers painted. The 639{\bfseries alias} statement has the additional function of allowing 640backward-compatibility for technology files making use of stackable 641contacts (see below) with older layouts, and cross-compatibility 642between similar technologies that may have slight differences in layer 643names. 644 645The {\bfseries contact} section lets Magic know which types are contacts, 646and the planes and component types to which they are connected. 647 648Each line in the {\bfseries contact} 649section begins with a tile type, {\itshape base}, which is thereby 650defined to be a contact. 651This type is also referred to as a contact's {\itshape base type}. 652The remainder of each line is a list of non-contact tile types 653that are connected by the contact. 654These tile types are referred to as the {\itshape residues} 655of the contact, and are the layers that would be present if there 656were no electrical connection ({\itshape i.e.}, no via hole). 657In Table~\ref{contacts}, for example, the type 658{\bfseries pcontact} is the base type of a contact connecting 659the residue layers {\bfseries polysilicon} on the active plane 660with {\bfseries metal1} on the metal1 plane. 661 662\begin{table}[ht] 663 \begin{center} 664 \begin{tabular}{|llll|} \hline 665 {\bfseries contact} &&& \\ 666 pcontact & poly & metal1 & \\ 667 ndcontact & ndiff & metal1 & \\ 668 pdcontact & pdiff & metal1 & \\ 669 ppcontact & ppdiff & metal1 & \\ 670 nncontact & nndiff & metal1 & \\ 671 m2contact & metal2 & metal1 & \\ 672 pad & metal1 & metal2 & glass \\ 673 {\bfseries end} &&& \\ \hline 674 \end{tabular} 675 \caption{{\bfseries Contact} section} 676 \label{contacts} 677 \end{center} 678\end{table} 679 680In Magic-7.3 and above, any number of types can be connected, and those 681types may exist on any planes. It is the duty of the technology file 682developer to ensure that these connections make sense, especially 683if the planes are not contiguous. However, because Magic-7.3 handles 684stacked contacts explicitly, it is generally better to define contacts 685only between two adjacent planes, and use the {\bfseries stackable} 686keyword (see below) to allow types to be stacked upon one another. 687The multiple-plane representation exists for backward compatibility 688with technology files written for versions of Magic prior to 7.3. 689Stackable contacts in older technology files take the form: 690 691\starti 692 \ii {\bfseries contact pc polysilicon metal1} \\ 693 \ii {\bfseries contact m2c metal1 metal2} \\ 694 \ii {\bfseries contact pm12c polysilicon metal1 metal2} 695\endi 696 697In Magic version 7.3, the above line would be represented as: 698 699\starti 700 \ii {\bfseries contact pc polysilicon metal1} \\ 701 \ii {\bfseries contact m2c metal1 metal2} \\ 702 \ii {\bfseries stackable pc m2c pm12c} 703\endi 704 705where the third line declares that contact types m2c and pc may be 706stacked together, and that type name ``pm12c'' is a valid alias for 707the combination of ``pc'' and ``m2c''. 708 709Each contact has an {\itshape image} on all the planes it connects. 710Figure~\ref{contacttiles} depicts the situation graphically. In later 711sections of the technology file, it is sometimes useful to refer 712separately to the various images of contact. A special 713notation using a slash character (``/'') is used for this. If a tile type 714{\itshape aaa/bbb} is specified in the technology file, this refers 715to the image of contact {\itshape aaa} on plane {\itshape bbb}. For example, 716{\bfseries pcontact/metal1} refers to the image of the pcontact that 717lies on the metal1 plane, and {\bfseries pcontact/active} refers to the 718image on the active plane, which is the same as {\bfseries pcontact}. 719 720\begin{figure}[ht] 721 \begin{center} 722 \epsfig{file=../psfigures/maint2.1.ps, width=0.7\columnwidth} 723 \caption{A different tile type is used to represent a contact 724 on each plane that it connects. Here, a contact between poly 725 on the {\bfseries active} plane and metal1 on the {\bfseries metal1} 726 plane is stored as two tile types. One, {\bfseries pcontact}, 727 is specified in the technology file as residing on the {\bfseries 728 active} plane; the other is automatically-generated for the 729 {\bfseries metal1} plane.} 730 \label{contacttiles} 731 \end{center} 732\end{figure} 733 734\section{Specifying Type-lists} \label{typelists} 735 736In several places in the technology file you'll need to specify 737groups of tile types. For example, in the {\bfseries connect} section 738you'll specify groups of tiles that are mutually connected. These 739are called {\itshape type-lists} and there are several ways to specify 740them. The simplest form for a type-list is a comma-separated list 741of tile types, for example 742 743\starti 744 \ii poly,ndiff,pcontact,ndc 745\endi 746 747The null list (no tiles at all) is indicated by zero, i.e., 748 749\starti 750 \ii 0 751\endi 752 753There must not be any spaces in the type-list. Type-lists may also 754use tildes (``\~{}'') to select all tiles but a specified set, and 755parentheses for grouping. For example, 756 757\starti 758 \ii \~{}(pcontact,ndc) 759\endi 760 761selects all tile types but pcontact and ndc. When a contact name appears 762in a type-list, it selects {\itshape all} images of the contact unless 763a ``/'' is used to indicate a particular one. The example 764above will not select any of the images of pcontact or ndc. 765Slashes can also be used in conjunction with parentheses and tildes. 766For example, 767 768\starti 769 \ii \~{}(pcontact,ndc)/active,metal1 770\endi 771 772selects all of the tile types on the active plane except for 773pcontact and ndc, and also selects metal1. Tildes have higher operator 774precedence than slashes, and commas have lowest precedence of 775all. 776 777A special notation using the asterisk (``*'') is a convenient way 778to abbreviate the common situation where a rule requires the inclusion 779of a tile type and also all contacts that define that tile type as one 780of their residue layers, a common occurrence. The notation 781 782\starti 783 \ii *metal1 784\endi 785 786expands to metal1 plus all of the contact types associated with 787metal1, such as ndc, pdc, nsc, m2c, and so forth. 788 789Note: in the CIF sections of the technology file, only simple 790comma-separated names are permitted; tildes and parentheses are 791not understood. However, everywhere else in the technology file 792the full generality can be used. The ``*'' notation for inclusion 793of contact residues may be present in any section. 794 795\section{Styles section} 796 797Magic can be run on several different types of graphical displays. 798Although it would have been possible to incorporate display-specific 799information into the technology file, 800a different technology file would have been required for each display type. 801Instead, the technology file gives one or more display-independent 802{\itshape styles} for each type that is to be displayed, 803and uses a per-display-type styles file to map to 804colors and stipplings specific to the display being used. The 805styles file is described in 806Magic Maintainer's Manual\ \#3: ``Styles and Colors'', 807so we will not describe it further here. 808 809Table~\ref{styles} shows part of the {\bfseries styles} 810section from the scmos technology file. 811The first line specifies the type of style file 812for use with this technology, which in this 813example is {\bfseries mos}. 814Each subsequent line consists of a tile type and a style number 815(an integer between 1 and 63). 816The style number is nothing more than a reference between the technology 817file and the styles file. 818Notice that a given tile type can have several styles 819(e.g., pcontact uses styles \#1, \#20, and \#32), 820and that a given style may be 821used to display several different tiles 822(e.g., style \#2 is used in ndiff and ndcontact). 823If a tile type should not be displayed, 824it has no entry in the {\bfseries styles} section. 825 826It is no longer necessary to have one style per line, a restriction 827of format 27 and earlier. Multiple styles for a tile type can be 828placed on the same line, separated by spaces. Styles may be 829specified by number, or by the ``long name'' in the style file. 830 831 832\begin{table}[ht] 833 \begin{center} 834 \begin{tabular}{|ll|} \hline 835 {\bfseries styles} & \\ 836 styles & \\ 837 styletype mos & \\ 838 poly & 1 \\ 839 ndiff & 2 \\ 840 pdiff & 4 \\ 841 nfet & 6 \\ 842 nfet & 7 \\ 843 pfet & 8 \\ 844 pfet & 9 \\ 845 metal1 & 20 \\ 846 metal2 & 21 \\ 847 pcontact & 1 \\ 848 pcontact & 20 \\ 849 pcontact & 32 \\ 850 ndcontact & 2 \\ 851 ndcontact & 20 \\ 852 ndcontact & 32 \\ 853 pdcontact & 4 \\ 854 pdcontact & 20 \\ 855 pdcontact & 32 \\ 856 m2contact & 20 \\ 857 m2contact & 21 \\ 858 m2contact & 33 \\ 859 {\bfseries end} & \\ \hline 860 \end{tabular} 861 \caption{Part of the {\bfseries styles} section} 862 \label{styles} 863 \end{center} 864\end{table} 865 866\section{Compose section} 867 868The semantics of Magic's paint operation are defined by a collection 869of rules of the form, ``given material {\itshape HAVE} on plane {\itshape PLANE}, 870if we paint {\itshape PAINT}, then 871we get {\itshape Z}'', plus a similar set of rules for the erase operation. 872The default paint and erase rules are simple. Assume that we 873are given material {\itshape HAVE} on plane {\itshape PLANE}, and are painting 874or erasing material {\itshape PAINT}. 875 876\begin{enumerate} 877 \item {\itshape You get what you paint.} \\ 878 If the home plane of {\itshape PAINT} is {\itshape PLANE}, or 879 {\itshape PAINT} is space, you get {\itshape PAINT}; otherwise, nothing 880 changes and you get {\itshape HAVE}. 881 \item {\itshape You can erase all or nothing.} \\ 882 Erasing space or {\itshape PAINT} from {\itshape PAINT} will give space; 883 erasing anything else has no effect. 884\end{enumerate} 885 886These rules apply for contacts as well. 887Painting the base type of a contact paints the base type 888on its home plane, and each image type on its home plane. 889Erasing the base type of a contact erases both the base type 890and the image types. 891 892It is sometimes desirable for certain tile types to behave as 893though they were ``composed'' of other, more fundamental ones. 894For example, painting poly over ndiffusion in scmos 895produces ntransistor, instead of ndiffusion. 896Also, painting either poly or ndiffusion 897over ntransistor leaves ntransistor, 898erasing poly from ntransistor leaves ndiffusion, 899and erasing ndiffusion leaves poly. 900The semantics for ntransistor 901are a result of the following rule in the 902{\bfseries compose} section of the scmos technology file: 903 904\starti 905 \ii {\bfseries compose} ntransistor poly ndiff 906\endi 907 908Sometimes, not all of the ``component'' layers of a type are layers 909known to magic. 910As an example, in the {\bfseries nmos} technology, there are two types 911of transistors: {\bfseries enhancement-fet} and {\bfseries depletion-fet}. 912Although both contain polysilicon and diffusion, 913depletion-fet can be thought of as also containing 914implant, which is not a tile type. 915So while we can't construct depletion-fet by painting poly and then 916diffusion, we'd still like it to behave as though it contained 917both materials. 918Painting poly or diffusion over a depletion-fet should not change it, and 919erasing either poly or diffusion should give the other. 920These semantics are the result of the following rule: 921 922\starti 923 \ii {\bfseries decompose} dfet poly diff 924\endi 925 926The general syntax of both types of composition rules, 927{\bfseries compose} and {\bfseries decompose}, 928is: 929 930\starti 931 \ii {\bfseries compose} {\itshape\ \ \ type \ a1 b1 \ a2 b2 \ \dots} \\ 932 \ii {\bfseries decompose} {\itshape type \ a1 b1 \ a2 b2 \ \dots} 933\endi 934 935The idea is that each of the pairs {\itshape a1 b1}, {\itshape a2 b2}, etc 936comprise {\itshape type}. 937In the case of a {\bfseries compose} rule, 938painting any {\itshape a} atop its corresponding {\itshape b} 939will give {\itshape type}, as well as vice-versa. 940In both {\bfseries compose} and {\bfseries decompose} rules, erasing {\itshape a} from 941{\itshape type} gives {\itshape b}, erasing {\itshape b} from {\itshape type} gives 942{\itshape a}, and painting either {\itshape a} or {\itshape b} over {\itshape type} 943leaves {\itshape type} unchanged. 944 945\begin{table}[ht] 946 \begin{center} 947 \begin{tabular}{|llll|} \hline 948 {\bfseries compose} \\ 949 compose & nfet & poly & ndiff \\ 950 compose & pfet & poly & pdiff \\ 951 paint & pwell & nwell & nwell \\ 952 paint & nwell & pwell & pwell \\ 953 paint & pdc/active & pwell & ndc/active \\ 954 paint & pdc/m1 & pwell & ndc/m1 \\ 955 paint & pfet & pwell & nfet \\ 956 paint & pdiff & pwell & ndiff \\ 957 paint & nsd & pwell & psd \\ 958 paint & nsc/active & pwell & psc/active \\ 959 paint & nsc/m1 & pwell & psc/m1 \\ 960 paint & ndc/active & nwell & pdc/active \\ 961 paint & ndc/m1 & nwell & pdc/m1 \\ 962 paint & nfet & nwell & pfet \\ 963 paint & ndiff & nwell & pdiff \\ 964 paint & psd & nwell & nsd \\ 965 paint & psc/active & nwell & nsc/active \\ 966 paint & psc/m1 & nwell & nsc/m1 \\ 967 {\bfseries end} &&& \\ \hline 968 \end{tabular} 969 \caption{{\bfseries Compose} section} 970 \label{compose} 971 \end{center} 972\end{table} 973 974Contacts are implicitly composed of their component types, 975so the result obtained when painting a type {\itshape PAINT} over a contact 976type {\itshape CONTACT} will by default depend only on 977the component types of {\itshape CONTACT}. 978If painting {\itshape PAINT} doesn't affect the component 979types of the contact, then it is considered not to affect the 980contact itself either. If painting {\itshape PAINT} does affect any of 981the component types, then the result is as though the contact 982had been replaced by its component types in the layout before type 983{\itshape PAINT} was painted. Similar rules hold for erasing. 984 985A pcontact has component types poly and metal1. 986Since painting poly doesn't affect either poly or metal1, it 987doesn't affect a pcontact either. 988Painting ndiffusion does affect 989poly: it turns it into an ntransistor. 990Hence, painting ndiffusion over a pcontact breaks up 991the contact, leaving ntransistor on the 992active plane and metal1 on the metal1 plane. 993 994The {\bfseries compose} and {\bfseries decompose} rules 995are normally sufficient to specify the desired semantics 996of painting or erasing. 997In unusual cases, however, it may be necessary to provide 998Magic with explicit {\bfseries paint} or {\bfseries erase} rules. 999For example, 1000to specify that painting pwell over pdiffusion switches its 1001type to ndiffusion, the technology file contains the 1002rule: 1003 1004\starti 1005 \ii {\bfseries paint} pdiffusion pwell ndiffusion 1006\endi 1007 1008This rule could not have been written as a {\bfseries decompose} rule; 1009erasing ndiffusion from pwell does not yield pdiffusion, 1010nor does erasing pdiffusion from ndiffusion yield pwell. 1011The general syntax for these explicit rules is: 1012 1013\starti 1014 \ii {\bfseries paint} {\itshape have t result }[{\itshape p}] \\ 1015 \ii {\bfseries erase} {\itshape have t result }[{\itshape p}] 1016\endi 1017 1018Here, {\itshape have} is the type already present, on plane {\itshape p} 1019if it is specified; otherwise, on the home plane of {\itshape have}. 1020Type {\itshape t} is being painted or erased, and the result is type {\itshape result}. 1021Table~\ref{compose} gives the {\bfseries compose} section for scmos. 1022 1023It's easiest to think of the paint and erase rules as being built 1024up in four passes. 1025The first pass generates the default rules for all non-contact types, 1026and the second pass replaces these as specified by the {\bfseries compose}, 1027{\bfseries decompose}, etc. rules, also for non-contact types. 1028At this point, the behavior of the component types of contacts has 1029been completely determined, so the third pass can generate the 1030default rules for all contact types, and the fourth pass 1031can modify these as per any {\bfseries compose}, etc. rules for contacts. 1032 1033\section{Connect section} 1034 1035For circuit extraction, routing, and some of the net-list operations, 1036Magic needs to know what types are electrically connected. 1037Magic's model of electrical connectivity used is based on signal propagation. 1038Two types should be marked as connected if a signal will 1039{\itshape always} 1040pass between the two types, in either direction. 1041For the most part, this will mean that all non-space types within a plane 1042should be marked as connected. 1043The exceptions to this rule are devices (transistors). 1044A transistor should be considered electrically 1045connected to adjacent polysilicon, but not to adjacent diffusion. 1046This models the fact that polysilicon connects to the gate of 1047the transistor, but that the transistor acts as a switch 1048between the diffusion areas on either side of the channel of the transistor. 1049 1050The lines in the {\bfseries connect} 1051section of a technology file, as shown in Table~\ref{connect}, 1052each contain a pair of type-lists in the format described in 1053Section~\ref{typelists}. 1054Each type in the first list connects to each type in the second list. 1055This does not imply that the types in the first list are themselves 1056connected to each other, or that the types in the second list are 1057connected to each other. 1058 1059\begin{table}[ht] 1060 \begin{center} 1061 \begin{tabular}{|l@{\hspace*{1.5in}}l|} \hline 1062 {\bfseries connect} & \\ 1063 \multicolumn{2}{|l|}{\#define allMetal2 m2,m2c/m2,pad/m2} \\ 1064 \multicolumn{2}{|l|}{\#define allMetal1 1065 m1,m2c/m1,pc/m1,ndc/m1,pdc/m1,ppcont/m1,nncont/m1,pad/m1} \\ 1066 \multicolumn{2}{|l|}{\#define allPoly poly,pc/a,nfet,pfet} \\ 1067 allMetal2 & allMetal2 \\ 1068 allMetal1 & allMetal1 \\ 1069 allPoly & allPoly \\ 1070 ndiff & ndc \\ 1071 pdiff & pdc \\ 1072 nwell,nnc,nsd & nwell,nnc,nsd \\ 1073 pwell,ppc,psd & pwell,ppc,psd \\ 1074 nnc & pdc \\ 1075 ppc & ndc \\ 1076 {\bfseries end} & \\ \hline 1077 \end{tabular} 1078 \caption{{\bfseries Connect} section} 1079 \label{connect} 1080 \end{center} 1081\end{table} 1082 1083Because connectivity is a symmetric relationship, only one of 1084the two possible orders of two tile types need be specified. 1085Tiles of the same type 1086are always considered to be connected. 1087Contacts are treated specially; they should be specified as 1088connecting to material in all planes spanned by the contact. 1089For example, pcontact is shown as connecting to 1090several types in the active plane, as well as several types 1091in the metal1 plane. 1092The connectivity of a contact should usually be that 1093of its component types, 1094so pcontact should connect 1095to everything connected to poly, and 1096to everything connected to metal1. 1097 1098\section{Cifoutput section} 1099 1100The layers stored by Magic do not always correspond to physical 1101mask layers. For example, there is no physical layer corresponding 1102to (the scmos technology file layer) ntransistor; instead, the actual 1103circuit must be built up by overlapping poly and diffusion over pwell. 1104When writing CIF (Caltech Intermediate Form) or Calma GDS-II files, 1105Magic generates the actual 1106geometries that will appear on the masks used to fabricate the 1107circuit. The {\bfseries cifoutput} section of the technology file 1108describes how to generate mask layers from Magic's abstract layers. 1109 1110\begin{table}[ht!] 1111 \begin{center} 1112 \begin{tabular}{|l|} \hline 1113 {\bfseries cifoutput} \\ 1114 style lambda=1.0(gen) \\ 1115 \I scalefactor 100 \\ 1116 \I layer CWN nwell \\ 1117 \II bloat-or pdiff,pdc,pfet * 600 \\ 1118 \II bloat-or nsc,nnd * 300 \\ 1119 \II grow 300 \\ 1120 \II shrink 300 \\ 1121 \II gds 42 1 \\ 1122 \I layer CWP pwell \\ 1123 \II bloat-or ndiff,ndc,nfet * 600 \\ 1124 \II bloat-or psc,ppd * 300 \\ 1125 \II grow 300 \\ 1126 \II shrink 300 \\ 1127 \II gds 41 1 \\ 1128 \I layer CMS allMetal2 \\ 1129 \II labels m2 \\ 1130 \II gds 51 1 \\ 1131 \I layer CAA allDiff \\ 1132 \II labels ndiff,pdiff \\ 1133 \II gds 43 1 \\ 1134 \I layer CCA ndc,pdc \\ 1135 \II squares 200 \\ 1136 \II gds 48 1 \\ 1137 \I layer CCA nncont,ppcont \\ 1138 \II squares 200 \\ 1139 \II gds 48 1 \\ 1140 \I layer CCP pc \\ 1141 \II squares 200 \\ 1142 \II gds 47 1 \\ 1143 {\bfseries end} \\ \hline 1144 \end{tabular} 1145 \caption{Part of the {\bfseries cifoutput} section for style 1146 lambda=1.0(gen) only.} 1147 \label{cifoutput} 1148 \end{center} 1149\end{table} 1150 1151\subsection{CIF and GDS styles} 1152 1153From the 1990's, the CIF format has largely been replaced by the 1154GDS format. However, they describe the same layout geometry, 1155and the formats are similar enough that magic makes use of the CIF 1156generation code as the basis for the GDS write routines. The 1157technology file also uses CIF layer declarations as the basis 1158for GDS output. So even a technology file that only expects to 1159generate GDS output needs a ``{\bfseries cifoutput}'' section 1160declaring CIF layer names. If only GDS output is required, these 1161names may be longer and therefore more descriptive than allowed 1162by CIF format syntax. 1163 1164The technology file can contain several different specifications 1165of how to generate CIF. Each of these is called a CIF 1166{\itshape style}. Different styles may be used for fabrication at 1167different feature sizes, or for totally different purposes. For 1168example, some of the Magic technology files contain a style 1169``plot'' that generates CIF pseudo-layers that have exactly the 1170same shapes as the Magic layers. This style is used for generating 1171plots that look just like what appears on the color display; it 1172makes no sense for fabrication. Lines of the form 1173 1174\starti 1175 \ii {\bfseries style} {\itshape name} 1176\endi 1177 1178are used to end the description of the previous style and start 1179the description of a new style. The Magic command 1180{\bfseries :cif ostyle} {\itshape name} is typed by users to change 1181the current style used for output. The first style in the 1182technology file is used by default for CIF output if the 1183designer doesn't issue a {\bfseries :cif style} command. 1184If the first line of the {\bfseries cifoutput} 1185section isn't a {\bfseries style} line, then Magic uses an initial style 1186name of {\bfseries default}. 1187 1188\subsection{Scaling} 1189 1190Each style must contain a line of the form 1191 1192\starti 1193 \ii {\bfseries scalefactor} {\itshape scale} 1194 [{\bfseries nanometers}\vbar {\bfseries angstroms}] 1195\endi 1196 1197that tells how to scale Magic coordinates into CIF coordinates. 1198The argument {\itshape scale} indicates how many hundredths of a 1199micron correspond to one Magic unit. {\itshape scale} may be any 1200number, including decimals. However, all units in the style description 1201must be integer. Because deep submicron processes may require CIF 1202operations in units of less than one centimicron, the optional parameter 1203{\bfseries nanometers} declares that all units (including the {\itshape 1204scale} parameter) are measured in units of nanometers. Likewise, the 1205units may all be specified in {\bfseries angstroms}. However unlikely 1206the dimensions may seem, the problem is that magic needs to place some 1207objects, like contacts, on half-lambda positions to ensure correct 1208overlap of contact cuts between subcells. A feature size such as, 1209for example, 45 nanometers, has a half-lambda value of 22.5 nanometers. 1210Since this is not an integer, magic will complain about this scalefactor. 1211This is true even if the process doesn't {\itshape allow} sub-nanometer 1212coordinates, and magic uses the {\itshape squares-grid} statement to 1213enforce this restriction. In such a case, it is necessary to declare 1214a scalefactor of 450 angstroms rather than 45 nanometers. 1215 1216Versions of {\itshape magic} prior to 7.1 allowed an optional second 1217(integer) parameter, {\itshape reducer}, or the keyword {\bfseries calmaonly}. 1218The use of {\itshape reducer} is integral to CIF output, which uses the value 1219to ensure that output values are reduced to the smallest common denominator. 1220For example, if all CIF values are divisible by 100, then the reducer is set 1221to 100 and all output values are divided by the same factor, thus reducing 1222the size of the CIF output file. Now the reducer is calculated automatically, 1223avoiding any problems resulting from an incorrectly specified reducer value, 1224and any value found after {\itshape scale} is ignored. 1225The {\bfseries calmaonly} keyword specified that the {\itshape scale} was 1226an odd integer. This limitation has been removed, so any such keyword is 1227ignored, and correct output may be generated for either CIF or Calma at all 1228output scales. 1229 1230In addition to specifying a scale factor, each style can specify 1231the size in which chunks will be processed when generating CIF 1232hierarchically. This is particularly important when the average 1233design size is much larger than the maximum bloat or shrink (e.g, 1234more than 3 orders of magnitude difference). 1235The step size is specified by a line of the following form: 1236 1237\starti 1238 \ii {\bfseries stepsize} {\itshape stepsize} 1239\endi 1240 1241where {\itshape stepsize} is in Magic units. For example, if you plan 1242to generate CIF for designs that will typically be 100,000 Magic 1243units on a side, it might make sense for {\itshape stepsize} to be 124410000 or more. 1245 1246\subsection{Layer descriptions} 1247 1248The main body of information for each CIF style is a set of layer 1249descriptions. Each layer description consists of one or more 1250{\itshape operations} describing how to generate the CIF for a 1251single layer. The first line of each description is one of 1252 1253\starti 1254 \ii {\bfseries layer} {\itshape name} [{\itshape layers}] 1255\endi 1256or 1257\starti 1258 \ii {\bfseries templayer} {\itshape name} [{\itshape layers}] 1259\endi 1260 1261These statements are identical, except that templayers are not 1262output in the CIF file. They are used only to build up intermediate 1263results used in generating the ``real'' layers. In each case, 1264{\itshape name} is the CIF name to be used for the layer. If {\itshape layers} 1265is specified, it consists of a comma-separated list of Magic layers and 1266previously-defined CIF layers in this style; these layers form 1267the initial contents of the new CIF layer (note: the layer lists 1268in this section are less general than what was described in 1269Section~\ref{typelists}; tildes and parentheses are not allowed). 1270If {\itshape layers} is 1271not specified, then the new CIF layer is initially empty. The 1272following statements are used to modify the contents of a CIF 1273layer before it is output. 1274 1275After the {\bfseries layer} or {\bfseries templayer} statement come several 1276statements specifying geometrical operations to apply in building 1277the CIF layer. Each statement takes the current contents of the 1278layer, applies some operation to it, and produces the new contents 1279of the layer. The last geometrical operation for the layer determines 1280what is actually output in the CIF file. The most common geometrical 1281operations are: 1282 1283\starti 1284 \ii {\bfseries or} {\itshape layers} \\ 1285 \ii {\bfseries and} {\itshape layers} \\ 1286 \ii {\bfseries and-not} {\itshape layers} \\ 1287 \ii {\bfseries grow} {\itshape amount} \\ 1288 \ii {\bfseries shrink} {\itshape amount} \\ 1289 \ii {\bfseries bloat-or} {\itshape layers layers2 amount layers2 amount \dots} \\ 1290 \ii {\bfseries squares} {\itshape size} \\ 1291 \ii {\bfseries squares} {\itshape border size separation} \\ 1292\endi 1293 1294Some more obscure operations are: 1295 1296\starti 1297 \ii {\bfseries grow-grid} {\itshape amount} \\ 1298 \ii {\bfseries bloat-max} {\itshape layers layers2 amount layers2 amount \dots} \\ 1299 \ii {\bfseries bloat-min} {\itshape layers layers2 amount layers2 amount \dots} \\ 1300 \ii {\bfseries bloat-all} {\itshape layers layers2} \\ 1301 \ii {\bfseries squares-grid} {\itshape border size separation x y} \\ 1302 \ii {\bfseries slots} {\itshape border size separation} \\ 1303 \ii {\bfseries slots} {\itshape border size separation border\_long} \\ 1304 \ii {\bfseries slots} {\itshape border size separation border\_long 1305 size\_long sep\_long} [{\itshape offset}]] \\ 1306 \ii {\bfseries bbox} [{\bfseries top}] 1307\endi 1308 1309The operation {\bfseries or} takes all the {\itshape layers} (which may be 1310either Magic layers or previously-defined CIF layers), and or's 1311them with the material already in the CIF layer. The operation 1312{\bfseries and} is similar to {\bfseries or}, except that it and's the layers 1313with the material in the CIF layer (in other words, any CIF 1314material that doesn't lie under material in {\itshape layers} is 1315removed from the CIF layer). {\bfseries And-not} finds all areas covered 1316by {\itshape layers} and erases current CIF material from those areas. 1317{\bfseries Grow} and {\bfseries shrink} will 1318uniformly grow or shrink the current CIF layer by {\itshape amount} 1319units, where {\itshape amount} is specified in CIF units, not Magic 1320units. The {\bfseries grow-grid} operator grows layers non-uniformly 1321to snap to the grid spacing indicated by {\itshape amount}. This can be 1322used to ensure that features fall on a required minimum grid. 1323 1324The three ``bloat'' operations {\bfseries bloat-or}, 1325{\bfseries bloat-min}, and {\bfseries bloat-max}, provide selective forms 1326of growing. In these statements, all the layers must be Magic 1327layers. Each operation examines all the tiles in {\itshape layers}, 1328and grows the tiles by a different distance on each side, depending 1329on the rest of the line. Each pair {\itshape layers2 amount} specifies 1330some tile types and a distance (in CIF units). Where a tile of 1331type {\itshape layers} abuts a tile of type {\itshape layers2}, the first 1332tile is grown on that side by {\itshape amount}. The result is or'ed 1333with the current contents of the CIF plane. The layer ``{\bfseries *}'' may 1334be used as {\itshape layers2} to indicate all tile types. Where tiles 1335only have a single type of neighbor on each side, all three forms 1336of {\bfseries bloat} are identical. Where the neighbors are different, 1337the three forms are slightly different, as illustrated in Figure~\ref{bloat}. 1338Note: all the layers specified in any given {\bfseries bloat} 1339operation must lie on a single Magic plane. For {\bfseries bloat-or} 1340all distances must be positive. In {\bfseries bloat-max} and {\bfseries bloat-min} 1341the distances may be negative to provide a selective form of 1342shrinking. 1343 1344\begin{figure}[ht] 1345 \begin{center} 1346 \epsfig{file=../psfigures/maint2.2.ps, width=\columnwidth} 1347 \caption{The three different forms of {\bfseries bloat} behave 1348 slightly differently when two different bloat distances apply 1349 along the same side of a tile. In each of the above examples, 1350 the CIF that would be generated is shown in bold outline. 1351 If {\bfseries bloat-or} is specified, a jagged edge may 1352 be generated, as on the left. If {\bfseries bloat-max} is used, 1353 the largest bloat distance for each side is applied uniformly to 1354 the side, as in the center. If {\bfseries bloat-min} is used, the 1355 smallest bloat distance for each side is applied uniformly to the 1356 side, as on the right.} 1357 \end{center} 1358 \label{bloat} 1359\end{figure} 1360 1361In retrospect, it's not clear that {\bfseries bloat-max} and {\bfseries bloat-min} 1362are very useful operations. The problem is that they operate on tiles, 1363not regions. This can cause unexpected behavior on concave regions. 1364For example, if the region being bloated is in the shape of a ``T'', a 1365single bloat factor will be applied to the underside of the horizontal 1366bar. If you use {\bfseries bloat-max} or {\bfseries bloat-min}, you should 1367probably specify design-rules that require the shapes being bloated to 1368be convex. 1369 1370The fourth bloat operation {\bfseries bloat-all} takes all tiles of 1371types {\itshape layers}, and grows to include all neighboring tiles of 1372types {\itshape layers2}. This is very useful to generate marker layers 1373or implant layers for specific devices, where the marker or implant must 1374cover both the device and its contacts. Take the material of the device 1375and use {\bfseries bloat-all} to expand into the contact areas. 1376 1377An important geometric operation for creating contact cuts is 1378{\bfseries squares}. It examines 1379each tile on the CIF plane, and replaces that tile with one or 1380more squares of material. Each square is {\itshape size} CIF units 1381across, and squares are separated by {\itshape separation} units. A border 1382of at least {\itshape border} units is left around the edge of the original 1383tile, if possible. This operation is used to generate contact vias, as in 1384Figure~\ref{squares}. If only one argument is given in the {\bfseries squares} 1385statement, then {\itshape separation} defaults to {\itshape size} and 1386{\itshape border} defaults to {\itshape size}/2. If a tile doesn't hold an 1387integral number of squares, extra space is left around the edges of 1388the tile and the squares are centered in the tile. If the tile is 1389so small that not even a single square can fit and still leave enough 1390border, then the border is reduced. If a square won't fit in the 1391tile, even with no border, then no material is generated. 1392The {\bfseries squares} operation 1393must be used with some care, in conjunction with the design rules. 1394For example, if there are several adjacent skinny tiles, there 1395may not be enough room in any of the tiles for a square, so no 1396material will be generated at all. Whenever you use the {\bfseries squares} 1397operator, you should use design rules to prohibit adjacent contact 1398tiles, and you should always use the {\bfseries no{\_}overlap} rule to prevent 1399unpleasant hierarchical interactions. The problems with hierarchy 1400are discussed in Section~\ref{hierarchy} below, and design rules are discussed 1401in Section~\ref{s_mzrouter}. 1402 1403\begin{figure}[ht] 1404 \begin{center} 1405 \epsfig{file=../psfigures/maint2.3.ps, width=0.33\columnwidth} 1406 \caption{The {\bfseries squares} operator chops each tile up 1407 into squares, as determined by the {\itshape border}, {\itshape size}, 1408 and {\itshape separation} parameters. In the example, the bold 1409 lines show the CIF that would be generated by a {\bfseries squares} 1410 operation. The squares of material are always centered so that 1411 the borders on opposite sides are the same.} 1412 \label{squares} 1413 \end{center} 1414\end{figure} 1415 1416The {\bfseries squares-grid} operator is similar to {\bfseries squares} and 1417takes the same arguments, except for the additional optional {\itshape x} and 1418{\itshape y} offsets (which default to 1). Where the {\bfseries squares} 1419operator places contacts on the half-lambda grid, the {\bfseries squares-grid} 1420operator places contacts on an integer grid of {\itshape x} and {\itshape y}. 1421This is helpful where manufacturing grid limitations do not allow half-lambda 1422coordinates. However, it is necessary then to enforce a ``no-overlap'' rule 1423for contacts in the DRC section to prevent incorrect contacts cuts from 1424being generated in overlapping subcells. The {\bfseries squares-grid} 1425operator can also be used with {\itshape x} and {\itshape y} values to 1426generate fill geometry, or to generate offset contact cut arrays for pad 1427vias. 1428 1429The {\bfseries slots} operator is similar to {\bfseries squares} operator, 1430but as the name implies, the resulting shapes generated are rectangular, 1431not (necessarily) square. Slots are generated inside individual tiles, 1432like the squares operator, so each slots operation is separately oriented 1433relative to the tile's long and short edges. Separate border, size, and 1434separation values can be specified for the short and long dimensions of 1435the tile. This operator can be used in a number of situations: 1436 1437\begin{enumerate} 1438 \item Generate square contact cuts with different border requirements on 1439 the short and long sides, as required for a number of deep submicron 1440 processes like 90 nanometer. 1441 \item Automatically generate slots in large metal areas, which most 1442 processes require. Note, however, that it is impossible to 1443 correctly generate all slots, so this cannot completely replace 1444 the widespacing DRC rule. 1445 \item Generate slot contacts. 1446 \item Generate fill geometry. 1447 \item Generate marker layers for resitors that abut the position of 1448 contacts, a generally-accepted way to define a resistor area 1449 boundary. 1450\end{enumerate} 1451 1452Note that the {\bfseries slots} operator comes in three different forms 1453with different numbers of arguments. With only three arguments (short 1454side description only), the {\bfseries slots} operator creates stripes 1455that extend to the edge of the tile. With four arguments (short side 1456description plus long side border dimension only), the {\bfseries slots} 1457operator create stripes that extend to the edge of the tile, with 1458an appropriate border spacing at each end. In these two cases, the 1459slots have variable length that is set by the size of the tile. In the 1460final form, all short and long side dimensions are declared. The 1461generated slots are of fixed size, and like the {\bfseries squares} 1462operator, their positions will be adjusted to center them on the tile. 1463The {\itshape offset} is intended to let each row of slots be offset 1464from the previous one by a fixed amount, but is currently unimplemented 1465and has no effect. 1466 1467\begin{figure}[ht] 1468 \begin{center} 1469 \epsfig{file=../psfigures/maint2.3b.ps, width=0.6\columnwidth} 1470 \caption{The {\bfseries slots} operator chops each tile up 1471 into rectangles.} 1472 \label{slots} 1473 \end{center} 1474\end{figure} 1475 1476The {\bfseries bbox} operator generates a single rectangle that encompasses 1477the bounding box of the cell. This is useful for the occasional process 1478that requires marker or implant layers covering an entire design. The 1479variant {\bfseries bbox top} will generate a rectangle encompassing the 1480bounding box of the cell, but will only do so for the top-level cell of the 1481design. 1482 1483\subsection{Labels} 1484 1485There is an additional statement permitted in the {\bfseries cifoutput} 1486section as part of a layer description: 1487 1488\starti 1489 \ii {\bfseries labels} {\itshape Magiclayers} 1490\endi 1491 1492This statement tells Magic that labels attached to Magic layers 1493{\itshape Magiclayers} are to be associated with the current CIF layer. 1494Each Magic layer should only appear in one such statement for 1495any given CIF style. If a Magic layer doesn't appear in any 1496{\bfseries labels} statement, then it is not attached to a specific 1497layer when output in CIF. 1498 1499\subsection{Calma (GDS II Stream format) layers} 1500 1501Each layer description in the {\bfseries cifoutput} section may also 1502contain one of the following statements: 1503 1504\starti 1505 \ii {\bfseries gds} {\itshape gdsNumber} {\itshape gdsType} \\ 1506 \ii {\bfseries calma} {\itshape gdsNumber} {\itshape gdsType} 1507\endi 1508 1509Although the format is rarely referred to as ``Calma'' anymore, the 1510keyword is retained for backwards compatibility with format 27 (and 1511earlier) files. 1512 1513This statement tells Magic which layer number and data type 1514to use when the {\bfseries gds} command outputs GDS II Stream format 1515for this defined CIF layer. 1516Both {\itshape gdsNumber} and {\itshape gdsType} should be positive 1517integers, between 0 and 63. 1518Each CIF layer should have a different {\itshape gdsNumber}. 1519If there is no {\bfseries gds} line for a given CIF layer, then 1520that layer will not be output by the ``{\bfseries gds write}'' command. 1521The reverse is not true: every generated output layer must have a 1522defined CIF layer type, even if the foundry only supports GDS format. 1523In such case, the CIF layer name may violate the restrictive 4-character 1524format required by the CIF syntax specification, and may be used to 1525provide a reasonable, human-readable descriptive name of the GDS layer. 1526 1527\begin{figure}[ht] 1528 \begin{center} 1529 \epsfig{file=../psfigures/maint2.4.ps, width=0.85\columnwidth} 1530 \caption{If the operator {\bfseries grow 100} is applied to the 1531 shapes in (a), the merged shape in (b) results. If the operator 1532 {\bfseries shrink 100} is applied to (b), the result is (c). However, 1533 if the two original shapes in (a) belong to different cells, and 1534 if CIF is generated separately in each cell, the result will be 1535 the same as in (a). Magic handles this by outputting additional 1536 information in the parent of the subcells to fill in the gap between 1537 the shapes.} 1538 \label{growshrink} 1539 \end{center} 1540\end{figure} 1541 1542\subsection{Hierarchy} \label{hierarchy} 1543 1544Hierarchical designs make life especially difficult for the 1545CIF generator. The CIF corresponding 1546to a collection of subcells may not necessarily be the same 1547as the sum of the CIF's of the individual cells. For example, 1548if a layer is generated by growing and then shrinking, nearby 1549features from different cells may merge together so that they 1550don't shrink back to their original shapes (see Figure~\ref{growshrink}). 1551If Magic 1552generates CIF separately for each cell, the interactions between 1553cells will not be reflected properly. The CIF generator attempts 1554to avoid these problems. Although it generates CIF in a 1555hierarchical representation that matches the Magic cell structure, 1556it tries to ensure that the resulting CIF patterns are exactly the same 1557as if the entire Magic design had been flattened into a single cell 1558and then CIF were generated from the flattened design. It does this 1559by looking in each cell for places where subcells are close enough 1560to interact with each other or with paint in the parent. Where this 1561happens, Magic flattens the interaction area and generates CIF for 1562it; then Magic flattens each of the subcells separately and generates 1563CIF for them. Finally, it compares the CIF from the subcells with the 1564CIF from the flattened parent. Where there is a difference, Magic 1565outputs extra CIF in the parent to compensate. 1566 1567Magic's hierarchical approach only works if the overall CIF for the 1568parent ends up covering at least as much area as the CIFs for the 1569individual components, so all compensation can be done by adding 1570extra CIF to the parent. In mathematical terms, this requires 1571each geometric operation to obey the rule 1572 1573\starti 1574 \ii Op(A $\cup$ B) $\supseteq$ Op(A) $\cup$ Op(B) 1575\endi 1576 1577The operations {\bfseries and}, {\bfseries or}, {\bfseries grow}, and 1578{\bfseries shrink} all 1579obey this rule. Unfortunately, the {\bfseries and-not}, {\bfseries bloat}, 1580and {\bfseries squares} 1581operations do not. For example, if there are two partially-overlapping 1582tiles in different cells, the squares generated from one of the cells 1583may fall in the separations between squares in the other cell, resulting 1584in much larger areas of material than expected. 1585There are two ways around this problem. One 1586way is to use the design rules to prohibit problem situations from 1587arising. This applies mainly to the {\bfseries squares} operator. Tiles 1588from which squares are made should never be allowed to overlap 1589other such tiles in different cells unless the overlap is exact, 1590so each cell will generate squares in the same place. You can 1591use the {\bfseries exact{\_}overlap} design rule for this. 1592 1593The second approach is to leave things up to the designer. 1594When generating CIF, Magic issues warnings where there is less material 1595in the children than the parent. The designer can locate these problems 1596and eliminate the interactions that cause the trouble. Warning: 1597Magic does not check the {\bfseries squares} operations for hierarchical 1598consistency, so you absolutely must use {\bfseries exact{\_}overlap} design 1599rule checks! Right now, the {\bfseries cifoutput} section of the 1600technology is one of the trickiest things in the whole file, particularly 1601since errors here may not show up until your chip comes back and doesn't 1602work. Be extremely careful when writing this part! 1603 1604\begin{table}[ht!] 1605 \begin{center} 1606 \begin{tabular}{|l|} \hline 1607 {\bfseries cifinput} \\ 1608 style lambda=1.0(gen) \\ 1609 \I scalefactor 100 \\ 1610 \I layer m1 CMF \\ 1611 \II labels CMF \\ 1612 \I layer ndiff CSN \\ 1613 \II and CAA \\ 1614 \I layer nsd CWN \\ 1615 \II and CSN \\ 1616 \II and CAA \\ 1617 \I layer nfet CPG \\ 1618 \II and CAA \\ 1619 \II and CSN \\ 1620 \I layer ndc CCA \\ 1621 \II grow 100 \\ 1622 \II and CAA \\ 1623 \II and CWP \\ 1624 \II and CSN \\ 1625 \II and CMF \\ 1626 \I layer nncont CCA \\ 1627 \II grow 100 \\ 1628 \II and CAA \\ 1629 \II and CSN \\ 1630 \II and CWN \\ 1631 \II and CMF \\ 1632 \I calma CAA 1 * \\ 1633 \I calma CCA 2 * \\ 1634 \I calma CMF 4 * \\ 1635 \I calma CPG 7 * \\ 1636 \I calma CSN 8 * \\ 1637 \I calma CWN 11 * \\ 1638 \I calma CWP 12 * \\ 1639 {\bfseries end} \\ \hline 1640 \end{tabular} 1641 \caption{Part of the {\bfseries cifinput} section. The order of 1642 the layers is important, since each Magic layer overrides the 1643 previous ones just as if they were painted by hand.} 1644 \label{cifinput} 1645 \end{center} 1646\end{table} 1647 1648Another problem with hierarchical generation is that it can be very 1649slow, especially when there are a number of rules in the cifoutput 1650section with very large grow or shrink distances, such that magic 1651must always expand its area of interest by this amount to be sure 1652of capturing all possible layer interactions. When this ``halo'' 1653distance becomes larger than the average subcell, much of the 1654design may end up being processed multiple times. Noticeably slow 1655output generation is usually indicative of this problem. It can 1656be alleviated by keeping output rules simple. Note that basic AND 1657and OR operations do not interact between subcells, so that rules 1658made from only these operators will not be processed during subcell 1659interaction generation. Remember that typically, subcell interaction 1660paint will only be generated for layers that have a ``grow'' operation 1661followed by a ``shrink'' operation. This common ruleset lets layers 1662that are too closely spaced to be merged together, thus eliminating 1663the need for a spacing rule between the layers. But consider carefully 1664before implementing such a rule. Implementing a DRC spacing rule 1665instead may eliminate a huge amount of output processing. Usually 1666this situation crops up for auto-generated layers such as implants and 1667wells, to prevent magic from auto-generating DRC spacing violations. 1668But again, consider carefully whether it might be better to require 1669the layout engineer to draw the layers instead of attempting to 1670auto-generate them. 1671 1672\subsection{Render statements} 1673 1674At the end of each style in the {\bfseries cifoutput} section, one may 1675include {\bfseries render} statements, one per defined CIF/GDS layer. 1676These {\bfseries render} statements are used by the 3-D drawing window 1677in the OpenGL graphics version of magic, and are also used by the 1678``{\bfseries cif see}'' command to set the style painted. The syntax 1679for the statement is as follows: 1680 1681\starti 1682 \ii {\bfseries render} {\itshape cif\_layer style\_name height thickness} 1683\endi 1684 1685The {\itshape cif\_layer} is any valid layer name defined in the same 1686{\bfseries cifoutput} section where the {\bfseries render} statement occurs. 1687The {\itshape style\_name} is the name or number of a style in the styles 1688file. The names are the same as used in the {\bfseries styles} section of 1689the technology file. {\itshape height} and {\itshape thickness} are 1690effectively dimensionless units and are used for relative placement and 1691scaling of the three-dimensional layout view (such views generally have 1692a greatly expanded z-axis scaling). By default, all layers are given the 1693same style and a zero height and thickness, so effectively nothing useful 1694can be seen in the 3-D view without a complete set of {\bfseries render} 1695statements. 1696 1697\section{Cifinput section} 1698 1699In addition to writing CIF, Magic can also read in CIF files using 1700the {\bfseries :cif read} {\itshape file} command. The {\bfseries cifinput} 1701section of the technology file describes how to convert from CIF mask layers 1702to Magic tile types. 1703In addition, it provides information to the Calma reader to allow 1704it to read in Calma GDS II Stream format files. 1705The {\bfseries cifinput} section is very similar to the {\bfseries cifoutput} 1706section. It can contain several styles, with a line of the form 1707 1708\starti 1709 \ii {\bfseries style} {\itshape name} 1710\endi 1711 1712used to end the description of the previous style (if any), and start a 1713new CIF input style called {\itshape name}. If no initial style name is 1714given, the name {\bfseries default} is assigned. Each style must have a 1715statement of the form 1716 1717\starti 1718 \ii {\bfseries scalefactor} {\itshape scale} {\bfseries [nanometers]} 1719\endi 1720 1721to indicate the output scale relative to Magic units. Without the 1722optional keyword {\bfseries nanometers}, {\itshape scale} describes how 1723many hundredths of a micron correspond to one unit in Magic. With 1724{\bfseries nanometers} declared, {\itshape scale} describes how many 1725nanometers correspond to one unit in Magic. 1726 1727Like the {\bfseries cifoutput} section, each style consists of a number 1728of layer descriptions. A layer description contains one 1729or more lines describing a series of geometric operations to be 1730performed on CIF layers. The result of all these operations is 1731painted on a particular Magic layer just as if the user had 1732painted that information by hand. 1733A layer description begins with a statement of the form 1734 1735\starti 1736 \ii {\bfseries layer} {\itshape magicLayer }[{\itshape layers}] 1737\endi 1738 1739In the {\bfseries layer} statement, {\itshape magicLayer} is the Magic layer 1740that will be painted after performing the geometric operations, 1741and {\itshape layers} is an optional list of CIF layers. If 1742{\itshape layers} is specified, it is the initial value for the layer 1743being built up. If {\itshape layers} isn't specified, the layer starts 1744off empty. As in the {\bfseries cifoutput} section, each line after 1745the {\itshape layer} statement gives a geometric operation that is applied 1746to the previous contents of the layer being built in order to generate 1747new contents for the layer. The result of the last geometric operation 1748is painted into the Magic database. 1749 1750The geometric operations that are allowed in the {\bfseries cifinput} section 1751are a subset of those permitted in the {\bfseries cifoutput} section: 1752 1753\starti 1754 \ii {\bfseries or} {\itshape layers} \\ 1755 \ii {\bfseries and} {\itshape layers} \\ 1756 \ii {\bfseries and-not} {\itshape layers} \\ 1757 \ii {\bfseries grow} {\itshape amount} \\ 1758 \ii {\bfseries shrink} {\itshape amount} 1759\endi 1760 1761In these commands the {\itshape layers} must all be CIF layers, and the 1762{\itshape amounts} are all CIF distances (centimicrons, unless the keyword 1763{\bfseries nanometers} has been used in the {\bfseries scalefactor} 1764specification). As with the 1765{\bfseries cifoutput} section, layers can only be specified in simple 1766comma-separated lists: tildes and slashes are not permitted. 1767 1768When CIF files are read, all the mask information is read for a cell 1769before performing any of the geometric processing. After the cell 1770has been completely read in, the Magic layers are produced and 1771painted in the order they appear in the technology file. In 1772general, the order that the layers are processed is important 1773since each layer will usually override the previous ones. For 1774example, in the scmos tech file shown in Table~\ref{cifinput} the commands 1775for {\bfseries ndiff} will result in the {\bfseries ndiff} layer being generated 1776not only where there is only ndiffusion 1777but also where there are 1778ntransistors and ndcontacts. 1779The descriptions 1780for {\bfseries ntransistor} and {\bfseries ndcontact} appear later in the section, 1781so those layers will replace the {\bfseries ndiff} material that was originally 1782painted. 1783 1784Labels are handled in the {\bfseries cifinput} section just like in the 1785{\bfseries cifoutput} section. A line of the form 1786 1787\starti 1788 \ii {\bfseries labels} {\itshape layers} 1789\endi 1790 1791means that the current Magic layer is to receive all CIF labels 1792on {\itshape layers}. This is actually just an initial layer assignment 1793for the labels. Once a CIF cell has been read in, Magic scans the 1794label list and re-assigns labels if necessary. In the example of 1795Table~\ref{cifinput}, if a label is attached to the CIF layer CPG then it will 1796be assigned to the Magic layer {\bfseries poly}. However, the polysilicon 1797may actually be part of a poly-metal contact, which is Magic layer 1798{\bfseries pcontact}. After all the mask information has been processed, 1799Magic checks the material underneath the layer, and adjusts the 1800label's layer to match that material ({\bfseries pcontact} in this case). 1801This is the same as what would happen if a designer painted {\bfseries poly} 1802over an area, attached a label to the material, then painted {\bfseries pcontact} 1803over the area. 1804 1805No hierarchical mask processing is done for CIF input. Each cell 1806is read in and its layers are processed independently 1807from all other cells; Magic assumes that there 1808will not be any unpleasant interactions between cells as happens 1809in CIF output (and so far, at least, this seems to be a valid 1810assumption). 1811 1812If Magic encounters a CIF layer name that doesn't appear 1813in any of the lines for the current CIF input style, it 1814issues a warning message and ignores the information associated 1815with the layer. If you would like Magic to ignore certain 1816layers without issuing any warning messages, insert a line 1817of the form 1818 1819\starti 1820 \ii {\bfseries ignore} {\itshape cifLayers} 1821\endi 1822 1823where {\itshape cifLayers} is a comma-separated list of one or 1824more CIF layer names. 1825 1826Calma layers are specified via {\bfseries calma} lines, which should appear 1827at the end of the {\bfseries cifinput} section. They are of the form: 1828 1829\starti 1830 \ii {\bfseries calma} {\itshape cifLayer} {\itshape calmaLayers} 1831 {\itshape calmaTypes} 1832\endi 1833 1834The {\itshape cifLayer} is one of the CIF types mentioned in the {\bfseries cifinput} 1835section. Both {\itshape calmaLayers} and {\itshape calmaTypes} are one or more 1836comma-separated integers between 0 and 63. The interpretation of 1837a {\bfseries calma} line is that any Calma geometry whose layer is any 1838of the layers in {\itshape calmaLayers}, and whose type is any of the 1839types in {\itshape calmaTypes}, should be treated as the CIF layer 1840{\itshape cifLayer}. 1841Either or both of {\itshape calmaLayers} and {\itshape calmaTypes} may be 1842the character {\bfseries *} instead of a comma-separated list of integers; 1843this character means {\itshape all} layers or types respectively. 1844It is commonly used for {\itshape calmaTypes} to indicate that the 1845Calma type of a piece of geometry should be ignored. 1846 1847Just as for CIF, Magic also issues warnings if it encounters 1848unknown Calma layers while reading Stream files. If there are 1849layers that you'd like Magic to ignore without issuing warnings, 1850assign them to a dummy CIF layer and ignore the CIF layer. 1851 1852\section{Lef section} 1853 1854This section defines a mapping between magic layers and layers that may 1855be found in LEF and DEF format files. Without the section, magic cannot 1856read a LEF or DEF file. The LEF and DEF layer declarations are usually 1857simple and straightforward (as they typically define metal layers only), 1858so often it will suffice to insert a plain vanilla {\bfseries lef} section 1859into a technology file if one is missing. The {\bfseries lef} section 1860was introduced in technology file format 28, and is therefore absent from 1861all {\ttfamily .tech27} technology files. All of the statements in 1862the {\bfseries lef} section have the same format: 1863 1864\starti 1865 \ii {\bfseries layer} {\itshape magic-type lefdef-type} \dots \\ 1866 \ii {\bfseries cut} {\itshape magic-type lefdef-type} \dots \\ 1867 \ii {\bfseries route}\vbar {\bfseries routing} {\itshape magic-type lefdef-type} 1868 \dots \\ 1869 \ii {\bfseries obstruction} {\itshape magic-type lefdef-type} \dots \\ 1870 \ii {\bfseries masterslice} {\itshape magic-type lefdef-type} \dots \\ 1871 \ii {\bfseries overlap} {\itshape magic-type lefdef-type} \dots 1872\endi 1873 1874Each statement defines a mapping between a Magic layer type 1875{\itshape magic-type} and one or more type names {\itshape lefdef-type} 1876(space-separated) that might be encountered in a LEF or DEF file. The 1877different command names all refer to different type classes defined 1878by the LEF/DEF specification. For most purposes, it is only necessary 1879to use the {\bfseries layer} statement. If the magic type is a contact 1880type, then the {\bfseries layer} statement is equivalent to specifying 1881{\bfseries cut}; otherwise, it is equivalent to {\bfseries route}. 1882 1883Table \ref{lefdef} is a typical {\bfseries lef} section for a 5-metal technology, 1884which encompasses the most commonly used layer names found in LEF and DEF files. 1885 1886\begin{table}[ht] 1887 \begin{center} 1888 \begin{tabular}{|lllllll|} \hline 1889 {\bfseries lef} &&&&&& \\ 1890 & masterslice & ndiff & diffusion & active && \\ 1891 & masterslice & poly & poly & POLY1 & pl & \\ 1892 & routing & m1 & m1 & metal1 & METAL1 & METAL\_1 \\ 1893 & routing & m2 & m2 & metal2 & METAL2 & METAL\_2 \\ 1894 & routing & m3 & m3 & metal3 & METAL3 & METAL\_3 \\ 1895 & routing & m4 & m4 & metal4 & METAL4 & METAL\_4 \\ 1896 & routing & m5 & m5 & metal5 & METAL5 & METAL\_5 \\ 1897 &&&&&&\\ 1898 & cut & pc & cont1 & pl-m1 && \\ 1899 & cut & m2c & via1 & cont2 & VIA12 & m1-m2 \\ 1900 & cut & m3c & via2 & cont3 & VIA23 & m2-m3 \\ 1901 & cut & m4c & via3 & cont4 & VIA34 & m3-m4 \\ 1902 & cut & m5c & via4 & cont5 & VIA45 & m4-m5 \\ 1903 &&&&&& \\ 1904 & overlap & comment & overlap & OVERLAP && \\ 1905 {\bfseries end} &&&&&& \\ \hline 1906 \end{tabular} 1907 \caption{A plain vanilla lef section.} 1908 \label{lefdef} 1909 \end{center} 1910\end{table} 1911 1912\section{Mzrouter section} \label{s_mzrouter} 1913 1914This section defines the layers and contacts available to the Magic maze router, {\itshape mzrouter}, and assigns default costs for each type. Default widths 1915and spacings are 1916derived from the {\bfseries drc} section of the technology file (described below) 1917but can be overridden in this 1918section. Other mzrouter parameters, for example, search rate and width, 1919can also be specified in this section. The syntax and function of the 1920lines in the {\bfseries mzrouter} section of the technology file 1921are specified in the subsections below. Each 1922set of specifications should be headed by a {\bfseries style} line. 1923{\bfseries Routelayer} 1924and {\bfseries routecontact} specifications should precede references to them. 1925 1926\begin{table}[ht] 1927 \begin{center} 1928 \begin{tabular}{|llllll|} \hline 1929 {\bfseries mzrouter} &&&&& \\ 1930 style & irouter &&&& \\ 1931 layer & m2 & 32 & 64 & 256 & 1 \\ 1932 layer & m1 & 64 & 32 & 256 & 1 \\ 1933 layer & poly & 128 & 128 & 512 & 1 \\ 1934 contact & m2contact & metal1 & metal2 & 1024 & \\ 1935 contact & pcontact & metal1 & poly & 2056 & \\ 1936 notactive & poly & pcontact &&& \\ 1937 style & garouter &&&& \\ 1938 layer & m2 & 32 & 64 & 256 & 1 \\ 1939 layer & m1 & 64 & 32 & 256 & 1 \\ 1940 contact & m2contact & metal1 & metal2 & 1024 & \\ 1941 {\bfseries end} &&&&& \\ \hline 1942 \end{tabular} 1943 \caption{Mzrouter section for the scmos technology.} 1944 \label{mzrouter} 1945 \end{center} 1946\end{table} 1947 1948\subsection{Styles} 1949 1950The mzrouter is currently used in two contexts, 1951interactively via the {\bfseries iroute} command, and as a subroutine to the garouter 1952for stem generation. To permit distinct parameters for these two 1953uses, the lines in the {\bfseries mzrouter} section are grouped into {\itshape styles}. 1954The lines pertaining to the irouter should be preceded by 1955 1956\starti 1957 \ii {\bfseries style irouter} 1958\endi 1959 1960and those pertaining to the garouter should be preceded by the specification 1961 1962\starti 1963 \ii {\bfseries style garouter} 1964\endi 1965 1966Other styles can be specified, but are currently not used. 1967Table~\ref{mzrouter} shows the mzrouter section from the scmos technology. 1968 1969\subsection{Layers} 1970 1971Layer lines 1972define the route-layers available to the maze router in that style. They 1973have the following form: 1974 1975\starti 1976 \ii {\bfseries layer} {\itshape type hCost vCost jogCost hintCost} 1977\endi 1978 1979Here {\itshape type} is the name of the tiletype of the layer and {\itshape hCost}, 1980{\itshape vCost}, {\itshape jogCost} and {\itshape hintCost}, are non-negative integers 1981specifying the cost per unit horizontal distance, 1982cost per unit vertical distance, cost per jog, and 1983cost per unit area of deviation from magnets, respectively. Route layers 1984for any given style must lie in distinct planes. 1985 1986\subsection{Contacts} 1987 1988Contact lines specify 1989the route-contacts available to the mzrouter in the current 1990style. They have the following form: 1991 1992\starti 1993 \ii {\bfseries contact} {\itshape type routeLayer1 routeLayer2 cost} 1994\endi 1995 1996Here {\itshape type} is the tiletype of the contact, {\itshape routeLayer1} and 1997{\itshape routeLayer2} are the two layers connected by the contact, and {\itshape cost} 1998is a nonnegative integer specifying the cost per contact. 1999 2000\subsection{Notactive} 2001 2002It maybe desirable to have a layer or contact available to the maze router, 2003but default to off, i.e., not be used by the mzrouter until explicitly 2004made active. Route-types (route-layers or route-contacts) can be made to 2005default to off with the following specification: 2006 2007\starti 2008 \ii {\bfseries notactive} {\itshape route-type} \dots [{\bfseries route-typen}] 2009\endi 2010 2011\subsection{Search} 2012 2013The search {\bfseries rate}, {\bfseries width}, and {\bfseries penalty} parameters can 2014be set with a specification of the form: 2015 2016\starti 2017 \ii {\bfseries search} {\itshape rate width penalty} 2018\endi 2019 2020Here {\itshape rate} and {\itshape width} are positive integers. And {\itshape penalty} 2021is a positive rational (it may include a decimal point). See the irouter 2022tutorial for a discussion of these parameters. (Note that {\bfseries penalty} 2023is a ``wizardly'' parameter, i.e., it is interactively 2024set and examined via {\bfseries iroute wizard} not {\bfseries iroute search}). 2025If no {\bfseries search} line 2026is given for a style, the overall mzrouter defaults are used. 2027 2028\subsection{Width} 2029 2030Appropriate widths for route-types are normally derived from the {\bfseries drc} 2031section 2032of the technology file. These can be overridden with width specifications 2033of the following form: 2034 2035\starti 2036 \ii {\bfseries width} {\itshape route-type width} 2037\endi 2038 2039Here {\itshape width} is a positive integer. 2040 2041\subsection{Spacing} 2042 2043Minimum spacings between routing on a route-type and other types are 2044derived from the design rules. These values can be overridden by explicit 2045spacing specifications in the {\bfseries mzrouter} section. Spacing 2046specifications have the following form: 2047 2048\starti 2049 \ii {\bfseries spacing} {\itshape routetype type1 spacing1 } \dots 2050 [{\itshape typen spacingn}] 2051\endi 2052 2053Spacing values must be nonnegative integers or {\bfseries NIL}. The special type 2054{\bfseries SUBCELL} can be used to specify minimum spacing to unexpanded subcells. 2055 2056\section{Drc section} 2057 2058The design rules used by Magic's design rule checker 2059come entirely from the technology file. 2060We'll look first at two simple kinds of rules, 2061{\bfseries width} and and {\bfseries spacing}. 2062Most of the rules in the {\bfseries drc} 2063section are one or the other of these kinds of rules. 2064 2065\subsection{Width rules} 2066 2067The minimum width of a collection of types, taken together, 2068is expressed by a {\bfseries width} rule. 2069Such a rule has the form: 2070 2071\starti 2072 \ii {\bfseries width} {\itshape type-list width error} 2073\endi 2074 2075where {\itshape type-list} is a set of tile types 2076(see Section~\ref{typelists} for syntax), 2077{\itshape width} is an integer, and {\itshape error} 2078is a string, enclosed in double quotes, 2079that can be printed by the command {\bfseries :drc why} 2080if the rule is violated. 2081A width rule requires that all regions containing any types 2082in the set {\itshape types} must be wider than {\itshape w} in both dimensions. 2083For example, in Table~\ref{drcwidth}, the rule 2084 2085\starti 2086 \ii {\bfseries width} nwell 6 {\itshape {\q}N-Well width must be at least 6 2087 (MOSIS rule \#1.1){\q}} 2088\endi 2089 2090means that nwells must be at least 6 units 2091wide whenever they appear. 2092The {\itshape type-list} 2093field may contain more than a single type, as in the following rule: 2094 2095\starti 2096 \ii {\bfseries width} allDiff 2 {\itshape {\q}Diffusion width must 2097 be at least 2 (MOSIS rule \#2.1){\q}} 2098\endi 2099 2100which means that all regions consisting of the types 2101containing any kind of diffusion 2102be at least 2 units wide. 2103Because many of the rules in the {\bfseries drc} section refer to the 2104same sets of layers, the {\bfseries \#define} facility of the C preprocessor 2105is used to define a number of macros for these sets of layers. 2106Table~\ref{drctiles} gives a complete list. 2107 2108\begin{table}[ht] 2109 \begin{center} 2110 \begin{tabular}{|lll|} \hline 2111 \#define & allDiff & ndiff,pdiff,ndc/a,pdc/a,ppcont/a,nncont/a,pfet,nfet,psd,nsd 2112 \\ 2113 \#define & extPoly & poly,pcontact \\ 2114 \#define & extM1 & metal1,pcontact/m1,ndc/m1,ppcont/m1,pdc/m1,nncont/m1 \\ 2115 \#define & extM2 & metal2,m2contact/m2 \\ \hline 2116 \end{tabular} 2117 \caption{Abbreviations for sets of tile types.} 2118 \label{drctiles} 2119 \end{center} 2120\end{table} 2121 2122\begin{table}[ht] 2123 \begin{center} 2124 \begin{tabular}{|llll|} \hline 2125 width & pwell & 6 & {\q}P-Well width must be at least 6 2126 (MOSIS rule \#1.1){\q} \\ 2127 width & nwell & 6 & {\q}N-Well width must be at least 6 2128 (MOSIS rule \#1.1){\q} \\ 2129 width & allDiff & 2 & {\q}Diffusion width must be at least 2 2130 (MOSIS rule \#2.1){\q} \\ 2131 width & allPoly & 2 & {\q}Polysilicon width must be at least 2 2132 (MOSIS rule \#3.1){\q} \\ \hline 2133 \end{tabular} 2134 \caption{Some width rules in the {\bfseries drc} section.} 2135 \label{drcwidth} 2136 \end{center} 2137\end{table} 2138 2139All of the layers named in any one width rule must lie on the 2140same plane. However, if some of the layers are contacts, Magic 2141will substitute a different contact image if the named image 2142isn't on the same plane as the other layers. 2143 2144\subsection{Spacing rules} 2145 2146The second simple kind of design rule is a {\bfseries spacing} rule. 2147It comes in two flavors: 2148{\bfseries touching{\_}ok}, and {\bfseries touching{\_}illegal}, 2149both with the following syntax: 2150 2151\starti 2152 \ii {\bfseries spacing} {\itshape types1 types2 distance flavor error} 2153\endi 2154 2155The first flavor, {\bfseries touching{\_}ok}, does not prohibit 2156{\itshape types1} and {\itshape types2} from being immediately adjacent. 2157It merely requires that any type in the set {\itshape types1} 2158must be separated by a ``Manhattan'' distance of at least 2159{\itshape distance} units from any type in the set {\itshape types2} 2160that is not immediately adjacent to the first type. 2161See Figure~\ref{distance} for an illustration of Manhattan distance 2162for design rules. 2163As an example, consider the metal1 separation rule: 2164 2165\starti 2166 \ii {\bfseries spacing} allPoly allPoly 2 {\bfseries touching{\_}ok} {\bk} \\ 2167 \ii\> {\itshape {\q}Polysilicon spacing must be at least 2 (MOSIS rule \#3.2){\q}} 2168\endi 2169 2170\begin{figure}[ht] 2171 \begin{center} 2172 \epsfig{file=../psfigures/maint2.5.ps, width=0.4\columnwidth} 2173 \caption{For design rule checking, the Manhattan distance between 2174 two horizontally or vertically aligned points is just the normal 2175 Euclidean distance. If they are not so aligned, then the Manhattan 2176 distance is the length of the longest side of the right triangle 2177 forming the diagonal line between the points.} 2178 \end{center} 2179 \label{distance} 2180\end{figure} 2181 2182This rule is symmetric ({\itshape types1} is equal to {\itshape types2}), 2183and requires, for example, that a pcontact 2184be separated by at least 2 units from a piece of polysilicon. 2185However, this rule does not prevent the pcontact 2186from touching a piece of poly. In {\bfseries touching{\_}ok} rules, 2187all of the layers in both {\itshape types1} and {\itshape types2} must be stored 2188on the same plane (Magic will substitute different contact 2189images if necessary). 2190 2191\begin{table}[ht] 2192 \begin{center} 2193 \begin{tabular}{|lllll|} \hline 2194 spacing & allPoly & allPoly & 2 & touching{\_}ok {\bk} \\ 2195 & \multicolumn{4}{l|}{{\itshape {\q}Polysilicon spacing must be 2196 at least 2 (MOSIS rule \#3.2){\q}}} \\ 2197 spacing & pfet & nncont,nnd & 3 & touching{\_}illegal {\bk} \\ 2198 & \multicolumn{4}{l|}{{\itshape {\q}Transistors must be separated 2199 from substrate contacts by 3 (MOSIS rule \#4.1){\q}}} \\ 2200 spacing & pc & allDiff & 1 & touching{\_}illegal {\bk} \\ 2201 & \multicolumn{4}{l|}{{\itshape {\q}Poly contact must be 1 unit 2202 from diffusion (MOSIS rule \#5B.6){\q}}} \\ \hline 2203 \end{tabular} 2204 \caption{Some spacing rules in the {\bfseries drc} section.} 2205 \label{drcspacing} 2206 \end{center} 2207\end{table} 2208 2209{\bfseries TOUCHING{\_}OK SPACING} RULES DO NOT WORK 2210FOR VERY LARGE SPACINGS (RELATIVE TO THE TYPES INVOLVED). SEE FIGURE 6 2211FOR AN EXPLANATION. If the spacing to be checked is greater 2212than the width of one of the types involved plus either its self-spacing or 2213spacing to a second involved type, 2214{\bfseries touching{\_}ok spacing} may not work properly: a violation can 2215be masked by an intervening touching type. In such cases the rule 2216should be written using the {\bfseries edge4way} construct described below. 2217 2218\begin{figure}[ht] 2219 \begin{center} 2220 \epsfig{file=../psfigures/maint2.6.ps, width=0.5\columnwidth} 2221 \caption{The {\bfseries touching{\_}ok} rules cancels spacing checks 2222 if the material is touching. This means that even distant material 2223 won't be checked for spacing. If the rule applied at edge A is a 2224 touching{\_}ok rule between material t1 and t2, then no check will 2225 be made between the t1 material and the t2 material on the far right 2226 side of the diagram. If this check was desired, it could be 2227 accomplished in this case by a {\bfseries edge4way} check from edge 2228 B. This would not work in general, though, because that check 2229 could also be masked by material of type t2, causing the touching{\_}ok 2230 rule to be invoked.} 2231 \label{touchingok} 2232 \end{center} 2233\end{figure} 2234 2235The second flavor of spacing rule, {\bfseries touching{\_}illegal}, disallows 2236adjacency. It is used for rules where {\itshape types1} and {\itshape types2} 2237can never touch, as in the following: 2238 2239\starti 2240 \ii {\bfseries spacing} pc allDiff 1 {\bfseries touching{\_}illegal} {\bk} \\ 2241 \ii\> {\itshape {\q}Poly contact must be 1 unit from diffusion 2242 (MOSIS rule \#5B.6){\q}} 2243\endi 2244 2245Pcontacts and any type of diffusion must be at least 1 unit apart; 2246they cannot touch. 2247In {\bfseries touching{\_}illegal} 2248rules {\itshape types1} and {\itshape types2} may not have any types in common: 2249it would be rather strange not to permit a type to touch itself. In 2250{\bfseries touching{\_}illegal} rules, {\itshape types1} 2251and {\itshape types2} may be spread across multiple planes; Magic will find 2252violations between material on different planes. 2253 2254\subsection{Wide material spacing rules} 2255 2256Many fabrications processes require a larger distance between layers when 2257the width and length of one of those layers exceeds a certain minimum 2258dimension. For instance, a process might declare that the normal spacing 2259between metal1 lines is 3 microns. However, if a metal1 line exceeds 2260a width of 100 microns, then the spacing to other unrelated metal1 lines 2261must increase to 10 microns. This situation is covered by the 2262{\bfseries widespacing} rule. The syntax for {\bfseries widespacing} is as 2263follows: 2264 2265\starti 2266 \ii {\bfseries widespacing} {\itshape types1 wwidth types2 distance flavor error} 2267\endi 2268 2269The {\bfseries widespacing} rule matches the syntax of {\bfseries spacing} in all 2270respects except for the addition of the parameter {\itshape wwidth}, which declares 2271the minimum width of layers of type(s) {\itshape types1} that triggers the rule. 2272So for the example above, the correct {\bfseries widespacing} rule would be 2273(assuming 1 magic unit = 1 micron): 2274 2275\starti 2276 \ii {\bfseries widespacing} allMetal1 100 allMetal1 10 {\bfseries touching{\_}ok} {\bk} \\ 2277 \ii\> {\itshape {\q}Space to wide Metal1 (length and width \grt 100) must be at least 10{\q}} 2278\endi 2279 2280\begin{figure}[ht] 2281 \begin{center} 2282 \epsfig{file=../psfigures/maint2.6b.ps, width=0.8\columnwidth} 2283 \caption{The {\bfseries widespacing} rule covers situations like that 2284 shown above, in which material of type {\itshape t1} normally must 2285 be {\itshape dist} units away from type {\itshape t2} (situation A). 2286 However, if both dimensions of material type {\itshape t1} are 2287 larger than or equal to some width {\itshape wwidth} (situation B), 2288 then the spacing must be increased to {\itshape wdist}.} 2289 \label{widespacing} 2290 \end{center} 2291\end{figure} 2292 2293\subsection{Surround rule} 2294 2295The {\bfseries surround} rule specifies what distance a layer must surround 2296another, and whether the presence of the surrounding material is optional or 2297mandatory. This rule is designed for materials which must {\itshape completely} 2298surround another, such as metal around a contact cut or MiM capacitor layer. 2299The syntax is: 2300 2301\starti 2302 \ii {\bfseries surround} {\itshape types1 types2 distance presence error} 2303\endi 2304 2305and states that the layers in {\itshape types2} must surround the layers 2306in {\itshape types1} by an amound {\itshape distance} lambda units. The 2307value of {\itshape presence} must be one of the keywords {\bfseries 2308absence\_ok} or {\bfseries absence\_illegal}. When {\itshape presence} is 2309{\bfseries absence\_illegal}, then types {\itshape types2} must always be 2310present when types {\itshape types1} are present. When {\itshape presence} 2311is {\bfseries absence\_ok}, types {\itshape types1} may exist outside of 2312types {\itshape types2} without error, but where they coincide, types 2313{\itshape types2} must overlap {\itshape types1} by the amount 2314{\itshape distance}. 2315 2316\subsection{Overhang rule} rule specifies what distance a layer must overhang 2317another at an intersection. This is used, for example, to specify the length 2318of polysilicon end-caps on transistors, which is the distance that the 2319polysilicon gate must extend beyond the defined gate area of the transistor 2320to ensure a correctly operating device. The syntax is: 2321 2322\starti 2323 \ii {\bfseries overhang} {\itshape types1 types2 distance error} 2324\endi 2325 2326and states that layers in {\itshape types1} must overhang layers in 2327{\itshape types2} by an amount {\itshape distance} lambda units. The 2328rule flags the complete absence of types {\itshape types1}, but does not 2329prohibit the use of {\itshape types1} as a bridge (that is, with 2330types {\itshape types2} on either side of {\itshape types1}, which 2331will generally be covered by a separate spacing rule, and which may 2332have a different spacing requirement). 2333 2334\subsection{Rectangle-only rule} 2335 2336The {\bfseries rect\_only} rule is used to denote layers that must be 2337rectangular; that is, they cannot bend, or have notches or tabs. 2338Generally, this is used for contacts, so that the CIF output operator 2339{\bfseries squares} will be guaranteed to generate a correct contact. 2340This is due to magic's corner-stitching tile database, where bends, 2341notches, tabs, and slots will break up an otherwise continuous patch 2342of material into potentially many small tiles, each one of which 2343might be too small to fit a contact cut. 2344 2345\starti 2346 \ii {\bfseries rect\_only} {\itshape types error} 2347\endi 2348 2349\subsection{Edge rules} 2350 2351The width and spacing rules just described are actually translated 2352by Magic into an underlying, edge-based rule format. This underlying 2353format can handle rules more general than simple widths and spacings, 2354and is accessible to the writer of a technology file via {\bfseries edge} rules. 2355These rules are applied at boundaries between material of 2356two different types, in any of four directions as shown in Figure~\ref{tileedge}. 2357The design rule table contains a separate list of rules for each possible 2358combination of materials on the two sides of an edge. 2359 2360\begin{figure}[ht] 2361 \begin{center} 2362 \epsfig{file=../psfigures/maint2.7.ps, width=0.4\columnwidth} 2363 \caption{Design rules are applied at the edges between tiles in 2364 the same plane. A rule is specified in terms of type {\itshape t1} 2365 and type {\itshape t2}, the materials on either side of the edge. 2366 Each rule may be applied in any of four directions, as shown by 2367 the arrows. The simplest rules require that only certain mask types 2368 can appear within distance {\itshape d} on {\itshape t2}'s side of 2369 the edge.} 2370 \label{tileedge} 2371 \end{center} 2372\end{figure} 2373 2374In its simplest form, a rule specifies a distance 2375and a set of mask types: only the given types are permitted 2376within that distance on {\itshape type2}'s side of the edge. 2377This area is referred to as the {\itshape constraint region}. 2378Unfortunately, this simple scheme will miss errors 2379in corner regions, such as the case shown in Figure~\ref{cornererror}. 2380To eliminate these problems, the full rule format allows the constraint 2381region to be extended past the ends of the edge under some 2382circumstances. 2383See Figure~\ref{cornerextend} for an illustration of the 2384corner rules and how they work. 2385Table~\ref{edgerules1} gives a complete 2386description of the information in each design rule. 2387 2388\begin{figure}[hb!] 2389 \begin{center} 2390 \epsfig{file=../psfigures/maint2.8.ps, width=0.7\columnwidth} 2391 \caption{If only the simple rules from Figure~\ref{tileedge} are used, errors 2392 may go unnoticed in corner regions. For example, the polysilicon 2393 spacing rule in (a) will fail to detect the error in (b).} 2394 \label{cornererror} 2395 \end{center} 2396\end{figure} 2397 2398\begin{figure}[ht!] 2399 \begin{center} 2400 \epsfig{file=../psfigures/maint2.9.ps, width=0.75\columnwidth} 2401 \caption{The complete design rule format is illustrated in (a). 2402 Whenever an edge has {\itshape type1} on its left side and 2403 {\itshape type2} on its right side, the area A is checked to be 2404 sure that only {\itshape OKTypes} are present. If the material 2405 just above and to the left of the edge is one of 2406 {\itshape cornerTypes}, then area B is also checked to be 2407 sure that it contains only {\itshape OKTypes}. A similar 2408 corner check is made at the bottom of the edge. Figure (b) 2409 shows a polysilicon spacing rule, (c) shows a situation where 2410 corner extension is performed on both ends of the edge, and 2411 (d) shows a situation where corner extension is made only at 2412 the bottom of the edge. If the rule described in (d) were to 2413 be written as an {\bfseries edge} rule, it would look like:} 2414 \starti 2415 \ii {\bfseries edge} poly space 2 \~{}poly \~{}poly 2 {\bk} \\ 2416 \ii\> {\itshape {\q}Poly-poly separation must be at least 2{\q}} 2417 \endi 2418 \label{cornerextend} 2419 \end{center} 2420\end{figure} 2421 2422\begin{table}[ht] 2423 \begin{center} 2424 \begin{tabular}{|l|p{0.5\columnwidth}|} \hline 2425 Parameter & Meaning \\ \hline \hline 2426 type1 & Material on first side of edge. \\ \hline 2427 type2 & Material on second side of edge. \\ \hline 2428 d & Distance to check on second side of edge. \\ \hline 2429 OKTypes & List of layers that are permitted within 2430 {\itshape d} units on second side of edge. 2431 ({\itshape OKTypes}={\bfseries 0} means never OK) \\ \hline 2432 cornerTypes & List of layers that cause corner extension. 2433 ({\itshape cornerTypes}={\bfseries 0} means no 2434 corner extension) \\ \hline 2435 cornerDist & Amount to extend constraint area when 2436 {\itshape cornerTypes} matches. \\ \hline 2437 plane & Plane on which to check constraint region (defaults 2438 to same plane as {\itshape type1} and {\itshape type2} 2439 and {\itshape cornerTypes}). \\ \hline 2440 \end{tabular} 2441 \caption{The parts of an edge-based rule.} 2442 \label{edgerules1} 2443 \end{center} 2444\end{table} 2445 2446Edge rules are specified in the technology file using the following syntax: 2447 2448\starti 2449 \ii {\bfseries edge} {\itshape types1 types2 d OKTypes cornerTypes 2450 cornerDist error} [{\itshape plane}] 2451\endi 2452 2453Both {\itshape types1} and {\itshape types2} are type-lists. 2454An edge rule is generated for each pair consisting of a type from 2455{\itshape types1} and a type from {\itshape types2}. All the types in 2456{\itshape types1}, {\itshape types2}, and {\itshape cornerTypes} must lie 2457on a single plane. See Figure~\ref{cornerextend} for an example edge rule. 2458It is sometimes 2459useful to specify a null list, i.e., {\bfseries 0}, for {\itshape OKTypes} 2460or {\itshape CornerTypes}. Null {\itshape OKTypes} means no edges between 2461{\itshape types1} and {\itshape types2} are OK. Null {\itshape CornerTypes} 2462means no corner extensions are to be checked (corner extensions are explained 2463below). 2464 2465Some of the edge rules in Magic have the property that if a rule 2466is violated between two pieces of geometry, the violation can be 2467discovered looking from either piece of geometry toward the other. 2468To capitalize on this, Magic normally applies an edge 2469rule only in two of the four possible directions: bottom-to-top 2470and left-to-right, reducing the work it has to do by a factor of two. 2471Also, the corner extension is only performed to one side of the edge: 2472to the top for a left-to-right rule, and to the left for a bottom-to-top 2473rule. All of the width and spacing rules translate neatly into edge 2474rules. 2475 2476However, you'll probably find it easiest when you're writing 2477edge rules to insist that they be checked in all directions. 2478To do this, write the rule the same way except use the keyword 2479{\bfseries edge4way} instead of {\bfseries edge}: 2480 2481\starti 2482 \ii {\bfseries edge4way} nfet ndiff 2 ndiff,ndc ndiff 2 {\bk} \\ 2483 \ii\> {\itshape {\q}Diffusion must overhang transistor by at least 2{\q}} 2484\endi 2485 2486Not only are {\bfseries edge4way} rules checked in all four directions, 2487but the corner extension is performed on {\itshape both} sides of the 2488edge. For example, when checking a rule from left-to-right, 2489the corner extension is performed both to the top and to the bottom. 2490{\bfseries Edge4way} rules take twice as much time to check as {\bfseries edge} 2491rules, so it's to your advantage to use {\bfseries edge} rules wherever 2492you can. 2493 2494\begin{table}[ht] 2495 \begin{center} 2496 \begin{tabular}{|lllllll|} \hline 2497 edge4way & ppcont,ppd & ndiff,ndc,nfet & 3 & ndiff,ndc,nfet & 2498 ndiff,ndc,nfet & 3 {\bk} \\ 2499 & \multicolumn{5}{l}{{\itshape {\q}Ndiff must be 3 wide if it abuts 2500 ppcont or ppd (MOSIS rule \#??){\q}}} & \\ 2501 edge4way & allPoly & \~{}(allPoly)/active & 3 & \~{}pc/active & 2502 \~{}(allPoly)/active & 3 {\bk} \\ 2503 & \multicolumn{5}{l}{{\itshape {\q}Poly contact must be at least 3 from 2504 other poly (MOSIS rule \#5B.4,5){\q}}} & \\ 2505 edge4way & allPoly & \~{}(allPoly)/active & 1 & \~{}m2c/metal2 & 2506 \~{}(allPoly)/active & 1 {\bk} \\ 2507 & \multicolumn{5}{l}{{\itshape {\q}Via must be on a flat surface 2508 (MOSIS rule \#8.4,5){\q}} metal2} & \\ \hline 2509 \end{tabular} 2510 \caption{Some edge rules in the {\bfseries drc} section.} 2511 \label{edgerules2} 2512 \end{center} 2513\end{table} 2514 2515Normally, an edge rule is checked completely within a single plane: 2516both the edge that triggers the rule and the constraint area to check 2517fall in the same plane. However, the {\itshape plane} argument can be 2518specified in an edge rule to force Magic to perform the constraint 2519check on a plane different from the one containing the triggering 2520edge. In this case, {\itshape OKTypes} must all be tile types in {\itshape plane}. 2521This feature is used, for example, to ensure that 2522polysilicon and diffusion edges don't lie underneath metal2 contacts: 2523 2524\starti 2525 \ii {\bfseries edge4way} allPoly \~{}(allPoly)/active 1 \~{}m2c/metal2 2526 \~{}(allPoly)/active 1 {\bk} \\ 2527 \ii\> {\itshape {\q}Via must be on a flat surface (MOSIS rule \#8.4,5){\q}} metal2 2528\endi 2529 2530Magic versions using techfile formats more recent than 28 are generally 2531more clever about determining the correct plane from {\itshape OKTypes} 2532when they differ from the triggering types, and the situation is 2533unambiguous (use of ``space'' in rules tends to introduce ambiguity, since 2534space tiles appear on all planes). 2535 2536\subsection{Subcell Overlap Rules} 2537 2538In order for CIF generation and circuit extraction to work properly, 2539certain kinds of overlaps between subcells must be prohibited. The 2540design-rule checker provides two kinds of rules for restricting 2541overlaps. They are 2542 2543\starti 2544 \ii {\bfseries exact{\_}overlap} {\itshape type-list} \\ 2545 \ii {\bfseries no{\_}overlap} {\itshape type-list1 type-list2} 2546\endi 2547 2548In the {\bfseries exact{\_}overlap} rule, {\itshape type-list} 2549indicates one or more tile types. 2550If a cell contains a tile of one of these types and that tile is 2551overlapped by another tile of the same type from a different cell, 2552then the overlap must be exact: the tile in each cell must cover 2553exactly the same area. Abutment between tiles from different cells 2554is considered to be a partial overlap, so it is prohibited too. 2555This rule is used to ensure that the CIF {\bfseries squares} operator 2556will work correctly, as described in Section~\ref{hierarchy}. 2557See Table~\ref{exactoverlap} for the {\bfseries exact{\_}overlap} 2558rule from the standard scmos technology file. 2559 2560\begin{table}[ht] 2561 \begin{center} 2562 \begin{tabular}{|lll|} \hline 2563 exact{\_}overlap & \multicolumn{2}{l|}{m2c,ndc,pdc,pc,ppcont,nncont} \\ 2564 no{\_}overlap & pfet,nfet & pfet,nfet \\ \hline 2565 \end{tabular} 2566 \caption{Exact{\_}overlap rule in the {\bfseries drc} section.} 2567 \label{exactoverlap} 2568 \end{center} 2569\end{table} 2570 2571The {\bfseries no{\_}overlap} rule makes illegal any overlap between a tile in 2572{\itshape type-list1} and a tile in {\itshape type-list2}. You should rarely, 2573if ever, need to specify {\bfseries no{\_}overlap} rules, since 2574Magic automatically prohibits many kinds of overlaps between 2575subcells. After reading the technology file, Magic examines the paint 2576table and applies the following rule: if two tile types A and 2577B are such that the result of painting A over B 2578is neither A nor B, or the result of painting B over A isn't 2579the same as the result of painting A over B, then A and B 2580are not allowed to overlap. 2581Such overlaps are prohibited because they change the 2582structure of the circuit. Overlaps are supposed only to connect 2583things without making structural changes. Thus, for example, poly can 2584overlap pcontact without violating the above rules, but 2585poly may not overlap diffusion because the result is efet, which 2586is neither poly nor diffusion. The only {\bfseries no{\_}overlap} rules 2587you should need to specify are rules to keep transistors from 2588overlapping other transistors of the same type. 2589 2590\subsection{Background checker step size} 2591 2592Magic's background design-rule checker breaks large cells up into 2593smaller pieces, checking each piece independently. For very large 2594designs, the number of pieces can get to be enormous. 2595If designs are large but sparse, the performance of the design-rule 2596checker can be improved tremendously by telling it to use a larger 2597step size for breaking up cells. This is done as follows: 2598 2599\starti 2600 \ii {\bfseries stepsize} {\itshape stepsize} 2601\endi 2602 2603which causes each cell to be processed in square pieces 2604of at most {\itshape stepsize} by {\itshape stepsize} units. 2605It is generally a good idea to pick a large {\itshape stepsize}, but 2606one that is small enough so each piece will contain no more than 2607100 to 1000 rectangles. 2608 2609Note that the distances declared in the DRC section are used to determine 2610the ``halo'' of possible interactions around a tile edge. Magic must 2611consider all paint in all cells simultaneously; thus for each edge in 2612the design, magic must flatten the hierarchy around it to a distance 2613equal to the interaction halo. Clearly this has a huge impact on 2614processing time. Because the DRC is interactive, the performance hit 2615can be noticeable to downright irritating. Often this performance hit 2616can be greatly reduced by removing rules with large distance measures, 2617such as rules involving distances to pads, and widespacing rules. 2618If this is a problem, consider using one technology file for layout, 2619and one which can be used ``offline'' to do a slow, non-interactive 2620DRC check for pad and widespacing rules on an entire project layout. 2621 2622\section{Extract section} 2623 2624The {\bfseries extract} section of a technology file contains the parameters 2625used by Magic's circuit extractor. 2626Each line in this section begins 2627with a keyword that determines the interpretation of the remainder of 2628the line. 2629Table~\ref{extract} gives an example {\bfseries extract} section. 2630 2631\begin{table}[ht!p] 2632 \begin{center} 2633 \begin{tabular}{|ll|} \hline 2634 {\bfseries extract} & \\ 2635 style & lambda=0.7 \\ 2636 lambda & 70 \\ 2637 step & 100 \\ 2638 sidehalo & 4 \\ \vns 2639 & \\ 2640 resist & poly,pfet,nfet 60000 \\ 2641 resist & pc/a 50000 \\ 2642 resist & pdiff,ppd 120000 \\ 2643 resist & ndiff,nnd 120000 \\ 2644 resist & m2contact/m1 1200 \\ 2645 resist & metal1 200 \\ 2646 resist & metal2,pad/m1 60 \\ 2647 resist & ppc/a,pdc/a 100000 \\ 2648 resist & nnc/a,ndc/a 100000 \\ 2649 resist & nwell,pwell 3000000 \\ \vns 2650 & \\ 2651 areacap & poly 33 \\ 2652 areacap & metal1 17 \\ 2653 areacap & metal2,pad/m1 11 \\ 2654 areacap & ndiff,nsd 350 \\ 2655 areacap & pdiff,psd 200 \\ 2656 areacap & ndc/a,nsc/a 367 \\ 2657 areacap & pdc/a,psc/a 217 \\ 2658 areacap & pcontact/a 50 \\ \vns 2659 & \\ 2660 perimc & allMetal1 space 56 \\ 2661 perimc & allMetal2 space 55 \\ \vns 2662 & \\ 2663 overlap & metal1 pdiff,ndiff,psd,nsd 33 \\ 2664 overlap & metal2 pdiff,ndiff,psd,nsd 17 metal1 \\ 2665 overlap & metal1 poly 33 \\ 2666 overlap & metal2 poly 17 metal1 \\ 2667 overlap & metal2 metal1 33 \\ \vns 2668 & \\ 2669 sideoverlap & allMetal1 space allDiff 64 \\ 2670 sideoverlap & allMetal2 space allDiff 60 \\ 2671 sideoverlap & allMetal1 space poly 64 \\ 2672 sideoverlap & allMetal2 space poly 60 \\ 2673 sideoverlap & allMetal2 space allMetal1 70 \\ \vns 2674 & \\ 2675 fet & pfet pdiff,pdc/a 2 pfet Vdd! nwell 0 0 \\ 2676 fet & nfet ndiff,ndc/a 2 nfet GND! pwell 0 0 \\ 2677 {\bfseries end} & \\ \hline 2678 \end{tabular} 2679 \caption{{\bfseries Extract} section.} 2680 \label{extract} 2681 \end{center} 2682\end{table} 2683 2684This section is like the {\bfseries cifinput} and {\bfseries cifoutput} sections 2685in that it supports multiple extraction styles. Each style is 2686preceded by a line of the form 2687 2688\starti 2689 \ii {\bfseries style} {\itshape stylename} 2690\endi 2691 2692All subsequent lines up to the next {\bfseries style} line or the end 2693of the section are interpreted as belonging to extraction style 2694{\itshape stylename}. 2695If there is no initial {\bfseries style} line, the first 2696style will be named ``default''. 2697 2698The keywords {\bfseries areacap}, {\bfseries perimcap}, 2699and {\bfseries resist} define the capacitance to substrate 2700and the sheet resistivity of each of the Magic layers in a layout. 2701All capacitances that appear in the {\bfseries extract} section are 2702specified as an integral number of attofarads (per unit area or perimeter), 2703and all resistances as an integral number of milliohms per square. 2704 2705The {\bfseries areacap} keyword is followed by a list of types 2706and a capacitance to substrate, as follows: 2707 2708\starti 2709 \ii {\bfseries areacap} {\itshape types} {\itshape C} 2710\endi 2711 2712Each of the types listed in {\itshape types} has a capacitance to substrate 2713of {\itshape C} attofarads per square lambda. 2714Each type can appear in at most one {\bfseries areacap} line. 2715If a type does not appear in any {\bfseries areacap} line, 2716it is considered to have zero 2717capacitance to substrate per unit area. 2718Since most analysis tools compute transistor gate capacitance directly 2719from the area of the transistor's gate, Magic should produce node 2720capacitances that do not include gate capacitances. To ensure 2721this, all transistors should have zero {\bfseries areacap} values. 2722 2723The {\bfseries perimcap} keyword is followed by two type-lists 2724and a capacitance to substrate, as follows: 2725 2726\starti 2727 \ii {\bfseries perimcap} {\itshape intypes} {\itshape outtypes} {\itshape C} 2728\endi 2729 2730Each edge that has one of the types in {\itshape intypes} 2731on its inside, and one of the types in {\itshape outtypes} on its outside, 2732has a capacitance to substrate of {\itshape C} attofarads per lambda. 2733This can also be used as an approximation of the effects due 2734to the sidewalls of diffused areas. 2735As for {\bfseries areacap}, each unique combination of an {\itshape intype} 2736and an {\itshape outtype} may appear at most once in a {\bfseries perimcap} line. 2737Also as for {\bfseries areacap}, if a combination of {\itshape intype} and 2738{\itshape outtype} does not appear in any {\bfseries perimcap} line, its 2739perimeter capacitance per unit length is zero. 2740 2741The {\bfseries resist} keyword is followed by a type-list 2742and a resistance as follows: 2743 2744\starti 2745 \ii {\bfseries resist} {\itshape types} {\itshape R} 2746\endi 2747 2748The sheet resistivity of each of the types in {\itshape types} is 2749{\itshape R} milliohms per square. 2750 2751Each {\bfseries resist} line in fact defines a ``resistance class''. 2752When the extractor outputs the area and perimeter of nodes in 2753the {\bfseries .ext} file, it does so for each resistance class. 2754Normally, each resistance class consists of all types with 2755the same resistance. 2756However, if you wish to obtain the perimeter and area of each 2757type separately in the {\bfseries .ext} file, you should make each 2758into its own resistance class by using a separate {\bfseries resist} 2759line for each type. 2760 2761In addition to sheet resistivities, there are two other ways 2762of specifying resistances. Neither is used by the normal 2763Magic extractor, but both are used by the resistance extractor. 2764Contacts have a resistance that is inversely proportional to 2765the number of via holes in the contact, which is proportional 2766(albeit with quantization) to the area of the contact. The 2767{\bfseries contact} keyword allows the resistance for a single 2768via hole to be specified: 2769 2770\starti 2771 \ii {\bfseries contact} {\itshape types size R} \\ 2772 \ii {\bfseries contact} {\itshape types size border separation R} 2773\endi 2774 2775where {\itshape types} is a comma-separated list of types, {\itshape size} 2776is in lambda, and {\itshape R} is in milliohms. {\itshape Size} is interpreted 2777as a hole-size quantum; the number of holes in a contact is equal to 2778its width divided by {\itshape size} times its length divided by {\itshape size}, 2779with both quotients rounded down to the nearest integer. The resistance 2780of a contact is {\itshape R} divided by the number of holes. 2781 2782Note that the {\itshape size} alone may not compute the same number of 2783contact cuts as would be generated by the {\itshape cifoutput} command, 2784since it has no understaning of border and separation, and therefore may 2785compute an incorrect contact resistance. To avoid this problem, the 2786second form provides a way to give values for {\itshape border} and 2787{\itshape separation}, again in units of lambda. There is no automatic 2788check to guarantee that the extract and cifoutput sections agree on the 2789number of contact cuts for a given contact area. 2790 2791Transistors also have resistance information associated with them. 2792However, a transistor's resistance may vary depending on a number 2793of variables, so a single parameter is generally insufficient to 2794describe it. The {\bfseries fetresist} line allows sheet resistivities 2795to be given for a variety of different configurations: 2796 2797\starti 2798 \ii {\bfseries fetresist} {\itshape fettypes region R} 2799\endi 2800 2801where {\itshape fettypes} is a comma-separated list of transistor types 2802(as defined in {\bfseries fet} lines below), {\itshape region} is a string 2803used to distinguish between resistance values for a fet if more 2804than one is provided (the special {\itshape region} value of ``{\bfseries linear}'' 2805is required for the resistance extractor), and {\itshape R} is the on-resistance 2806of the transistor in ohms per square ({\itshape not} milliohms; there would 2807otherwise be too many zeroes). 2808 2809Magic also extracts internodal coupling capacitances, as 2810illustrated in Figure~\ref{capextract}. 2811The keywords 2812{\bfseries overlap}, {\bfseries sidewall}, {\bfseries sideoverlap}, 2813and {\bfseries sidehalo} provide the parameters needed to do this. 2814 2815Overlap capacitance is between pairs of tile types, 2816and is described by the {\bfseries overlap} keyword as follows: 2817 2818\starti 2819 \ii {\bfseries overlap} {\itshape toptypes bottomtypes cap} [{\itshape shieldtypes}] 2820\endi 2821 2822where {\itshape toptypes}, {\itshape bottomtypes}, and optionally 2823{\itshape shieldtypes} are type-lists and {\itshape cap} 2824is a capacitance in attofarads per square lambda. 2825The extractor searches for tiles whose types are in {\itshape toptypes} 2826that overlap tiles whose types are in {\itshape bottomtypes}, and 2827that belong to different electrical nodes. 2828(The planes of {\itshape toptypes} and {\itshape bottomtypes} must be disjoint). 2829When such an overlap is found, the capacitance to substrate 2830of the node of the tile in {\itshape toptypes} is deducted for the 2831area of the overlap, 2832and replaced by a capacitance to the node of the tile in {\itshape bottomtypes}. 2833 2834\begin{figure}[ht] 2835 \begin{center} 2836 \epsfig{file=../psfigures/tut8.4.ps, width=0.6\columnwidth} 2837 \caption{Magic extracts three kinds of internodal coupling 2838 capacitance. This figure is a side view of a set of masks that shows 2839 all three kinds of capacitance. {\itshape Overlap} capacitance is 2840 parallel-plate capacitance between two different kinds of material 2841 when they overlap. {\itshape Parallel wire} capacitance is 2842 fringing-field capacitance between the parallel vertical edges 2843 of two pieces of material. {\itshape Sidewall overlap} capacitance 2844 is fringing-field capacitance between the vertical edge of one piece 2845 of material and the horizontal surface of another piece of material 2846 that overlaps the vertical edge.} 2847 \label{capextract} 2848 \end{center} 2849\end{figure} 2850 2851If {\itshape shieldtypes} are specified, overlaps between {\itshape toptypes} 2852and {\itshape bottomtypes} that also overlap a type in {\itshape shieldtypes} 2853are not counted. 2854The types in {\itshape shieldtypes} must appear on a different plane 2855(or planes) than any of the types in {\itshape toptypes} or {\itshape bottomtypes}. 2856 2857\begin{figure}[ht!] 2858 \begin{center} 2859 \epsfig{file=../psfigures/maint2.11.ps, width=0.33\columnwidth} 2860 \caption{Parallel wire capacitance is between pairs of edges. 2861 The capacitance applies between the tiles {\itshape tinside} 2862 and {\itshape tfar} above, where {\itshape tinside}'s type is 2863 one of {\itshape intypes}, and {\itshape tfar}'s type is 2864 one of {\itshape fartypes}.} 2865 \label{wirecap} 2866 \end{center} 2867\end{figure} 2868 2869Parallel wire capacitance is between pairs of edges, and 2870is described by the {\bfseries sidewall} keyword: 2871 2872\starti 2873 \ii {\bfseries sidewall} {\itshape intypes outtypes neartypes fartypes cap} 2874\endi 2875 2876where {\itshape intypes}, {\itshape outtypes}, {\itshape neartypes}, 2877and {\itshape fartypes} are all type-lists, described in 2878Figure~\ref{wirecap}. {\itshape Cap} is half the capacitance 2879in attofarads per lambda when the edges are 1 lambda apart. 2880Parallel wire coupling capacitance is computed as being 2881inversely proportional to the 2882distance between two edges: at 2 lambda separation, it is equal 2883to the value {\itshape cap}; at 4 lambda separation, it is half of {\itshape cap}. 2884This approximation is not very good, in that it tends to overestimate 2885the coupling capacitance between wires that are farther apart. 2886 2887To reduce the amount of searching done by Magic, there is a 2888threshold distance beyond which the effects of parallel wire 2889coupling capacitance are ignored. 2890This is set as follows: 2891 2892\starti 2893 \ii {\bfseries sidehalo} {\itshape distance} 2894\endi 2895 2896where {\itshape distance} is the maximum distance between two edges 2897at which Magic considers them to have parallel wire coupling capacitance. 2898{\bfseries If this number is not set explicitly in the technology file, 2899it defaults to 0, with the result that no parallel wire 2900coupling capacitance is computed.} 2901 2902Sidewall overlap capacitance is between material on the inside 2903of an edge and overlapping material of a different type. 2904It is described by the {\bfseries sideoverlap} keyword: 2905 2906\starti 2907 \ii {\bfseries sideoverlap} {\itshape intypes outtypes ovtypes cap} 2908\endi 2909 2910where {\itshape intypes}, {\itshape outtypes}, and {\itshape ovtypes} are type-lists 2911and {\itshape cap} is capacitance in attofarads per lambda. 2912This is the capacitance associated with an edge with a type 2913in {\itshape intypes} on its inside and a type in {\itshape outtypes} on 2914its outside, that overlaps a tile whose type is in {\itshape ovtypes}. 2915See Figure~\ref{capextract}. 2916 2917Devices are represented in Magic by explicit tile types. 2918The extraction of a device is determined by the declared device type 2919and the information about types which comprise the various 2920independent {\itshape terminals} of the device. 2921 2922\starti 2923 \ii {\bfseries device mosfet} {\itshape model gate\_types sd\_types 2924 subs\_types subs\_node\_name} {\bk} \\ 2925 \ii\> [{\itshape perim\_cap} [{\itshape area\_cap}]] \\ 2926 \ii {\bfseries device capacitor} {\itshape model top\_types bottom\_types} 2927 [{\itshape perim\_cap}] {\itshape area\_cap} \\ 2928 \ii {\bfseries device resistor} {\itshape model resist\_types term\_types} \\ 2929 \ii {\bfseries device bjt} {\itshape model base\_types emitter\_types 2930 collector\_types} \\ 2931 \ii {\bfseries device diode} {\itshape model pos\_types neg\_types} \\ 2932 \ii {\bfseries device subcircuit} {\itshape model gate\_types} 2933 [{\itshape term\_types} [{\itshape subs\_types}]] \\ 2934 \ii {\bfseries device rsubcircuit} {\itshape model id\_types term\_types} 2935\endi 2936 2937Arguments are as follows: 2938 2939\begin{itemize} 2940 \item {\itshape model} The SPICE model name of the device. In the case of 2941 a subcircuit, it is the subcircuit name. For resistor and capacitor 2942 devices for which a simple, unmodeled device type is needed, the 2943 {\itshape model} can be the keyword {\bfseries None}. 2944 \item {\itshape gate\_types} Layer types that form the gate region of a 2945 MOSFET transistor. 2946 \item {\itshape sd\_types} Layer types that form the source and drain 2947 regions of a MOSFET transistor. Currently there is no way to specify 2948 a device with asymmetric source and drain. 2949 \item {\itshape subs\_types} Layer types that form the bulk (well or 2950 substrate) region under the device. This can be the keyword 2951 {\itshape None} for a device such as an nFET that has no identifiable 2952 substrate layer type (``space'' cannot be used as a layer type here). 2953 \item {\itshape top\_types} Layer types that form the top plate of a 2954 capacitor. 2955 \item {\itshape bottom\_types} Layer types that form the bottom plate of 2956 a capacitor. 2957 \item {\itshape resist\_types} Layer types that represent the primary 2958 characterized resistive portion of a resistor device. 2959 \item {\itshape term\_types} Layer types that represent the ends of a 2960 resistor. Normally this is a contact type, but in the case of 2961 silicide block or high-resistance implants, it may be normal salicided 2962 polysilicon or diffusion. 2963 \item {\itshape base\_types} Layer types that represent the base region 2964 of a bipolar junction transistor. 2965 \item {\itshape emitter\_types} Layer types that represent the emitter 2966 region of a bipolar junction transistor. 2967 \item {\itshape collector\_types} Layer types that represent the collector 2968 region of a bipolar junction transistor. 2969 \item {\itshape pos\_types} Layer types that represent the positive (anode) 2970 terminal of a diode or P-N junction. 2971 \item {\itshape neg\_types} Layer types that represent the negative (cathode) 2972 terminal of a diode or P-N junction. 2973 \item {\itshape id\_types} Identifier layers that identify a specific 2974 resistor type. 2975 \item {\itshape subs\_node\_name} The default name of a substrate node in 2976 cases where a 4-terminal MOSFET device is missing an identifiable 2977 bulk terminal, or when the {\itshape subs\_type} is the keyword 2978 {\bfseries None}. 2979 \item {\itshape perim\_cap} A value for perimeter capacitance in units of 2980 attoFarads per lambda 2981 \item {\itshape area\_cap} A value for area capacitance in units of 2982 attoFarads per lambda squared. 2983\end{itemize} 2984 2985The {\itshape subs\_node\_name} can be a Tcl variable name (beginning with ``\$'') 2986in the Tcl-based version of magic. Thus, instead of hard-coding a global net 2987name into the general-purpose, project-independent technology file, the 2988technology file can contain a default global power and ground net variable, 2989normally {\bfseries \$VDD} and {\bfseries \$VSS}. Each project should then 2990set these variables (in the {\ttfamily .magicrc} file, for example) to the 2991correct value for the project's default global power and ground networks. 2992 2993SPICE has two formats for resistors and capacitors: one uses a model, and 2994the other does not. The model implies a semiconductor resistor or 2995capacitor, and takes a length and width value. The resistivity or 2996capacitance per unit area of the devices is assumed to be declared in 2997the model, so these values are not generated as part of the SPICE 2998netlist output. 2999 3000Magic technology file formats 27 and earlier only understood one device 3001type, the FET transistor. The extraction of a fet (with gate, sources, and 3002drains) from a collection of transistor tiles is governed by the 3003information in a {\bfseries fet} line. This keyword and syntax is 3004retained for backward compatibility. This line has the following 3005format: 3006 3007\starti 3008 \ii {\bfseries fet} {\itshape types dtypes min-nterms name snode } 3009 [{\itshape stypes}]{\itshape gscap gccap} 3010\endi 3011 3012{\itshape Types} is a list of those tiletypes that 3013make up this type of transistor. Normally, there will be only 3014one type in this list, since Magic usually represents each 3015type of transistor with a different tiletype. 3016 3017{\itshape Dtypes} is a list of those tiletypes 3018that connect to the diffusion terminals of the fet. 3019Each transistor of this type must have at least {\itshape min-nterms} 3020distinct diffusion terminals; otherwise, the extractor will 3021generate an error message. 3022For example, an {\bfseries efet} in the scmos technology must have 3023a source and drain in addition to its gate; {\itshape min-nterms} 3024for this type of fet is 2. 3025The tiletypes connecting to the gate of the fet are the same 3026as those specified in the {\bfseries connect} section as connecting 3027to the fet tiletype itself. 3028 3029{\itshape Name} is a string used to identify this type of transistor 3030to simulation programs. 3031 3032The substrate terminal of a transistor is determined in one 3033of two ways. 3034If {\itshape stypes} 3035(a comma-separated list of tile types) is given, and 3036a particular transistor overlaps one of those types, 3037the substrate terminal will be connected to the node 3038of the overlapped material. 3039Otherwise, the substrate terminal will be connected 3040to the node with the global name of {\itshape snode} 3041(which {\itshape must} be a global name, i.e., end in 3042an exclamation point). 3043 3044{\itshape Gscap} is the capacitance between the transistor's gate 3045and its diffusion terminals, in attofarads per lambda. 3046Finally, {\itshape gccap} is the capacitance between the gate 3047and the channel, in attofarads per square lambda. 3048Currently, {\itshape gscap} and {\itshape gccap} are unused by the extractor. 3049 3050In technology format 27 files, devices such as resistors, capacitors, 3051and bipolar junction transistors could be extracted by treating them 3052like FETs, using a ``{\bfseries fet}'' line in the extract file, and 3053assigning the terminal classes (somewhat arbitrarily) to the FET 3054terminal classes gate, source/drain, and bulk. Resistors are rather 3055cumbersome using this method, because the ``gate'' terminal maps to 3056nothing physical, and a dummy layer must be drawn. The ``ext2spice'' 3057command generates an ``M'' spice record for all devices declared with 3058a {\bfseries fet} line, so an output SPICE deck must be post-processed 3059to produce the correct SPICE devices for simulation. One important 3060other difference between the older form and the newer is the ability 3061of the ``{\bfseries device}'' records to handle devices with bends or 3062other irregular geometry, including annular (ring-shaped) FETs. 3063 3064Often the units in the extracted circuit for a cell will always 3065be multiples of certain basic units larger than centimicrons 3066for distance, attofarads for capacitance, or milliohms for resistance. 3067To allow larger units to be used in the {\bfseries .ext} file for this 3068technology, thereby reducing the file's size, 3069the {\bfseries extract} section may specify a scale 3070for any of the three units, as follows: 3071 3072\starti 3073 \ii {\bfseries cscale} {\itshape c} \\ 3074 \ii {\bfseries lambda} {\itshape l} \\ 3075 \ii {\bfseries rscale} {\itshape r} 3076\endi 3077 3078In the above, {\itshape c} is the number of attofarads per unit capacitance 3079appearing in the {\bfseries .ext} files, {\itshape l} is the number of centimicrons 3080per unit length, and {\itshape r} is the number of milliohms per unit 3081resistance. All three must be integers; 3082{\itshape r} should divide evenly all the resistance-per-square values 3083specified as part of {\bfseries resist} lines, 3084and {\itshape c} should divide evenly all the capacitance-per-unit values. 3085 3086Magic's extractor breaks up large cells into chunks 3087for hierarchical extraction, to avoid having to process too 3088much of a cell all at once and possibly run out of memory. 3089The size of these chunks is determined by the {\bfseries step} 3090keyword: 3091 3092\starti 3093 \ii {\bfseries step} {\itshape step} 3094\endi 3095 3096This specifies that chunks of {\itshape step} units by {\itshape step} units 3097will be processed during hierarchical extraction. The default 3098is {\bfseries 100} units. 3099Be careful about changing {\itshape step}; if it is too small then 3100the overhead of hierarchical processing will increase, and if 3101it is too large then more area will be processed during 3102hierarchical extraction than necessary. 3103It should rarely be necessary to change {\itshape step} unless the 3104minimum feature size changes dramatically; if so, a value of about 310550 times the minimum feature size appears to work fairly well. 3106 3107Magic has the capability to generate a geometry-only extraction of a 3108network, useful for 3-D simulations of electric fields necessary to 3109rigorously determine inductance and capacitance. When this feature 3110is used, it is necessary for the field-equation solver to know the 3111vertical stackup of the layout. The extract section takes care of 3112this by allowing each magic layer to be given a definition of 3113height and thickness of the fabricated layer type: 3114 3115\starti 3116 \ii {\bfseries height} {\itshape layers height thickness} 3117\endi 3118 3119where {\itshape layers} is a comma-separated list of magic layers 3120sharing the same height and thickness, and {\itshape height} and 3121{\itshape thickness} are floating-point numbers giving the height 3122of the bottom of the layer above the substrate, and the thickness 3123of the layer, respectively, in units of lambda. 3124 3125\section{Wiring section} 3126 3127The {\bfseries wiring} section provides information used by the 3128{\bfseries :wire switch} command to generate contacts. 3129See Table~\ref{wiring} for the {\bfseries wiring} section from the scmos 3130technology file. Each line in the section has the syntax 3131 3132\starti 3133 \ii {\bfseries contact} {\itshape type minSize layer1 surround1 layer2 surround2} \\ 3134\endi 3135 3136{\itshape Type} is the name of a contact layer, and {\itshape layer1} and 3137{\itshape layer2} 3138are the two wiring layers that it connects. {\itshape MinSize} is the 3139minimum size of contacts of this type. If {\itshape Surround1} is non-zero, 3140then additional material of type {\itshape layer1} will be painted for 3141{\itshape surround1} units around contacts of {\itshape type}. If {\itshape surround2} 3142is non-zero, it indicates an overlap distance for {\itshape layer2}. 3143 3144\begin{table}[ht] 3145 \begin{center} 3146 \begin{tabular}{|lllllll|} \hline 3147 {\bfseries wiring} &&&&&& \\ 3148 {\bfseries contact} & pdcontact & 4 & metal1 & 0 & pdiff & 0 \\ 3149 {\bfseries contact} & ndcontact & 4 & metal1 & 0 & ndiff & 0 \\ 3150 {\bfseries contact} & pcontact & 4 & metal1 & 0 & poly & 0 \\ 3151 {\bfseries contact} & m2contact & 4 & metal1 & 0 & metal2 & 0 \\ 3152 {\bfseries end} &&&&&& \\ \hline 3153 \end{tabular} 3154 \caption{{\bfseries Wiring} section} 3155 \label{wiring} 3156 \end{center} 3157\end{table} 3158 3159During {\bfseries :wire switch} commands, Magic scans the wiring information 3160to find a contact whose {\itshape layer1} and {\itshape layer2} correspond to the 3161previous and desired new wiring materials (or vice versa). 3162If a match is found, a contact is generated according to {\itshape type}, 3163{\itshape minSize}, {\itshape surround1}, and {\itshape surround2}. 3164 3165\section{Router section} 3166 3167The {\bfseries router} section of a technology file provides information 3168used to guide the automatic routing tools. The section contains four 3169lines. See Table~\ref{router} for an example {\bfseries router} section. 3170 3171\begin{table}[ht] 3172 \begin{center} 3173 \begin{tabular}{|lllllll|} \hline 3174 {\bfseries router} &&&&&& \\ 3175 {\bfseries layer1} & metal1 & 3 & allMetal1 & 3 && \\ 3176 {\bfseries layer2} & metal2 & 3 & allMetal2 & 4 & allPoly,allDiff & 1 \\ 3177 {\bfseries contacts} & m2contact & 4 &&&& \\ 3178 {\bfseries gridspacing} & 8 &&&& \\ 3179 {\bfseries end} &&&&&& \\ \hline 3180 \end{tabular} 3181 \caption{{\bfseries Router} section} 3182 \label{router} 3183 \end{center} 3184\end{table} 3185 3186The first two lines have the keywords {\bfseries layer1} and {\bfseries layer2} 3187and the following format: 3188 3189\starti 3190 \ii {\bfseries layer1} {\itshape wireType wireWidth type-list distance 3191 type-list distance} \dots 3192\endi 3193 3194They define the two layers used for routing. After the {\bfseries layer1} 3195or {\bfseries layer2} keyword are two fields giving the name of the material 3196to be used for routing that layer and the width to use for its wires. 3197The remaining fields are used by Magic to avoid routing over existing 3198material in the channels. Each pair of fields contains a list of 3199types and a distance. The distance indicates how far away the given 3200types must be from routing on that layer. Layer1 and layer2 3201are not symmetrical: wherever possible, Magic will try to 3202route on layer1 in preference to layer2. Thus, in a single-metal 3203process, metal should always be used for layer1. 3204 3205The third line provides information about contacts. It has the format 3206 3207\starti 3208 \ii {\bfseries contacts} {\itshape contactType size } 3209 [{\itshape surround1 surround2}] 3210\endi 3211 3212The tile type {\itshape contactType} 3213will be used to make contacts between layer1 and layer2. Contacts 3214will be {\itshape size} units square. In order to avoid placing contacts 3215too close to hand-routed material, Magic assumes that both the layer1 3216and layer2 rules will apply to contacts. If {\itshape surround1} and 3217{\itshape surround2} are present, they specify overlap distances around 3218contacts for layer1 and layer2: additional layer1 material will be 3219painted for {\itshape surround1} units around each contact, and additional 3220layer2 material will be painted for {\itshape surround2} units around 3221contacts. 3222 3223The last line of the {\bfseries routing} section indicates the size of 3224the grid on which to route. It has the format 3225 3226\starti 3227 \ii {\bfseries gridspacing} {\itshape distance} 3228\endi 3229 3230The {\itshape distance} must be chosen large enough that 3231contacts and/or wires on adjacent grid lines will not generate 3232any design rule violations. 3233 3234\section{Plowing section} 3235 3236The {\bfseries plowing} section of a technology file identifies those types 3237of tiles whose sizes and shapes should not be changed as a result of plowing. 3238Typically, these types will be transistors and buried contacts. 3239The section currently contains three kinds of lines: 3240 3241\starti 3242 \ii {\bfseries fixed} {\itshape types} \\ 3243 \ii {\bfseries covered} {\itshape types} \\ 3244 \ii {\bfseries drag} {\itshape types} 3245\endi 3246 3247where {\itshape types} is a type-list. 3248Table~\ref{plowing} gives this section for the scmos technology file. 3249 3250\begin{table}[ht] 3251 \begin{center} 3252 \begin{tabular}{|ll|} \hline 3253 {\bfseries plowing} & \\ 3254 {\bfseries fixed} & pfet,nfet,glass,pad \\ 3255 {\bfseries covered} & pfet,nfet \\ 3256 {\bfseries drag} & pfet,nfet \\ 3257 {\bfseries end} & \\ \hline 3258 \end{tabular} 3259 \caption{{\bfseries Plowing} section} 3260 \label{plowing} 3261 \end{center} 3262\end{table} 3263 3264In a {\bfseries fixed} line, 3265each of {\itshape types} is considered to be fixed-size; 3266regions consisting of tiles of these types are not deformed by plowing. 3267Contact types are always considered to be fixed-size, so need not 3268be included in {\itshape types}. 3269 3270In a {\bfseries covered} line, 3271each of {\itshape types} will remain ``covered'' by plowing. 3272If a face of a covered type is covered with a given type 3273before plowing, it will remain so afterwards. 3274For example, if a face of a transistor is covered by diffusion, 3275the diffusion won't be allowed to slide along the transistor 3276and expose the channel to empty space. 3277Usually, you should make all fixed-width types covered 3278as well, except for contacts. 3279 3280In a {\bfseries drag} line, 3281whenever material of a type in {\itshape types} moves, it will drag 3282with it any minimum-width material on its trailing side. This 3283can be used, for example, to insure that when a transistor moves, 3284the poly-overlap forming its gate gets dragged along in its entirety, 3285instead of becoming elongated. 3286 3287\section{Plot section} 3288 3289The {\bfseries plot} section of the technology file contains information 3290used by Magic to generate hardcopy plots of layouts. Plots can 3291be generated in different styles, which correspond to different 3292printing mechanisms. For each style of printing, there is a separate 3293subsection within the {\bfseries plot} section. Each subsection is 3294preceded by a line of the form 3295 3296\starti 3297 \ii {\bfseries style} {\itshape styleName} 3298\endi 3299 3300Magic version 6.5 and earlier supported {\bfseries gremlin}, 3301{\bfseries versatec}, and {\bfseries colorversatec} styles. As these 3302are thoroughly obsolete, versions 7 and above instead implement 3303two formats {\bfseries postscript} and {\bfseries pnm}. Generally, 3304the {\bfseries pnm} format is best for printouts of entire chips, and 3305the {\bfseries postscript} format is best for small cells. The 3306PostScript output includes labels, whereas the PNM output does not. 3307The PostScript output is vector-drawn with stipple fills, whereas the 3308PNM output is pixel-drawn, with antialiasing. Small areas of layout 3309tend to look artificially pixellated in the PNM format, while large 3310areas look almost photographic. The PostScript output is a perfect 3311rendering of the Magic layout, but the files become very large and 3312take long spans of time to render for large areas of layout. 3313 3314%-------------------------------------------------- 3315 3316\begin{table}[p] 3317 \renewcommand{\baselinestretch}{0.9} 3318 \normalsize 3319 \begin{center} 3320 \begin{tabular}{|llll|} \hline 3321 {\bfseries plot} &&& \\ 3322 {\bfseries style} & {\bfseries postscript} && \\ 3323 3324& 5 & \multicolumn{2}{l|}{FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF \dots} \\ 3325& 7 & \multicolumn{2}{l|}{18181818 30303030 60606060 C0C0C0C0 \dots} \\ 3326& 9 & \multicolumn{2}{l|}{18181818 3C3C3C3C 3C3C3C3C 18181818 \dots} \\ 3327& 10 & \multicolumn{2}{l|}{F0F0F0F0 60606060 06060606 0F0F0F0F \dots} \\ 3328& 13 & \multicolumn{2}{l|}{00000000 00000000 33333333 33333333 \dots} \\ 3329&&& \\ 3330& 1 & 47 95 111 0 & \\ 3331& 9 & 223 47 223 0 & \\ 3332& 10 & 0 255 255 0 & \\ 3333& 12 & 191 127 0 0 & \\ 3334& 13 & 95 223 63 0 & \\ 3335& 14 & 0 0 0 255 & \\ 3336& 16 & 111 151 244 0 & \\ 3337& 17 & 23 175 183 0 & \\ 3338&&& \\ 3339& \multicolumn{2}{l}{pc,ndc,pdc,psc,nsc} & 14 X \\ 3340& m2c && 14 B \\ 3341& m2c && 14 13 \\ 3342& m2,m2c && 13 10 \\ 3343& \multicolumn{2}{l}{pdc,ndc,psc,nsc,pc,m1,m2c} & 12 9 \\ 3344& poly,pc && 10 5 \\ 3345& nfet && 9 7 \\ 3346& nfet && 16 5 \\ 3347& pfet && 1 7 \\ 3348& pfet && 17 5 \\ 3349& pdiff,pdc && 1 5 \\ 3350& ndiff,ndc && 9 5 \\ 3351&&& \\ 3352 {\bfseries style} & {\bfseries pnm} && \\ 3353& draw & metal1 & \\ 3354& draw & metal2 & \\ 3355& draw & polysilicon & \\ 3356& draw & ndiffusion & \\ 3357& draw & pdiffusion & \\ 3358& draw & ntransistor & \\ 3359& draw & ptransistor & \\ 3360& map & psubstratepdiff pdiffusion & \\ 3361& map & nsubstratendiff ndiffusion & \\ 3362& map & polycontact polysilicon metal1 & \\ 3363& map & m2contact metal1 metal2 & \\ 3364& map & ndcontact ndiffusion metal1 & \\ 3365& map & pdcontact pdiffusion metal1 & \\ 3366 3367 {\bfseries end} &&& \\ \hline 3368 \end{tabular} 3369 \caption{Sample {\bfseries plot} section (for an SCMOS process). PostScript 3370 stipple patterns have been truncated due to space limitations.} 3371 \end{center} 3372 \renewcommand{\baselinestretch}{1.0} 3373\end{table} 3374 3375The {\bfseries postscript} style requires three separate sections. The 3376first section defines the stipple patterns used: 3377 3378\starti 3379 \ii {\itshape index} {\itshape pattern-bytes}\dots 3380\endi 3381 3382The {\itshape index} values are arbitrary but must be a positive integer and 3383must be unique to each line. The indices will be referenced in the third 3384section. The {\itshape pattern-bytes} are always exactly 8 sets of 8-digit 3385hexidecimal numbers (4 bytes) representing a total of 16 bits by 16 lines of 3386pattern data. If a solid color is intended, then it is necessary to declare 3387a stipple pattern of all ones. The actual PostScript output will implement 3388a solid color, not a stipple pattern, for considerably faster rendering. 3389 3390The second section defines the colors used in standard printer CMYK notation 3391(Cyan, Magenta, Yellow, blacK): 3392 3393\starti 3394 \ii {\itshape index C M Y K} 3395\endi 3396 3397Like the first section, each {\itshape index} must be a unique positive 3398integer, and the color values each range from 0 to 255. 3399 3400The third section assigns colors and stipple patterns to each style: 3401 3402\starti 3403 \ii {\itshape type-list color-index stipple-index}\vbar 3404 {\bfseries X}\vbar {\bfseries B} 3405\endi 3406 3407The {\itshape type-list} is a comma-separated list of magic layer types 3408that collectively use the same color and style. The {\itshape color-index} 3409refers to one of the colors defined in the second section, and the 3410{\itshape stipple-index} refers to one of the stipple patterns defined in 3411the first section. In addition to the stipple pattern indices, two characters 3412are recognized: {\bfseries B} declares that a border will be drawn around 3413the layer boundary, and {\bfseries X} declares that the layout boundary will 3414be printed over with a cross in the same manner as contact areas are drawn 3415in the Magic layout. 3416 3417To get a proper PostScript plot, it is necessary to have a properly defined 3418{\bfseries plot postscript} section in the technology file. Without such 3419a defined set, the {\bfseries plot postscript} command will generate blank 3420output. 3421 3422The {\bfseries pnm} style declarations are as follows: 3423 3424\starti 3425 \ii {\bfseries draw} {\itshape magic-type} \\ 3426 \ii {\bfseries map} {\itshape magic-type} {\itshape draw-type}\dots 3427\endi 3428 3429where both {\itshape magic-type} and {\itshape draw-type} represent 3430a magic layer name. The {\bfseries draw} command states that a specific 3431magic type will be output exactly as drawn on the layout. The {\bfseries 3432map} statement declares that a specific magic type will be drawn as 3433being composed of other layers declared as {\bfseries draw} types. 3434The colors of the {\bfseries draw} types will be blended to generate 3435the mapped layer color. Colors are defined by the style set used for 3436layout and defined in the {\bfseries styles} section of the technology 3437file. Stipple patterns, borders, and cross-hatches used by those styles 3438are ignored. When multiple styles are used for a layer type, the PNM 3439output blends the base color of each of those styles. Thus, contact 3440areas by default tend to show up completely black, as the ``X'' pattern 3441is usually defined as black, and black blended with other colors 3442remains black. This is why the above example re-defines all of the 3443contact types as mapped type blends. Contact cuts are not represented, 3444which is generally desired if the plot being made represents a large 3445area of layout. 3446 3447Unlike the PostScript section, the PNM plot section does {\itshape not} 3448have to be declared. Magic will set up a default style for PNM plots 3449that matches (more or less) the colors of the layout as specified by 3450the {\bfseries styles} section of the technology file. The {\bfseries 3451plot pnm} section can be used to tweak this default setup. Normally 3452this is not necessary. The default setup is helpful in that it allows 3453the {\bfseries plot pnm} command to be used with all technology files, 3454including those written before the {\itshape plot pnm} command option 3455was implemented. 3456 3457\section{Conditionals, File Inclusions, and Macro Definitions} 3458 3459The ``raw'' technology files in the {\bfseries scmos} subdirectory of 3460the Magic distribution were written for a C preprocessor and cannot be 3461read directly by Magic. The C preprocessor must first be used 3462to eliminate comments and expand macros in a technology file before it gets 3463installed, which is done during the ``{\bfseries make install}'' step when 3464compiling and installing Magic from source. 3465Macro definitions can be made with the preprocessor {\bfseries \#define} 3466statement, and ``conditional compilation'' can be specified using 3467{\bfseries \#ifdef}. Also, the technology file can be split into parts 3468using the {\bfseries \#include} statement to read in different parts 3469of the files. 3470However, this has for the most part proven to be a poor method for 3471maintaining technology files. End-users often end up making modifications 3472to the technology files for one purpose or another. They should not 3473need to be making changes to the source code distribution, they often 3474do not have write access to the source distribution, and furthermore, 3475the elimination of comments and macros from the file makes the actual 3476technology file used difficult to read and understand. 3477 3478Technology file formats more recent that 27 include several built-in 3479mechanisms that take the place of preprocessor statements, and allow 3480the technology file source to be directly edited without the need to 3481re-process. This includes the {\bfseries include} statement, which may 3482be used anywhere in the technology file, the {\bfseries alias} statement 3483in the {\bfseries types} section, and the {\bfseries variant} statement, 3484which may be used in the {\bfseries cifoutput}, {\bfseries cifinput}, 3485or {\bfseries extract} sections. The {\bfseries alias} statements 3486appear in the {\bfseries types} section, covered above. The {\bfseries 3487include} statement may appear anywhere in the file, and takes the form 3488 3489\starti 3490 \ii {\bfseries include} {\itshape filename} 3491\endi 3492 3493Assuming that the included files exist in the search path Magic uses 3494for finding system files (see command {\bfseries path sys}), then no 3495absolute path needs to be speficied for {\itshape filename}. Note 3496that the file contents will be included verbatim; section names and 3497{\bfseries end} statements that appear in the included file should not 3498exist in the file that includes it, and vice versa. 3499 3500%--------------------------------------------------------------------- 3501 3502The most common use of ``\#ifdef'' preprocessor statements in the default 3503``scmos'' technology is to selectively define different cifoutput, 3504cifinput, and extract files for process variants. The result is that 3505these sections become quite large and repeat many definitions that are 3506common to all process variations. Technology file format 30 defines 3507the {\bfseries variants} option to the {\bfseries style} statement for 3508all three sections {\bfseries cifinput}, {\bfseries cifoutput}, and 3509{\bfseries extract}. This statment option takes the form: 3510 3511\starti 3512 \ii {\bfseries style} {\itshape stylename} {\bfseries variants} {\itshape 3513 variantname,\dots} 3514\endi 3515 3516where {\itshape stylename} is a base name used for all variants, and one 3517of the comma-separated list of {\itshape variantname}s is a suffix appended 3518to the {\itshape stylename} to get the actual name as it would be used in, 3519for example, a {\bfseries cif ostyle} command. For example, the statement 3520 3521\starti 3522 \ii {\bfseries style scmos0.18 variants (p),(c),(pc),()} 3523\endi 3524 3525defines four similar styles named {\bfseries scmos0.18(p)}, 3526{\bfseries scmos0.18(c)}, {\bfseries scmos0.18(pc)}, and 3527{\bfseries scmos0.18()}. All of the variants are assumed to be 3528minor variations on the base style. Within each style description, 3529statements may apply to a single variant, a group of variants, or 3530all variants. After the {\bfseries style} statement has been 3531processed, all following lines are assumed to refer to all variants 3532of the base style until a {\bfseries variant} statment is encountered. 3533This statment takes the form: 3534 3535\starti 3536 \ii {\bfseries variant} {\itshape variantname,\dots} 3537\endi 3538 3539to refer to one or more variants in a comma-separated list. All lines 3540following the {\bfseries variant} statment will apply only to the 3541specific process variants in the list, until another {\bfseries variant} 3542statement is encountered. The special character ``{\bfseries *}'' can 3543be used as a shorthand notation for specifying all process variants: 3544 3545\starti 3546 \ii {\bfseries variant *} 3547\endi 3548 3549\end{document} 3550