230 lines
11 KiB
HTML
230 lines
11 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<STYLE type="text/css">
|
|
H1 {color: black }
|
|
H2 {color: maroon }
|
|
H3 {color: #007090 }
|
|
A.head:link {color: #0060a0 }
|
|
A.head:visited {color: #3040c0 }
|
|
A.head:active {color: white }
|
|
A.head:hover {color: yellow }
|
|
A.red:link {color: red }
|
|
A.red:visited {color: maroon }
|
|
A.red:active {color: yellow }
|
|
</STYLE>
|
|
</HEAD>
|
|
<TITLE>Magic-8.3 Command Reference</TITLE>
|
|
<BODY BACKGROUND=graphics/blpaper.gif>
|
|
<H1> <IMG SRC=graphics/magic_title8_3.png ALT="Magic VLSI Layout Tool Version 8.3">
|
|
<IMG SRC=graphics/magic_OGL_sm.gif ALIGN="top" ALT="*"> </H1>
|
|
|
|
<H2>property</H2>
|
|
<HR>
|
|
Attach a "property" (string key and value pair) to the edit cell
|
|
<HR>
|
|
|
|
<H3>Usage:</H3>
|
|
<BLOCKQUOTE>
|
|
<B>property</B> [<I>type</I>] [<I>key</I> [<I>value</I>]] <BR>
|
|
or
|
|
<B>property</B> [<B>compat</B>] [<B>true</B>|<B>false</B>] <BR><BR>
|
|
<BLOCKQUOTE>
|
|
where <I>key</I> and <I>value</I> are any text strings. <BR>
|
|
<I>type</I> may be one of <B>string</B>, <B>integer</B>,
|
|
<B>dimension</B>, or <B>double</B>.
|
|
</BLOCKQUOTE>
|
|
</BLOCKQUOTE>
|
|
|
|
<H3>Summary:</H3>
|
|
<BLOCKQUOTE>
|
|
The <B>property</B> command implements a general-purpose method
|
|
of attaching information to a cell definition. Except for a
|
|
few properties known to the <B>lef</B>, <B>extract</B>, and
|
|
<B>gds</B> commands (q.v.), properties have no inherent meaning
|
|
to magic but may be used with other programs or scripts to add
|
|
additional information about a cell definition. <P>
|
|
|
|
With no arguments, all properties of the current edit cell are
|
|
listed. With only the <I>key</I> argument, the value associated
|
|
with the key is returned. With both arguments, the string
|
|
<I>value</I> is associated with the string <I>key</I> as a
|
|
property of the cell. If <I>key</I> is an existing key, then
|
|
its original value will be overwritten. <P>
|
|
|
|
By default, properties are interpreted as verbatim string values,
|
|
with exceptions for the reserved types (see below). To force the
|
|
values of the property to be interpreted as a specific type, use
|
|
the <I>type</I> option. <P>
|
|
|
|
The <B>property compat</B> setting determines how properties are
|
|
written out to a .mag file. The default setting is <B>true</B>
|
|
(backwards compatibility mode), which writes all properties as
|
|
type "<TT>string</TT>". Properties which are reserved names
|
|
(see below) will be converted to the best type when reading the
|
|
.mag file. However, if the user wants to create a property that
|
|
is handled differently than a string (namely, to be a dimensional
|
|
value that scales), then comptability mode should be turned off. <P>
|
|
</BLOCKQUOTE>
|
|
|
|
<BLOCKQUOTE>
|
|
Types are interpreted as follows:
|
|
<DL>
|
|
<DT> <B>string</B> type:
|
|
<DD> The property value is a character string. Character strings
|
|
may contain spaces, but if so, then the string should be quoted
|
|
or in braces, per Tcl syntax.
|
|
<DT> <B>integer</I> type:
|
|
<DD> The property value is an integer value or a list of integer
|
|
values. The values are not considered to be measurements and
|
|
do not scale. Multiple values may be passed on the command
|
|
line as additional arguments, or the set of values may be
|
|
given as a list.
|
|
<DT> <B>dimension</I> type:
|
|
<DD> The property value is an integer value or a list of integer
|
|
values. The values are considered to be (linear) dimensional
|
|
measurements and therefore scale with the database internal
|
|
units. They are interpreted as having the values currently
|
|
specified for <B>units</B>, and display back in the same
|
|
units. Multiple values may be passed on the command line as
|
|
additional arguments, or the set of values may be given as a
|
|
list.
|
|
<DT> <B>double</I> type:
|
|
<DD> The property value is a double-wide (64-bit) integer value or
|
|
a list of double-wide integer values. The values are not
|
|
considered to be measurements and do not scale. Multiple
|
|
values may be passed on the command line as additional arguments,
|
|
or the set of values may be given as a list.
|
|
</DL>
|
|
</BLOCKQUOTE>
|
|
|
|
<BLOCKQUOTE>
|
|
Property names reserved by and used by magic (types are <B>string</B>
|
|
unless otherwise noted):
|
|
<DL>
|
|
<DT> <B>GDS_FILE</B>
|
|
<DD> The value is the name of a GDS file which contains the mask
|
|
data for the cell. The cell is then effectively an abstract
|
|
view, because its contents are in the GDS file and do not
|
|
necessarily match what is displayed (although they might).
|
|
<DT> <B>GDS_START</B>
|
|
<DD> If a <B>GDS_FILE</B> is defined, then this value indicates the
|
|
byte position of the start of mask data for this cell definition
|
|
in the file. If set to value <B>0</B>, then the file will be
|
|
searched for the data bounds. This property is always of type
|
|
<B>double</B>.
|
|
<DT> <B>GDS_END</B>
|
|
<DD> If a <B>GDS_FILE</B> is defined, then this value indicates the
|
|
byte position of the end of mask data for this cell definition
|
|
in the file. If <B>GDS_START</B> is set to <B>0</B>, then this
|
|
property may be omitted. This property is always of type
|
|
<B>double</B>.
|
|
<DT> <B>LEFview</B>
|
|
<DD> If set to <B>TRUE</B>, this cell is an abstract view such as that
|
|
obtained from a LEF macro, and should not be used for extraction
|
|
or for writing mask data (unless <B>GDS_FILE</B> is defined).
|
|
<DT> <B>LEFproperties</B>
|
|
<DD> If the file was read from a LEF macro, then this property corresponds
|
|
to the LEF <B>PROPERTY</B> block values. All values from the block
|
|
are contatenated into the single property string.
|
|
<DT> <B>LEFsymmetry</B>
|
|
<DD> If the file was read from a LEF macro, then this property corresponds
|
|
to the macro's <B>SYMMETRY</B> value.
|
|
<DT> <B>LEFclass</B>
|
|
<DD> If the file was read from a LEF macro, then this property corresponds
|
|
to the macro's <B>CLASS</B> value.
|
|
<DT> <B>LEFsite</B>
|
|
<DD> If the file was read from a LEF macro, then this property corresponds
|
|
to the macro's <B>SITE</B> value.
|
|
<DT> <B>CIFhier</B>
|
|
<DD> If defined, then this cell will be written to CIF or GDS
|
|
output with hierachical processing regardless of the settings of
|
|
the command options "cif *hier write disable" and "cif *array write
|
|
disable". That allows those commands to be used to avoid
|
|
time-consuming and unnecessary hierarchical processing of a top-level
|
|
chip assembly with mostly correct-by-design components (such as a
|
|
digital standard cell layout) while preserving necessary hierarchical
|
|
processing on blocks (such as analog circuits) that need them.
|
|
<DT> <B>FIXED_BBOX</B>
|
|
<DD> This property value is a space-separated list of four integer values
|
|
corresponding to the abutment box of the cell, in magic's internal
|
|
units. The abutment box is automatically read from LEF files, but
|
|
may be defined for any file and can be used for placement alignment.
|
|
This property is always of type <B>dimension</B> and must contain
|
|
exactly four values.
|
|
<DT> <B>OBS_BBOX</B>
|
|
<DD> This property value is a space-sparated list of four integer values
|
|
corresponding to a bounding box to be used when generating a LEF
|
|
file abstract view of a cell. The area inside the bounding box
|
|
will be entirely covered in obstruction layers (unless cut-outs
|
|
are required to accommodate pins). Any set-back applied by the
|
|
"lef write -hide <value>" option will be applied to this obstruction
|
|
box. This property is always of type <B>dimension</B> and must
|
|
contain exactly four values.
|
|
<DT> <B>flatten</B>
|
|
<DD> This property is used in conjunction with the "flatten -doproperty"
|
|
command option and marks the cell for flattening. Cells without
|
|
this property defined will not be flattened.
|
|
<DT> <B>device</B>
|
|
<DD> This property declares that the cell is a device or contains a
|
|
single device that is not a known extractable device defined in
|
|
the technology file. In the first case, the device to be extracted
|
|
is a subcircuit and the name of the device is the same as the name
|
|
of the cell. In this case, the property value should begin with
|
|
"<B>primitive</B>". This may be followed by any parameters
|
|
associated with the device that need to be output in the netlist;
|
|
e.g., "<B>primitive nf=4</B>. When the cell is recast as a
|
|
primitive device, it is necessary for the port order in the cell
|
|
to match the port order of the device as it must appear in the
|
|
output netlist. In the second case, the device to be extracted
|
|
is either a low-level component type (not a subcircuit), or is a
|
|
subcircuit with a different name than the cell. In that case, the
|
|
value string should be the text of the line as it should appear
|
|
in a "<B>device</B>" line in the output <TT>.ext</TT> file when the
|
|
cell is extracted. That includes the names of all ports and any
|
|
parameters to be output. As the output device is defined inside
|
|
the subcircuit of the cell in which it is defined, the ports may
|
|
be reordered between the subcircuit and the instantiation of the
|
|
device. The use of either form of the <B>device</B> property
|
|
precludes the generation of parasitics associated with the cell.
|
|
All parasitics are assumed to be included in the device model.
|
|
<DT> <B>parameter</B>
|
|
<DD> If, when an instance of the cell's subcircuit is generated in the
|
|
output netlist, the instance should be passed one or more
|
|
parameters, then those parameter <I>key</I><B>=</B><I>value</I>
|
|
pairs (as a single, space-separated string) should be defined as
|
|
the value to the <B>parameter</B> property.
|
|
<DT> <B>MASKHINTS_</B><I>type</I>
|
|
<DD> The value is a string of consecutive sets of four integer values,
|
|
each set representing the bounding box of a rectangle defining
|
|
the area of CIF type <I>type</I>, in magic's internal units.
|
|
This indicates that magic will
|
|
always generate mask layer <I>type</I> in the specified rectangle
|
|
area when writing GDS or CIF output. <I>type</I> may be a templayer,
|
|
such that <I>type</I> could be defined as the absence of a mask layer,
|
|
for example. This property is always of type <B>dimension</B> and
|
|
must have a multiple of four values.
|
|
</DL>
|
|
</BLOCKQUOTE>
|
|
|
|
<H3>Implementation Notes:</H3>
|
|
<BLOCKQUOTE>
|
|
<B>property</B> is implemented as a built-in command in <B>magic</B>.
|
|
The property structure itself is implemented as a hash table in
|
|
the cell definition structure.
|
|
</BLOCKQUOTE>
|
|
|
|
<H3>See Also:</H3>
|
|
<BLOCKQUOTE>
|
|
<A HREF=units.html><B>units</B></A> <BR>
|
|
</BLOCKQUOTE>
|
|
|
|
<P><IMG SRC=graphics/line1.gif><P>
|
|
<TABLE BORDER=0>
|
|
<TR>
|
|
<TD> <A HREF=commands.html>Return to command index</A>
|
|
</TR>
|
|
</TABLE>
|
|
<P><I>Last updated:</I> March 7, 2020 at 1:06pm <P>
|
|
</BODY>
|
|
</HTML>
|