• Next message: R. Timothy Edwards: "grid vs. lambda"
• Previous message: Andrew Lines: "Contacts"
• In reply to: R. Timothy Edwards: "more on contacts. . ."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

R. Timothy Edwards writes:
 > Last week, I was trying to transfer an L-Edit layout into magic, and
 > encountered the long-standing problem with contacts:  This layout had
 > a cell containing contact, metal, and active (CAA), which was used
 > for n-diff, p-diff, n-well, and p-substrate contacts, and of course
 > disappeared entirely on CIF read because for each contact type the
 > layers ANDed into nothing.  However, I was using the new
 > SCN3M_SUBM.30.tech27 file, which contains entries for generic
 > contact and generic active, and I made the following observation:
 > if you simply add, to the top of the tech file "cifinput" section,
 > the following lines:
 > 
 >  layer gc CCA,CCC
 >  labels CCC
 >  calma CCA 48 *
 > 
 > Then ALL contacts become "gc" by default.  All other contact
 > definitions go after this one in the cifinput file, so that any
 > contacts which meet magic's requirements by having all the right
 > layer types in the same cell, will be overwritten with the correct
 > magic contact type.  The above definition will yield DRC errors,
 > but it will actually be a complete and correct layout (although
 > if you write CIF again from magic, CCA's which got turned into
 > "generic contact" will get written out as layer CCC. . . would
 > that be a problem?).  At least this way, magic doesn't obliterate
 > CIF geometry on input.

sorry for the late reply.  i'm don't believe magic cif read is
dependent on the order of the rules, so i don't think that it matters
where you put the 'layer gc' command (you could just as well put it at
the end of the cifin section), you should always get a 'gc' as well as
any symbolic contacts (like pc) whereever it can build them.


 > 
 > Additional note:  I made some other changes to the magic-7.1 source
 > last week.  I noted, on the same L-Edit layout, that magic will
 > re-align anything not on the lambda grid without bothering to post
 > any warning message that it has done so.  I fixed this problem,
 > and also added a "scalegrid" command, which changes the ratio of
 > magic's internal units to lambda, so that by doing, for example,
 > "scalegrid 1 2", magic units will be reduced to 1/2 lambda, and it
 > will be possible to correctly read CIF files containing geometry
 > on 1/2 lambda spacing without rewriting the tech file.  This is a
 > very simple implementation, and needs work, but it's a start.
 > 
 > 							---Tim

this sure would be nice, but would tty input (like ;box 0 0 10 10) be
dealing with lambda units or grid units?  how about drc rule units?
also, layouts sent to mosis in scmos rules are supposed to be on a 1/2
lambda grid (ie. mosis will snap vertices to a 1/2 lambda grid), but
some autogeneration commands (like squares) could be creating layout
on a 1/4 lambda grid if given shapes having vertices on a 1/2 lambba
grid.

can you let me know when you've got something to be 'beta-tested' ?
thanks,
/jeff

• Next message: R. Timothy Edwards: "grid vs. lambda"
• Previous message: Andrew Lines: "Contacts"
• In reply to: R. Timothy Edwards: "more on contacts. . ."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]