mirror of
https://github.com/RTimothyEdwards/magic.git
synced 2026-08-28 17:15:13 +02:00
R. Timothy Edwards
b1c7b52ed2
since this is a common artifact of foundry cells and almost always incompatible with magic. Modified the "port" command to allow "port make <index>" on a label where other labels of the same text already have the same index. Removed deprecated documentation and added some missing documentation, such as an explanation of the "ext2spice subcircuit auto" option.
214 lines
10 KiB
HTML
214 lines
10 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>lef</H2>
|
|
<HR>
|
|
LEF-format input and output
|
|
<HR>
|
|
|
|
<H3>Usage:</H3>
|
|
<BLOCKQUOTE>
|
|
<B>lef</B> <I>option</I> <BR><BR>
|
|
<BLOCKQUOTE>
|
|
where <I>option</I> may be one of the following:
|
|
<DL>
|
|
<DT> <B>read</B> [<I>filename</I>]
|
|
<DD> Read a LEF file named <I>filename</I>[<B>.lef</B>]
|
|
<DT> <B>read</B> [<I>filename</I>] <B>-import</B>
|
|
<DD> Read a LEF file. Import standard cells from <TT>.mag</TT>
|
|
files
|
|
<DT> <B>read</B> [<I>filename</I>] <B>-annotate</B>
|
|
<DD> Read a LEF file. Use any macros defined in the LEF file
|
|
to annotate existing layouts, and ignore all other macros.
|
|
<DT> <B>write</B> [<I>filename</I>] [<B>-tech</B>]
|
|
[<B>-hide</B> [<I>distance</I>]] [<B>-toplayer</B>]
|
|
[<B>-pinonly</B> [<I>distance</I>]] [<B>-nomaster</B>]
|
|
<DD> Write LEF for the current cell to the file <I>filename</I>.<BR>
|
|
Option <B>-tech</B> writes the technology information (layer
|
|
mapping and rules) to the same file as the cell macro. <BR>
|
|
Option <B>-hide</B> generates an abstract view that has all
|
|
interior detail removed, leaving only pins and obstruction
|
|
layers covering the entire cell with cut-out areas for the
|
|
pins. Option <B>-hide</B> may take an additional value
|
|
argument <I>distance</I> which will hide the central part
|
|
of a cell starting a distance <I>distance</I> from the edge.
|
|
The <I>distance</I> value is in units of lambda by default,
|
|
but like other distance measurements changes with respect
|
|
to the <B>snap</B> command setting, and can take a suffix
|
|
such as "<B>um</B>" to specify a physical distance relative
|
|
to the current CIF/GDS output scale. <BR>
|
|
Option <B>-toplayer</B> outputs pin geometry only for the
|
|
topmost layer belonging to the pin; all connected layers
|
|
underneath will be output as obstructions. <BR>
|
|
Option <B>-pinonly</B> will mark only areas that are port
|
|
labels as pins, while marking the rest of each related net
|
|
as an obstruction. Value <I>distance</I>, if given, will
|
|
extend any pin beyond the marked port label along the length
|
|
of the same net, to the specified distance into the interior
|
|
of the cell. <BR>
|
|
Option <B>-nomaster</B> will prevent the generation of
|
|
output geometry on layers defined as MASTERSLICE.
|
|
<DT> <B>writeall</B> [<B>-tech</B>] [<B>-hide</B> [<I>distance</I>]]
|
|
[<B>-notop</B>] [<B>-toplayer</B>] [<B>-nomaster</B>]
|
|
<DD> Write all cells including the top-level cell. This might
|
|
be appropriate if the top-level cell is a compendium of
|
|
standard cells. <BR>
|
|
With option <B>-notop</B>: Write all subcells of the top-level cell,
|
|
but not the top-level cell itself. This is appropriate for
|
|
generating a LEF library from a layout, for which the layout
|
|
itself would be written to a DEF file. <BR>
|
|
Options <B>-hide</B>, <B>-tech</B>, and <B>-toplayer</B> are
|
|
the same as for the <B>lef write</B> command.
|
|
<DT> <B>nocheck</B> [<I>netname</I> ...]|[<B>none</B>]|[<B>*</B>]
|
|
<DD> Do not check for antenna diffusion and gate area on the nets with
|
|
the names given as option <I>netname</I>.
|
|
Any number of net names may be given as arguments. Typically,
|
|
power and ground nets should not need these checks. If the nets
|
|
are attached to port labels that have been flagged with the use
|
|
"<B>power</B>" or "<B>ground</B>", then these nets will be
|
|
skipped automatically. If not, then this command option provides
|
|
an alternative way to avoid running the checks, which can cause
|
|
a huge performance hit when generating a LEF view of a large
|
|
layout. The single argument "<B>*</B>" will cause all net checks
|
|
to be skipped, and no antenna information will appear in the
|
|
LEF file output. The single argument "<B>none</B>" removes the
|
|
list of net names for which antenna checks should be skipped.
|
|
<DT> <B>datestamp</B> [<I>value</I>|<B>default</B>]
|
|
<DD> Force all cell definitions generated from LEF macros to have
|
|
the datestamp (timestamp) of <I>value</I>. This can be used to
|
|
ensure that the timestamps of abstract views match the timestamps
|
|
of the equivalent full views, so that switching between abstract
|
|
and full views does not cause timestamp mismatch handling. The
|
|
string <B>default</B> cancels any fixed timestamps.
|
|
<DT> <B>help</B>
|
|
<DD> Print help information
|
|
</DL>
|
|
</BLOCKQUOTE>
|
|
</BLOCKQUOTE>
|
|
|
|
<H3>Summary:</H3>
|
|
<BLOCKQUOTE>
|
|
The <B>lef</B> command writes LEF-format files, which are files
|
|
containing technology information and information about the content
|
|
of standard cells. It is used in conjunction with the <B>def</B>
|
|
command to read databases of routed digital standard-cell layouts.
|
|
The <TT>.lef</TT> file shares some information with the technology
|
|
file in <B>magic</B>. At a minimum, to read <TT>.lef</TT> files
|
|
from third-party sources, the technology file should have a
|
|
<B>lef</B> section that maps magic layers to layer names that are
|
|
found in the <TT>.lef</TT> and <TT>.def</TT> files. Without
|
|
this information, <B>magic</B> will attempt to make an educated
|
|
guess about the routing layers, which normally will be named
|
|
in an obvious manner such as "metal1", "metal2", etc. The
|
|
technology file section may be necessary to handle more complicated
|
|
input such as obstruction layers. Most other aspects of a
|
|
technology will be contained within the <TT>.lef</TT> file.
|
|
When writing <TT>.lef</TT> files, <B>magic</B> will use internal
|
|
layer names for the routing layers if no other information is
|
|
present in the <B>lef</B> section of the technology file. <P>
|
|
|
|
Because the <B>lef</B> format allows standard cells to be minimally
|
|
defined (for purposes of protecting intellectual property), often
|
|
the <TT>.lef</TT> file contains no actual layout information for
|
|
the standard cells. <B>magic</B> provides a command option
|
|
"<B>-import</B>". When specified, for each macro cell in the
|
|
input <TT>.lef</TT> file, <B>magic</B> will look for a <TT>.mag</TT>
|
|
file of the same name. If found, it will be loaded and used in
|
|
preference to the definition in the <TT>lef</TT> file. <P>
|
|
|
|
Magic uses the <B>port</B> mechanism for labels to determine
|
|
what are the standard cells in a design. All cells containing
|
|
<B>port</B> labels will be considered standard cells when writing
|
|
a <TT>.lef</TT> file. Ports retain various bits of information
|
|
used by the LEF/DEF definition, including the port use and
|
|
direction. See the <B>port</B> documentation for more information.<P>
|
|
|
|
Macro cell properties common to the LEF/DEF definition but that
|
|
have no corresponding database interpretation in <B>magic</B>
|
|
are retained using the cell <B>property</B> method in <B>magic</B>.
|
|
There are specific property names associated with the LEF format.
|
|
These are as follows:
|
|
<DL>
|
|
<DT> <B>LEFclass</B>
|
|
<DD> Corresponds to the value of <B>CLASS</B> for a macro
|
|
cell in the LEF format.
|
|
<DT> <B>LEFsymmetry</B>
|
|
<DD> Corresponds to the value of <B>SYMMETRY</B> for a macro
|
|
cell in the LEF format.
|
|
<DT> <B>LEFsite</B>
|
|
<DD> Corresponds to the value of <B>SITE</B> for a macro
|
|
cell in the LEF format.
|
|
<DT> <B>LEFproperties</B>
|
|
<DD> Corresponds to the value of <B>PROPERTY</B> for a macro
|
|
cell in the LEF format. LEF properties should be specified
|
|
in a single cell property, in key:value pairs and space-separated.
|
|
Like all properties containing spaces, the entire property string
|
|
should be enclosed in quotes. When writing output, each of the
|
|
space-separated entries will be output on its own PROPERTY line
|
|
in the LEF file.
|
|
</DL>
|
|
|
|
Normally, when importing a LEF/DEF layout into <B>magic</B>, one
|
|
will first execute a <B>lef read</B> command followed by a
|
|
<B>def read</B> command. Likewise, when writing a layout, one
|
|
will first execute a <B>lef writeall -notop</B> command followed
|
|
by a <B>def write</B> command. <P>
|
|
|
|
If a LEF file of macro definitions is read when the same cells
|
|
as named in the macros already exist in the magic database, then
|
|
the LEF file macros will be used to annotate the existing layout.
|
|
This includes setting pin properties (see above), extending the
|
|
area of labels to cover an entire port, and setting a bounding
|
|
box on the cell corresponding to the LEF origin and size. <P>
|
|
|
|
Note that <B>lef write -hide</B> will generate only the minimum
|
|
amount of obstruction bounding any non-pin geometry inside a
|
|
layout. To enforce a larger obstruction area, the property
|
|
"<B>OBS_BBOX</B>" can be created in the cell, a string with
|
|
four values for the lower left and upper right corners of the
|
|
bounding box, in magic internal database units.
|
|
</BLOCKQUOTE>
|
|
|
|
<H3>Implementation Notes:</H3>
|
|
<BLOCKQUOTE>
|
|
<B>lef</B> is implemented as a built-in command in <B>magic</B>.
|
|
Only the critical portion of the LEF syntax has been implemented.
|
|
In particular, simulation-specific properties of the technology
|
|
and of macro cells are not implemented.
|
|
</BLOCKQUOTE>
|
|
|
|
<H3>See Also:</H3>
|
|
<BLOCKQUOTE>
|
|
<A HREF=def.html><B>def</B></A> <BR>
|
|
<A HREF=port.html><B>port</B></A> <BR>
|
|
<A HREF=property.html><B>property</B></A> <BR>
|
|
<A HREF=snap.html><B>snap</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> June 28, 2021 at 12:28pm <P>
|
|
</BODY>
|
|
</HTML>
|