An Introduction to IC Design Under Linux
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.
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.
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.
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
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.
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.
Sponsored by AMD
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.
Sponsored by DLT Solutions
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Dart: a New Web Programming Experience
- New Products
- myip
2 hours 16 min ago - Keeping track of IP address
4 hours 7 min ago - Roll your own dynamic dns
9 hours 20 min ago - Please correct the URL for Salt Stack's web site
12 hours 32 min ago - Android is Linux -- why no better inter-operation
14 hours 47 min ago - Connecting Android device to desktop Linux via USB
15 hours 16 min ago - Find new cell phone and tablet pc
16 hours 14 min ago - Epistle
17 hours 42 min ago - Automatically updating Guest Additions
18 hours 51 min ago - I like your topic on android
19 hours 37 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
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.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
Simulation support for Gnucap / ngspice
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.