2022-01-21 16:44:13 +01:00
|
|
|
<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>
|
2024-01-09 22:37:00 +01:00
|
|
|
<TITLE>Magic-8.3 Command Reference</TITLE>
|
2022-01-21 16:44:13 +01:00
|
|
|
<BODY BACKGROUND=graphics/blpaper.gif>
|
2024-01-09 22:37:00 +01:00
|
|
|
<H1> <IMG SRC=graphics/magic_title8_3.png ALT="Magic VLSI Layout Tool Version 8.3">
|
2022-01-21 16:44:13 +01:00
|
|
|
<IMG SRC=graphics/magic_OGL_sm.gif ALIGN="top" ALT="*"> </H1>
|
|
|
|
|
|
|
|
|
|
<H2>xor</H2>
|
|
|
|
|
<HR>
|
|
|
|
|
Perform exclusive-or between the current cell and the indicated destination cell.
|
|
|
|
|
The destination cell is overwritten with the result.
|
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
|
|
<H3>Usage:</H3>
|
|
|
|
|
<BLOCKQUOTE>
|
|
|
|
|
<B>xor</B> [<I>option</I>] <I>cellname</I> <BR><BR>
|
|
|
|
|
<BLOCKQUOTE>
|
|
|
|
|
where <I>cellname</I> is the name of a cell definition to be
|
|
|
|
|
compared against, and into which the compared geometry will be placed.
|
|
|
|
|
<I>option</I> may be one of <B>-nolabels</B>, <B>-nosubcircuit</B>,
|
|
|
|
|
or <B>-novendor</B>, similar to the "<B>flatten</B>" command.
|
|
|
|
|
</BLOCKQUOTE>
|
|
|
|
|
</BLOCKQUOTE>
|
|
|
|
|
|
|
|
|
|
<H3>Summary:</H3>
|
|
|
|
|
<BLOCKQUOTE>
|
|
|
|
|
The <B>xor</B> command compares the current edit cell against
|
|
|
|
|
the target cell <I>cellname</I> by flattening and exclusive-or,
|
|
|
|
|
replacing the target cell paint as it works. The result is an
|
|
|
|
|
empty cell if the two cells have exactly the same geometry;
|
|
|
|
|
otherwise, paint remains in the target cell where the geometry
|
|
|
|
|
of the current edit cell does not match the geometry of the
|
|
|
|
|
target cell.
|
|
|
|
|
<P>
|
|
|
|
|
|
|
|
|
|
The target cell is assumed to be flattened already. That is,
|
|
|
|
|
to compare hierarchical layout <I>layout1</I> to hierarchical
|
|
|
|
|
layout <I>layout2</I>, one would normally do:
|
|
|
|
|
|
|
|
|
|
<BLOCKQUOTE>
|
|
|
|
|
<TT>load <I>layout1</I></TT><BR>
|
|
|
|
|
<TT>flatten <I>dest</I></TT><BR>
|
|
|
|
|
<TT>load <I>layout2</I></TT><BR>
|
|
|
|
|
<TT>xor <I>dest</I></TT><BR>
|
|
|
|
|
</BLOCKQUOTE>
|
|
|
|
|
|
|
|
|
|
This will result in cell <I>dest</I> containing geometry
|
|
|
|
|
mismatches between cell <I>layout1</I> and cell <I>layout2</I>. <P>
|
|
|
|
|
|
|
|
|
|
The options allow selective flattening, as follows:
|
|
|
|
|
<DL>
|
|
|
|
|
<DT> <B>-nolabels</B>
|
|
|
|
|
<DD> Prevents magic from copying labels into the flattened cell.
|
|
|
|
|
Otherwise, magic flattens labels by prepending the cell
|
|
|
|
|
hierarchy to each label as it copies it into the flat cell.
|
|
|
|
|
<DT> <B>-nosubcircuit</B>
|
|
|
|
|
<DD> Prevents magic from flattening cells declared to be subcircuits
|
|
|
|
|
(by the presence of ports in the cell). These cells are
|
|
|
|
|
retained as subcells in the flattened version.
|
|
|
|
|
<DT> <B>-novendor</B>
|
|
|
|
|
<DD> Prevents magic from flattening cells that are vendor cells,
|
|
|
|
|
that is, cells that are generated by reading GDS using the
|
|
|
|
|
<B>gds readonly</B> option, or which have the appropriate
|
|
|
|
|
property values set.
|
|
|
|
|
</DL>
|
|
|
|
|
|
|
|
|
|
In effect, <B>xor</B> is just the command <B>flatten</B> called
|
|
|
|
|
with a special paint translation table that erases paint in the
|
|
|
|
|
target when painted with the same type from the source. <P>
|
|
|
|
|
|
|
|
|
|
Note that <I>cellname</I> is a top-level cell but is not displayed
|
|
|
|
|
or saved subsequent to the <B>xor</B> command. The usual
|
|
|
|
|
procedure is to follow the command "<B>xor</B> <I>cellname</I>"
|
|
|
|
|
with "<B>load</B> <I>cellname</I>", to view the new compared
|
|
|
|
|
layout. <P>
|
|
|
|
|
|
|
|
|
|
Also note that a technology file's paint and erase tables
|
|
|
|
|
can interfere with strict XOR function results. Typical paint
|
|
|
|
|
and erase rules will tend to generate a result that is useful
|
|
|
|
|
for a yes-no answer (cells either match or not), and for finding
|
|
|
|
|
places in mismatched cells where differences occur. But it may
|
|
|
|
|
not be possible to determine exactly what the difference is
|
|
|
|
|
from the <B>xor</B> output. For a "proper" XOR function, use
|
|
|
|
|
a techfile that does not have interacting types and planes, and
|
|
|
|
|
draws contact cuts on separate planes rather than using magic's
|
|
|
|
|
contact types (which automatically have interacting paint and
|
|
|
|
|
erase rules).
|
|
|
|
|
</BLOCKQUOTE>
|
|
|
|
|
|
|
|
|
|
<H3>Implementation Notes:</H3>
|
|
|
|
|
<BLOCKQUOTE>
|
|
|
|
|
<B>xor</B> is implemented as a built-in command in <B>magic</B>,
|
|
|
|
|
available from magic version 8.1.64.
|
|
|
|
|
</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>
|
