[Cyan]<DATools6.1>CDDoc23>ChipNDaleToolsDoc.tioga!3

ChipNDaleToolsDoc.tioga

last edited by: Christian Jacobi March 24, 1986 11:29:59 am PST

gbb May 15, 1986 11:22:32 am PDT

Last Edited by: Jacobi June 3, 1986 11:03:08 am PDT

Last Edited by: Christian Jacobi, August 7, 1986 11:04:21 am PDT

ChipNDaleTOOLS 2.3

ChipNDaleTOOLS 2.3 — FOR INTERNAL XEROX USE ONLY

ChipNDale 2.3

An interactive editor for VLSI designs

Some additional tools

Release 2.3

Ch. Jacobi, (with entries from Kim Rachmeler, Jim Gasbarro, Mark Shand, Ed McCreight, George Bier, Giordano Beretta) et al. (August 7, 1986)

A relatively incomplete documentation.

Filed on: [DATools]<DATools6.1>CDDoc23>ChipNDaleToolsDoc.tioga

Abstract: ChipNDale, is an interactive graphic layout tool made to run in Cedar. ChipNDale makes use of multiple windows, extensive parallel processing, vast amounts of memory, pop-up menus, and other assorted goodies. When complete, ChipNDale will have a DRC and circuit extractor, a fast set of IO and checkplot routines, and modular device extensibility. What's more, everything in ChipNDale will be completely technology independent, that is, all the features will be equally at home dealing with PC boards or CMOS chips.

This document document tells the designer about additional tools, like generating checkplots, masks, CIF output

XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304

For Internal Xerox Use Only

0. Contents

1. General programs to run in ChipNDale

2. Design rule checking

2a. Design rule checking with Spinifex

2b. Design rule checking in background

3. Generating CIF files

4. Plotting in PD format

5. Plotting Interpress files

6. Recognizing primitive objects

7. Removing Overlapping Wires

8. Generating Labels

9. Counting features

10. Reading CIF Files

11. Read and write of Chipmonk files

12. Chipmonk compatible colors

13. Generating Program Text

14. Generating MEBES files

15. ColorTool: Changing the Color Map

Some further tools have a separate documentation; This documentation can not be complete about all the further tools, nevertheless some can be named:

CDFlatCif

CDVPlot

CDPressPlot

Generating Labels on top of texts

1. General programs to run in ChipNDale

Abort the program: <ESC><DEL> aborts most programs; all programs should listen; most really do.

The Program menu: <SPACE>-<P> shows a menu of Programs to run.

The rect program menu: <SHIFT>-<P>-middle shows also a menu of programs to run. The command allows you first to drag a rectangular area; This area is provided the program as a parameter.

The Other program menu: <SPACE>-<O> shows a menu of Other programs to run.

The Hard copy menu: <mouse>-<H> shows a menu where most hard copy programs register their commands.

Usually programs must be started first, only thereafter they register their commands. However some very basic programs may have tiptable entries of their own.

2. Design rule checking

There are several design rule check programs for ChipNDale. None of them is the really ultimate design rule checker. A cautious designer should run all of them, maybe with exception of the background checker.

Spinifex: The real, hierarchical design rule checker. Checks most rules.

CDBackgroundCheck: A simplistic, flat checker which can run in parallel with designing.

Gismo: A collection of simple checkers. Gismo is intended to be a simple collection of single tests, which can not be included easily into Spinifex or SoS. See separate documentation.

SoS: Another design rule checker, on some higher level than mask geometry. See separate documentation.

2a. Design rule checking with Spinifex

DF File: /DATools/DATools6.1/Top/Spinifex23.df

Start program: use drc pop up menu <space-k> (or <k-middle>)

DRC/Extraction

(contributed by Mark Shand et al.)

Spinifex - the ChipNDale DRC/Extraction Package

August 9, 1984

DF file: /DATools/DATools6.1/Top/Spinifex23.df

Documentation: SpinifexDoc.tioga (in DF file)

Maintainer:

The Spinifex DRC/Extraction Package is ready for use by ChipNDale designs. What follows is a list of problem areas a new user may encounter, for more details see the documentation.

1) The design rules are not 100% complete, this is particularly true of rules with regard to well contacts (though Spinifex does insist that wells are connected to by one and only one node) and via flatness. Gismo contains tools that close the gap.

2) The .thy files produced require some hand editing.

3) Aliases for signal names are not handled fully, currently one name is chosen and a comment is insert in the .thy file indicating the choices which were available to Spinifex.

4) Strays are fairly accurate but there could be bugs in this computation (if there are it is only a few percent error).

5) When Spinifex extracts Thyme for a transistor it includes the poly from the gate in the gate's stray statement. The gate poly should be omitted from the stray statement since its effects are usually included in the transistor models already. The capacitance and resistance from the gates are negligible with respect to the imprecision of the model, hence it does not matter if the poly from the gates is included or not. The reason Spinifex includes the poly in the gate's stray statement is to handle correctly sets of transistors in series gate to gate.

Spinifex/HighlightNode - highlighting electrically connected regions.

August 9, 1984

Spinifex has the ability to interactively highlight electrical nodes the command is invoked by MiddleDown WHILE Slash. If material on the current layer is found at the point indicated and it is part of a cell which has been previously extracted then all regions electrically connected to that region have boxes on the ChipNDale shadeLayer layer laid over them. Be warned that shading does not extend to material in cells which have not been analyzed or above the current pushed in level.

The ChipNDale program menu also contains a command to highlight a node by specifying a coordinate pair as it can be found in the .thy file after setting SXOutputImplA.printLocalNodeLocation ← TRUE with the interpreter.

How to show at error messages

Use the push by name command to push into the cell with the error. (Space-C for the cell menu)

The "next" key together with left, right, or CTRL will select an error message and zoom in to that error message. (Right; the left and right mouse keys behave just like usual, they make an exclusive or an inclusive selection)

Useful atoms

$Export: If an object has a property with this key and if the value is $TRUE and the cell is at the root of analysis, then the signal name of the node with this property is used as a parameter (port).

$SXCrystal: If a transistor has this property, then its rope value is placed in the Thyme parameter list preceded by a semicolon.

$SpinifexCircuitDescription: for CDPropTool [used to attach a Rope.ROPE to a ChipNDale cell which contains the rosemary structural description of a cell].

$Opaque: believed to prevent Spinifex from looking inside an object. The code to implement it was not found yet at the time of writing.

2b. Design rule checking in background

DF File: /DATools/DATools6.1/Top/CDBackgroundCheck23.df

Start program: use drc menu

The background checker is a very simplistic distance checker which can run in the background. It is enabled or disabled on a per viwer basis with the program menu. It restricts itself to the area of the design which is visible in the viewer you are working. To get reasonable speed it also is restricted to scales which really show features large enough to edit.

3. Generating Hierarchical CIF files

DF File: /DATools/DATools6.1/Top/CDCifGen23.DF

Start program: CDCMosACIF.cm
or CDCMosBCIF.cm
or CDNMosCIF.cm
or look in the DF file what command files are available.

Execute: use program menu (Space-P)

CIF output of the whole design is generated, not only of the selection.

A command file installs the relationship between ChipNDale layers and CIF layers. This command file also specifies the value of lambda and which layers should be compensated and by what amount. (The mask may be grown or shrink. Layers which are shrinked before CIF generation are flattened, to ensure connectivity in spite of shrink.) Please do check the command file if the right CIF layer names and bloats are used.

These command files can be easily edited. If you want to edit the command file, ase the existing command files as examples. Make sure you create a new file and that the new file has a key assigned. This key is necessary to tell the designer what commandfile is run last, so he knows he is generating the right kind of CIF. When editing the command file such that not all layers generate CIF, it is necessary to remove the CIF layer name from the layer, otherwise a previosly installed CIF layer name might be used.

Special problem for CMos: The P+ needs an implant which is larger. But the P+implant may not grow to close to N+. This can not be checked by the simple hierachical CIF generation program. To make sure the P+implant is not grown excessively, a design rule check whether N+ is close to P+ should be performed. (At this time spinifex does not do this check; For N+ and P+ of the same node this check would be overly conservative). The construct "split contact" is predefined such that the P+ - N+ division really is in the right place. (This macro must not be used for different values of lambda or for different compensation). The command file contains a prepared CIF macro for the split contacts. The CIF generation program will include the prepared CIF macros instead of generating new ones for as it is set up.

