----------------------------------------------
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.