Development Directions

• Rendering---
  1. Implement rendered fonts. Font text should scale with the window zoom factor, allow different font styles, read from a standard font vector format; allow rotation, scale, and offset. Ideally, text should rotate to any angle, but at 90 degree increments is considerably easier to implement. Font text should make use of GDS text extensions, although specifying font vectors in the GDS itself is not a common usage, and probably is not necessary.

     TIME: about 1 month
     SKILLS: OpenGL, X11
     STATUS: Done (magic version 8.0)
     

  2. Is there a way to speed up the OpenGL rendering by handling arrays such that all operations on one array component can be copied to each array position rather than tediously redoing the calculations for each array position?
     • If there are functions in OpenGL that can handle this, they should be used. e.g., bit block transfers.
     • Alternately, magic could put all drawing operations for an array into a single list, then execute that list at different matrix translations.

     TIME: 1-2 weeks
     SKILLS: OpenGL
     STATUS: Open
     

  3. For most video cards and their hardware-accelerated drivers, it may be true that texture mapping renders faster and looks better (probably a lot better) than stipple patterns. Texture mapping capability should be added to the style file for OpenGL, and the rendering speed should be compared against the stipple patterns (note that one would normally make the texture map the single paint style for a layer, so rendering it would be a single-pass painting operation, as opposed to the multi-pass operation used for layers declaring multiple styles to get the right color/effect. And the texture map would scale with the layout view scale, so one would expect a better-looking result on full views of complete chip designs.

     TIME: 1 month
     SKILLS: OpenGL
     STATUS: Open
     

  4. Develop the Windows API graphics modules (esp. for OpenGL/WGL).

     TIME: 3 months
     SKILLS: OpenGL, WinAPI, X11, magic internals
     STATUS: Mostly done, but unfinished and not updated for a long time.
     

  5. Identify rendering speed bottlenecks for large designs and generate a plan for getting rid of them.

     TIME: ongoing
     SKILLS: various
     STATUS: Open
     

• Database---
  1. Complete the "images" section "device" type as separate from a contact type. Prove that a consistent technology file can be generated with separate planes for poly, poly2, and active.

     TIME: At least 3-4 months
     SKILLS: various
     STATUS: Partially complete
     

  2. Implement what I call the "pseudo-flat" database. This may or may not be practicable. The idea is to extend the bits in the tile type record to include bits that indicate that a tile belongs to a subcell, not the cell def itself. This way, portions of the database can be flattened in a reversible manner. DRC will then be run on the pseudo-flat database. This method should resolve problems with DRC speed bottlenecks as well as all issues arising from incompatible layers overlapping between cells. The drawback is that it can potentially eat up vast amounts of memory, so some attention will need to be made to implement a system to remove flattened areas that have been inactive, or to "page out" areas when memory usage gets large.

     TIME: At least 6 months
     SKILLS: various
     STATUS: Open
     

• DRC---
  1. DRC Halo is a bad bottleneck. This is due almost entirely to the problem that DRC rules are, as binned by rule distance, bimodal or trimodal. Most rules are over short distances. However, a handful of rules are over longer distances: Wide metal rules, and Pad rules. The larger the halo, the slower everything goes. It is likely that DRC could be significantly improved by splitting the rules into two or three sets based on distance. We run the complete DRC cycle for each of the three sets. If the difference in halo is significant enough, it will actually save time.
     • Need to investigate how DRC completion time changes as a function of halo size for large designs.

     TIME: 2-3 weeks
     SKILLS: EDA, magic internals, algorithms
     STATUS: Open
     

  2. Need electrical rule checks such as the antenna rule. This would probably be part of a set of rules (including the existing coverage rules) to be performed off-line, not as part of the interactive DRC code. Need to identify all the rule types that magic cannot check and come up with some plan on how to include them.

     TIME: 2-3 months
     SKILLS: EDA, magic internals, TCL programming
     STATUS: Antenna rules done (early 2020) More planned for mid-2020.
     

  3. Need correct DRC checks on non-Manhattan geometry (see below)
     
     
• OpenAccess---
  1. Implement the viewer. First for cells, then for all geometry.

     TIME: 2-3 months
     SKILLS: OpenAccess, OpenGL, X11, magic internals, EDA
     STATUS: Open
     

• MilkyWay---
  1. Implement once the OpenAccess database and methods are generally well-understood, if it seems like a good idea.

     TIME: 2-3 months
     SKILLS: OpenAccess, MilkyWay, OpenGL, X11, magic internals, EDA
     STATUS: Open
     

• Non-Manhattan Geometry---
  1. DRC checks (see above). The "advertised" rules should work but some don't. In addition, it is necessary to write a routine to check corner-to-diagonal rules. Cases where corners may be closer to the diagonal somewhere other than the tile corners is a pretty restricted case. Possibly this could be done, like the antenna rules (see above), as a non-interactive check.

     TIME: 2 months
     SKILLS: EDA, magic internals, algorithms
     STATUS: Open
     

  2. There should be a tile-merging function for split tiles, as currently the more a tile is split, the more fractured the tile plane becomes. Possibly this is easier to do as a background function that occasionally cleans up the plane, and ensures a clean plane before writing output.

     TIME: 2 months
     SKILLS: magic internals, geometry, algorithms
     STATUS: Partly done. At least, magic now un-splits fractures on an "undo" command, which definitely helps alleviate the plane fracturing problem.
     

• Place & Route---
  1. TimberWolf needs to read/write LEF/DEF.

     TIME: 1-2 months
     SKILLS: EDA, C programming, maybe lex/yacc
     STATUS: Done (November 2006), using Tcl scripts. Some of this is posted under the Open Circuit Design "Digital Flow" page.
     

• Simulation---
  1. Need to get tclspice/magic/xcircuit all working together. See below for tclspice and xcircuit.

     TIME: variable; at least 2-3 months
     SKILLS: EDA, Tcl/Tk programming
     STATUS: Open
     

  2. Would be nice to have a SPICE method which handles the IRSIM interface, such that IRSIM and SPICE can be run at the same time. Would need a clever interface to partition circuits into standard-cell digital vs. analog parts and submit each part to the proper simulator.

     TIME: 3 months
     SKILLS: EDA, Tcl/Tk, C programming
     STATUS: Open
     

• Extraction---
  1. The "extresist" RC extraction needs to be updated to handle new device types, and a number of other aspects of the newer code changes (such as recognizing output of the "resistor tee" option).

     TIME: 1 month
     SKILLS: EDA, magic internals
     STATUS: Partly done (early 2020). Extresist now handles all device types, but there is a very strong need to remove the dependence on reading the ".sim" format and just work all calculations from the values in the ".ext" file. For example, extresist cannot now handle the substrate node because the ".sim" format has no concept of a substrate.
     

  2. There needs to be a general-purpose way of describing devices such that they do not need to always be hard-wired into the code. One possible way would be to use a method similar to the CIF-DRC method, in which "cifoutput" temp layers are used to perform boolean operations. There would be a temp layer for each port of each device, and these temp layers would be used during normal extraction as marker layers to identify each device.

     TIME: 2 months
     SKILLS: EDA, magic internals
     STATUS: Open
     

  3. All device types should accept a marker layer type that uniquely identifies the device. In many cases it is simpler to mark devices with an identifier rather than create new layer types for every single different possible device. Layers like "thickox" and "sdblock" can also be used to distinguish between different device types.

     TIME: 1 week
     SKILLS: EDA, magic internals
     STATUS: Done (early 2020)
     

  4. Magic should be able to generate a hierarchical SPICE deck. The "ext2spice" routine always flattens the input, and so the "ext2spice" and "extflat" code is not really appropriate for this task. It should be part of the "extract" code, and use a 2-pass algorithm: The first pass generates the .ext files, and determines what are the ports of each subcircuit, based on connections into the subcircuit. The second pass would read information from each .ext file, and use the information about ports to write each subcircuit record into a single SPICE deck.

     TIME: 1 month
     SKILLS: EDA, magic internals
     STATUS: Done (started 2010, mainly finished in 2014)
     

• CIF/GDS---
  1. GDS should be able to read/write contacts as cell arrays. That is, it should be able to generate subcells from contacts on the fly when writing, and to flatten them into magic contact regions when reading.

     TIME: 3 weeks
     SKILLS: EDA, GDS/CIF format, C programming
     STATUS: Done, but not well tested. Some bugs were found in early 2008 in the read routine, which now has been pretty thoroughly tested.
     

• XCircuit---
  1. Need to work out how to get "multimeter"-like symbols into xcircuit that can pick up values from a simulation and print them. Speed concerns require that in addition to the simple "refresh", XCircuit should be able to handle erase and redraw of small areas of interest. This may mean simply having a secondary redraw function that looks for expression parameters and updates them.

     TIME: 2-3 weeks
     SKILLS: EDA, Tcl/Tk, xcircuit internals
     STATUS: Partially done
     

  2. Parameterization of color really should supercede the handling of color as done currently in XCircuit, as well as the kludgy way it's handled in the output.

     TIME: 2 weeks
     SKILLS: xcircuit internals
     STATUS: Open
     

  3. Get around to implementing all the ASG stuff.

     TIME: variable, at least 3-4 months for the essentials.
     SKILLS: EDA, xcircuit internals, SPAR internals, SPICE, EDIF, Verilog formats
     STATUS: In progress, but slooooooow. Rebooting summer 2020.
     

• Netgen---
  1. Implement hierarchical LVS. Netgen can compare an arbitrary subcircuit call in circuit1 to another in circuit2. However, it needs the capability to understand that pin ordering in circuit1 may be permuted with respect to circuit2, but that unlike MOSFET source/drain permutations, the ordering must be the same for all subcircuit calls. Magic needs to be able to output an LVS-ready hierarchical SPICE deck (no flattening, one subcircuit call per cell definition; see above. This is not just a trivial extension of "ext2spice"). Every subcircuit should be compared from the bottom up. When subcircuits do not compare properly, they should be subsumed (flattened) into the parent circuit. There should be some method to insist that a subcircuit is the same as its counterpart and should not be flattened if it cannot be compared; this should be a command-line command.

     TIME: 1 month
     SKILLS: EDA, Netgen internals, Magic internals
     STATUS: Done.
     

• Ng-SPICE---
  1. Since SPICE is still based on the same batch-job code, the interactive features of SPICE-3 are implemented by interrupts. This works best with other programs by using piped I/O. There is then no inherent advantage to having a Tcl interpreter wrapping Ng-SPICE, which has its own interpreter anyway. XCircuit demonstrates interactive simulation with Ng-SPICE; this should be demonstrated in Magic as well, with a tutorial and supporting Tcl procedures. XCircuit needs a dedicated library for SPICE testbench circuits. Finish the XCircuit tutorial 3 with a simulation example!

     TIME: 3 weeks
     SKILLS: EDA
     STATUS: Partially done.
     

• Bottlenecks---
  1. For all the tools, it is necessary to identify performance bottlenecks (both memory and speed) and determine what to do about them.

     TIME: variable
     SKILLS: EDA
     STATUS: Open
     

• Technology Files---
  1. Develop a good set of technology files for all the major modern processes.

     TIME: ongoing
     SKILLS: EDA
     STATUS: Partly done
     

  2. Develop some distribution method for proprietary technology files; either get permission to post the magic technology files from the vendor or have some method in place with the vendors to verify who has NDAs, or give the technology files to the vendors to distribute with their kits.

     TIME: ongoing
     SKILLS: EDA
     STATUS: Working with foundries on this one.
     

• Documentation---
  1. Updates of existing documentation for magic, xcircuit, IRSIM, Timberwolf, Tclspice
  2. Transfer of text documentation to LaTeX (and thence to HTML and PDF).

     TIME: 1-2 months
     SKILLS: EDA, tech writing
     STATUS: Partly done
     

  3. New documentation covering new topics and extensions.
  4. Tutorials

     TIME: 2-3 months
     SKILLS: EDA, tech writing
     STATUS: Partly done
     

  5. Maintenance

     TIME: ongoing
     SKILLS: EDA, tech writing
     STATUS: Open
     

• Distribution---
  1. Expand mailing lists, forums, download sites
  2. Ongoing maintenance and packaging of binary versions
  3. Technical support

     TIME: ongoing
     SKILLS: HTML, website construction and maintentance, software packaging, EDA
     STATUS: Open
     

Developer's Primer

This link points to a primer on the magic source code, its files, data structures, and methods, and other helpful tidbits gleaned from years of delving into the code.

Helping with Magic Development

Current development has been modernized by the advent of web-based repositories like github and gitlab. The best way to report bugs is to file an issue on the github mirror site at https://github.com/RTimothyEdwards/magic. The best way to join development is to fork the repository, work on a branch, and submit a pull request. Pull requests are generally honored if they appear reasonable and don't break anything.

For general discussion, the discussion email group's mailing address is magic-dev@opencircuitdesign.com
See the Magic home page for mailing list archives and instructions on how to subscribe to the mailing list.

The Magic Development Teams

Here is the original Magic Development team that kept Magic alive and kicking through the late 1990s and the first decade of the 2000s (in alphabetical order):

• Tim Edwards (Johns Hopkins APL)
• Mike Godfrey (Stanford, Pixeldevices)
• Wes Hansford (MOSIS)
• Rajit Manohar (Cornell)
• Mika Nyström (Caltech)
• Philippe Pouliquen (Johns Hopkins University)
• Stefanos Sidiropolous (Aeluros)
• Jeff Solomon (Stanford)
• Jeff Sondeen (USC)
• Holger Vogt (Fraunhofer-Institut IMS, Duisburg, Germany)

Some people deserve to be mentioned for critical help with certain aspects of the code development. From the same period as above (1990s and 2000s), they are (in addition to the ones mentioned above):

John Wood (MultiGiG)
     For generously funding the open-source magic development, testing, discussion, and feedback.

Stefan Jones (MultiGiG)
     For help with Tcl and development of Tcl-SPICE.

Charles Krinke
     For extensive testing, support, discussion, suggestions, and feedback

Mark Martin (JHU/APL)
     For using the bleeding-edge develpment versions, testing, discussion, and instantaneous feedback

Stefan Robert (U. Sherbrooke, Montreal)
     Michael Doster
     For help with the Mac OS X port

"Spaceborne" Calin
     Erik Peterson (Yanntek)
     For helping to answer questions on the magic-dev mailing list

Erwin Prinz
     For extensive help with RedHat and RPM archives.

Cecil Aswell
     For help with Octtools and Timberwolf.

James Stine (IIT)
     For work on standard-cell libraries

Richard Lethin (Reservoir Labs)
     Tim Chuang (SITI, Taiwan)
     For heavy use of the latest distribution and/or development versions and a lot of feedback.

Jason Schonberg
     For a lot of help with cleaning up the source code in Magic-7.3.

Development from 2005 to 2012 was largely underwritten by my employer at the time, MultiGiG (since bought by Analog Devices). Development from 2015 to 2020 was largely underwritten by my employer at the time, efabless.

For more recent development, acknowledgements can be found in the code history.

email:

Last updated: January 9, 2024 at 9:00am