The ChipNDale authors do NOT consider it a good approach to create already compensated CIF. It would be more reasonable to use uncompensated values to exchange layouts and to do the compensation on the mask generation step. Unhappily the old MPC software wants compensated CIF.

Format:

The hierarchical CIF generation program creates standard Mead and Conway CIF with the following additional commands:

9 alphanumericName;

AFTER the DS lines for name of cells

94 alphanumericName point layerName;

arbitrary number of signal names, BEFORE the DF line.

4. Plotting in PD format

DF File: /DATools/DATools6.1/Top/CDPDPlot23.df

Commands: Use the hard copy menu. (H-mouse)

This is the plot program which allows full colors, overlaps, and huge designs. However, it is a little clumsy on non manhatten features.

Plot any portion of the design by selecting an area using a mouse button with 'H' held down. There will be lots of questions with pop up menus, but answering them should be obvious.

As the PD file is being generated, a '.' will be printed for every horizontal band as it is completed. An arrow will travel down the screen indicating the current band under consideration; the phrase "finished plot(s)" indicates that all strips have been done.

Now you have a PD file resident on your local disk which must be transferred to the device. Read the separate section, or, you should have told the plot program to do it automaticaly

There is one special command which can plot to any device which can be set up using a command file. See the df file to find examples of these command files. This is usefull for setting up special colors, making color separation or specifying exact scale factors.

Supported devices

Versatec color plotter: may use 1 or multiple stripes
C150: 1 stripe only
C400: 1 stripe only
ANY set up from command file

Restriction:

Objects will be rendered to a bitmap in ChipNDale units.

Sending PD files to a Peach print server (Printing the PD file)

The Peach interface allows to chat directly to servers for plotting PD files. Plot requests are spooled and serviced in serial order.
Peach is a generally available package which has its own documentation stored on /Indigo/peach/documentation/peachdoc.tioga. We cover it here only very briefly

The Peach package requires that your machine is running STPServer. [% STPServer on]
Use chat to interface the plot server. [% chat <server name>]

In the chat viewer type

>> Print <filename> <optional #copies> <optional title>

where the filename is [name of machine]<Cedar>subdirectory>filename.pd.

Available plot (Peach) servers in CSL

Versatec color plotter

name: "Sleepy" Completed plots are cut off each night and left for pick-up on a table in the Purple Lab. Users are strongly discouraged from cutting off their own plots. (It is fairly difficult to install the paper properly such that the next user gets good registration on his/her plot.)

Ink Jet, C150

Thermal printer, C400

5. Plotting Interpress files

DF File: /DATools/DATools6.1/Top/CDInterpressPlot23.DF

Commands: Use the hard copy menu.
(Draw a rectangle with the mouse, holding H down)

Interpress does not yet know about the overlapping colors of ChipNDale.

Interactive options for single page, multi pages, or stripes (versatec plotter)

Interactive options for plotting a particular rectangle or the whole design.

Interactive options for a font substitution file. Default substitution file is the file CDSubstituteFonts.SubstituteFonts.

6. Recognizing primitive objects

DF File: /DATools/DATools6.1/Top/CDRecognizer23.df

Start program: CMosRecognizer

NMosRecognizer

Execute: Use the Program menu

Recognizer will replace drawn transistors and contacts with the corresponding ChipNDale primitive. It is particularly useful for ReadCif designs since ReadCif does not know about ChipNDale transistors etc. From the program menu two choices for invocation of the command exist: "Recognize All" will traverse the hiearchy of the design finding transistors throughout the whole design and "Recognize Top" which will only search the top level of the design.

7. Removing Overlapping Wires

DF File: /DATools/DATools6.1/Top/CDOverlapRemover23.df

Start program: CMosCifOverlap

Execute: Use the Program menu

