Magic

MagicOriginal author(s)| John K. Ousterhout, Gordon T. Hamachi, Robert N. Mayo, Walter S. Scott, George S. Taylor

|

Developer(s)| Magic Development Team
Initial release| April 1983; 43 years ago (1983-04)
Stable release|

8.3.153 / April 7, 2021; 5 years ago (2021-04-07)

Repository| https://github.com/RTimothyEdwards/magic
Written in| C
Operating system| Linux
Available in| English
Type| Electronic design automation
License| BSD license[1]
Website| opencircuitdesign.com/magic/
VLSI layout of an inverter circuit using Magic software

Magic is an electronic design automation (EDA) layout tool for very-large-scale integration (VLSI) integrated circuit (IC) originally written by John Ousterhout and his graduate students at UC Berkeley. Work began on the project in February 1983. A primitive version was operational by April 1983,[2] when Joan Pendleton, Shing Kong and other graduate student chip designers suffered through many fast revisions devised to meet their needs in designing the SOAR CPU chip, a follow-on to Berkeley RISC.

Fearing that Ousterhout was going to propose another name that started with "C" to match his previous projects Cm*, Caesar, and Crystal, Gordon Hamachi proposed the name Magic because he liked the idea of being able to say that people used magic to design chips. The rest of the development team enthusiastically agreed to this proposal after he devised the backronym Manhattan Artwork Generator for Integrated Circuits. The Magic software developers called themselves magicians, while the chip designers were Magic users.

As free and open-source software, subject to the requirements of the BSD license, Magic continues to be popular because it is easy to use and easy to expand for specialized tasks.

## Contents

* 1 Differences
* 1.1 Design rule checking
* 2 Internals
* 3 File formats
* 3.1 Importing & Exporting
* 4 See also
* 5 References
* 6 External links

## Differences

The main difference between Magic and other VLSI design tools is its use of "corner-stitched" geometry, in which all layout is represented as a stack of planes, and each plane consists entirely of "tiles" (rectangles). The tiles must cover the entire plane. Each tile consists of an (X, Y) coordinate of its lower left-hand corner, and links to four tiles: the right-most neighbor on the top, the top-most neighbor on the right, the bottom-most neighbor on the left, and the left-most neighbor on the bottom. With the addition of the type of material represented by the tile, the layout geometry in the plane is exactly specified. The corner-stitched geometry representation leads to the concept of layout as "paint" to be applied to, or erased from, a canvas. This is considerably different from other tools that use the concept of layout as "objects" to be placed and manipulated separately from one another. Each concept has its own strengths and weaknesses in terms of both practical use and speed of computation. The corner-stitched representation is particularly well suited to searches within a single plane, for which it excels in speed. It is not particularly well suited to extremely large databases: The need to maintain four pointers for each tile, as well as the need to store tiles representing the space between areas of material on a layout, makes it more memory-intensive than object-based representations.

An extension to the corner-stitched geometry representation called the "split tile" method, added in version 7.1, allows true representation of non-Manhattan geometry. This method allows each tile in the database to specify two material types, in which case the tile is regarded as being bisected by a diagonal line from corner to corner, with one material type on one side of the diagonal and the other material type on the other side of the diagonal. An additional flag specifies whether the diagonal runs from the top left corner to the bottom right, or the top right corner to the bottom left. The split-tile method has the advantage that nearly all rules that apply to corner-stitched geometry apply, unaltered, to split tiles. A further advantage is that all non-Manhattan geometry must have corners lying on the database internal grid. This makes it impossible to generate geometry that is off-grid within a single plane, a rule error for most fabrication processes that is a common problem with object-based representations.

### Design rule checking

Magic features real-time design rule checking, something that some costly commercial VLSI design software packages don't feature. Magic implements this by counting distance using Manhattan distance rather than Euclidean distance, which is much faster to compute. Magic versions from 7.3 properly compute Euclidean distance when given the `drc euclidean on` command. Euclidean distance checks are a trivial extension of the Manhattan distance checks, and require very little overhead. On a straight-line edge, the Manhattan and Euclidean distances are the same. Only on corners do the two distances diverge. When checking corners, it is only necessary to keep track of the direction of search from the corner point. Any geometry found inside the square representing the Manhattan distance from the corner undergoes an additional check to see if the same geometry lies outside the quarter-circle radius representing the Euclidean distance. Since this additional check is applied only to geometry found in violation of the Manhattan distance rule, it is not invoked often, so the computational overhead is very small.

Magic currently runs under Linux, although versions exist for DOS, OS/2, and other operating systems. Magic is frequently used in conjunction with IRSIM[3] and other simulation programs.

## Internals

It uses Tcl/Tk under the hood.[4]

## File formats

### Importing & Exporting

* Magic supports CIF/Calma GDS files.

## See also

* XCircuit
* Netgen

## References

1. ↑ http://opencircuitdesign.com/magic/archive/papers/copyright.pdf [bare URL PDF]
2. ↑ A Collection of Papers on Magic.
3. ↑ IRSIM switch-level simulator
4. ↑ "Magic Development". http://opencircuitdesign.com/magic/develop.html.

Notes

