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.
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:
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:
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.
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:
Your layout should then look like Figure 3.
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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide