|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Mon Mar 24 2003 - 17:04:49 EST
Dear Charles, I'm still looking into the problem of CIF and GDS reads. At first, I found a couple of errors which were definitely causing a segmentation violation. However, with that fixed, I still get very bizarre behavior. I will probably post the fixes at the end of the day, and keep working on how to resolve the remaining problems. Looking at the CIF file, there is a lot of nonmanhattan geometry in there, and most of it is defined on a fairly standard lambda grid. Most CIF cells are defined with a multiplier of 1000 and most values are divisible by 1000. Then, it hits the BufZ cell, which has a nonmanhattan polygon defined on y=71244. The eventual fallout of this is that the magic grid gets redefined to 1/6250 of its original size. This very, very fine internal grid is apparently causing arithmetic overflow in various routines, but I have not yet figured out where, and if there is anything that can be done about it. As far as the contacts are concerned, I've never been particularly happy with the way contacts are defined in the tech files. The tech files define a "generic contact" type. In my mind, "generic contact" should always be defined in the cifinput section such that every contact in the input is turned into a generic contact, after which the generated layer is ANDed with various layers to create the magic types pc, ndc, pdc, etc., etc. (likewise for vias). If that's done, then any contact which does not have other layers defined along with it becomes a generic contact. While the use of generic contacts is not as appealing as splitting them into different sub-types, with this method at least you don't LOSE them when reading the input, and they can be written back out in the same way without screwing up the layout. For the MOSIS tech files, this doesn't work so well because the generic contact is defined on its own plane, so you can't define everything to be a contact and then overwrite specific combinations of layers with other contact types. For the standard cell files in question, it appears that the only thing the techfiles lose is the active contacts, because L-Edit only differentiates between N and P diffusion with select boundaries, so magic loses ndc and pdc after applying its rules. This can be kludged into the tech file by adding, in the cifinput section, after all the other "layer gc" definitions, the following: layer gc CCA and CAA and CMF and-not CSN and-not CWN and-not CSP calma CCA 48 * This appears to cover all the cases which caused missing contacts. Regards, Tim
|
|
|
|