An Introduction to IC Design Under Linux

A discussion of various Linux tools for integrated circuit board design.
Introductory Magic Commands

First, invoke Magic from your shell prompt. Let's call our example file “inverter”. We'll use the default tech file, so we don't need to specify one with the -T switch.

magic inverter

A new layout window appears in which you design your chip; error messages and feedback appear in the window in which you started Magic (the command window). Magic handles window focus a little differently than you might expect—even though the input focus remains on the layout window, anything you type appears in the command window. Many commands work regardless of which window has the focus. When everything is ready, Magic displays a prompt in the command window.

The first thing to do is “paint” the two metal wires that supply current to the inverter—these wires are called the power rails. To create the first rail, make sure the focus is in the layout window, and type the following commands (the colon in the first column is required):

:grid
:box 0 0 4 5
:paint m1

The first command simply turns on the reference grid, although we're zoomed too far out to see it right now. The second command changes the shape of the box so that the lower-left corner is at (0,0) and the upper-right corner is at (4,5). The third command fills the box with blue paint that represents the first layer of metal. The box is the center of attention; most operations, such as painting and erasing, affect only the area within the box.

Now zoom in to get a clearer picture:

:box 0 0 12 32

Instead of typing a long command, we use a macro. Simply press the z without the colon, and the layout window zooms to the box. Note that after zooming the reference grid appears; each hash mark represents one lambda. Shortcuts like this are very handy, so let's explore them some more.

Shortcuts—Macros and the Mouse

A macro is a single keystroke not preceded by a colon. It can represent any arbitrary sequence of typed commands; for example, the z above represents the :findbox zoom command. System-wide macros are read at start-up from the file $CAD_HOME/lib/magic/sys/.magic. You can define you own macros in a .magic file in your home directories. And you can define macros at any time by entering:

:macro <key> <action to perform>

The mouse provides a quick way to both move and resize the box as well as paint. Move the cursor around the layout window and click the left mouse button as you do. This action moves the box so that its lower-left corner (the anchor point) is placed at the spot where you clicked. Now move the cursor around while clicking the right mouse button. The corner opposite the anchor point is placed where you let the button up. Notice this might result in the anchor point moving, since it's always the lower-left corner of the box.

To see how the mouse makes painting easier, first enter:

:box 0 27 4 32

to move the box where we want the second rail. Normally, you'd use the mouse to move and resize instead of typing a box command, but we want to make sure we all have the box in the exact same location. Now instead of typing :paint m1, move the cursor over the existing m1 rectangle and click the middle mouse button (for those of you using a 2-button mouse, click both buttons simultaneously). The box is now filled with metal 1. Clicking the middle button fills the box with whatever paint layers are underneath the cursor when you click. This leads to a simple way to erase any paint in the box—place the cursor over empty background and click the middle button, which paints “nothing” into the box.

Arggh—I Made a Mistake

Like any good editor, Magic has an undo facility for those times when you make a mistake or just want to try something out without having to commit. The u macro undoes the last action while the U macro implements the redo command. It's not unlimited; expect only the last 10 actions or so to be undoable. However, it's more than enough to let you erase a few rectangles and get them back.

Drawing the Inverter

A CMOS inverter has two Field-Effect Transistors, one p-type (PFET) and one n-type (NFET). Transistors are constructed by drawing polysilicon (or poly, for short) over diffusion. There are two types of diffusion, p and n. A PFET is poly over p-diffusion; an NFET is poly over n-diffusion.

Now let's start drawing the transistors. Position the box at ll (lower left) = (4,19), ur (upper right) = (8,27) and type:

:pai pdiff

Magic understands abbreviations for commands, such as pai for paint. The layer pdiff is p-type diffusion; each layer can have multiple names defined in the tech file. In SCMOS, p-diffusion can be called pdiffusion, pdiff or brown.

Now it's time for the n-diffusion. Place the box at ll=(4,5) and ur=(8,9) and type:

:pai ndiff

At this point your layout should look like the one in Figure 2. If not, you've gone astray; use the undo command and try again.

Figure 2. Layout Showing Diffusions Only

The transistors need poly running over the diffusion. In an inverter, the two polys for the transistors are connected together. This is the inverter's input—the signal driving the inverter is connected to the poly. It's simplest, then, to draw a single piece of poly which crosses both diffusions. Place the box at ll=(5,3) and ur=(7,29) and type:

:pai poly

Your layout should then look like Figure 3.

Figure 3. Layout Showing Polysilicon Crossing Diffusions to Define Transistors

For FETs, Size Does Matter

There are a couple of important points to notice. First, the area where the poly crosses the diffusion has a diagonally-striped pattern different from both poly and diffusion. This area represents the actual transistor, since FETs are constructed wherever poly passes over diffusion. To see this, place the cursor over the top transistor, and select it by pressing the s key. Now enter :what, which displays the names of the selected paint. Here, the selected area is “ptransistor”; Magic actually changes the paint from pdiffusion to ptransistor when poly crosses over it. The same concept applies when poly crosses over n-diffusion to form an “ntransistor”.

The other, very important thing to notice in Figure 3 is that white dots suddenly appear. If you work with Magic, get used to these dots—they indicate design rule violations, which Magic always checks for whenever something changes. To see which rule has been violated, place the box over the error dots, and use the y macro, which represents the :drc why command. Magic prints the reason for the error in the command window:

Diffusion must overhang transistor by at least 3 (MOSIS rule #3.4)

Since the overhang is only 1, we get design rule violations. Notice the dots occur only in the area that causes the error.

Now that we know what the problems are, let's fix them. Move the box to ll=(2,19) and ur=(10,27) to contain the upper error dots and type :pai pdiff. The error disappears. Now color the area in ndiffusion to eliminate the remaining errors. The layout now contains two “DRC-clean” transistors—no error dots are now displayed.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Simulation support for Gnucap / ngspice

G.Ravi Teja's picture

Sir,
It was a wonderful tutorial. It was really helpful. I want to know if there are any ways to simulate the layout design using gnucap. Thank in advance.

Webcast
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions