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.
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
- Using tshark to Watch and Inspect Network Traffic
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development