CMosCifOverlap finds all wires of type ndif that lie completely on top of wires of type pdif and removes the ndif wire from the design. Its most probable use is after reading in a design using XeroxCmosCif. Currently when reading in a design using XeroxCmosCif, all rects of type pdif in CIF are given a ChipNDale representation of both an ndif and pdif wire. CMosCifOverlap can be used to remove the ndif.

OverlapRemover is a general tool that takes two layers, a keepLayer and a throwAwayLayer, and whenever a wire of type throwAwayLayer is found that lies completely on keepLayer, then the throwAwaLayer wire is thrown away. An example of how to register the layers can be found in /DATools/DATools6.1/CDOverlapRemover22/CMosCifOverlapImpl.mesa

8. Generating Labels

DF File: /DATools/DATools6.1/Top/CDLabel22.DF

Start program: CDLabels

Commands: Use the rect-program-menu.

Restriction: TiogaFonts only

Command asks for a font name, a scaling factor and a text. (use a .strike or .ks font)

A cell for the label is created included into the design. It uses the current layer for the material of the cell.

The program tries to re-use characters made before; It uses their cell name; renaming of characters should therefore be done carefully or not at all.

It might be a good idea to make a special file containing the labels and importing them. Labels consist of surprisingly many rectangles, which do not always need be read or written.

To reduce the count of rectangles it is good to use a small font and a big scale factor.

Fonts are supposed to be stored on []<>Fonts>...

Example: Helvetica8 is stored (Cedar standard!) on []<>Fonts>Xerox>TiogaFonts>Helvetica8.ks

but it must be accessed using the name: Xerox/TiogaFonts/Helvetica8

9. Counting features

DF File: /DATools/DATools6.1/Top/CDCounting23.df

Counting all the (flat) rectangles of a design

Start program: run CDCountCommands

Command: Use program menu.

Counting static features of all designs

This is more of a debug tool than real user stuff.

Start program: run SweepCollectableStorageImpl CDCount

Commands: CDCount (to the command-tool)

Command will analyze all of the virtual memory and write how many Applications, Objects, Cells and Designs are stored totally.

10. Reading CIF Files

DF File: /DATools/DATools6.1/Top/ReadCif23.df

Start program: XeroxNmosCif, XeroxCmosCif, MosisCmosCif, StanfordCmosCif, etc.

Commands: ReadCif <filename>(.cif)

Maintainer: Jim <Gasbarro.pa>

ReadCif is a package for reading cif format files. It implements all of the cif primitives defined in Mead and Conway including arbitrary (i.e. non-rectilinear) polygons, wires, flashes, etc. Reading cif files can be complex for several reasons: 1) there is no standard definition for cif layer names and 2) cif files usually represent the mask image rather than the drawn image. ReadCif attempts to deal with these problems by allowing the user to specify in a command file the cif name to associate with a ChipNDale layer and a compensation to apply when drawing the object.

Running ReadCif

ReadCif currently knows about the following technologies: XeroxCmosCif, XeroxNmosCif, MosisCmosCif, StanfordCmosCif, and ChipwichNmosCif. These names are command files which can be run from the Commander to register a particular technology with ChipNDale. These command files register a new command "ReadCif" which is then used to read a cif file. ReadCif defaults the .cif extension if it is not supplied. Examples:

% XeroxCmosCif

% ReadCif Frog.cif

% ReadCif Cow

% StanfordCmosCif

% ReadCif Pig

...etc.

Making a new command file

The best way to make a new technology command file is to start with an existing one. ReadCif19.df contains several. Pick the one which is closest to you application.

The first line of the command file insures that the ChipNDale technology you expect to use is loaded. Currently this can either be CDCmos or CDNmos. ReadCif has to register a ChipNDale technology type when it creates a new design. It selects the technology type based upon the first character of the first layer command in the cif file. For example if the fist layer command is:

L ND;

ReadCif will create the design using ChipNDale Nmos technology. Similarly, for the cif command:

L CNW;

ReadCif will create a design using ChipNDale Cmos technology.

A layer is registered with ChipNDale by issuing an interpreter command of the form:

← %CDProperties.PutPropOnLevel[onto: %CMos.met2, prop: $CDxCIFName, val: "CM2"]

This associates the cif layer name CM2 with ChipNDale layer %CMos.met2 which is really just second layer metal. A more complicated registration would be:

