---------------------------------------------- non-Manhattan extensions in Magic ---------------------------------------------- written by R. Timothy Edwards version dated 12/10/01 ---------------------------------------------- 1. INTRODUCTION With the non-Manhattan extensions compiled in (choose the option in "make config"), 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: split [] spliterase 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 , which can be one of the list: (nw, sw, ne, se). names the layer type to paint, and the optional names a layer to fill the rest of the box not covered by . 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 a work in progress. 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 Nearly complete support for: CIF read/write (lack of BLOAT operations affects a few output layers Calma read/write such as n/p-select on transistors) Partial support for: Plotting (only PostScript plotting supported) Extraction (unlikely to extract non-Manhattan transistors) DRC (see below)* No support yet for: Extresis (may crash the program if attempted on non-Manhattan geometry) ---------------------------------------------- * 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.