[Magic-dev] Re: "staged" design rules

[R. Timothy Edwards]

Dear Mark,

 >> About a month or two ago, I added the ability to put "styles" sections
 >> into the DRC block of the techfile, and at the same time implemented
 >> the "variants" option
> I assume these are in the 7.5 branch of the code correct?

It pretty much *defines* the difference between 7.4 and 7.5.

> Is this documented anywhere?  I think I get the gist of it all,
> but I wanted to be sure.  Finally, I assume you switch between 
> the rules sets with something like 
>  drc style varient_name

It's in the online techfile reference manual.  And yes, that's
the right invocation.  Since there were already a lot of style
variants in the scmos techfiles like "lambda=1.0um(p)", etc.,
I decided that it would be helpful to keep a compatible syntax.
So if you declare:

	style lambda=1.0um  variants (p),(s),(ps),()

Then you can switch rulesets with "cif ostyle lambda=1.0(p)".
The same syntax applies to the cifoutput, cifinput, extract, and
(now) drc sections.

> I am thinking of reworking the ami0.5um techfile and this would
> also allow me to put the HV rules in a different variant if they
> aren't being used.

That's the obvious thing to do.

> Finally, I want to understand the scale factor as well.  say
> I have a deck with lambda = 0.1um.  and a design rule spacing of 
> say .7um.  I can then use .7 in my DRC section by setting my 
> scale factor to 10.  
> If I wanted the grid to be 0.05um, I then have to set my 
> scale factor to 20.  

If lambda is 0.1um and the design rule spacing is 0.7, then
the DRC rule distance is just 7 internal units with no scalefactor
needed.  If you set the drc scalefactor to 10, then the rule
distance would be 70 (unscaled) units.  And yes, if your
cifoutput section defines the internal unit-to-GDS unit scale
to be 1 internal unit = 0.05um, then you can just change the
DRC scalefactor to 20 and you don't have to touch the rules.

> But this feature doesn't allow me to check design rules that are
> on an internal grid that may be half of my lambda grid. size
> the (DRCVAL)*scalefactor must be an integer

It's more flexible than that.  The DRC scalefactor defines the
multiplication factor between units in the DRC database and Magic's
lambda value.  Physical units are still relative to the "cifoutput"
style scalefactor.  The whole point of the scalefactor is to let
you define rules with distances that are finer than the lambda
grid.

Normally you just set the DRC scalefactor so that you can represent
any DRC value as an integer, and preferably some obvious units such
as nanometers so you don't have to get out a calculator to copy the
process design rule manual into the techfile rules.  Magic remembers
the actual value (e.g., nanometer units value) for the rule, but also
computes a distance relative to its internal grid---so if, for example,
a spacing rule specifies 0.01um, and the internal grid is 0.1um, then
the spacing rule is 1/10 of Magic's internal grid resolution, and the
rule gets converted (rounded UP, of course) to 1 internal unit minimum
spacing.  HOWEVER, the 0.01um value is remembered, and if you then did
"scalegrid 1 20", then the DRC rule would be recomputed as 2 internal
units minimum.

In effect, what you get is "automatic scalable CMOS" where the DRC rules
are always correct relative to lambda.  I like it because it lets me
write all the DRC rules really fast by copying them more or less
verbatim from the process manual, but I can still set the default lambda
to 2 lambda = minimum poly gate length.  The automatic scaling then
effectively works out what are the minimum width and scaling for each
layer (usually more conservative than what you'd get if you did it by
hand), but you can always scale the grid down with "scalegrid" and
trade of ease of design for adherence to vendor minimum rules.

Example:  I did a 0.35um techfile a few months ago.  Lambda comes out
to the awkward value of 0.175, but I set it to this value anyway.
I set the cifoutput scalefactor to "175 nanometers", and I set the
DRC scalefactor to 175, so that all DRC rules were in (integer)
nanometers.  On startup, I had the .magicrc file do "scalegrid 1 7"
so that the internal grid would be 25nm (which was the minimum grid
resolution allowed by the process), and I used "squares-grid" for all
the contact cuts so that the contact cuts would not be placed at
positions finer than the 25nm internal grid.

Right now, I'm adding a "gridlimit" keyword to the "cifoutput" section
so that I can make life even simpler by defining what is the minimum
grid, and preventing Magic from ever generating any output geometry
finer than the minimum resolution.  Hopefully that feature will be
done by the end of the day.

						---Tim

+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim)   | email: tim.edwards at multigig.com     |
| MultiGiG, Inc.                 | web:   http://www.multigig.com      |
| 100 Enterprise Way, Suite A-3  | phone: (831) 621-3283               |
| Scotts Valley, CA 95066        | cell:  (240) 401-0616               |
+--------------------------------+-------------------------------------+