← %CDProperties.PutPropOnLevel[onto: %CMos.nwel, prop: $CDxCIFName, val: NEW[%CIFIntPhase2.CIFDestRec ← [cifDest: "CNW", deltaRadius: -4000 -- nm --]]]

This associates cif layer name CNW with ChipNDale layer %CMos.nwel and in addition causes ReadCif to bloat the geometry by 4 microns (the sign of the transformation indicates the change in size when the cif file was generated, this is for compatibility with BrandyCIFter). Mask compensation is done in a simple-minded manner; rectangles that were touching before compensation may end up disjoint, so be careful when using compensation.

If a layer command is specified in the cif file, but no such layer is registered with ReadCif then a warning message is printed on the terminal and all future objects on that layer are discarded. This allows extra layers (such as implant masks associated with diffusions) to be thrown away intentionally.

It is strongly recommended that each command file register some cif layer name with every ChipNDale layer. This prevents interference from previously run command files. To find out the valid ChipNDale layers for a particular technology, look in the file:

/Indigo/ChipNDale/©©/CD@©/<technology>.mesa
e.g. /Indigo/ChipNDale/6.1/CDCMos22/Cmos.mesa.

11. Read and write of Chipmonk files

DF File: /DATools/DATools6.1/Top/cdcmosa23.DF

/DATools/DATools6.1/Top/cdnmos23.DF

Start program: CDReadCmCmos or CDReadCmNmos have load files to run the programs

Commands:
CDReadCmCmos for input
CDReadCmNmos for input
Use the IO menu for entry chipmonk output.

CDReadCMNMOS, CDReadCMCMOS {optional filename}

If the filename is not specified, ChipNDale will query for one.

(The crazy names stand for

ChipNDaleReadChipMonkNMOS and

ChipNDaleReadChipMonkCMOS)

Commands: CDReadCmCmos for input
CDReadCmNmos for input
Use the IO menu for entry Chipmonk output.

When reading Chipmonk files, it is important to know the technology associated with that design so that you use the correct form of the read command. The Chipmonk files do not contain the ChipNDale technology.

The IO pop-up menu allows to create backwards compatible chipmonk output. (.chip file). This command is restricted to CMOS and NMOS IC designs. Try to avoid switching between the Chipmonk and ChipNDale worlds frequently; on every transfer you may loose some information. Not all ChipNDale features can be written onto Chipmonk compatible files. Not all Chipmonk representation of objects can be represented in ChipNDale, mainly those which can not be fabricated safely are excluded.

The commands to read and write Chipmonk files are in seperate configs and loaded on demand only.

12. Chipmonk compatible colors

A program exists which enables ChipNDale to read the color map description and the color pattern description files of Chipmonk. These commands are active only while a 4-bit per pixel device is used for display. (The general ChipNDale command CDColor allows you setting of 4 bit per pixel mode.)

DF File: /DATools/DATools6.1/Top/CDCMosA23.DF
/DATools/DATools6.1/Top/CDNMos23.DF

Start program: run ChipmonkColors

Commands:

CDColorMap {optional filename} {optional number}

This command allows to set up Chipmonk compatible colors. Ask for a colormap number and sets up the colormap. n>0 is an entry from a colormap file. A filename allows to read another colormap file. If no parameter appears on the commandline, ChipNDale will query you for a number.

CDPatterns {optional filename} {optional number}

This command allows to set up Chipmonk compatible colors. Ask for a pattern number, changes NMOS and CMOS to use this number to represent color patterns. 1 means Chipmonk's default patterns, n>1 is the entry on a pattern file. A filename allows to read another color pattern file. If no parameter appears on the commandline, ChipNDale will query you for a number.

It also implements some entries in the <SPACE>-B pop up menu

User profile entries

--The following color map and pattern entries are interpreted by the ChipmonkColors program.

ChipNDale.ChipmonkColorMaps: " ... default.CDColorMaps"

-- better use a full path name

ChipNDale.ChipmonkColorMapNum: -1

-- in four bits per pixel mode only

-- <0 use default colormap

-- 0 use default colormap, but read in the colormap file

