I. Code which has become obsolete:

  1. Change all of the in-line macros back to subroutines.  Let the
     compiler optimizer take care of the in-lining!  They probably
     do a better job of it, anyway.  It is probably a good idea to
     benchmark the changes before accepting them into the distribution,
     though.

II. Features to add:

  1. The new transistor W,L extraction method needs to be generalized.
     Also, the extractor should use the original, simple method when
     a device contains only one tile, and the new method for any
     device with more than one tile.  This is easy to determine, as
     the extractor already does a boundary search on each device.
     [Method extended to include a search on long devices, and
      applied to resistors.  However, both methods need to be
      incorporated into a more general framework]

  2. The resistance extraction for types "device resistor" (those
     without a model) now splits the "gate" capacitance between the
     nodes.  However, coupling capacitance is simply ignored.  This
     should be handled, also for "device rsubckt" and "device
     resistor" with a defined model, especially as any device model
     would not know about coupling capacitance.
     [fixed with the "tee" resistor model, September 2004]

  3. GDS output can be significantly compacted by replacing the "squares"
     generation function with one which first creates a cell from the
     contact cut and then arrays the cell to fill up the contact area.
     To go along with the output method, it is necessary to have an
     input method which will flatten such contacts back into magic's
     standard contact types.
     [done; use "gds contacts true" for output and "gds flatten true"
      for input]

  4. GDS cells may be instanced before they are defined.  If so, the
     "gds flatten" option cannot be used.  It would be nice to have
     and option that would force a GDS file to be read in the "correct"
     order.
     [done; use "gds order true" to force post-order]

  5. Style files should be able to use X11-named colors.  Styles should
     render in the order specified in the technology file.  Any style
     which would be obscured by a solid style for the same layer should
     be duplicated into a higher-numbered style entry and renumbered.
     This change allows styles which have been ordered in bizarre ways
     in the 7-bit graphics files (to get around the limitations of the
     7 bit planes) to be reordered naturally in the 24-bit and OpenGL
     files without affecting the way types in a tech file are rendered.

III. MicroMagic stuff:

  Now that MicroMagic is available as open-source (as of summer 2004,
  although I have never been able to get it to compile), there is no
  reason not to grab some of the more useful code.  In particular,
  the MMI crew has taken great pains to track down and eliminate the
  major performance bottlenecks in magic.  In summary, the main bits
  of useful code are:

  1. "BPlane" (binned plane) construct for the cell use plane.  Magic
     slows to a crawl when attempting to handle large numbers of cell
     uses in a design (especially contact arrays as often appear in
     3rd-party GDS input).  On the other hand, this does not appear
     to be similar to recursive bisectioning (b-tree), which is
     purported to be the best representation for such things.

  2. Child/Parent representation.  MMI has a special representation
     for defs and uses such that searching can be significantly
     faster when a cell def has only one instance.

  3. Hash table representation for labels.  Label handling in magic
     is suspect, and in particular slows down CIF/GDS input while
     re-assigning labels to layers.

  4. Graphics caching.  MMI can do very fast redraws on arrays and
     on layouts at large zoom factors using off-screen rendering.
     The off-screen rendering functions are already implemented in
     magic-7.2/7.3, so this should be easy to implement.

  5. Polygons and wirepaths.  After all the work I've done on
     non-Manhattan geometry, it may be necessary to admit that
     MMI's approach of having two database representations for
     polygons and wires separate from the manhattan paint planes
     may be the better way to do it (otherwise, something must be
     done about tile plane fracturing, such as dropping wires into
     subcells a la the CIF/GDS "polygon subcell" function, but making
     the subcells transparent to the end-user.  Ultimately, this
     approach of generating "transparent" subcells whenever the
     subcell representation is more efficient than the tile plane
     representation may be more universally applicable, and should
     be investigated).

  6. Plane hash tables instead of a mask.  This can greatly reduce
     overhead on designs that do not make use of all planes per
     cell.  In particular, standard cell designs are usually split
     into standard cells that call the lower-numbered planes, and
     the interconnect hierarchy, that calls the upper-numbered
     planes.  However, knowing that this split is the main reason
     for changing the database representation, it might suffice to
     simply record the minimum and maximum plane indices represented
     by layers present in a cell definition.  It is clear that MMI
     needed to abandon the simple indexed plane representation
     because they assume a large number of planes, up to 128.
     Magic 7.3 assumes a small number of planes, so it is not clear
     that switching to the hash table representation is a necessity.

IV. Experimental stuff:

  1. Find a way to implement general-purpose "composite" types, which
     are not necessarily contacts.  Specifically, it would be nice to
     split active, poly, and poly2 into separate planes, and let
     transistor and capacitor types exist on two planes, like contacts
     do.

  2. (BIG JOB) Reimplement the corner stitching tile pointers as
     indices into a list of tiles.  Use the smallest data type
     able to fit the total number of tiles in the cell.  This would
     realize a HUGE reduction in memory overhead for the layout
     database, especially on 64-bit architectures.

  3. (BIG JOB) Change the tile merging method ("maximum horizontal
     stripes") to the one used by extresist in ResFract.c, which
     gives a more fractal-like result.  In particular, watch the
     interaction with the routines in database/DBbound.c.

  4. Cast all of the button functions in the various modes (layout,
     wire, net. . .) into commands, and then treat buttons just
     like keys.  This would allow a lot more leeway in personalizing
     the interface.
     [work in progress]

V. Tcl version to-do list:

  1. Incorporate tclspice as a simulator.  Check out the possibility
     of using Tcl to handle both digital and analog simulators at the
     same time and enforce proper synchronization among them all, for
     a modular mixed-mode simulator.

  2. Incorporate LVS into the Tcl scheme of things (this is being done
     with netgen; still needs to have some direct feedback to magic)

  3. Work on the "techbuilder.tcl" technology file creation wizard
     program.  This program is intended to allow a technology file to
     be built interactively, mostly by reading values off of process
     specification and design rule manuals, without requiring the
     detailed and arcane knowledge that is required to properly set
     up the "cifinput", "cifoutput", and (especially!) the "drc"
     sections of the tech file.  Currently, this is a work-in-progress
     and has no direct path to execution.  The program requires Tcl
     package "BLT" for the tab windows.  The program can be test-driven
     by doing:

	magic -nowindow [-d OGL] -T minimum

     followed by:

	source $CAD_HOME/lib/magic/tcl/techbuilder.tcl

VI. Bugs to fix:

  1. The "widespacing" rule does not catch all cases of rule violation,
     depending on the tile configuration.  This problem is difficult
     to solve, but should be eliminated by the implementation of item
     IV.3. above.

  2. Rescaling during GDS reads does not always do the right thing;
     some of the input is not scaled along with the rest.

  3. The "polygon subcell" option, implemented originally for CIF,
     causes polygons to be both put in subcells AND dropped directly
     into the layout, for GDS reads (recently implemented).

  4. Significant rescaling, such as to 1:100, can cause integer overflow
     when writing GDS output on a large (e.g., 5mm x 5mm) layout.  The
     numbers don't get anywhere near the limit of 32 bits, so it should
     be possible to avoid the overflow for reasonably sized layouts.  It
     is not clear where the overflow is occurring.

  5. The Tcl callback function for tile searches is inherently
     dangerous, as it is possible to call magic functions from Tcl that
     alter the corner stitch database underneath the search function,
     resulting in a crash.  An alternative is to collect a list of tiles
     to send to Tcl, but this can result in unacceptably large lists to
     handle in Tcl.  The solution is probably a 2-step process, with
     magic first generating its own internal list of tiles to process,
     then invoking the callback function on each.
