An Introduction to IC Design Under Linux
In order to cram as much as possible onto the IC, modern processes define design rule measurements in microns, mm. A micron is one millionth of a meter. For example, in one particular CMOS process m1 wires must be at least 0.8mm apart from each other and at least 0.6mm wide. Each rule is independent of the others and is specified in fractions of microns.
Magic design rules, on the other hand, are expressed not in microns but in multiples of a unit called lambda, l. Introduced in Carver Mead and Lynn Conway's classic book Introduction to VLSI Systems, lambda is the “quantum” for the rules—all spacings and widths must be multiples of lambda. The previous rules concerning m1 spacing and width would be expressed in terms of lambda as 3<<tt>l and 2[lambda] respectively, where <<tt>l = 0.3<<tt>mm.
Note that using lambda rules is a little costly in terms of area. The spacing rule is now effectively 0.9~<<tt>mm instead of 0.8~<<tt>mm; however, basing rules on lambda allows for scalable designs. The scalable rules allow us to create one design and be confident that it is valid (i.e., it violates no design rules) regardless of the value of lambda. For example, the MOSIS service, which is a low-cost, low-volume IC prototyping service, fabricates chips through several different vendors in various processes. These processes have values of lambda ranging from 0.3<<tt>mm to 1.0<<tt>mm; MOSIS basically has one set of design rules which covers all of these processes. In reality, once lambda starts getting below 0.5~<<tt>mm, even scalable rules change somewhat, but this is a detail. These rules are referred to as the SCMOS (Scalable CMOS) rules, and we use them in our design example.
As mentioned earlier, there are several different IC process technologies. Magic is technology-independent and can be used with all. The information that Magic needs about the target process resides in an external file called the technology file (tech file), which Magic reads when the program starts. By default Magic looks in $CAD_HOME/lib/magic/sys for the file scmos.tech27. Both the location and name of the tech file can be specified on the command line with the -T switch, although the name of the tech file must end with a “.tech27” extension. For example, to use the scmos-sub.tech27 tech file, you type magic -T scmos-sub.
Included with the Magic distribution in the scmos directory are multiple tech files for various processes offered by MOSIS. As mentioned above, when lambda gets very small, the design rules begin to change. MOSIS provides different tech files to account for this.
Items defined in the tech file include:
layer definitions (e.g., names, colors) and how layers interact with one another
device (transistor) geometry and parasitics
instructions on how to convert Magic's abstract layers to mask layers and vice versa
Knowing the tech file internals isn't necessary to use Magic; in fact, unless you're writing a tech file for a new process or modifying one for an existing process, you can think of the tech file as a “black box”. If you're interested, you can find a complete discussion of the tech file format in Magic Maintainer's Manual #2: The Technology File, located in the doc subdirectory of the Magic source tree.
We now pull it all together with a real-world design example—an inverter. An inverter simply flips a bit; it turns a 1 into a 0 and a 0 into a 1. This may sound trivial, but it's an essential building block for more complex digital circuits.
First, we'll walk through the layout and design rule check (DRC) of the inverter, explaining things as we go. Then we'll extract the netlist and simulate the chip using SPICE. After we're convinced the chip works properly, we'll construct the CIF file to send to the foundry to have the chip fabricated.
Although this example is very rudimentary, you can find much more complete documentation in the Magic Tutorial series, located in the doc subdirectory of the Magic source distribution. These excellent tutorials cover both the basics and more advanced usage (such as hierarchical design, multiple windows and interactive routing) that isn't covered here.
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane