Magic 8.3 Release Notes
Magic 8.2 Release Notes
Magic 8.1 Release Notes
Magic 8.0 Release Notes
Magic 7.5 Release Notes
Magic 7.4 Release Notes
Magic 7.3 Release Notes
Magic 7.2 Release Notes
Magic 7.1 Release Notes
Magic 6.5 Release Notes
Date: April 8, 2020 to present
Magic versions since 8.2 are developed entirely within the usual git system. Simple development (i.e., bug fixing) is done largely in the master branch, although there are specific branches for larger development efforts. The system on opencircuitdesign.com checks the status of the git repository nightly. If the VERSION file has been updated since the last check, the master branch is merged into the "magic-8.3" branch, and a new tarball is compiled from the source. At the same time, the repository is mirrored to github.Consequently, when pulling source from git, always use the branch "magic-8.3" for compiling, unless attempting to get a bleeding-edge commit.
Issues with the code should be handled through the github issue system. Pull requests made on github will be honored.
Branch bplane: Implementation of binary planes to replace the "subcell tile plane". This implementation was lifted from code in the open-source version of MicroMagic. The method reduces the deep call stacks created when running things like connectivity searches. Performance increases of at least 3 to 5 times have been seen on extraction using this method, and various other methods that search or flatten deep hierarchy (e.g., DRC or connectivity searches) also realize significant performance gains.
Branch checksum: Implementation of checksums. The idea behind this improvement is that subcells often get copied from place to place and versioning control can be difficult. The change to put full paths in the "use" lines in the .mag file helps but makes subcells non-relocatable. The timestamp method is also problematic, because it forces magic to re-run DRC, extraction, etc., on any file that has updated a timestamp, regardless of whether or not any changes have been made. By using information from both a timestamp and a checksum on the layout (layer geometry + labels and properties), magic can ensure that a cell in different locations is the same cell, and can avoid forcing updates on cells with new timestamps, if the cell contents have not changed.Branch drc-types: New implementation of DRC errors. The idea behind this is that the existing DRC implementation does not save DRC information in the layout, but only indicates where a DRC error exists, without details. The new method would assign a number to each DRC rule (this part already implemented in the master branch), and this number would be used as the layer type when painting to the DRC error plane. A new paint routine variant is needed to create new types on the fly, such that the overlap of errors is represented by a new number. Then "drc why" and "drc count" do not need to re-run DRC checks to determine the reason for an error. Also, geometry returned by "drc list count" can track the boundary of the actual error rather than dumping individual rectangles coming from each tile edge check. This will lead to consistency between "drc why" and "drc count", and the value returned by "drc count" will be more representative of the actual number of errors.
Branch extresist: New implementation for "extresist". The problem with the existing "extresist" method is that it is based on writing and reading information using "ext2sim". The .sim format, however, does not understand most of the extraction device types that magic's extractor can produce, and it has no concept of the substrate at all, and it has no hierarchy. All of these problems (and more!) can be solved by reading the .ext files (using the routines in extflat/). Otherwise, the extresist method would retain the behavior of generating a ".res.ext" file for each cell containing modified nodes and devices, such that the "ext2spice" command can optionally use or ignore this information when generating the final SPICE netlist, depending on the command option "ext2spice extresist on".
Branch (not yet created): New implementation for LEF and DEF reading and writing. The existing "lef" section of the techfile relates LEF and DEF layers directly to magic layers. This is largely a mistake; because LEF and DEF files represent mask layout, they contain the same layer geometry as would be found in a GDS file. Therefore the LEF and DEF reading and writing should follow the same operator rules as for GDS and which are found in the "cifinput" and "cifoutput" sections of the techfile. This implies that where these sections employ the "calma" keyword to specify GDS layers, they should probably in the same sections employ a "lef" keyword to specify the names of LEF layers. This would likely make the entire "lef" section of the techfile unnecessary. But it also implies that both LEF and DEF read and write routines need to be completely recast to be like the CIF and GDS file operators, which implies a major code rewrite.Branch (not yet created): Improved implementation of the new CIF operator "grow-min" to accomodate more complex geometry (defining a different operator, if necessary). The problem with grow-min is that it only works well for simple, isolated rectangles. To drop an implant layer over a FET and ensure that the layer meets minimum width requirements when the device gets too small is an easier problem. To make sure that two catecorner wells do not have either a spacing violation or a too-narrow bridge of material between them after grow and shrink operations. Note that no algorithm for this has been determined yet, although there are a number of possibilities. No trivially simple algorithm looks possible for this.
Date: April 24, 2017 to April 8, 2020
Magic version 8.2 is developed entirely within the usual git system. Simple development (i.e., bug fixing) is done largely in the master branch, although there are specific branches for larger development efforts. The system on opencircuitdesign.com checks the status of the git repository nightly. If the VERSION file has been updated since the last check, the master branch is merged into the "magic-8.2" branch, and a new tarball is compiled from the source. At the same time, the repository is mirrored to github.Consequently, when pulling source from git, always use the branch "magic-8.2" for compiling, unless attempting to get a bleeding-edge commit.
Since starting the nightly mirror to github, there is no longer a Bugzilla page on opencircuitdesign.com (which had been largely shut down due to being a spam attractor). Issues with the code should be handled through the github issue system. Pull requests made on github will be honored.
Important note: Revisions 198 and 199 had a bad error that can deallocate a cell name when using the "save" command, leading to unpredictable output when writing output files. This error was fixed in revision 200. Do not use revision 198 or 199.
As of revision 30, the Cairo graphics interface code is complete and the code base is reasonably stable.Hierarchical DRC modified so that errors which exist in subcells in isolation, but which are resolved by layout in the parent cell, are no longer shown or counted in the parent cell.
LEF parser enhanced to handle many more keywords
Added cell versioning. The full path to each subcell file is recorded in the .mag file in the "use" statement. On reading, the subcell is pulled from this location. If not found at the location, the cell may be pulled from a location if found in the current search path. A warning is issued for cells that are not found at their specified location unless the "-dereference" switch is passed to the load command, which suppresses such warnings. This enhancement is still considered provisional. The ultimate goal is to check layout by checksum and determine whether a cell matches the expected layout through checksum matching; once this is done, warnings will not be issued unless a checksum mismatch is found.
The "plow" command was restored to its original function, although it is still, on the whole, not very useful.
GDS compositing implemented. Magic views with the GDS_FILE property set will pull data directly from the GDS file when writing GDS output. This effectively makes the cell an "abstract view". However, there is still a difference in the handling of cells that are declared "abstract" by the presence of the property "LEFview": Abstract cells with this property (which usually come from reading LEF macro libraries) have no hierarchy, so the position in the GDS source file cannot be trusted to contain all the information in the cell. Therefore when writing GDS output, the entire GDS library (minus header and trailer) will be dumped to the output, with all cells other than the one being output given a unique prefix to avoid the possibility of conflicting with names of cells present in the design. This can lead to a very large output GDS file. By contrast, cells that are read from GDS with the "gds readonly true" option set are abstract, but they do not have the LEFview property set, and they contain the hierarchy of subcells from the GDS data, intact. Therefore when writing GDS output, only the data for the cell (and each of its subcells) is pulled from the GDS source file and written to the GDS output. Therefore, generally it is recommended to switch from "LEFview" abstract views to abstract views created from GDS data (or else views that are not abstract at all) before writing GDS output.
Added a "port" flag to layers in the cifinput/cifoutput sections of the techfile, to specify that text in a GDS file on the given layer:purpose pair are to be translated directly to port labels. The "text" flag remains, but is used to indicate GDS layer:purpose pairs that are for text (indicating the GDS data type, but not indicating whether the label is or is not a port). The "noport" flag is used to specify that a layer is for non-port labels only.
Added a variation of the "widespacing" DRC rule to accomodate run-length restrictions.
Added extraction device "csubcircuit", indicating a capacitor device that is to be extracted as a subcircuit rather than a primitive.
Added command option "ext2spice lvs" as a shorthand for setting a number of ext2spice options specifically for running LVS.
Added option "-hide" to the "lef write" command. This helps to keep output LEF macros from having unnecessarily complicated internal geometry by tracking all of the layout associated with each I/O pin. Instead, only geometry touching the cell boundary (or any single rectangle nearest to the boundary, if there is no geometry actually touching the boundary) is marked as "PIN" in the output LEF macro. All pins are surrounded by a gap wide enough to meet DRC spacing rules, and the rest of the cell is filled with obstruction layers on each metal layer present in the cell.
Added escape sequence substitution for DRC rules. This allows the dimension printed by the "drc why" command option to give measurements in microns (or microns squared, for area rules), and to track with grid scaling. This avoids the need to put both the internal and micron units in the DRC definition and avoids the possibility that they might not match each other.
Added command option plot svg to create scalable graphics, when using the Cairo graphics interface ("magic -d XR").
Added a new cifinput/cifoutput operator "boundary" which translates a layer:purpose pair to a cell boundary using the "property FIXED_BBOX" method.
Extended the device extraction in the techfile extract section to allow multiple extraction methods to be defined for a single tile type. The only restriction is that the definitions must all describe unique situations that are clearly unambiguous. This allows, e.g., nfet with ndiff for source and drain to extract as one device, but nfet with ndiff on source and mvndiff on drain to extract as a different device. Added an optional "+" or "-" keyword at the end of the device extraction definition to indicate a layer (usually a marker layer) that must be present (or absent) specifically for that device. This allows, e.g., an nfet with deep nwell underneath to be extracted differently than an nfet not in deep nwell, or a device with an "ESD" or "RF" marker layer to be extracted as a different device.
Revised substrate extraction to accomodate deep nwell layers. The "substrate" keyword in the extract section can take an optional list of layers starting with "-" to indicate layer types (such as deep nwell) that shield layout from the substrate.
Restored the use of "extresist" with the extension to handle subcells, ports, and all extraction device types (also see "Features Under Development" below).
Added antenna rule violation checks using the new "antennacheck run" command.
Added a "DRC Manager" window to the GUI (lightly developed).
Added new CIF operators "close", to close up internal holes created by grow/shrink operators; and "grow-min" to ensure a minimum layer width (which should be used only in simple geometry cases).
Date: September 16, 2014 to April 24, 2017
As of revision 158, this version is "DISTRIBUTION" code. It can generally be expected to be stable. There is, however, no guarantee as to the correctness of generated layout from magic, due to the current sketchiness of technology files available for current fabrication processes. It should produce correct output for the standard "scmos" set of technology files supported by the MOSIS foundry service. For all other processes (especially deep submicron) it is always best to have a good array of backup (commercial) EDA tools. Most foundries provide DRC (design rule checking) services (sometimes free), and it is always best to check for clean DRC before final submission, particularly in regard to antenna and density rules that magic does not check. All layout should pass rigorous DRC, LVS (layout vs. schematic), extraction, and simulation.
First planned effort is to resolve the long-standing problems with Magic's inability to understand the concept of a substrate. The extraction methods will be rewritten to generate a specific node for the substrate, understand how to connect the substrate to metal through p-taps, and be able to detect soft p-tap connection errors.This effort was largely completed with version 8.1.58 (April 6, 2015). The source code for 8.1 is now reasonably stable, and should be expected to work without undue issues. The completed changes are mostly reflected in Magic's ability to extract the substrate correctly in a hierarchical netlist.
Date: Februrary 3, 2009 to September 16, 2014
Version 8.0 adds outline vector fonts (courtesy of the freefont project), and aims to clean up a lot of problems associated with labels in Magic. Version 8.0.22 (December 2008) has the first reasonably stable code for handling vector fonts; all the display, manipulation, and selection routines for both X11 and OpenGL are complete.In addition, Version 8.0 adds some "cifoutput" operators for use with the new "cif paint" command, for manipulating layout using boolean operators.
In 2012, I developed hierarchical SPICE output in conjunction with netgen development version 1.4 (now the distribution version). Magic version 8.0 has a number of new extraction features, such as declaring parameters to be passed to subcircuits, and allowing MOSFETs, resistors, and other devices to be output as subcircuits.
Date: Februrary 9, 2006 to February 3, 2008
Revision 2 contains extensions of the technology file format that allow multiple DRC styles, style variants, and a scaling factor which allows DRC rules to be written in vendor dimensions, which are rounded up to the nearest lambda or internal unit.The "extract" section's capacitance descriptions were simplified to allow simple translation between a process description document and the magic techfile.
Major overhaul of the point-to-point maze router, which now works decently well, and doesn't crash the program.
Support for HPGL and HPRTL was added to the raster and PNM plot routines.
Added layer and cell locking capability (commands "tech layer lock" and "instance lock", respectively).
Added the ability to parse a "site.def" file, which is untouched by re-installation of the software.
Revised the contact generation algorithm to place contact cuts in non-rectangular and non-manhattan areas.
Added an extraction method for FET devices with asymmetric source and drain.
Modified subcircuit device extraction to allow parameter passing to SPICE subcircuit calls.
Date: Februrary 9, 2006 to February 3, 2008
Date: September 12, 2003 to Februrary 8, 2006
- Contact Image method
Contacts in the technology file are no longer subject to the restrictions outlined in the current maintainer's manual. Contacts may connect any number of planes. The "home plane" of the contact is irrelevant, as long as it has one. Internally, magic no longer creates derived types for each "image" of each contact type on every plane connected. This relieves a lot of the problems associated with overrunning the built-in layer limit in magic for technologies with a lot of metal layers.The paint and erase tables have also been revised and better reflect the nature of contacts as existing "between" planes. Important note (see release noted for Revision 29, above): One result of the change is that it is no longer possible to stack contacts that share one or more planes unless those contacts have been declared to be stacking. It was possible to stack contacts this way under magic-7.2 and earlier versions, although it violates the database structure and so should probably not be trusted. To ensure that layouts of this type read correctly into magic-7.3, the conversion program (see the download table) should be applied to the original technology file to create an equivalent technology file with stackable contacts, and the layout viewed with the new technology file.
The restriction that no two contact types may have the same residues has also been lifted (as of revision 25). It is now legal to define, for example, types "via" and "via_cut" as both connecting metal1 to metal2, but have them treated differently by the design rule checker and by the CIF/GDS I/O handler.
- Stacked Contact method
To alleviate the necessity of defining separate contact types for every combination of stacked contacts, magic 7.3 allows contacts to be directly stacked on each other. This is no small feat. Under this method, contacts need to only be defined as connecting two layer types. This method is completely backwardly-compatible with the original defined stacked-contact types (e.g., pm12contact or m123contact). However, it is preferred to explicitly define only contacts connecting two neighboring planes, and define all the combinations as "stackable" types, rather than to define various combinations of contacts as separate contact types.The method has been tested on most sections of the magic code but may still break certain functions. Revision 4 corrects some of the weirdnesses with the stretch command. These weirdnesses were actually unresolvable in prior magic versions. Now, if a selection area passes between two contacts, and one contact is stretched away from the other, neither contact is resized, but the area between is filled with the residues common to both contacts. Revision 27 removed a few more problems with the selection operations such as stretch, and revision 29 has resolved (hopefully) all of the remaining problems with the paint and erase tables, especially for handling the stacking type name aliases for reading layout files drawn using an older technology file without stacking types.
Revision 1 of magic 7.3 requires the use of the keyword "stackable" to generate stackable contacts. This allows complete backwards compatibility (not counting bugs!) with versions 7.2 and earlier, and does not generate stacked contact types where they were not intended. New technology files are not required to use the stacked contact methods, but should do so simply because it's easier, more compact, and backwardly compatible. And it's the Right Thing To Do! The new syntax for the "contact" section of the techfile is:
stackable type1 type2 [type3 ...]The first style allows contact type type1 to stack with one or more other contact types, as listed on the remainder of the line with a space-separated list of contact types.
stackable type1 type2 [alias12] [type3 [alias13] ...]
stackable type1
stackable
The second style is similar, but allows one or more aliases to be defined for each stacking type. These aliases take precedence over the default name generated internally by magic for the stacking type (which is to add a "+" between the short names for the two types, such as "pc+v"), and are used to facilitate compatibility with layouts generated using the explicitly-defined stacked types. Thus, the line "stackable pc via pm12contact,pm12c" will allow poly contact and via to stack, and will also tell magic to accept the layer name "pm12c" as equivalent to a combination of poly contact and via. Layout (.mag) files containing layer "pm12contact" will be handled appropriately, as will commands "paint pm12c" and "erase pm12c".
The third style will generate stacked contacts between type1 and all other contact types currently defined with which stacking is possible.
The fourth style will generate all possible stacking types between pairs of contacts already defined.
Normally, one would define all contacts first and use the "stackable" definitions at the end of the "contact" section. It is illegal to use a contact type name in a "stackable" definition that has not been previously defined in the "contact" section. One common situation where you would want a contact line after "stackable" is for the pad, as one normally does not allow the pad layer to be stacked with any other contact types. Regarding the pad, note that magic 7.3 eliminates the need to define pad on a couple of metal planes plus an extra plane for passivation to avoid confusing it with stacked vias. One simply defines pad as the collection of all metal layers it contains. A plane for "oxide" or "passivation" is not necessary, and generally not useful.
- General Image method
There are now composite layers in addition to contacts. These layers represent (primarily) devices such as FETs and capacitors. The idea behind composite layers (which I attribute to Philippe Pouliquen) is that certain devices should have images on multiple planes, like contacts do, but do not necessarily contact the planes. Using composite types, it is possible to separate the poly, poly2, and active planes. For example, "nfet" can be a composite type on planes active and poly, with residue types ndiffusion and polysilicon. As of magic version 7.3.21, this is not completely implemented. It is possible to define composite images in the "contact" section (which can also be called the "image" section, as being more appropriate for the general image method), using the keyword "device" or "contact" followed by the normal syntax for a contact. If the keyword is missing, "contact" is assumed, for backwards compatibility. The method, however, needs to keep track of device layers separately from contact layers; this lack of information currently leads to the inability to properly specify DRC rules for composite layers.- General Macro method
Starting with revision 60, mouse buttons are treated like keys for the purpose of defining macros. That means there are no longer internal button handlers in magic, and button functions may be bound to any magic command, Tcl procedure, or combination of both. To facilitate this, several commands have been extended to incorporate the functions traditionally performed by button presses. In particular, the "cursor" keyword has been added to the "box" command to allow the box to be moved relative to the X11 pointer position, and the option box corner has been added to allow the box corner resizing. The button-release event is no longer supported, and the ungainly mixed-button pushing functions for manipulating the cursor box have been replaced by a somewhat more usable Shift-key-plus-button method.Unlike earlier versions, macros are now defined as hash tables, and each window type (layout, color, netlist, wind3d) maintains its own set of macros. The "tool" command is now a script, as with this binding method, the action of the tool command is to change the button bindings in the layout windows.
As of revision 80, there is a new MacroSubstitute command that allows the graphics package to make substitutions for predefined escape sequences in the macro string. The intention is to follow the usual Tk syntax using the percent ("%") symbol to denote sequences. One such substitution has been added in revision 80, which is "%W" to indicate the drawing window reporting the key event that triggered the macro call.
- Interactive graphics
Developed largely between revisions 75 and 80, the implementation of graphics backing store overcomes pretty much all of the limitations of the 24-bit and OpenGL graphics compared to the original 8-bit pseudocolor model. This is not to be confused with the X11 backing store---magic's backing store is specifically implemented to cache the layout drawing separately from the "highlights" (box, selections, feedback), and use fast copying from backing store to erase the highlights. In addition, scrolling the layout is made faster by copying part of the backing store from one screen location to another, and redrawing only the remaining parts.Because backing store allows the highlights to be erased and redrawn in "real time", interactive graphics are suddenly feasible. Between revisions 75 and 82, I added three interactive graphics features. These are:
- pick tool
- The first new tool in magic in decades. This tool connects the new select command options to button and pointer motion events, allowing drag-and-drop style manipulation of paint, labels, and cells.
- wire tool
- The wire tool was always cumbersome, mostly due to the inability to predict precisely where magic would put the next wire route. The new, improved wire tool adds the single important feature of tracking the next wire route using the selection box, and updating based on pointer motion.
- crosshair
- A crosshair cursor is extremely useful for checking vertical and horizontal alignment. Previously, it could not be implemented due to the slow refresh rate on highlights. Now it works like a good crosshair ought to. The Tcl/Tk GUI wrapper connects the crosshair command to pointer motion with a simple Options menu checkbox.
scmos8m.tech is an example technology file taking advantage of the new features. In particular, it makes use of the keyword stackable in the contacts section to define a very efficient set of stackable contacts in an 8-metal-layer process. In addition, it makes use of the format 29 extensions, including the asterisk notation for indicating the union of a layer and all contact types containing that layer as a residue, and the new DRC checking keywords "surround", "overhang", and "rect_only".Note how readable this file is compared to existing technology files (formats 28 and earlier). This technology file has been stripped down, removing high-voltage devices, metal fill layers, metal resistor layers, and the second polysilicon layer, and defining only one or two styles for CIF/GDS input, output, and extraction. However, with the new style, adding these back in will make the file only marginally less readable.
Caution, caution, caution. This technology file does not correspond to any specific fabrication process. It was created for demonstration and test purposes. To match a specific foundry process, values will need to be tweaked, layers added, etc.
scmos9m.tech is a slight modification of the above file for use with technologies defining nine metal layers. It requires magic 7.3 revision 6 (or newer), which defines the 9th metal layer in the graphics colormap and style files. Note how this file takes advantage of the new techfile enhancements, making the addition of the new top-metal layer trivial.
Note for AMD 64-bit users (January 2006): I had been having awful problems with the 64-bit version that seemed to be unrelated to magic but related instead to the NVidia graphics driver for the AMD 64-bit platform. Apart from magic, the server would crash on a fairly regular basis, and would crash upon exiting magic. I just updated to the version 8178 of the driver, and so far I have not seen any problems. The last buggy version of the driver that I installed was 7174; I don't know which exact version fixed the problem (there were 5 revisions between 7174 and 8178).There should be no bug fixes between versions 7.2 and 7.3, as for the time being, any required bug fixes will be made to both versions.
As of revisions starting in the mid-twenties or so, the above statement is probably no longer true. This partly reflects the intent to make version 7.3 the main development branch shortly (before the end of 2004).
Date: August 29, 2002 to June 3, 2004
I have been working hard on the next-generation "magic" product. While it is in no condition to be called stable, it is a working product and so I am releasing it as BETA code. This is an upgrade from the previous designation as ALPHA code, as several chips have been successfully designed and manufactured using version 7.2. For differences between the 7.1 CVS source version available from Cornell and the 7.2 development version posted here, please see the following sections.The new development version is 7.3, with the introduction of a complete overhaul of the way magic deals with contacts, allowing arbitrary stacked contacts. Currently this is in a ALPHA state. Information on this version can be found at the Magic 7.3 page.
Revision 36 was reposted on 4/21/03, as I fixed a bug in the extract section which was producing incorrect length and width values for any transistors extracted with technology files not using the new "device" keyword (which is basically all of them except for the default one that comes with the source). The revision number is not updated because I have Revision 37 still on my laptop at home, but did not have the chance to transfer it to my web host yet. However, the fix is critical for correct circuit extraction; otherwise, area and perimeter values are interpreted as length and width on read-in, producing poor results (to say the least).
Revision 37 introduces autoconf to magic. Inevitably, this will produce a whole new round of porting problems for Solaris, Cygwin, OS X, etc. However, once the essential bugs are ironed out, it should result in fewer porting problems overall. For the moment, both configure and make config methods are retained.
Revision 49 changes the "varargs" method to "stdarg" (one of the items in "TODO"). This became urgent when the latest version of gcc claimed not to support the varargs method for variable arguments any more. HOWEVER, the stdarg method is different on different operating systems. The GNU autoconf system checks for this. The original "make config" script does not. In "make config", the correct setting is made for Linux. However, until some bug reports come back, I'm not certain which systems this will or will not compile on.
Revision 55 incorporates a port to the 64-bit Linux platform. Correct operation has been confirmed on an AMD Opteron machine running RedHat GinGin64 (2.4.20 kernel), loading a design with a half-million standard-cell gates and a half-million nets.
- The "make config" process has been redesigned so that the interpreter (None, Tcl/Tk, or Scheme) option is offered at the beginning. Modular options are only prompted if they are available.
- Option THREADS is available for fully-threaded graphics handling in both X11 and OpenGL. This avoids the use of a forked "X11Helper" program, so it cannot be left around as a detached process.
- The ~cad "cad user" directory and associated directory structure is obsolete. It was rather unorthodox to begin with. Now magic relies entirely on the variable $CAD_HOME. A default value for this variable is set as the first prompt to "make config"; the directory so specified is the target root directory for installation. "/home/cad" is suggested if it exists, for reasons of backward compatibility; however, use of something more obvious like "/usr/local" is encouraged. Setting environment variable "$CAD_HOME" overrides the default value, as in previous versions. Installation to user directories is trivial (for those without root access, or those who want, for understandable reasons, to keep the ALPHA code in a relatively benign place and not overwrite existing, working versions of magic).
- OpenGL graphics have been fixed for use with multiple layout windows open at the same time. Slight single-pixel differences in positioning of boxes and rectangles due to OpenGL's different coordinate system has been (mostly) fixed.
- CIF writes to any precision, including nanometers, so is appropriate as output for deep submicron processes. Deep submicron is better handled so that scale factors in the tech file can be specified appropriately: "scalefactor 6.5" works for 0.13-micron processes, with cif grow/shrink factors listed in centimicrons; alternatively, "scalefactor 65 nanometers" works for 0.13-micron processes with cif grow/shrink distances listed in nanometers. The "calmaonly" keyword is deprecated. Note that not only are odd numbers allowed for the scalefactor, but also floating-point.
- The optional "reducer" keyword is ignored for the cifoutput scalefactor entry. CIF output is reduced by the maximum amount possible, and this is computed automatically by checking the greatest common factor among all the CIF output grow, shrink, bloat, and squares factors.
- The restriction that the magic internal grid must be equal to lambda has been lifted. This is the default, but it can be changed using the (new) "scalegrid" command, if higher or lower resolution is required. In addition, the "snap" command has been redefined so that the cursor can be made to snap to either internal units ("snap internal") or lambda units ("snap lambda"). Snapping occurs only on mouse-based actions. Command-based actions such as "bbox" and "move" always have units specified in lambda. However, units are not restricted to integers, so movement in internal units can be specified by floating-point distances ("move w 3.1").
- CIF input automatically takes care of internal vs. lambda grid scaling so that no information is lost in CIF/GDS reading due to input coordinates specified in fractional lambda coordinates. Magic file output is scaled to the largest scale which keeps all measurements on integer boundaries, so files do not tend to continuously fracture themselves into tinier and tinier internal units.
- A new command port turns labels into "ports", allowing special handling of cells as subcircuits with respect to extraction and simulation. Cells containing ports are extracted, but this extraction is ignored by "ext2spice", which treats the cell as a "black box". "ext2spice" generates an "X" (subcircuit call) record in place of the cell, with the arguments in the order that the ports are declared (use port help for usage information). This is a useful and powerful way to handle all sorts of situations from standard cells (where a pre-characterized simulation model may be preferred over magic's own extraction) to resistors, capacitors, inductors, and any special geometry with unusual features which cannot be handled by magic's extraction algorithm.
Note: This replaces a method introduced in one of the early revisions of 7.2 in which the ports were identified by the coincidence of a layer called "subcircuit" and labels in the cell. The new method is a response to complaints about the ugliness of the "subcircuit" layer method. Any layout generated with the earlier method should update by hand-editing the .mag files, removing "subcircuit" layer sections, and adding "port" lines after each label which is intended to be a port.- In conjunction with the "subcircuit" method, the "extresis" command has been extended to include the command "extresis geometry". When this is selected, subsequent execution of the command "extresis" will generate a geometry file in place of each cell with ports. This geometry file is in the format of input for the "FastHenry" inductance field-solver program. It is appropriate for extracting values for spiral inductors and other RF structures.
- Colormaps and style files have been extended for use with up to 10 metal layers (up to revision 19, the top 3 metal layers overwrote some styles used by the MOSIS technology file set. As of revision 19, the handling of styles has been revised, the overwritten styles reverted to their original descriptions, and additional styles added for handling 8 metal layers and associated vias).
- Memory management has been improved. Now, only the current CIF input and output style and extract style are held in memory. Changing styles forces a re-read of the technology file. This change reduces memory overhead from 120MB to 27MB!
- Commands"cellname" and "instance" replace the commands "parent", "child", "list", "listall", and "listtop". The command "cellname" expects a cell definition as an argument, whereas "instance" expects a cell instance name as an argument.
- A command "element" has been added for annotating the layout. The main purpose of this is to allow other programs to display information back onto the magic layout (IRSIM does this, but using its own method. This method is more general and not restricted to IRSIM). Presently the "element" command supports rectangles, lines, and text, although styles are limited to magic's known styles from the ".dstyle5" file. Option "element configure" can be used to change element position, change text, or add and delete styles. Note that with elements, styles are drawn in the order they are added to the element, not in numerical order of the style index, as they are in the layout. Option "element names" returns a list of all the known elements, and "element inbox" returns a list of all element which are found within the confines of the edit box's current position.
- A new command "tech" basically replaces and extends the wizard command "showtech" (which still exists). In particular, several options (do "tech help" for a complete list) returns various properties of the technology. A new option "tech layers" now replaces the magic "layers" command. The syntax "tech layers *" vs. "tech layers" differentiates between returning a list of all canonical layer names and a list of all names plus aliases, respectively. The wildcard character is in keeping with the "tech layer name" syntax which returns the canonical name of layer name or alias name.
"tech load filename" reloads the technology file or loads a new technology file. This was introduced in version 7.2.12 and does little checking against the previous technology, so it can really foul up an exising, loaded layout. Mainly intended for use in debugging new technology files. Beginning with Revision 31, the option "tech load filename [-noprompt]" is available, which is useful for including in a project directory's .magic file, to force loading of a specific technology file.- As of revision 12, version 7.2 renders outlined layers by drawing the border around the layer instead of drawing a border around each tile. This allows, for example, non-square contacts and beveled-corner pads to be drawn without filling in all the internal tile structure.
- Revision 19 changes the way the display style file is written, and moves from "dstyle5" to "dstyle6". The new style file is divided into three sections, "display_styles", "layout_styles", and "pale_styles". Each section is numbered separately. The "display_styles" section is the part containing the built-in styles for things such as the cursor box, highlighting, feedback, window border drawing, and defining a palette of solid colors. The order of these styles is fixed, as the ordering is hard-coded into the magic source. The "layout_styles" section defines the set of styles which can be used for layout types. The ordinal number (first column) for the style is backwardly-compatible to past technology file versions, which declare style by number only. However, the numbers do not need to be in ascending order, and styles may now be inserted between existing styles. The numbers assigned to existing styles should not be changed, though, to retain the backward-compatibility. The "pale_styles" section defines all of the styles used to draw layout in non-edit cells. Typically these are defined to be lighter or "paler" versions of the styles defined in the "layout_styles" section. The entries in the "pale_styles" section must match the entries in "layout_styles" one-to-one (this restriction may be lifted in the future).
- Revision 14 introduces the "techbuilder" Tcl script. This is now a skeleton script to be worked on, but the general concept is a user-friendly interface to building new technology files from scratch, or modifying existing technology files. The primary intention is to hide the ugly and arcane details of the CIF input and output and the DRC sections, and at the same time produce a layout file which doubles as a complete design rule reference manual.
- Tcl/Tk. The major feature of version 7.2 is the incorporation of Tcl/Tk as not only the interpreter, but a replacement for both magic's terminal and graphics input and output. Tcl/Tk features are listed in the following section.
- Beginning around revision 50, magic has the ability to read LEF and DEF format files, and to write LEF format libraries. Implementation is limited in some respects but should be expanded as the need arises.
- The techfile format has been upgraded (now in format 29) for the purpose of reducing complexity and increasing readability of the file. New features are meant to discourage the use of preprocessing to generate the technology files. The asterisk notation (e.g., "*m1") indicates the union of the specified type and all contact types containing that type as a residue. DRC checking types "overhang", "surround", and "rect_only" duplicate edge4way functions, but are easier to read.
scmos8m.tech is an example technology file taking advantage of the new features.- The use of environment variable "MAGIC_COLOR" has been deprecated in favor of calling magic with "-d 8BIT", "-d 16BIT", or "-d 24BIT" to force a specific graphics mode (note that this is case-insensitive).
- The magic terminal and graphics input/output have been completely subordinated to Tcl/Tk. The magic prompt is a Tcl prompt; all Tcl commands may be executed from the command line. Magic commands may also be executed from the command line, although in some cases where magic commands have the same name as Tcl commands, the Tcl version of the command is forced to take precedence, and the magic version of the command must be specified with the fully-qualified namespace "magic::" prepended to the command.
- Some commands return values back to Tcl. Currently this has only been implemented for the "path" and "getnode" commands, but will be extended.
- "openwindow [cellname]" has been extended to "openwindow [cellname [windowname]]". Under Tk, "windowname" is a pathname for a Tk widget. The resulting window will be created but NOT mapped; it should be mapped with the Tk "pack" command. This allows windows to be generated inside an application frame, such as a GUI.
- Full-frame GUIs are facilitated by the added command-line argument "-n[owindow]" passed to magic on startup. This prevents an initial window from being generated. The calling application is then responsible creating all windows with the "openwindow" command.
- Commands have been extended to include the syntax "windowname magic_command". This allows any command to be directed at a specific layout window. For example, painting can be done in window ".magic2" by the command ".magic2 paint m1".
- The "TkCon" console window has been incorporated into magic. Magic may be run with or without the console (by executing script "magic" with or without argument "-c[onsole]"), but the TkCon console more faithfully reproduces the behavior of the original magic input/output, with the cursor indicating pending DRC checks, and implementing command-line history and automatic function completion. Commands can be entered from the layout window in either method, but with the TkCon console, commands can be partially entered in one mode and completed in the other. The TkCon also "pretty prints" the input and output, highlighting commands and variables with special colors, and painting error messages in red and other informative output in blue.
- "ext2spice" and "ext2sim" are incorporated as modules under Tcl, renamed to "exttospice" and "exttosim", respectively, and are loaded automatically. They become available from the Tcl command prompt as "magic::exttospice" and "magic::exttosim", respectively. These namespaces are "pushed" so that the commands may be executed simply by typing "exttospice" and "exttosim".
- The GUI-wrapper implementation has been aided by expanding the commands "windowcaption" and "windowscrollbars". "windowcaption" with no arguments returns the current window title caption. One argument, a valid Tk window, causes the magic layout window not to render its own caption but redirects the caption to the specified Tk window, which should be of a widget type that can accept the command "configure -text". "windowscrollbars" with two arguments, both valid Tk windows, causes the magic layout window not to render its own scrollbars, but redirects the window position information to the specified Tk windows, which should be Tk scrollbar widgets.
- The "setpoint" command, under Tcl, returns two point values (x y coordinates), one for screen coordinates, in pixels, and one for layout coordinates, in magic internal units.
- In 8-bit (pseudocolor) visuals, the layout colormap installs itself into the TkCon console window, so that the console maintains the same colors as the cursor moves between layout windows and the console. This greatly improves the use of magic in pseudocolor mode!
- Magic revision 14 re-incorporates the interactive IRSIM simulator into the Tcl version. See the section below on using IRSIM.
- Options "plow", "plot", and "route" are now modularized. They auto-load into memory upon execution of an associated command, and otherwise remain unloaded. The "make config" script allows each of these sections to be modularized (choice "module"), incorporated into the main executable (choice "yes"), or ignored (choice "no"). AT the moment, however, the command "specialopen netlist" does not auto-load the route module, as it should.
- When OpenGL graphics are compiled with the Tcl/Tk version, Magic has a new command "specialopen wind3d". This command brings up a 3D-view window (see screenshot, below). The 3D window has its own command set, accessible by typing the Tk window pathname (.magic3d) as a command. Type ".magic3d help" to get a full list of commands. The window also has a set of keystroke commands. Type "?" in the 3D window for a list of these keystrokes.
- The new command "search" allows low-level tile searches on a design hierarchy, using a TCL procedure as the callback function. The syntax is "search layers proc", where the search routine calls the TCL procedure proc for each tile in the design matching one of the types in the layer list layers. The TCL procedure will be passed five arguments, llx lly urx ury ttype, where the first four are the coordinates of the tile relative to the root cell, and ttype is the name of the layer type defined by the tile.
- The "Pinout List" tool aids in managing labels on the padframe. The pop-up window has three buttons. Search enumerates all the pads in the design and generates a list. The list shows up in the window; when any entry is selected, the pad area is selected and the window view changes to center on that pad. Edit semi-automatically generates and handles labels for the selected pad. Update recreates the pad list, reflecting any changes made to the "canonical" name of each pinout.
- Implement a better FET extraction method for resistors, corresponding to the method that handles annular transistors. Probably a good rule-of-thumb would be to use the "quick and dirty" method when a FET gate layer is restricted to only one tile (in which case (length, width) and (area, perimeter) pairs can be derived from each other, and use the more exhaustive method when more tiles are involved. Thus, fast processing would be ensured for most designs.
- Implement better handling of contacts in GDS output. GDS output size can be significantly reduced by putting contact cuts into subcells and arraying the subcell. This would be the domain of the "squares" function. However, GDS input should be able to flatten such instances to recover magic's composite form of contacts. This is a major issue, because magic's boolean operations on GDS and CIF input are done on a per-cell basis, so contact cuts in subcells which are missing layers can disappear entirely. Even when handled correctly by the cifinput section of the tech file, some configurations will turn into generic contacts and vias, not as easy to deal with as magic's composite contact areas.
- Correct GDS arrays. Magic arrays may be indexed from high to low numbers, which is not allowed in GDS. Such arrays need to be rotated in GDS output, with individual cells counter-rotated to match.
- Code cleanup. Code should compile cleanly when "-Wall" is added to the gcc compiler flags. See the "TODO" file. Note that many of these items have been done in magic version 7.3, leaving version 7.2 for a loss.
- Implement Timberwolf Place-and-Route as a Tcl-based program to interact with Magic.
- Implement an OpenAccess database interface to Magic.
- Introduce SPICE as the main interactive simulator under the Tcl/Tk version. This has largely been accomplished by Stefan Jones (MultiGiG, Ltd./Inc.) with tclspice, available from SourceForge.
- Get the "element" command working with feedback from SPICE (i.e., a more interactive interface to tclspice than is currently available).
- Make a few more changes to the colormap and style files. The colormap should declare color names; the style file should be able to use colors by index, by name, or by standard X11 name or #rrggbb notation.
- Extend the geometry extraction and inductance solving, with automatic generation of SPICE subcircuits from FastHenry.
- Further reduction of memory overhead can be achieved by rearranging the allocation of vectors and matrices in the ExtStyle structure. Right now, the memory savings doesn't seem to justify the effort of recoding all the affected files.
- OpenGL no longer hangs when multiple windows are present
- CIF input and output has been corrected for use with expansion factors such as the "nanometers" keyword.
- Memory overhead on startup has been reduced by almost 100MB, from 120MB to 27MB (Tcl/Tk takes up an additional several MB).
- Error in extracted perimeter values for n-diffusion nodes fixed.
Date: September 1, 2000 to February 19, 2004
The source for the all-inclusive version 7.1 is available as CVS source. To download the source, do the following:
- Grid redefining to match CIF/GDS input (March 2002) (Tim Edwards)
- Non-manhattan geometry extensions (March 2001) (Tim Edwards)
- Improved compilation/install process (Jeff Solomon et al.)
- Scheme interpreter from 7.0 (Rajit Manohar)
- OpenGL interface from 6.5.2 (Tim Edwards)
- Windows 95/98/NT version (Holger Vogt)
- Readline interface (Rajit Manohar and Philippe Pouliquen)
- Up-to-date MOSIS tech files included with the source (Wes Hansford and Jeff Sondeen)
- PostScript plot option based on "pplot" (Tim Edwards)
- PNM plot option for bit-mapped output (Rajit Manohar)
- Multiple-user file locking (Michael Godfrey)
- Cell hierarchy listing commands (Philippe Pouliquen)
- Bug fixes (everybody)
- Updated manuals and tutorials, including all extensions
The password for user anoncvs is anonymous. The CVS checkout command will create a directory called simply "magic" in the current working directory.
% cvs -d :pserver:anoncvs@csl.cornell.edu:/ufs/repository login % cvs -d :pserver:anoncvs@csl.cornell.edu:/ufs/repository checkout magic The Magic CVS source page contains instructions and additional information on the very latest work-in-progress development version of Magic.
For more information on features of Magic 7.1 that stem from the Magic 6.5.2 implementation, please take a look at the Magic-6.5.2 page.
Date: September 1, 2000
Warning: You will need hardware-accelerated 3D graphics support for OpenGL to make reasonable use of this program. This should be readily available on all SGI platforms; check for compatibility with other systems.
Currently, Linux requires an OpenGL-compliant video card and the Xi Graphics, Inc., 3D Accelerated-X server (see http://www.xig.com). Other OpenGL-capable X-servers are available from MetroLink, Precision Insight, SuSE, and RedHat. The XFree86 server, beginning with version 4.0, supports OpenGL and also 8-bit color overlays. The overlay visual is the best way to use the X11 version in an otherwise-24-bit graphics environment.
Note that most X servers which have OpenGL support will provide it whether you have the accelerated hardware or not. Functions which do not have hardware support will be emulated in software. Running magic with OpenGL graphics using software-emulated color blending is an exercise in futility.
Graphics cards typically need 32MB of video RAM to fully implement OpenGL in the kind of resolution (1280 x 1024 or more) that you would want to have in order to do VLSI layout (here's a hint: Don't do VLSI layout on anything smaller than a 19" monitor).
For comparison:
| email: | 
|
Last updated: January 9, 2024 at 4:38pm
