.rm CM
.nr PS 12
.ps 12
.nr VS 14
.vs 14
\" sccsid "%W% (Berkeley) %G%"
.de (C
.nr PS -2
.nr VS -2
.nr LL 5.5i
.IP
..
.de )C
.sp .5c
.nr PS +2
.nr VS +2
.nr LL 6i
..
.DS C
.LG
.LG
.sp |2c
\fBMagic Tutorial #4: Cell Hierarchies\fR
.rm CH
.ds LH Magic Tutorial #4: Cell Hierarchies
.ds RH \*(DY
.ds CF - % -
.sp 1c
.NL
\fIJohn Ousterhout\fR
.sp 1c
.NL
Computer Science Division
Electrical Engineering and Computer Sciences
University of California
Berkeley, CA  94720

\fI(Updated by others, too.)\fR

.SM
This tutorial corresponds to Magic version 6.


.DE
.SM
.LP
\fBTutorials to read first:\fR
.DS
Magic Tutorial #1: Getting Started
Magic Tutorial #2: Basic Painting and Selection
.DE
.LP
\fBCommands introduced in this tutorial:\fR
.IP
:array, :edit, :expand, :flush, :getcell, :identify, :load, :path,
:see, :unexpand
.LP
\fBMacros introduced in this tutorial:\fR
.IP
x, X, ^X
.br
.NL
.sp 1c
.NH 1
Introduction
.PP
In Magic, a layout is a hierarchical collection of cells.
Each cell contains three things: paint, labels, and
subcells.  Tutorial #2 showed
you how to create and edit paint and labels.  This tutorial describes
Magic's facilities for building up cell hierarchies.  Strictly speaking,
hierarchical structure isn't necessary:  any design that can be
represented hierarchically can also be represented ``flat'' (with
all the paint and labels in a single cell).  However, many
things are greatly improved if you use a hierarchical
structure, including the
efficiency of the design tools, the speed with which you can enter
the design, and the ease with which you can modify it later.

.NH 1
Selecting and Viewing Hierarchical Designs
.PP
``Hierarchical structure'' means that each cell can
contain other cells as components.
To look at an example of a hierarchical layout, enter Magic
with the shell command \fBmagic tut4a\fR.  The cell \fBtut4a\fR
contains four subcells plus some blue paint.  Two of the subcells
are instances of cell \fBtut4x\fR and two are instances of
\fBtut4y\fR.  Initially, each subcell
is displayed in \fIunexpanded\fR form.  This means that
no details of the subcell are displayed;  all you see is the
cell's bounding box, plus two names inside the
bounding box.  The top name is the name of the subcell (the
name you would type when invoking Magic to edit the cell).  The
cell's contents are stored in a file with this name plus a \fB.mag\fR
extension.  The bottom name inside each bounding box is called an
\fIinstance identifier\fR, and is used to distinguish different
instances of the same subcell.  Instance id's are used for
routing and circuit extraction, and are discussed in Section 6.
.PP
Subcells can be manipulated using the same selection mechanism
that you learned in Tutorial #2.  To select a subcell, place the
cursor over the subcell and type \fBf\fR (``\fBf\fRind cell''),
which is a macro for \fB:select cell\fR.  You can also select a cell
by typing \fBs\fR when the cursor is over a location where there's
no paint;  \fBf\fR is probably more convenient, particularly for
cells that are completely covered with paint.  When you select
a cell the box will be set to the cell's bounding box, the cell's
name will be highlighted, and
a message will be printed on the text display.
All the selection operations (\fB:move\fR,
\fB:copy\fR, \fB:delete\fR, etc.) apply to subcells.  Try selecting
and moving the top subcell in \fBtut4a\fR.  You can also select
subcells using area selection (the \fBa\fR and \fBA\fR macros):
any unexpanded subcells that intersect the area of the box will
be selected.
.PP
To see what's inside a cell instance, you must \fIexpand\fR it.
Select one of the instances of \fBtut4y\fR, then type the command
.DS C
\fB:expand toggle\fR
.DE
or invoke the macro \fB^X\fR
which is equivalent.  This causes the internals of that instance
of \fBtut4y\fR to be displayed.  If you type \fB^X\fR again, the
instance is unexpanded so you only see a bounding box again.
The \fB:expand toggle\fR command expands all of the selected cells
that are unexpanded, and unexpands all those that are expanded.
Type \fB^X\fR a third time so that \fBtut4y\fR is expanded.
.PP
As you can see now, \fBtut4y\fR
contains an array of \fBtut4x\fR cells plus some additional
paint.  In Magic, an array is a special
kind of instance containing multiple copies of the same subcell spaced
at fixed intervals.  Arrays can be one-dimensional or two-dimensional.
The whole array is always treated
as a single instance:  any command that operates on one element of
the array also operates on all the other elements simultaneously.
The instance identifiers for the elements of the array
are the same except for an index.  Now select one of the elements
of the array and expand it.  Notice that the entire array is
expanded at the same time.
.PP
When you have expanded the array, you'll see that the paint
in the top-level cell \fBtut4a\fR is displayed more brightly than the paint
in the \fBtut4x\fR instances.  \fBTut3a\fR is called
the \fIedit cell\fR, because its contents are currently editable.
The paint in the edit cell is normally displayed more brightly than other
paint to make it clear that you can change it.  As long as \fBtut4a\fR
is the edit cell, you cannot modify the paint in \fBtut4x\fR.  Try
erasing paint from the area of one of the \fBtut4x\fR instances:
nothing will be changed.  Section 4 tells how to switch the
edit cell.
.PP
Place the cursor over one of the \fBtut4x\fR array elements again.
At this point, the cursor is actually over three different
cells: \fBtut4x\fR (an element of an array
instance within \fBtut4y\fR), \fBtut4y\fR (an
instance within \fBtut4a\fR), and \fBtut4\fR.
Even the topmost cell in the hierarchy is treated as an instance
by Magic.  When you press
the \fBs\fR key to select a cell, Magic initially chooses
the smallest instance visible underneath the cursor, \fBtut4x\fR
in this case.  However, if you invoke the \fBs\fR macro
again (or type \fB:select\fR) without moving the cursor, Magic
will step through all of the instances under the cursor in order.
Try this out.
The same is true of the \fBf\fR macro and \fB:select cell\fR.
.PP
When there are many different expanded cells on the screen,
you can use the selection commands to select paint from any
of them.  You can select anything that's visible, regardless of
which cell it's in.  However, as mentioned above, you can only
modify paint in the edit cell.  If you use \fB:move\fR or
\fB:upsidedown\fR or similar commands when you've selected
information outside the edit cell, the information outside
the edit cell is removed from the selection before performing
the operation.
.PP
There are two additional commands you can use for expanding and
unexpanding cells:
.DS C
\fB:expand\fR
\fB:unexpand\fR
.DE
Both of these commands operate on the area underneath the box.
The \fB:expand\fR command will recursively
expand every cell that intersects the box until there are no
unexpanded cells left under the box.  The \fB:unexpand\fR
command will unexpand every cell whose area intersects the box
but doesn't completely contain it.  The macro \fBx\fR is
equivalent to \fB:expand\fR, and \fBX\fR is
equivalent to \fB:unexpand\fR.  Try out the various expansion
and unexpansion facilities on \fBtut4a\fR.

.NH 1
Manipulating Subcells
.PP
There are a few other commands, in addition to the selection
commands already described, that you'll need in order to
manipulate subcells.  The command
.DS C
\fB:getcell\fI name\fR
.DE
will find the file \fIname\fB.mag\fR on disk, read the cell
it contains, and create an instance of that cell with
its lower-left corner aligned with
the lower-left corner of the box.
Use the \fBgetcell\fR
command to get an instance of the cell \fBtut4z\fR.
After the \fBgetcell\fR command, the new instance is selected
so you can move it or copy it or delete it.  The \fBgetcell\fR command
recognizes additional arguments that permit the cell to be positioned
using labels and/or explicit coordinates.  See
the \fIman\fR page for details.
.PP
To turn a normal instance into an array, select the
instance and then invoke the \fB:array\fR
command.  It has two forms:
.DS C
\fB:array \fIxsize ysize
\fB:array \fIxlo xhi ylo yhi\fR
.DE
In the first form, \fIxsize\fR indicates how many elements
the array should have in the x-direction, and \fIysize\fR
indicates how many elements it should have in the y-direction.
The spacing between elements is controlled by the box's
width (for the x-direction) and height (for the y-direction).
By changing the box size, you can space elements so that they
overlap, abut, or have gaps between them.
The elements are given indices from 0 to \fIxsize\fR-1 in
the x-direction and from 0 to \fIysize\fR-1 in the
y-direction.  The second form of the command is identical
to the first except that the elements are given indices
from \fIxlo\fR to \fIxhi\fR in the x-direction and from
\fIylo\fR to \fIyhi\fR in the y-direction.  Try making
a 4x4 array out of the \fBtut4z\fR cell with gaps between
the cells.
.PP
You can also invoke the \fB:array\fR command on an
existing array to change the number of elements or
spacing.  Use a size of 1 for \fIxsize\fR or \fIysize\fR
in order to get a one-dimensional array.  If there are
several cells selected, the \fB:array\fR command will make
each of them into an array of the same size and spacing.
It also works on paint and labels:  if paint and labels
are selected when you invoke \fB:array\fR, they will be
copied many times over to create the array.  Try using the array
command to replicate a small strip of paint.

.NH 1
Switching the Edit Cell
.PP
At any given time, you are editing the definition of a single
cell.  This definition is called the \fIedit cell\fR.  You
can modify paint and labels in the edit cell, and you can
re-arrange its subcells.  You may not re-arrange or delete
the subcells of any cells other than the edit cell, nor may
you modify the paint or labels of any cells except the edit
cell.  You may, however, copy information from other cells into
the edit cell, using the selection commands.
To help clarify what is and isn't modifiable, Magic
displays the paint of the edit cell in brighter colors than
other paint.
.PP
When you rearrange subcells of the edit cell, you aren't changing the
subcells themselves.  All you can do is change the way they are
used in the edit cell (location, orientation, etc.).  When you
delete a subcell, nothing happens to the file containing the
subcell;  the command merely deletes the instance from the edit cell.
.PP
Besides the edit cell, there is one other special cell in Magic.
It's called the \fIroot cell\fR and is the topmost cell in
the hierarchy, the one you named when you ran Magic (\fBtut4a\fR
in this case).  As you will see in Tutorial #5, there can
actually be several root cells at any given time, one in each window.
For now, there is only a single window on the
screen, and thus only a single root cell.  The window caption at
the top of the color display contains the name of the window's root
cell and also the name of the edit cell.
.PP
Up until now, the root cell and the edit cell have been
the same.  However, this need not always be the case.  You can
switch the edit cell to any cell in the hierarchy by selecting
an instance of the definition you'd like to edit, and then
typing the command
.DS C
\fB:edit\fR
.DE
Use this command to switch the edit cell to one of the \fBtut4x\fR
instances in \fBtut4a\fR.  Its paint brightens, while
the paint in \fBtut4a\fR becomes dim.  If you want to edit
an element of an array, select the array, place the
cursor over the element you'd like to edit, then type \fB:edit\fR.
The particular element underneath the cursor becomes the edit cell.
.PP
When you edit a cell, you are editing the master definition of that
cell.  This means that if the cell is used in several places in
your design, the edits will be reflected in all those places.
Try painting and erasing in the \fBtut4x\fR cell that you just made
the edit cell:  the modifications will appear in all of its instances.
.PP
There is a second way to change the edit cell.  This is the command
.DS C
\fB:load \fIname\fR
.DE
The \fB:load\fR command loads a new hierarchy into the window
underneath the cursor.  \fIName\fR is the name of the root cell in
the hierarchy.  If no \fIname\fR is given, a new unnamed cell is
loaded and you start editing from scratch.  The \fB:load\fR
command only changes the edit cell if there is not already
an edit cell in another window.

.NH 1
Subcell Usage Conventions
.PP
Overlaps between cells are occasionally useful to share busses
and control lines running along the edges.  However, overlaps
cause the analysis tools to work much harder than they would if
there were no overlaps:  wherever cells overlap, the tools have
to combine the information from the two separate cells.  Thus,
you shouldn't use overlaps any more than absolutely necessary.  For example,
suppose you want to create a one-dimensional array of cells that
alternates between two cell types, A and B:  ``ABABABABABAB''.  One
way to do this is first to make an array of A instances with large
gaps between them (``A  A  A  A  A  A''), then make an array of
B instances with large gaps between them (``B  B  B  B  B  B''),
and finally place one array on top of the other so that the B's
nestle in between the A's.  The problem with this approach is that
the two arrays overlap almost completely, so Magic will have to
go to a lot of extra work to handle the overlaps (in this case, there
isn't much overlap of actual paint, but Magic won't know this
and will spend a lot of time worrying about it).  A better solution
is to create a new cell that contains one instance of A and one
instance of B, side by side.  Then make an array of the new cell.
This approach makes it clear to Magic that there isn't any real
overlap between the A's and B's.
.PP
If you do create overlaps, you should use the overlaps only to
connect the two cells together, and not to change their structure.
This means that the overlap should not cause transistors to appear,
disappear, or change size.  The result of overlapping the two subcells
should be the same electrically as if you placed the two cells apart
and then ran wires to hook parts of one cell to parts of the other.  The
convention is necessary in order to be able to do hierarchical
circuit extraction easily (it makes it possible for each subcell
to be circuit-extracted independently).
.PP
Three kinds of overlaps
are flagged as errors by the design-rule checker.  First, you may
not overlap polysilicon in one subcell with diffusion in another
cell in order to create transistors.  Second, you may not overlap
transistors or contacts in one cell with different kinds of transistors
or contacts in another cell (there are a few exceptions to this rule
in some technologies).  Third, if contacts from different cells overlap,
they must be the same type of contact and must coincide exactly:
you may not have partial overlaps.  This rule is necessary
in order to guarantee that Magic can generate CIF for fabrication.
.PP
You will make life a lot easier on yourself (and on Magic)
if you spend a bit of time to choose a clean hierarchical structure.
In general, the less cell overlap the better.  If you use extensive
overlaps you'll find that the tools run very slowly and that it's
hard to make modifications to the circuit.

.NH 1
Instance Identifiers
.PP
Instance identifiers are used to distinguish the different subcells
within a single parent.  The cell definition names cannot be
used for this purpose because there could be many instances
of a single definition.  Magic will create default instance
id's for you when you create new instances with the \fB:get\fR
or \fB:copy\fR commands.  The default id for an instance will
be the name of the definition with a unique integer added on.
You can change an id by selecting
an instance (which must be a child of the edit cell) and invoking the command
.DS C
\fB:identify \fInewid\fR
.DE
where \fInewid\fR is the identifier you would like the instance
to have.  \fINewid\fR must not already be used as an instance
identifier of any subcell within the edit cell.
.PP
Any node or instance can be described uniquely by listing a
path of instance identifiers, starting from the root cell.  The
standard form of such names is similar to Unix file names.  For
example, if \fBid1\fR is the name of an instance within the
root cell, \fBid2\fR is an instance within \fBid1\fR, and
\fBnode\fR is a node name within \fBid2\fR, then
\fBid1/id2/node\fR can be used unambiguously to refer to the node.
When you select a cell, Magic prints out the complete path name
of the instance.
.PP
Arrays are treated specially.  When you use \fB:identify\fR to
give an array an instance identifier, each element of the array
is given the instance identifier you specified, followed
by one or two array subscripts enclosed in square brackets,
e.g, \fBid3[2]\fR or \fBid4[3][7]\fR.  When the array is
one-dimensional, there is a single subscript; when it is
two-dimensional, the first subscript is for the y-dimension
and the second for the x-dimension.

.NH 1
Writing and Flushing Cells
.PP
When you make changes to your circuit in Magic, there is
no immediate effect on the disk files that hold the cells.
You must explicitly save each cell that has changed, using
either the \fB:save\fR command or the \fB:writeall\fR command.
Magic keeps track of the cells that
have changed since the last time they were saved
on disk.  If you try to leave Magic without saving all the
cells that have changed, the system will warn you and give
you a chance to return to Magic to save them.  Magic never
flushes cells behind your back, and never throws away
definitions that it has read in.  Thus, if you edit a cell
and then use \fB:load\fR to edit another cell, the first
cell is still saved in Magic even though it doesn't appear
anywhere on the screen.  If you then invoke \fB:load\fR
a second time to go back to the first cell, you'll get the
edited copy.
.PP
If you decide that you'd really like to discard the edits
you've made to a cell and recover the old version, there
are two ways you can do it.  The first way is using the
\fBflush\fR option in \fB:writeall\fR.  The second way is
to use the command
.DS C
\fB:flush \fR[\fIcellname\fR]
.DE
If no \fIcellname\fR is given, then the edit cell is flushed.
Otherwise, the cell named \fIcellname\fR is flushed.  The
\fB:flush\fR command will expunge Magic's internal copy of the
cell and replace it with the disk copy.
.PP
When you are editing large chips, Magic may claim that cells
have changed even though you haven't modified them.  Whenever
you modify a cell, Magic makes changes in the parents of the
cell, and their parents, and so on up to the root of the
hierarchy.  These changes record new design-rule violations,
as well as timestamp and bounding box information used by
Magic to keep track of design changes and enable fast cell
read-in.  Thus, whenever you change one cell you'll generally
need to write out new copies of its parents and grandparents.
If you don't write out the parents, or if you edit a child
``out of context'' (by itself, without the parents loaded),
then you'll incur extra overhead the next time you try to edit
the parents.  ``Timestamp mismatch'' warnings are printed
when you've edited cells out of context and then later go back
and read in the cell as part of its parent.  These aren't serious
problems;  they just mean that Magic is doing extra work to
update information in the parent to reflect the child's new state.

.NH 1
Search Paths
.PP
When many people are working on a large design, the design
will probably be more manageable if different pieces of it
can be located in different directories of the file system.
Magic provides a simple mechanism for managing designs spread
over several directories.  The system maintains a \fIsearch path\fR
that tells which directories to search when trying to read in
cells.  By default, the search path is ``.'', which means that
Magic looks only in the working directory.  You can change the
path using the command
.DS C
\fB:path \fR[\fIsearchpath\fR]
.DE
where \fIsearchpath\fR is the new path that Magic should use.
\fISearchpath\fR consists of a list of directories separated
by colons.  For example, the path ``.:\(apouster/x:a/b'' means
that if Magic is trying to read in a cell named ``foo'', it
will first look for a file named ``foo.mag'' in the current directory.
If it doesn't find the file there, it will look for a file named
``\(apouster/x/foo.mag'', and if that doesn't exist, then it will try
``a/b/foo.mag'' last.  To find out what the current path is, type
\fB:path\fR with no arguments.  In addition to your path, this command
will print out the system cell library path (where Magic looks for
cells if it can't find them anywhere in your path), and the system
search path (where Magic looks for files like colormaps and technology
files if it can't find them in your current directory).
.PP
If you're working on a large design, you should use the search
path mechanism to spread your layout over several directories.
A typical large chip will contain a few hundred cells;  if you
try to place all of them in the same directory there will just
be too many things to manage.  For example, place the datapath in one
directory, the control unit in another, the instruction buffer in
a third, and so on.  Try to keep the size of each directory down
to a few dozen files.  You can place the \fB:path\fR command in
a \fB.magic\fR file in your home directory or the directory you
normally run Magic from;  this will save you from having to
retype it each time you start up (see the Magic man page to
find out about \fB.magic\fR files).
If all you want to do is add another directory onto the end of the search 
path, you can use the \fB:addpath \fR[\fIdirectory\fR] command.  
.PP
Because there is only a single search path that is used everywhere
in Magic, you must be careful not to re-use the same cell name in
different portions of the chip.  A common problem with large
designs is that different designers use the same name for different
cells.  This works fine as long as the designers are working separately,
but when the two pieces of the design are put together using a search
path, a single copy of the cell (the one that is found first in the search
path) gets used everywhere.
.PP
There's another caveat in the use of search paths.  Magic looks for system
files in ~cad, but sometimes it is helpful to put Magic's system files
elsewhere.  If the \fBCAD_HOME\fR shell environment variable is set, then
Magic uses that as the location of ~cad instead of the location in the
password file.  This overrides all uses of ~cad within magic, including 
the ~cad seen in the search paths printed out by \fB:path\fR.
.NH 1
Additional Commands
.PP
This section describes a few additional cell-related commands that
you may find useful.  One of them is the command
.DS C
\fB:select save \fIfile\fR
.DE
This command takes the selection and writes it to disk as a new
Magic cell in the file \fIfile\fB.mag\fR.  You can use this command
to break up a big file into smaller ones, or to extract pieces from
an existing cell.
.PP
The command
.DS C
\fB:dump \fIcellName\fR \fR[\fIlabelName\fR]
.DE
does the opposite of \fBselect save\fR:  it copies the contents of
cell \fIcellName\fR into the edit cell, such that the lower-left
corner of label \fIlabelName\fR is at the lower-left corner of the
box.  The new material will also be selected.  This command is similar
in form to the \fBgetcell\fR command except that it copies the contents
of the cell instead of using the cell as a subcell.  There are several
forms of \fBdump\fR;  see the \fIman\fR page for details.
.PP
The main purpose of \fBdump\fR is to
allow you to create a library of cells representing
commonly-used  structures such as standard transistor shapes
or special contact arrangements.  You can then define macros
that invoke the \fBdump\fR command to place the cells.  The result
is that a single keystroke is all you need to copy one of them into the
edit cell.
.PP
As mentioned earlier, Magic normally displays the edit cell in
brighter colors than non-edit cells.  This helps to distinguish
what is editable from what is not, but may make it hard for
you to view non-edit paint since it appears paler.  If you
type the command
.DS C
\fB:see allSame\fR
.DE
you'll turn off this feature:  all paint everywhere will be
displayed in the bright colors.  The word \fBallSame\fR must
be typed just that way, with one capital letter.  If you'd
like to restore the different display styles, type the
command
.DS C
\fB:see no allSame\fR
.DE
You can also use the \fB:see\fR command to selectively disable
display of various mask layers in order to make the other ones
easier to see.  For details, read about \fB:see\fR in the
Magic man page.
