|
|
Magic Mailing List |
|
From: Jeff W. Sondeen (sondeen AT rcf-fs DOT usc.edu) Date: Fri Jan 11 2002 - 23:23:57 EST
> 6) During CIF or GDS reads, magic checks every value before
> scaling, both at the input level for CIF only (scaling by the
> multiplier/reducer amounts declared in the cell "DS" definition),
> and during the conversion from CIF units to magic units. If
> fractional centimicrons result from a CIF read, the CIF planes will
> be redefined so that the input can be read exactly, without
> realigning itself to an integer boundary. When converting to magic
> units, the same consideration applies, except that some half-lambda
> geometry is allowed, such as for box centers and for contacts
> (which can be placed on the half-lambda grid by the "squares"
> operation in CIF output). Otherwise, fractional-lambda geometry
> causes magic to redefine its basic grid unit so that the input
> geometry is not altered.
would there be anyway to override this to get back the old magic
"snapping" effect? (just curious).
> I tested the code out by writing out a CIF file at 0.065um, reading
> it back in a 0.09um style, then writing it back out in a 0.065um
> style. It preserved the geometry as specified throughout all of
> the operations, although the final output is some awful thing
> measured in angstroms (units of 1/72 centimicron, to be precise).
not sure i understand this, since math 1/72 = 0.0138888888888889, so
vertices got "rounded" to this number ? or are they exact mulitples
of it ? wish you could give an example of a 2x2 lambda box,
what the units and scale factors are after each scaling.
> There are a couple of things I still need to do. By relaxing the 1
> Magic unit = 1 lambda restriction, it is necessary to have magic
> start measuring boxes in lambda rather than internal Magic units,
> or perhaps both (and perhaps it should also give measurements in
> microns according to the current CIF output style).
i hacked the 'box' command to optionally take an extra scale factor,
so for example, 'box 0 0 300 300 .3' means my integers are "microns":
:box 0 0 300 300 .3
:box
EDITbox width height llx lly urx ury
1000 1000 0 0 1000 1000
um AT 0 DOT 30 width height llx lly urx ury
300.00 300.00 0.00 0.00 300.00 300.00
but the scale factor is arbitrary, you could just as well say:
:box 0 0 1000 1000 .4
:box
EDITbox width height llx lly urx ury
2500 2500 0 0 2500 2500
um AT 0 DOT 40 width height llx lly urx ury
1000.00 1000.00 0.00 0.00 1000.00 1000.00
the lastest factor provided was 'sticky' so all box's would be
reported both in lambda and those units. (i mention this as an example
to consider, that's all).
> It might also be useful to define a 'drawing grid' spacing in
> lambda instead of magic units to make it easier to move around and
> draw simple geometry when the magic grid is very finely defined. I
> was thinking perhaps that mouse click operations on the cursor box
> might always snap to the lambda boundary, whereas specific "box"
> commands could be made to move around on a finer scale, if
> necessary. This sort of suggests that all geometry-related
> commands should accept values either in lambda or in internal units
> (maybe even in microns).
i remember how difficult trying to hack in 'major' and 'minor' grids
was: i never got very far. the 'minor' grid would be something like
.01 or .005 um with the idea that you could draw most your stuff on
the 'major' (lambda) grid but then occassionally 'pop into' the minor
grid to tune certain dimensions. however, that assumes that the
resolution of the drc rules is really in terms of the minor grid (or
let's just say microns). but the rules have to be 'intelligently'
converted into lambdas to let me get drc-checking when i draw in
lambdas, too. let's say poly width needs to be .16um and my 'minor'
grid is .01um and my 'major' (lambda) grid is .06um. if i draw a 2
lambda gate it says poly is too narrow (.12um needs to be .16um) but
if i draw a 3 lambda poly then i've made it bigger than it has to be.
this is an real issue if say the poly spacing must be .25um, for a
minimum pitch of .41um. then, drawing poly with a lambda spacing of 4
is an error (.24um needs to be .25um) but using a spacing of 5 lambda
is again wasteful. i get forced into a pitch of 8 lambda when a 7
lambda pitch would do.
for some cases, you could automatically tweak the lambda rules -- say,
allowing drawing a poly width of 2 lambda which really gets mapped
into 16 .01um units -- which you would see if you popped into the
'minor' grid -- and of course that means that your 5 lambda (.30um)
spacing really became .26um (as the poly was effectively bloated by
.02um per side when drawn in lambda units).
but in general such 'tweak's can't be automatically computed from a
set of design rules (as there are competing tradeoffs, believe me), so
they have to be done by the techfile developer and explicitely
specified in the techfile -- that is, the drc rules would need both
'minor' and 'major' values and the bloating between them specified
(and shrinking can be done also for shapes that can't abutt across
cells, like contacts)
anyway, not sure how this applies to your much better way of formally
introducing an intermediate set of units, and i certainly like your
idea of giving text command numbers with units, like 'i' or 'um', but
i also think you must allow a mode where mouse clicks can snap to
internals units.
thanks,
/jeff
> You could say "move e 10" (lambda) or "move e 10i" (internal) or
> "move e 1um" (according to current CIF output style) or even "move
> e 10.5" (lambda, if 1 lambda = 2 internal units or finer). I would
> like some feedback on this before launching into another massive
> code rewrite.
|
|
|
|