-- >0 use a colormap from the ChipmonkColorMaps file as in profile

-- better use a full path name

ChipNDale.ChipmonkColorPatterns: " ... default.CDColorPatterns"

-- NMOS and CMOS only

-- better use a full path name

ChipNDale.ChipmonkColorPatternNum: 0

-- currently cmos only

-- <0 use entry from ChipmonkColorPatterns file

-- with positionkey = ABS[ChipmonkColorPatternNum]

-- (to get positionkey -0 use 1)

-- 0 use default colorpatterns

-- 1 use chipmonks default colorpatterns

-- >1 use entry from ChipmonkColorPatterns file

13. Generating Program Text

DF File: /DATools/DATools6.1/Top/CDMakeProc23.DF

Commands: Use the program menu and select "make text"

The command generates a file (and a viewer) with a program text. This program will generate the selected object... Of course you have to compile and run the program first.

There is no guarantee that the generated program will run with any other ChipNDale version than the one used to generate it. It might be more work to transfer source text to a newer ChipNDale version, than to transfer the .dale file.

Not all ChipNDale features are handled for the program; Give it a try, look if the command generates a program powerful enough, or, if not, you have bad luck.

I do not intend to do any AI to get an optimal program...

14. Generating MEBES files

DF File: /DATools/DATools6.1/Top/CDMEBES23.DF

Start program: CDMEBESForMPC55.load or similar (see below)

Commands: Use the program menu and select "MEBES mask generation"

By: Ed <McCreight.pa>

This utility does two things. The first is to generate a set of MEBES Mode I/II pattern files from which the mask tooling for a design can be generated by a mask house. Along with these pattern files the utility generates an "archive tape header" file that must be written as the first file on a magnetic tape containing the pattern files. All of these files are put into a subdirectory specified by the $CDMEBESMaskSetName property of the design, and the entire subdirectory should be written by the TapeTool onto a tape. The important TapeTool parameters are 1600 bpi and 2048-character blocks.

The other function of this utility is to measure various mask areas, perimiters, lengths of minimum-width coverage and space, etc. These numbers, together with yield measurements of process monitor test structures, can be used by a foundry to predict fabrication yield.

Now for the parameters. The first is the variable CDMEBES.stripesPerClump, which controls a space-time tradeoff inside the package. It should be set to the largest positive integer value that does not induce thrashing. The default value is 10, which is fine for simple designs, but for the most complex designs it may have to be set as low as 2. One day I might automate this setting...

Another group of numeric parameters, measured in nanometers, are registered as properties of the technology. The values of these parameters are REF INT's, or more suggestive, REF CDMEBES.Nm. The first parameter, $CDMEBESNmPerLambda, gives the multiplicative scale factor that relates CD.lambda to nanometers on the mask. The second, $CDMEBESNmPerEBESPixel, gives the nominal MEBES pixel size in nanometers. As of this writing there are only two useful values for this second parameter: 500 and 250. This parameter must be uniform over an entire wafer, and we are using the value 500 for technologies with two-micron minimum feature sizes (it's considerably less expensive than 250). Notice that the MEBES pixel size constrains the reasonable choice of NmPerLambda: all positions and feature sizes must resolve to integral pixels.

The next two numeric parameters, $CDMEBESXNmPerDie and $CDMEBESYNmPerDie, describe the final die size, including a half-scribe-line perimeter if appropriate. CDMEBES will center the design within this die. It's not smart enough to try rotating the design if it won't fit; you have to do that yourself. The next parameter, $CDMEBESActiveToScribeCenter, describes the minimum spacing from any design-generated mask feature to the edge of the die (meaning the outer edge of the half-scribe-line). The final parameter, $CDMEBESNmMaxBloat, is at least as large as the maximum diameter by which any ChipNDale layer in this technology enlarges to produce a mask feature.

The next parameter is the seven-character ROPE mask set name. It should be registered as the $CDMEBESMaskSetName property of the design, but there is also a default name registered as the same property of the atom $MEBESMask. A typical mask set name would be "MPC55AW", meaning Xerox MPC series, run 55, wafer A, die W.

