[Cyan]<DATools6.1>CDDoc24>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, December 9, 1986 2:03:58 pm PST

McCreight April 29, 1987 7:13:38 pm PDT

ChipNDaleTOOLS 2.4

ChipNDaleTOOLS 2.4 — FOR INTERNAL XEROX USE ONLY

ChipNDale 2.4

An interactive editor for VLSI designs

Some additional tools

Release 2.4

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

A relatively incomplete documentation.

Filed on: [DATools]<DATools6.1>CDDoc24>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. Empty [program will not be converted to cd2.4]

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/Spinifex24.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/Spinifex24.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/CDBackgroundCheck24.df

Start program: use drc menu <space-k>

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/CDCifGen24.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/CDPDPlot24.df

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

This is the plot program which allows full colors, overlaps, and huge designs.

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/CDInterpressPlot24.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.

6. Recognizing primitive objects

NOT YET CONVERTED TO 2.4

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

NOT YET CONVERTED TO 2.4

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/CDLabel24.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/CDCounting24.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

NOT YET CONVERTED TO 2.4

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:

11. Read and write of Chipmonk files

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

/DATools/DATools6.1/Top/cdnmos24.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.

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/CDMEBES24.DF

Start program: MEBESConvert30Apr87CMOSBDesign.cm or similar (see below)

By: Ed <McCreight.pa>

This utility does two things. The first is to generate a set of MEBES Mode I/II or Reticle Mode pattern files from which the mask tooling for a design can be generated by a mask house. These pattern files are are put into the subdirectory specified by the $CDMEBESMaskSetName property of the design. A companion utility, MEBESPAMLabel, generates an "archive tape header" file based on reading the pattern files. All of these files should then be written by the Cedar 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, perimeters, 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 integer 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.

Another parameter is the ROPE variable CDMEBES.wDir, which specifies the subdirectory where the MEBES files should be put. The default is "///MEBES".

Another group of numeric parameters, measured in nanometers, are registered as properties of the ChipNDale technology, like CMosB.cmosB. The values of these parameters are REF INT's, or more suggestive, REF CDMEBES.Nm. The first parameter, $CDMEBESNmPerLambda, gives the scale factor that relates the design's CD.lambda to nanometers on the mask.

The next two technology properties, $CDMEBESNmDieSizeX and $CDMEBESNmDieSizeY, are REF INT's that are either nanometers or NIL, indicating that the size is to be computed by measuring the design. The next technology property, $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 technology property, $CDMEBESNmMaxBloat, is at least as large as the maximum diameter by which any ChipNDale layer in this technology enlarges to produce a mask feature. If the die size is not specified explicitly, the die size is computed as the maximum size of the ChipNDale geometry, plus twice the sum of $CDMEBESActiveToScribeCenter and $CDMEBESNmMaxBloat.

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 XRVTI3A1A.

All MEBES pattern file names are nine alphanumeric characters, followed by a period, followed by two alphanumeric characters. Any alphabetic characters must be upper-case. We customarily use MEBES reticle mode format these days, and the convention for reticle mode is that the nine characters specify the mask set name and the two characters are the two-character numeric mask level identifier. Thus the pattern file for the Metal1 mask in the set above might have the file name XRVTI3A1A.60 .

The next parameter, registered as the $CDMEBESToolingSpec property of the technology, is a property list whose property names are mask name atoms (like $Metal1, for example), and whose matching values are REF CDMEBES.ToolingMaskSpecRec's. A ToolingMaskSpecRec contains six fields: a ROPE identifying the mask level number ("60" in the example above), CL or DK to indicate the field tone of the mask, the pixel pitch of the mask, the mask skew per side, and the width and offset (from scribe line center) of the mask's scribe line. Distances are expressed in nanometers. For VTI's 2-micron double metal CMOS process, the ToolingMaskSpecRec we use today is ["60", CL, 250, 500, 14000, scribeEmptyLaneWidth+6000].

The final parameter, registered as the $CDMEBESMaskSetSpec property of the technology, specifies the set of masks to be generated. Its value is a LIST OF REF CDMEBES.DerivationMaskSpecRec. A DerivationMaskSpecRec contains three fields: a mask name atom ($Metal1 in the example above), a specification of the geometry to cover on that mask (a CDMEBES.CoverSpec), and a property list.

A CDMEBES.CoverSpec is recursively defined as follows:

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

Basic

CDMEBES.CDLayer

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

For further examples of parameters and their use, see the file /Cherry/MPCCIF/6.1/top/XRVTI3X.df and the .cm and .load files that it mentions.

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.