[Magic-dev] Re: MAGIC - CIFOUTPUT

R. Timothy Edwards tim.edwards at multigig.com
Wed Jun 7 11:29:17 EDT 2006


Dear Oliver,

> But now it comes to write the Cifoutput/ Cifinput.
> Either this is a very simple section to write or I'm seeing
> way to much in it.

It can be simple or not, depending on how the rest of the tech file is written.

> I know that it's just about getting the masks for each physical
> layer. I read the corresponding part of the online techfile manual
> a few times but I still don't understand.
> 
> I order to draw I set the scalefactor in the Cifoutput to 100 (or 1000 nanometers)
> so I get 1um for one Lambda. That way I can see the x y coordinates directly in um.
> To draw a feature size of 0.55um I set the scalegrid to 20/1 -> 0.05um per internal unit.
> In the DRC -Section I set the scalefactor to 20 (1/20 of Lambda) as you said in 
> order to measure also in 0.05um.

The "cifoutput" scalefactor sets the physical dimensions of the layout, which are otherwise
"dimensionless" lambda units.  The scalefactor maps the value of 1 internal unit (before
any scaling with "scalegrid") to centimicrons or nanometers.

> Does the Cif-Section also take the internal units for measuring? (eg for squares operator)
> Because nowhere is said what a Cifunit is. Or at least I didn't see it.
> Or is it enough here that 1Lambda equals 1um...

A "cif unit" is 1 centimicron (1/100 micron, or 10 nanometers).  If you said "scalefactor 100"
then the units in the cifoutput section must be in centimicrons.  If you said "scalefactor 1000
nanometers" then they must be in nanometers.

> For what are the or,ands... operations for?

"or" comes in several forms:

    layer CAA ndiff,pdiff,nsd,psd,ndc/a,pdc/a,nsc/a,psc/a,nfet,pfet

is equivalent to:

    layer CAA ndiff
    or pdiff
    or nsd
    or psd
    or ndc/a
    or pdc/a
    or nsc/a
    or psc/a
    or nfet
    or pfet

and is also equivalent to:

    layer CAA *ndiff,*pdiff,*nsd,*psd,nfet,pfet

so you can often get by without using the "or" operator.

The "and" operator is required in the "cifinput" section if you want to separate out the
layer types that got OR'd together in the "cifoutput" section:

    layer ndiff CAA
    and-not CPG
    and-not CWN
    and CSN

    layer nfet CAA
    and CPG
    and-not CWN
    and CSN

    layer pdiff CAA
    and-not CPG
    and CWN
    and CSP

    layer pfet CAA
    and CPG
    and CWN
    and CSP

and so forth.  That is, mask layer CAA (diffusion), can represent either "ndiff", "pdiff",
"nfet", "pfet", "nsd", or "psd", depending on the presence or absense of other layers
CWN (N-well) or CPG (polysilicon), CSP (P+), and CSN (N+), depending on what the technology
defines.

> Can't I just write eg "layer CNW n-well"
>                                   gds 42 (1 ???)
> in order to extract the mask for n-well?

Yes, if you insist that the n-well layer must be drawn, and have the correct DRC rules for it.
If you have a one-to-one mapping between drawn layers and GDS layers, then yes, you can do it
this way, and everything is simple.

You can also choose to make the drc and cif/gds rules more complicated as a trade-off for
making the layout drawing simpler.  For example, magic can auto-generate the CWN layer for
you, with a complicated set of boolean operators.

By the way, if the fabrication process doesn't define CIF names for layers (most don't
anymore), I recommend using names that you're more likely to remember, like POLY, DIFF,
CONT, and WELL, rather than the more cryptic "CPG", "CAA", "CCC", and "CWN".  For that
matter, if you never write CIF, you don't need to stick to the 4-character limit on
layer names that CIF format imposes, so you can use names like "CONTACT" and "NWELL"
(auf Deutsch, if you prefer).

> If I import a GDS/Cif I would take the same scalefactor (100) so that
> I get my 1Lambda-1um, correct?

Yes.

> The Label statement says that each Magic Layer should only appear in one Cifstatement of a 
> Style. But what about the layers like pfet,cap?

This means that you should only have one "label" statement for a layer.  This is because labels
are handled separately from layout geometry in the database, and so each label record indicates
what layer the label is attached to.  So a label can be attached to layer "pfet", but since there
is no layer "pfet" in the GDS output, the label will be missing in the GDS file unless the cifoutput
section explicitly states that labels attached to "pfet" in magic should be attached to, say,
polysilicon in the GDS file.  So at the end of the "layer CPG" block in cifoutput, you might put
"labels poly,pfet,nfet" so that labels attached to transistor gates will be attached to the poly
layer in GDS.

> For what are different Cifstyles useful if the Techfile is only written for a specific process (eg 0.5um)?

It depends on a number of things.  I often start out with a single cifoutput style, then write others
as I need them.  You might have a style that generates fill patterns, for example, or that exercises
different process options (most fabrication processes come with lots of options).  I did extend the
cifoutput/cifinput/extract/drc section formats to allow each style to have "variants", so that it is
not necessary to duplicate an entire cifoutput style to cover a single process option.

> Personally, I would use the 1Lambda-1um scaling in any case. For the actual drawing process I
> would use the scalegrid (eg 20/1..)
> But probably this is only useful for absolute processes in around 0.5um...

For a long time, magic was stuck with 1 internal unit = 1 lambda.  I have myself only recently
started to make use of my own code changes and start writing techfiles in vendor units and
using scalegrid in the startup script.  So if anything doesn't work right, let me know.

						Regards,
						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               |
+--------------------------------+-------------------------------------+



More information about the magic-dev mailing list