|
|
Magic Mailing List |
|
From: Jeff W. Sondeen (sondeen AT rcf-fs DOT usc.edu) Date: Thu Sep 27 2001 - 12:07:02 EDT
R. Timothy Edwards writes: > Dear Jeff, > I'll give that some serious thought, as I have been occasionally > troubled by magic's habit of leaving gaps between cells when shrinking > layers (usually this means a well, and usually can be ignored, but > it's really not proper to assume that everybody "knows" that you > have to write CIF, read it back in verbatim, and check for these kind > of violations. by the way, mosis always bloats and shrinks the well and select layers by 1/2 their spacings to merge shapes, at least for scmos* rules (and i think for all native rules, too). by the way squared, this means that if you draw ohmic active nested within diffusion active (eg pdiff-nohmic-pdiff) with the ohmic width <= select spacing, then the ohmic active is turned into diffusion active. (eg. the growing pselects erase the nselect). so in general, never nest ohmic active in diffusion active (unless it's wide enough)! > I don't think that a "must-overlap"-type of rule would be advisable, > though. "no-overlap" and "exact-overlap" only have to check a boolean > (yes/no) condition, which is easier to do across the hierarchy thanr i think for this 'native design rule' application all shrinks could be <= 1/2 lambda, so a hard-wired 'must_overlap' value of 1 lambda would still do the job. > checking for compliance across a given distance. However, I admit > that I have not looked closely at the code for DRC checks across > cell boundaries, so I will look at it and see how it might be > implemented. > I have become used to the fact that the original authors of magic > were extraordinarily clever, and any obvious things which have not > been implemented can be expected to be a real pain to deal with. i agree! it's amazing software. > > Regards, > Tim
|
|
|
|