|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Wed Apr 05 2000 - 13:21: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 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, 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. ---Tim
|
|
|
|