int *parm; char *valueS; FILE *file; Void SetNoisyBool(parm,valueS,file) bool *parm; char *valueS; FILE *file; Void SetNoisyDI(parm,valueS,file) DoubleInt *parm; char *valueS; FILE *file; DESCRIPTION
These procedures interpet a string and set a parameter accordingly. Error messages are printed if the string doesn’t make sense, and in any event the final parameter value is printed. If valueS is NULL, the parame- ter value is not changed. If file is NULL the result is printed with TxPrintf, Magic’s standard print func- tion, otherwise it is printed on the specified file.
SEE ALSO
magicutils (3)
SHOW ( 3 ) CAD Tool User’s Manual SHOW ( 3 )
NAME
show−procedure for displaying rects as feedback, for debugging. printing their values.
SYNOPSIS
Void ShowRect(def, r, style) CellDef *def;
Rect *r; int style;
DESCRIPTION
Highlights the specified area in the specified cell and the specified style. See the Magic garouter module for example uses.
SEE ALSO
magicutils (3)
STACK ( 3 ) CAD Tool User’s Manual STACK ( 3 )
NAME
stack−procedures for managing stacks in libmagicutils.a
SYNOPSIS #include magic.h #include stack.h Stack *StackNew(sincr) int sincr; StackFree(stack) Stack *stack; ClientData StackPop(stack) Stack *stack; ClientData StackLook(stack) Stack *stack; StackPush(arg, stack) ClientData arg; Stack *stack;
StackEnum(stack, func, cdata) Stack *stack;
int (*func)(item, i, cdata) ClientData item, cdata; int i;
StackCopy(src, dest, copystr) Stack *src, **dest; bool copystr; bool StackEmpty(stack) Stack *stack; ClientData STACKPOP(stack) Stack *stack; ClientData STACKLOOK(stack) Stack *stack; STACKPUSH(arg, stack) ClientData arg; Stack *stack; DESCRIPTION
These procedures implement a simple stack mechanism, allowing stacks containing an arbitrary number of one-word elements to be created, manipulated, and destroyed.
StackNew creates and returns a new Stack. This stack grows automatically as new items are pushed on it.
The number of new elements for which space is added each time the stack grows is specified by sincr. When the stack is through being used, StackFree frees it.
Elements can be pushed on the stack using StackPush. The top of the stack can be viewed without remov- ing it by using StackLook, or removed by StackPop. Both return the top element from the stack, or NULL if the stack is empty. Fast macro versions exist for each of these functions: STACKPUSH, STACKLOOK, and STACKPOP. To test whether stack is empty, one can call StackEmpty, which returns TRUE if the stack is empty, or FALSE if it contains any entries.
STACK ( 3 ) CAD Tool User’s Manual STACK ( 3 )
StackEnum visits all the elements in stack without popping them. It applies (*func)() to each element. The
arguments to (*func)() are item, the stack element being visited, i, its index on the stack (1 for the top of the stack, increasing as one moves down the stack), and the same cdata as was passed to StackEnum. If
(*func)() returns a non-zero value, the enumeration of the stack aborts and StackEnum returns 1; otherwise, StackEnum returns 0 after visiting all elements in the stack.
StackCopy is used to make a copy of a stack src. It leaves *dest pointing to the copy. If the parameter copystr is TRUE, then the elements of src are interpreted as pointers to NULL-terminated ASCII strings,
which are copied into newly allocated memory before the address of the new string is stored in *dest; oth- erwise, the elements of src are just copied to *dest.
BUGS
There should be a way of declaring a Stack that pushes or pops more than a single word at a time.
SEE ALSO
magicutils (3)
STRING ( 3 ) CAD Tool User’s Manual STRING ( 3 )
NAME
string−procedures for manipulating strings in libmagicutils.a
SYNOPSIS
#include magic.h #include utils.h
typedef struct { char *d_str; } LookupTable; int Lookup(str, table)
char *str; char *table[];
int LookupStruct(str, table, size) char *str;
LookupTable *table; int size;
int LookupAny(c, table) char c;
char *table[];
int LookupFull(name, table) char *name;
char *table[];
char *StrDup(oldstr, str) char **oldstr, *str;
bool StrIsWhite(str, commentok) char *str;
bool commentok; bool StrIsInt(str) char *str;
bool Match(pattern, string) char *pattern, *string;
char *ArgStr(pargc, pargv, argType) int *pargc;
char ***pargv; char *argType;
DESCRIPTION
This collection of procedures provide a number of useful functions for dealing with strings. Lookup searches a table of strings to find one that matches a given string. It’s useful mostly for command lookup. The table of strings should be terminated with a NULL string pointer, and the entries should be alphabeti- cal and all lower-case. Any characters following the first white space in an entry are ignored. If str is an unambiguous abbreviation for one of the entries in table, then the index of the matching entry is returned. If str is an abbreviation for more than one entry in table, then -1 is returned. If str doesn’t match any entry, then -2 is returned. Case differences are ignored.
LookupStruct is a more general version of Lookup for dealing with tables of structures whose first word is a
string pointer. The table argument should be a pointer to an array of such structures, cast as type
(LookupTable *). The table should be terminated with an entry whose string pointer is NULL. As in Lookup, all entries should contain lower-case strings and should be sorted alphabetically. The size parame-
ter gives the size in bytes of each structure in the table.
STRING ( 3 ) CAD Tool User’s Manual STRING ( 3 )
LookupAny looks up a single character in a table of pointers to strings. The last entry in the string table
must be a NULL pointer. The index of the first string in the table containing the indicated character is returned, or -1 if no matching string is found.
LookupFull is like Lookup, but does not allow abbreviations. It either returns the index of the entry of table
matching str, or -1 if no match is found. Case is significant, and entries are considered to extend all the way to their trailing NULL byte, instead of being terminated by the first white space as in Lookup.
StrDup can be used to replace an old string with a new one, freeing the storage for the old one and allocat-
ing sufficient storage for the new one. It returns a pointer to a newly allocated character array just large enough to hold str and its trailing NULL byte. This newly allocated array contains a copy of str. How- ever, if str is NULL, no memory is allocated and we return NULL. If oldstr is non-NULL, then if *oldstr is non-NULL, StrDup frees the storage pointed to by *oldstr. StrDup then sets *oldstr to point to the new array of memory just allocated, or NULL if str was NULL.
StrIsWhite returns TRUE if str is all white space, or FALSE otherwise. If commentok is TRUE, then if the
first non-white character in str is a pound-sign (‘‘#’’), str is considered to be all white space.
StrIsInt returns TRUE if str is a well-formed decimal integer, or FALSE if it isn’t.
Match provides a csh (1)-like wild-card matching facility. The string pattern may contain any of the csh
wildcard characters: *, ?, \, [, and ]. If pattern matches string, Match returns TRUE; otherwise, it returns FALSE.
ArgStr is provided to allow standard processing of command-line arguments that take parameters. It recog-
nizes flag-value pairs of either the form ‘‘−−Xvalue’’ (a single argument string) or ‘‘−−X value’’ (two succes-
sive argument strings) in the argument list (*pargc, *pargv), incrementing *pargc and *pargv by an amount sufficient to step over the flag-value pair. If there are no more arguments remaining in the list,
ArgStr prints an error message complaining that argType is required for the flag *pargv[0].
SEE ALSO
magicutils (3)
CMAP ( 5 ) CAD Tool User’s Manual CMAP ( 5 )
NAME
cmap−format of .cmap files (color maps)
DESCRIPTION
Color-map files define the mapping between eight-bit color numbers and red, green and blue intensities used for those numbers. They are read by Magic as part of system startup, and also by the :load and :save commands in color-map windows. Color-map file names usually have the form x.y.z.cmapn, where x is a class of technology files, y is a class of displays, z is a class of monitors, and n is a version number (currently 1). The version number will change in the future if the formap of color-map files ever changes. Normally, x and y correspond to the corresponding parts of a display styles file. For example, the color map file mos.7bit.std.cmap1 is used today for most nMOS and CMOS technology files using displays that support at least seven bits of color per pixel and standard-phosphor monitors. It corresponds to the display styles file mos.7bit.dstyle5.
Color-map files are stored in ASCII form, with each line containing four decimal integers separated by white space. The first three integers are red, green, and blue intensities, and the fourth field is a color number. For current displays the intensities must be integers between 0 and 255. The color numbers must increase from line to line, and the last line must have a color number of 255. The red, green, and blue intensities on the first line are used for all colors from 0 up to and including the color number on that line. For other lines, the intensities on that line are used for all colors starting one color above the color number on the previous line and continuing up and through the color number on the current line. For example, consider the color map below:
255 0 0 2
0 0 255 3
255 255 255 256
This color map indicates that colors 0, 1, and 2 are to be red, color 3 is to be blue, and all other colors are to be white.
SEE ALSO
magic (1), dstyle (5)
DISPLAYS ( 5 ) CAD Tool User’s Manual DISPLAYS ( 5 )
NAME
displays−Display Configuration File
DESCRIPTION
The interactive graphics programs Caesar, Magic, and Gremlin use two separate terminals: a text terminal from which commands are issued, and a color graphics terminal on which graphical output is displayed. These programs use a displays file to associate their text terminal with its corresponding display device. The displays file is an ASCII text file with one line for each text terminal/graphics terminal pair. Each line contains 4 items separated by spaces: the name of the port attached to a text terminal, the name of the port attached to the associated graphics terminal, the phosphor type of the graphics terminal’s monitor, and the type of graphics terminal.
An applications program may use the phosphor type to select a color map tuned to the monitor’s charac- teristics. Only the std phosphor type is supported at UC Berkeley.
The graphics terminal type specifies the device driver a program should use when communicating with its graphics terminal. Magic supports types UCB512, AED1024, and SUN120. Other programs may recog- nize different display types. See the manual entry for your specific application for more information. A sample displays file is:
/dev/ttyi1 /dev/ttyi0 std UCB512
/dev/ttyj0 /dev/ttyj1 std UCB512 /dev/ttyjf /dev/ttyhf std UCB512 /dev/ttyhb /dev/ttyhc std UCB512
/dev/ttyhc /dev/ttyhb std UCB512.in -0.5i
In this example, /dev/ttyi1 connects to a text terminal. An associated UCB512 graphics terminal with stan- dard phosphor is connected to /dev/ttyi0.
FILES
Magic uses the displays file∼cad/lib/displays. Gremlin looks in /usr/local/displays.
SEE ALSO
magic(1)
DLYS ( 5 ) CAD Tool User’s Manual DLYS ( 5 )
NAME
dlys−format of .dlys files read by the SCALD simulator and timing verifier
DESCRIPTION
The SCALD simulator and timing verifier can accept information about the actual delays of wires in a cir- cuit. This delay information is described in a .dlys file, which consists of a sequence of records, one for each electrical net. Each record begins with the signal name for the net (note that this is the SCALD signal name, i.e, the name given by the user to the entire net, and not usually the name of one of the pins in the net), followed by an =, then a comma-separated list of the terminals in the net and their associated delay, with the list terminated by a semicolon. The end of the file is marked with a second semicolon.
The elements of the comma-separated list for each net take the form
location [min:max]
where location is the full hierarchical SCALD name of the physical pin to which the delay is computed, and min and max are the best-case and worst-case wire delay in nanoseconds (both are floating-point numbers). The assumption is that only a single driver exists per net, so all delays are computed from this driver. If a net has multiple drivers, then the interpretation of delays is up to the program reading this file (e.g, min delays are taken from the fastest driver, max from the slowest).
Here is an example .dlys file:
(APS )ALU STATUS BITS I1<0> =
(APS MR 3V6 R1 1P )IN#63[ 0.3 : 0.4 ], (APS APS 4RI RFC RF )OUT[ 0.5 : 0.7 ]; (APS )ALU STATUS BITS I1<1> =
(APS APS 4ALUD DCD )AN#12[ 1.4 : 1.6 ], (APS APS 4ALUD DCD )AN#8[ 1.1 : 1.3 ], (APS APS 4ALUD DCD )AN#9[ 1.1 : 1.3 ], (APS APS 4ALUD DCD )AN#10[ 1.1 : 1.3 ], (APS APS 4ALUD DCD )AN#11[ 1.1 : 1.3 ], (APS MR 3V2 R1 1P )#23 [ 0.6 : 0.8 ], (APS MR 3V6 R1 1P )#62 [ 0.3 : 0.4 ], (APS APS 4ALUD DCD ) [ 0.4 : 0.6 ], (APS APS 4ALUD DCD )#1 [ 0.4 : 0.6 ], (APS APS 4ALUD DCD )#2 [ 0.4 : 0.6 ], (APS APS 4ALUD DCD )#3 [ 0.4 : 0.6 ], (APS APS 4ALUD DCD )#4 [ 0.7 : 0.8 ], (APS APS 4ALUD DCD )#5 [ 0.7 : 0.8 ]; ;
Although it is not good practice, it is possible to omit the actual pin names from the location names and only give the path to the part; the example above shows several cases where the final pin name is missing. Since the timing verifier and simulator have the original SCALD netlist available, they are usually able to use the signal name to determine the net, and then use the part’s path to identify which pin of the net is meant. This is accurate when a net connects to at most one pin per part; if it connects to more than one pin per part then there is ambiguity over which pin is meant. Usually, though, this ambiguity results in only a small inaccuracy, since the delay to different pins on the same part is usually similar. Also, if delay is capacitive, the delay to all pins in a net will be the same anyway, so there is no inaccuracy.
DLYS ( 5 ) CAD Tool User’s Manual DLYS ( 5 )
SEE ALSO
ext2dlys (1), ext (5), sim (5)
BUGS
There should be some way to specify which pins are drivers and which are receivers in a net.
The ability to omit pin names is dangerous; although it usually works it can introduce large inaccuracies when the parts are large compared to the sizes of the wires used to connect them, as might be the case on a silicon PCB.
DSTYLE ( 5 ) CAD Tool User’s Manual DSTYLE ( 5 )
NAME
dstyle−format of .dstyle files (display styles)
DESCRIPTION
Display styles indicate how to render information on a screen. Each style describes one way of rendering information, for example as a solid area in red or as a dotted outline in purple. Different styles correspond to mask layers, highlights, labels, menus, window borders, and so on. See ‘‘Magic Maintainer’s Manual #3: Display Styles, Color Maps, and Glyphs’’ for more information on how the styles are used.
Dstyle files usually have names of the form x.y.dstylen, where x is a class of technologies, y is a class of displays, and n is a version number (currently 5). The version number may increase in the future if the for- mat of dstyle files changes. For example, the display style file mos.7bit.dstyle5 provides all the rendering information for our nMOS and CMOS technologies for color displays with at least 7 bits of color.
Dstyle files are stored in ASCII as a series of lines. Lines beginning with ‘‘#’’ are considered to be com- ments and are ignored. The rest of the lines of the file are divided up into two sections separated by blank lines. There should not be any blank lines within a section.