|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Mon Jun 16 2003 - 12:20:09 EDT
Dear Jeff,
> now it's worse, at least with tsmc.90 nm, there are like 5 'wide
> metal' bins, se we really need rules like
>
> width < 5 space=2
> 5 <= width < 10 space=4
> 10 <= width space=6
> ...
I *think* that a set of widespacing rules will actually work correctly
here, as certain rules tend to "shadow" other ones. However, there is
(still! $#@!) an error with the way I implemented the widespacing rule,
and once I fix that, I'll check whether they can be layered like your
example.
> this (>= 5 bins of spacings) also applies to via spacing: a 2x2 array
> can be spaced closer than a 3x3 (to 5x5) array, and so on.
That can be implemented in the cifoutput rules: e.g., take all areas
of via, shrink by half the size of a 3x3 array, and expand, which
removes all the 2x2-sized via areas. Then with the proper boolean
logic, you can do "squares" operations separately on 2x2 via arrays
and larger arrays (of course, for more bins, it gets rather
complicated). I did this for the UMC process, which required a
different border on via areas larger than some amount.
> > 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.
>
> it would be easier if the units were microns.
Magic's extract section is all lambda-based and apparently intended
to be purely scalable. With extraction separate from CIF I/O, there's
no way to ensure that the two match up. I have been thinking, however,
that it might be better to "package" the extract, cifinput, and
cifoutput sections under a single "style", instead of the other way
around. That way, you always ensure that extraction matches output,
and problems like lambda vs. microns in the extract section go away.
> >
> > 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:
> >
> are you saying that the only difference is that the extractor counts
> the "correct" number of contacts for a 'contact' than for a squares' ?
Yes. The previous method calculates the number of squares differently
for extraction than for physical output, and so the calculated resistance
through contact regions can be way off.
> ("correct" modulo the off-lambda issues). what i'd really like is a
> mode where you get a drc violation unless your contacts are exactly
> sized to generate on-lambda contacts.
I think it makes more sense for the cifoutput "squares" function to
take an extra argument "onlambda" which ensures that contacts will
always be written out on the lambda grid.
> the problem with contacts is that they take up too many 'types' (as i
> think those 'images' are). i already ran out of types for tsmc.90 nm
> and had to scrap the 'HV' (high voltage) diffusions, and now just
> implement HV (thick oxide) transistors with 3 types: 'to' 'ntfet' and
> 'ptfet' (similar to low- and high- threshold transistors). this
> limits the drc checking, tho, and requires that you generally have to
> draw the 'to' layer itself to get (limited) drc checking of it.
I am partially through re-coding large portions of magic's core
painting routines to completely overhaul the contact image problem.
The difficulty lies in some rather poorly designed structures, in
which each contact layer is given a "home plane" and lists neigboring
"above" and "below" planes, and the "residue" types for each of those
three planes. This creates the three-planes-maximum limit for
contacts. The way the code is written around these structures
necessitates the creation of a new layer type for each contact
image on each plane. I redesigned everything so that each contact
has only one type, and that type gets put on each plane that the
contact connects to. Each contact type defines all the residues on
all the contacted planes, so there is 1) no meaningful idea of a
"home plane", 2) no limit on the number of planes contacted, 3)
no restriction of adjacency for the contacted planes, and 4) no
requirement that two contact types can't have the same residues
(so "generic" contact types can be defined to connect the same
layers as their "specific" equivalents). These changes are a huge
benefit for deep-submicron technologies, removing all the limitations
you mentioned.
Philippe was the first person to suggest this change to me, and
suggested that instead of just "contacts", the idea of layer
images on multiple planes could be extended to devices as well,
so that, for instance, an "nfet" would be an image existing on
plane "poly" and plane "diffusion". One benefit of this is that
in double-poly processes, you can define poly and poly2 to be
on different planes, and (where the process allows it), have
poly-poly2 caps but also allow poly to cross poly2 on field
oxide.
> it would really be nice if magic had an 'edge-to-edge' drc rule, since
> many new tsmc.90 rules prohibit an edge of one layer (say 'to') near
> and edge of another (say 'nwell') UNLESS they align. that is, if an
> edge of 'to' is < X of an edge of 'nwell', you must align the edges
> (or space them further apart by >= X).
I thought the "touching_ok" flag on spacing rules was supposed to
account for that.
> there's even more grizzly
> rules, like: a corner of layer1 cannot be within X of a corner of
> layer2, unless one of their dx or dy offsets (distances between the
> points) is Y.
Doesn't this work with the edge4way rule just by specifying the
appropriate distance for the corner extension? If it doesn't
work with a single rule, then it should work by having the normal
spacing rule "shadow" the corner rule. At least, I think so.
Regards,
Tim
|
|
|
|