|
|
Magic Mailing List |
|
From: Jeff W. Sondeen (sondeen AT rcf-fs DOT usc.edu) Date: Wed Apr 05 2000 - 17:19:08 EDT
> I agree that a fix is needed to deal with the problem of cells which contain, > for instance, contacts only. However, I also agree that defining a separate > plane for each contact type is unwarranted. This solution is of course what i haven't heard yet what's bad about it, since i don't agree that the number of planes is an issue. in terms of the number of types, if you remove the gc,gc2(for poly2),and gv1-gv5 from SCN6M_SUBM.10, then you'll go from about 180 to 173 types, i think, which is a speed improvement of around 10% (whether ratio of squares or cubes), which i'm not sure i'd notice (when cif read/write of large designs can take 3+ hours). > happens when you try to work around a bothersome problem using the existing > capabilities of magic (I did likewise for bipolar device extraction, and was > never satisfied with the kludgy result). Since we're a *development* team, > we have the opportunity to rewrite magic to handle this in the proper way. > The real underlying problem is that magic CIF input's boolean functions > allow it to read in a cif polygon and then obliterate it completely when > it doesn't intersect any layers that it's ANDed with. This method of > contact generation creates even more problems than can be handled by > separate contact planes: A (Cadence, Mentor Graphics, L-Edit) user can > define a cell called "two_contacts" containing two contacts side by side, > then use that cell once over poly/metal (making them poly contacts) AND > once over ndiff/metal (making them ndiff contacts). I have a solution, 'gc' connects to poly or diff, but it takes a 'gc2' to connect to poly2 due to poly2 being on a separate plane than poly (which was for easy poly2-poly caps). also, there's a bug mentioned in ftp://ftp.isi.edu/pub/sondeen/magic/new/beta/CHANGELOG about the "implementation of stacked contacts" (look for that string). > though it's a bit complicated: define a CIF temp layer "contact", used to > read in all contacts which couldn't be resolved into any of the usual > contact types. After the CIF file has been read, call a (new) routine which > attempts to resolve all the temporary layers by combining with paint in > cells which overlap. It would have to be smart enough to discover when > a contact was being used as two different contact types, and duplicate the > cell as necessary. If anyone has a better idea, please let me know. gee, my wishlist for magic is in ftp://ftp.isi.edu/pub/sondeen/magic/new/INTRO, but i think the most useful improvement would be a slight variation of the edge4way drc rule which would simplify (and make possible) better drc checking. if you look at figure 9.a, page 29, of magic maintainers manual #2, it shows "cornerTypes" just to the left of the t1/t2 junction, which indeed is what magic considers: how about a rule 'edge4wayb' that considers the "cornerTypes" just to the right of the t1/t2 junction. > > ---Tim
|
|
|
|