109 lines
4.6 KiB
Plaintext
109 lines
4.6 KiB
Plaintext
|
----------------------------------------------
|
||
|
|
non-Manhattan extensions in Magic
|
||
|
|
----------------------------------------------
|
||
|
|
written by R. Timothy Edwards
|
||
|
|
version dated 12/10/01
|
||
|
|
updated 2/21/06
|
||
|
|
----------------------------------------------
|
||
|
|
|
||
|
|
1. INTRODUCTION
|
||
|
|
|
||
|
|
With the non-Manhattan extensions compiled in (this is the default
|
||
|
|
configuration), Magic includes the ability to handle a large subset
|
||
|
|
of non-Manhattan geometry. The implementation was chosen to fit into
|
||
|
|
the "corner-stitched" data structures which form the basis of all
|
||
|
|
operations in Magic, so as to require as little possible overhead.
|
||
|
|
In fact, when non-Manhattan extensions are compiled in, Magic will not
|
||
|
|
be measurably slower when acting on standard Manhattan geometry than
|
||
|
|
it is without the extensions compiled in.
|
||
|
|
|
||
|
|
2. IMPLEMENTATION
|
||
|
|
|
||
|
|
The chosen implementation does not include every possible type of
|
||
|
|
non-Manhattan geometry (for instance, it does not include any kind of
|
||
|
|
circular geometry). It implements what I would call "corner-split
|
||
|
|
geometry". Every rectangular tile in Magic may be split across the
|
||
|
|
diagonal, with one layer type on one side and another layer type on
|
||
|
|
the other side, thus:
|
||
|
|
|
||
|
|
+-----+
|
||
|
|
|XXXX/|
|
||
|
|
|XXX/ |
|
||
|
|
|XX/ |
|
||
|
|
|X/ |
|
||
|
|
|/ |
|
||
|
|
+-----+
|
||
|
|
|
||
|
|
The corner-split geometry allows angles of any value, as long as the
|
||
|
|
endpoints of each tile lie on the integer layout grid.
|
||
|
|
|
||
|
|
[For those interested in implementation issues: There are only a
|
||
|
|
maximum of 256 or so "types", which means TileType could easily be
|
||
|
|
type short int, or 2 bytes long, with plenty room to spare. Instead,
|
||
|
|
the TileType is defined as int, 4 bytes long, partly to let the
|
||
|
|
data structure share the space as a pointer for subcell definitions.
|
||
|
|
This allows the 32 bits to be sliced up into bit fields. I define
|
||
|
|
14 bits for the left-side type, 14 bits for the right-side type, one
|
||
|
|
bit to define the direction ("/" or "\") of the split, and one bit
|
||
|
|
to declare the tile as being split. Each Magic function requiring
|
||
|
|
a check for non-Manhattan geometry makes a single test for the
|
||
|
|
non-Manhattan declaration bit and branches to the non-Manhattan
|
||
|
|
handling code, thus limiting the overhead on Manhattan geometry to
|
||
|
|
two machine instructions (AND + BZ).]
|
||
|
|
|
||
|
|
3. COMMANDS
|
||
|
|
|
||
|
|
Two simple commands allow basic generation and manipulation of
|
||
|
|
non-Manhattan geometry:
|
||
|
|
|
||
|
|
splitpaint <direction> <layer_type> [<layer_type2>]
|
||
|
|
|
||
|
|
spliterase <direction> <layer_type>
|
||
|
|
|
||
|
|
These commands are analogous to the "paint" and "erase" commands.
|
||
|
|
Instead of filling (or erasing the contents of) the box cursor, the
|
||
|
|
non-Manhattan command paints (or erases) a triangle inside the cursor
|
||
|
|
select box, with the corner of the triangle facing the direction
|
||
|
|
indicated by <direction>, which can be one of the list: (nw, sw, ne, se).
|
||
|
|
<layer_type> names the layer type to paint, and the optional <layer_type2>
|
||
|
|
names a layer to fill the rest of the box not covered by <layer_type>.
|
||
|
|
|
||
|
|
For instance, in the example tile shown above, if the X's represent metal1,
|
||
|
|
the tile would be generated by the command "split nw m1".
|
||
|
|
|
||
|
|
4. SUPPORTED FEATURES
|
||
|
|
|
||
|
|
Non-Manhattan geometry extensions are complete in magic versio 7.4, apart
|
||
|
|
from possible minor bug fixes. Supported features are listed below.
|
||
|
|
|
||
|
|
Full support for:
|
||
|
|
X11 and OpenGL rendering
|
||
|
|
Painting/erasing (including move, copy, flip, rotate, and subcell geometry)
|
||
|
|
Loading/saving
|
||
|
|
Selection
|
||
|
|
Connectivity searches
|
||
|
|
CIF read/write (see below)*
|
||
|
|
GDS read/write
|
||
|
|
Plotting
|
||
|
|
Extraction/Extresis (unlikely to extract non-Manhattan transistors)
|
||
|
|
DRC (see below)**
|
||
|
|
|
||
|
|
----------------------------------------------
|
||
|
|
* Non-Manhattan CIF and GDS writes: The "bloat-max" and "bloat-min"
|
||
|
|
functions are not defined for non-Manhattan geometry. However, I
|
||
|
|
am not aware of any technology file which uses either function.
|
||
|
|
"bloat-or" may produce incorrect output in pathological situations,
|
||
|
|
but is expected to work properly for the usual uses of bloat-or
|
||
|
|
such as auto-generated wells and selects. The CIF/GDS output "squares"
|
||
|
|
function will not produce contact cuts inside nonmanhattan tiles.
|
||
|
|
Technologies allowing/requiring nonmanhattan contact cuts should
|
||
|
|
define the Magic layer to exactly correspond to the cut, instead of
|
||
|
|
using the "squares" command. Otherwise, nonmanhattan regions should
|
||
|
|
not be created from Magic contact layers.
|
||
|
|
|
||
|
|
** Non-Manhattan DRC: Currently, non-Manhattan DRC operates in the following
|
||
|
|
manner: DRC checks occur for each orthogonal edge of a split tile. So
|
||
|
|
the tile must obey DRC rules separately for each of the two types which
|
||
|
|
make up the tile. This covers about 90% of the required DRC rules.
|
||
|
|
Additional rules are required but have not yet been implemented.
|