|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Wed Apr 30 2003 - 10:55:03 EDT
Dear Jeff,
> anyway, i'm getting close to releasing a new set of simplified, 'table
> driven' techfiles, within weeks i hope, altho they will probably be
> limited to 7.2 magic and above, in order to (try to) enforce
> 'wide-metal' spacing rules.
There are a number of recommendations I would like to make regarding
any set of techfiles that's targeted for version 7.2. Unfortunately
I'm just getting around to documenting them, so you wouldn't
necessarily know about them. In addition, my attempts to document
them regularly get pre-empted by higher-priority items. Regardless,
here they are (along with some other random comments):
1) I have changed ".tech27" to just ".tech", but added an extra keyword
"format" in the tech section. The format version number is now 28,
in version 7.2. So the tech section looks like:
tech
format 28
scmos
end
In addition, I would like to get away from the habit of labeling
all technologies "scmos". Since version 7.2 is able to load and
reload technology files on-the-fly, it makes more sense to match
the name in the tech file to something having to do with the
actual process and vendor (e.g., "ami05"). If the techfiles
match closely enough not to cause problems when loading under
different technologies all of which are called "scmos", then they
won't cause problems when loading an alternative technology while
the layout is still in memory.
2) The widespacing rule is problematic largely because it describes
a discontinuous rule. For all the simple edge-based rules,
moving a piece of layout by 1 unit will increase or decrease the
DRC violation area by 1 unit. With the widespacing rule, moving
or stretching certain pieces of the layout can cause large areas
of DRC violation to suddenly appear or disappear. The main
consequence of this is that there is no single, obvious way to
define a widespacing rule. As far as I am aware, no one has
created a standard definition of the widespacing rule that
covers all possible cases unambiguously (maybe I should go have
a talk with somebody at NIST?). So instead, the implementation
in Dracula is the "de facto standard" except that I have no
idea what that implementation is. We need to either find out
what algorithm Dracula uses or reverse-engineer it from a slew
of test cases. Otherwise, we're going to start getting emails
from annoyed users who found out that their magic layout didn't
pass muster with a vendor.
These are not priority items, and some may cross the boundary
into vendor-proprietary information, but some of the following
can be included if you have the specs available, and they are
not subject to NDA restrictions:
3) layer height and width (for 3-D rendering and precise geometry
extraction for passing to field-solver tools) can be put in the
extract section, using the line
height <layer(s)> <height_above_substrate> <layer_thickness>
Units are in lambda and may be floating-point.
4) extended "contact" line in the extract section takes the same
arguments as the "squares" command in the cifoutput section.
Otherwise, the extractor makes a different count of contact cuts
than actually ends up in the output, so extracted values (mainly
resistance through contacts) can be incorrect. The syntax is:
contact <layer(s)> [<size> <border>] <separation> <resistance>
Dimensions are integer, units of lambda, which means that if the
cifoutput "squares" function is not on lambda boundaries, the
extractor's count of contact cuts may still be wrong. I may try
to allow floating-point values in the future, if this seems to
be a common problem.
5) Add plot section information for PNM and PostScript rendering.
Remove plot section information for "gremlin", "versatec", and
"colorversatec"
6) The "styles" section can (and preferably, should) take style
"long names" instead of style numbers as the second argument.
It should be fairly easy to write a little program or script
that will go through and replace numbers with names from one
of the ".dstyle" files; I know that doing it by hand is very
painful. Using names is much more portable, though, and makes
the "styles" section easier to write. For example,
cwell 10
nwell 12
poly 1
nfet 6
nfet 7
becomes:
cwell cwell
nwell nwell
poly polysilicon
nfet ntransistor
nfet ntransistor_stripes
The style files themselves are much more amenable to extension, now,
and the numbers in the first column are actually meaningless. If
you need extra styles, just add them in, and let me know what they
are so I can add them to the standard style files in the distribution.
Note that since I changed the style files, there is no restriction on
the number of styles, and I have added lines for metal6 through metal8
and via5 through via7.
7) An additional change with the syntax for "device ..." in the extract
section is the use of variable names for the default substrate name.
This is meant for use with the Tcl interpreter, so I'll probably
need to make sure that the non-Tcl versions handle it sensibly, but
you can replace "Vdd!" and "Gnd!" with "$VDD" and "$GND" ("$VSS" has
been suggested to me as being more accurate), which then default to
"Vdd!" and "Gnd!" unless the user or .magic file sets the variables
explicitly to match the actual names of the power and ground networks.
-------------
In addition to the existing additions to tech format 28, I am currently
toying with at least one more idea which will affect the technology format
I am in the process of testing a version of magic in which the existing
method for contacts is replaced by a method suggested to me by
Philippe, in which *any* layer can be set up to create images of itself
on another plane. It lifts all the primary restrictions on contacts
such as 1) contacts are no longer restricted to connecting a maximum
of 3 planes, and 2) planes connected by contacts do not need to be
contiguous. I am also considering lifting the restriction that no
two contacts can declare the same residuals, and let the order of the
contacts in the techfile disambiguate circumstances.
I am also starting to add stuff into Magic for handling Place & Route;
not a real integrated PAR tool (yet), but at least the ability to
handle cells as part of "standard cell" libraries, including definition
of labels as "ports" (q.v., the new "port" command), defining routing
through-channels and obstructions, and boundaries for cell abutment.
It is likely that there will be a new techfile section to handle these
definitions, but there's no point in worrying about it right now.
-------------
If there are any other aspects of the technology file which are lacking,
or which seem stupidly implemented or have become outdated, please let
me know and we can have a discussion among the developers on what to do
about them. Implementing "antenna rules" is the primary one I can think
of, but I'm sure there are others.
Regards,
Tim
|
|
|
|