Magic
Original author(s)John K. Ousterhout, Gordon T. Hamachi, Robert N. Mayo, Walter S. Scott, George S. Taylor
Developer(s)Magic Development Team
Initial releaseApril 1983 (1983-04)
Stable release
8.3.153 / April 7, 2021 (2021-04-07)
Repositoryhttps://github.com/RTimothyEdwards/magic
Written inC
Operating systemLinux
Available inEnglish
TypeElectronic design automation
LicenseBSD license[1]
Websiteopencircuitdesign.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.

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

See also

References

  1. ↑ http://opencircuitdesign.com/magic/archive/papers/copyright.pdf
  2. ↑ A Collection of Papers on Magic.
  3. ↑ IRSIM switch-level simulator
  4. ↑ "Magic Development". opencircuitdesign.com. Retrieved 2022-04-27.
Notes
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.