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. Use the graphics caching functions and off-screen rendering
     routines to implement a "pick" tool, that will allow selections
     to be dragged around and placed without all the guesswork of
     the "move" and "copy" commands.  There should be two "pick"
     functions, one equivalent to "move" and one to "copy".  Is it
     possible to implement a drag-and-drop version of "stretch"?
     [done in revision 79, although it needs to get the transformation
     between the edit and root cells correct, and should probably
     be prevented from attempting to pick up the root use.]

  2. Item 1 can be extended to the "wire" command, allowing a real-
     time view of where magic will place the next wire according to
     the current cursor position, and updating based on pointer
     motion.  It is very fast (especially with the backing store
     mechanism in place) to continuously update a small set of
     highlights.
     [done in revision 81.  Very cool.  Also implemented a crosshair
      cursor.]

  3. The "array" command needs to do much more.  It should be possible
     to add or subtract an extra element in an array in any of the
     four directions without affecting the existing array pitch.
     "array count" should give just the total count; add something like
     "array index" to get the actual indices.  Allow "grow" and "shrink"
     options, as for boxes:  "array grow e 1",  "array shrink n 2",
     "array grow w -1" (equivalent to "array shrink w 1"), "array grow
     c 1" (c = center; add one instance to the array in all directions).

  4. Simlarly, the "sideways" and "upsidedown" commands should take
     a direction option (maybe preferable to merge the two commands
     into a single "flip" command) that determines whether the flip is
     to the current standard of maintaining the lower-left corner,
     or centered ("flip c") or at the left edge ("flip w"), etc.
 
  5. 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]

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

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

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

  9. 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.
     [8/12/05---consider creating an "inline" subcell representation,
      similar to the above, especially to use with non-manhattan
      polygons and wires.  An "inline" subcell would be allowed to
      have only one instance, and should be written to the same .mag
      file as the parent, with a specific syntax declaring the
      subcell.  In particular, this would avoid the proliferation
      of cells caused by the "gds subcell polygon" option.  Can the
      editing of such subcells also be made transparent?]

  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) [see #2 above].

  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.
     [done; completed in revision 61, various errors fixed by version
      70.  However, as currently implemented, users with their own
      key macros suddenly find that the "tool" command no longer
      works.]

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 "extresist" code only recognizes original "fet" types, not
     the new "device" types in the extract file.

  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.

  6. The "maxwidth" rule logically should indicate the maximum LEGAL
     width of a layer.  However, as it stands, the value <distance>
     for the "maxwidth" rule is interpreted as the smallest ILLEGAL
     layer width.  This is okay, in that putting the "logical" value
     makes the rule just a little conservative.  But, adding 1 to
     the distance to get the correct result can create a situation
     in which, if the grid is subdivided more finely than the original
     lamda grid, it is possible to generate layout that magic thinks
     is correct but that would fail a rigorous DRC checker program.
     It is not clear how this should be addressed.

  7. The "maxwidth" rule, pad rules, etc., tend to come with large
     distance values.  These set the DRC "halo", forcing the DRC
     subcell interaction routine to flatten huge chunks of layout
     for every simple change made to the layout.  Magic consequently
     spends most of its time doing DRC, and most of that time is
     spent in the uninterruptible function of flattening paint,
     making magic's response sluggish.  This must be addressed,
     somehow.
