• Previous message: Jeff W. Sondeen: "Re: pending changes to Magic"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Dear Jeff,
   Thanks for all the comments.  Here are some further explanations and
some answers to your questions:

> would there be anyway to override this to get back the old magic
> "snapping" effect?  (just curious).

As written so far, you can't put magic in some mode where it acts like it
did before.  My opinion on this is that it is dangerous (not to mention
rude) for magic to alter input data without being told to do so explicitly.
The "snapping" effect *can* be forced, but only because the user intended
it.  For instance, if you load a CIF file with some geometry on quarter-
lambda spacing, magic's grid will jump to 4x resolution to accept the
input exactly (the same effect as specifying the command "scalegrid 1 4"
before doing the CIF read).  However, if after the CIF read, you decide
that it is better to snap the geometry to lambda boundaries, and fix any
resulting problems by hand, then you can specify "scalegrid 4 1" which will
force magic to go back to 1 lambda = 1 internal unit, snapping the geometry
as it goes.  This reproduces the result of magic's original behavior, the
main difference being that the user is aware that he/she is potentially
altering the geometry of the layout.  I had a situation like this recently,
where a file I received had one rectangle off the grid, apparently the
result of an unintended geometry change in Cadence.  All that was really
called for was to snap that one rectangle back onto the lambda grid.

> 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.

Sorry, maybe not such a good example.  What I mean is that the CIF file
declares cells with the line "DS n 1 72", meaning that every geometry
value in the cell must be divided by 72 to get the equivalent measurement
in centimicrons (actually, it should be divided by 36, because magic
already multiplies all values by 2 to cover the problem of rectangle
centers landing at half-integer values).

> 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

That's basically what I had in mind, except that "natural" units of
micrometers would be stated relative to the current CIF output style;
that is, it would be saying that "if you write out CIF using the
current output style, then the measurement of this box would be xxx
microns".  Your method is more flexible, but I'm not sure if there's
much value to looking at measurements which magic doesn't know how
to generate.

I'm waffling at the moment as to whether it makes more sense to print
values in all three units (internal, lambda, and microns), or to set
a "default units" property which will show values in the requested
units.

> 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.

My implementation does more or less the same thing.  "internal units"
are equivalent to the "minor grid" and "lambda units" are equivalent
to the "major grid".  For the time being, I will leave the cursor box
on the minor grid, on the assumption that most people will continue
to work in the default 1 lambda = 1 internal unit ratio.  I have
built an entire chip for a 0.25 micron process using a 1 internal
unit = 0.1um grid, which at times was a royal pain but which worked
(as did the chip).

> 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.

My implementation assumes that DRC rules are specified in lambda.
Magic starts off with a 1 lambda = 1 internal unit grid and makes the
grid finer as it needs to when reading CIF/GDS input, or if the user
makes the grid finer with a "scalegrid" command.  DRC rule distances are
then multiplied by the scalefactor, so that the DRC rules continue to
be measured in internal units, while a "drc why" command continues to
tell you the result in lambda (because it belongs to a fixed char *
string, I can't scale what it reports.  This method prevents the kind
of "tweaking" of DRC rules that you mentioned.  For that, the best way
would probably be to implement something mentioned a while ago in a
posting to magic-dev (possibly by you?), which is to allow DRC "styles"
in the same manner as the tech cifinput and cifoutput sections allow.
Each "DRC style" might then have a scalefactor, so you could specify
"conservative" rules at a resolution of the lambda grid, and more
exact, foundry-specified rules at a resolution of 1/10 the lambda grid.
If someone wants to work in the conservative rules, no action is
required, whereas if someone wants to work with foundry rules, it is
only necessary to specify a couple of startup commands in the .magic
file, like "scalegrid 1 10;  drc style foundry".  Probably it would
only be necessary to use "drc style foundry", because the scalefactor
in the drc style would force magic to run the "scalegrid 1 10"
command---which is better, because if magic discovered that all of the
drc rules were divisible by 10, it would divide out the common factor
rather than rescaling the grid (this is what I have it do when it reads
the cifinput/cifoutput sections in the tech file:  If I specify
"scalefactor 65 nanometers" for a 0.13 micron process, it treats this
as 6.5 centimicrons scaled in the output by a multiplier of 10, and
after discovering that all of the bloat/grow/shrink/squares rules are
divisible by 5, it reduces this automatically from 65:10 to 13:2.  For
these sections, however, this only has a bearing on how magic writes
out CIF, not the resolution of magic's internal 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 explicitly
> 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 abut across
> cells, like contacts)

I think my previous paragraph properly addressed that issue.  Until/unless
I implement "drc styles", only the "conservative" lambda-based rulesets
will be possible, but that's no change from what is possible in the current
release.

						Regards,
						Tim

• Next message: R. Timothy Edwards: "The "scriptEDA manifesto""
• Previous message: Jeff W. Sondeen: "Re: pending changes to Magic"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]