* Ousterhout, John K.; Hamachi, Gordon T.; Mayo, Robert N.; Scott, Walter S.; Taylor, George S. (December 1983). "A Collection of Papers on Magic". EECS Department University of California Berkeley Technical Report No. UCB/CSD-83-154. https://www2.eecs.berkeley.edu/Pubs/TechRpts/1983/5295.html.
* Ousterhout, John K. (January 1984). "Corner Stitching: A Data-Structuring Technique for VLSI Layout Tools". IEEE Transactions on Computer-Aided Design 3 (1): 87–100. doi:10.1109/TCAD.1984.1270061. http://techreports.lib.berkeley.edu/accessPages/CSD-83-114.html.
* Ousterhout, John K.; Hamachi, Gordon T.; Mayo, Robert N.; Scott, Walter S.; Taylor, George S. (1984). "Magic: A VLSI Layout System". 21st Design Automation Conference Proceedings. Piscataway, NJ: IEEE Press. pp. 152–159. doi:10.1109/DAC.1984.1585789. ISBN 0-8186-0542-1. http://dl.acm.org/citation.cfm?id=800790.
* Taylor, George S.; Ousterhout, John K. (1984). "Magic's Incremental Design-Rule Checker". 21st Design Automation Conference Proceedings. pp. 160–165. doi:10.1109/DAC.1984.1585790. ISBN 0-8186-0542-1. http://dl.acm.org/citation.cfm?id=800791.
* Scott, W.S.; Ousterhout, John K. (1984). "Plowing: Interactive Stretching and Compaction in Magic". 21st Design Automation Conference Proceedings. pp. 166–172. doi:10.1109/DAC.1984.1585791. ISBN 0-8186-0542-1. https://www.researchgate.net/publication/4218441.
* Hamachi, Gordon T.; Ousterhout, John K. (1984). "A Switchbox Router with Obstacle Avoidance". 21st Design Automation Conference Proceedings. pp. 173–179. doi:10.1109/DAC.1984.1585792. ISBN 0-8186-0542-1. http://dl.acm.org/citation.cfm?id=800033.800793.
* Scott, Walter S.; Ousterhout, John K. (1985). "Magic's Circuit Extractor". IEEE Design & Test of Computers 3 (22nd): 286–292. doi:10.1109/MDT.1986.294914. https://www.researchgate.net/publication/221061372.

## External links

* Magic VLSI Layout Tool
* Magic, Man Pages & Tutorial
* Magic, Old version
* IRSIM
* VLSI Layout of 16 bit Full Adder using Magic software

* v
* t
* e

CAD software

Free and open-source|

| Mechanical|

* BRL-CAD
* BudCAD [uk; uk; БудКАД]
* FreeCAD
* HeeksCAD
* LibreCAD
* Open Cascade Technology
* OpenSCAD
* QCAD
* Salome
* SolveSpace

|

Electrical|

* Electric
* FreePCB
* Fritzing
* gEDA
* KiCad
* kTechLab
* Magic
* ngspice
* Oregano
* QUCS
* XCircuit

Proprietary|

| Mechanical|

* Alibre Design
* AutoCAD
* Autodesk Alias
* Autodesk Inventor
* Autodesk Revit
* ArchiCAD
* BricsCAD
* CADKEY
* CATIA
* Cimatron
* Cobalt
* DesignSpark Mechanical
* FastCAD
* FastCAD
* FINE
* FORAN
* Fusion 360
* GstarCAD
* IRONCAD
* KeyCreator
* MEDUSA
* MicroStation
* NX
* Onshape
* PDMS
* Rhinoceros 3D
* Grasshopper 3D
* RUCAPS
* Solid Edge
* SolidWorks
* SpaceClaim
* T-FLEX CAD
* Tinkercad
* TurboCAD
* VariCAD

|

Electrical|

* Allegro
* AutoCAD Electrical
* Autotrax
* Altium Designer
* BoardStation
* CADSTAR
* CircuitMaker
* CR-2000
* CR-3000
* CR-5000
* CR-8000
* Delta Design
* DesignSpark PCB
* DipTrace
* EAGLE
* EasyEDA
* Easytrax
* FreeStyle
* IntegraStation
* LTspice
* Micro-Cap
* Multisim
* OrCAD
* PADS
* P-CAD
* PCB
* Protel
* Proteus
* Pulsonix
* SolidWorks Electrical
* Tango
* TARGET
* TopoR
* Ultiboard
* Upverter
* Xpedition

File formats|

* 3MF
* ACIS
* AMF
* C3D
* CKD
* DSN
* DWF
* DWFX
* DWG
* DXF
* IGES
* OBJ
* OpenDWG
* PLY
* PSpice
* SES
* STEP
* STL

Modeling kernels|

* ACIS
* C3D
* Open Cascade Technology
* Parasolid
* RGK
* Romulus
* KernelCAD
* ShapeManager
* Teigha
* IntelliCAD
* SMLib

Old|

* DAC-1 (1963)
* Sketchpad (1963)
* UNISURF (1968)

History of CAD software

0.00

(0 votes)

Original source: https://en.wikipedia.org/wiki/a. Read more

|

0.00

(0 votes)

|

Retrieved from "https://handwiki.org/wiki/index.php?title=Software:Magic&oldid=739051"
*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template