The final parameter specifies the set of masks to be generated. It is registered as the $CDMEBESMaskSetSpec property of the technology, and its value is a LIST OF REF ANY. Each element of this list must be either a CDMEBES.MaskSpec or a CDMEBES.CoverSpec.

If a mask m is specified as a CDMEBES.MaskSpec ( = REF CDMEBES.MaskSpecRec[ name: ROPE -- a two character decimal number -- , cover: CDMEBES.CoverSpec ] ), real pattern files sufficient to cover the die will be generated, and their names will like ///MPC55AW/MPC55AW10.AA, ///MPC55AW/MPC55AW10.AB, ///MPC55AW/MPC55AW10.AC, ..., ///MPC55AW/MPC55AW10.BA, ///MPC55AW/MPC55AW10.BB, ..., where MPC55AW is the mask set name of the design, and "10" is the two-character ROPE m.name of the mask layer being generated. Usually one pattern file is sufficient to cover a die, but for large dice a regular array of pattern files (whose row and column are indicated in the filename suffix) is generated. In the latter case, that is, if a mask is specified as a CDMEBES.CoverSpec, then no pattern files are generated.

If a mask is simply specified as a CDMEBES.CoverSpec, it is computed and then discarded. This behavior is useful mainly if CoverSpec is an analysis function like $MeasureRuns.

A CDMEBES.CoverSpec is one of the following:

Boolean combinations

LIST[$NOT, CDMEBES.CoverSpec]

LIST[$AND, CDMEBES.CoverSpec, CDMEBES.CoverSpec, ...]

LIST[$OR, CDMEBES.CoverSpec, CDMEBES.CoverSpec, ...]

LIST[$ANDNOT, CDMEBES.CoverSpec, CDMEBES.CoverSpec]

Complex functional combinations

CDMEBES.Enlarge

= REF CDMEBES.EnlargeRec[basis: CDMEBES.CoverSpec, deltaDiameter: CDMEBES.Nm ← 0]

LIST[$RestrictNImplant, maxGrowth: REF CDMEBES.Nm, ndif: CDMEBES.CoverSpec, pdif: CDMEBES.CoverSpec]

... others as needed

Complex analysis specifications

LIST[$MeasureRuns, maxCoverInterest: REF CDMEBES.MEBESPixels, minCoverFeature: REF CDMEBES.MEBESPixels, maxSpaceInterest: REF CDMEBES.MEBESPixels, minSpaceFeature: REF CDMEBES.MEBESPixels, geom: CDMEBES.CoverSpec ]

.. this computes geom and then measures its area and perimeter. It also produces a table of lengths for various feature widths (in MEBES pixels up to maxInterest), and complains about features smaller than minFeature, separately for areas covered by geom and spaces in between.

Basic

CDMEBES.CDLayer

= REF CDMEBES.CDLayerRec[source: CD.Layer, deltaDiameter: CDMEBES.Nm ← 0]

CDMEBES.Scribe

= REF CDMEBES.ScribeRec[dieEdgeToLineCenter, lineWidth: CDMEBES.Nm ← 0]

For further examples of parameters, see the files CDMEBESForMPC55.load and CDMebesAnalyze.load.

15. ColorTool: Changing the Color Map

Available for NMos, CMos-A, CMos-B

DF Files: included in the technologies df files

Start program: NMos8BitColors
or CMosA8BitColors
or CMosB8BitColors

These ColorTools create a button. Hitting the button with the left mouse key (when no color tool viewer is open) will set up the appropriate colors. Using the middle key will open a tool viewer. Once a tool viewer is open, the colors can be edited interactively.

The color tool viewer:

The left side of the tool viewer shows layer buttons and intensity sliders. The right part shows rgb sliders. In the middle are some buttons.

Layer buttons: select which layer is edited with the rgb sliders.

Intensity sliders: select intensity (transparency) of a layer.

rgb sliders: select rgb value of selected layer.

Trying it is much easier than to understand the description, which is incomplete anyway. Don't change colors to quickly; changeing the colormap causes lots of recomputations inside the cedar system. Use the standard command tool command "ColorMap -create filename" to create a color map file which you want be able to reuse.

It is best to use your user profile to set up initial values for the color tools.