|
|
Magic Mailing List |
|
From: Jeff Sondeen (sondeen AT ISI DOT EDU) Date: Thu Jul 10 2003 - 12:30:42 EDT
i once converted some Tanner pad cells into magic (ftp://ftp.isi.edu/pub/sondeen/magic/tanner_pads_ported_to_magic/) and, besides the drc problems introduced by snapping layout from .5 lambda locations onto lambda locations ((imagine a child cell in cif with a box lower-left corner at (0.5 0.5) lambda. imagine a parent cell instancing that child cell at (0.5 0.5). would the resulting box in magic be at (0 0) or (1 1) ?)), another problem is that magic enforces spacing rules orthogonally (ie manhatten distance) while the original cells had met them only diagonally (often in arrays of contacts and vias). i used a magic techfile that had no symbolic layers (NO_DRC.00.tech27) to read the original cif in, then flattened the cells, and (cif) wrote out the flattened cells, then used the symbolic-layer techfile (like SCN4M_SUBM.20.tech27) to read in the flattened cif files. then i had to edit the resulting drc violations. i'm sure the new magic version 7.2+ would have worked much better, with it's nice snapping behavior. /jeff R. Timothy Edwards writes: > Dear Prabhat, > > > I've Magic 7.1 running on Red Hat Linux 7.1 > > We are interested in SCN4M_SUBM.20.TSMC process technology. > > We've downloaded MTSMS035DL.CIF standard cell library. > > Magic starts fine in the desired technology with the following command > > magic -T SCN4M_SUBM.20.TSMC.tech27 > > Magic also reads in the standard cell library from mtsms035dl.cif file. > > But all the cells show errors due to drc violation. The library is > > supposed to be correct. Why then does Magic show so many drc errors > > I will CC this message to the magic discussion email group; I hope > you don't mind. This topic has come up before, regarding the mismatch > between the standard cell libraries that can be downloaded from MOSIS > and the magic technology files. For anyone who doesn't know where the > referenced CIF file comes from, it's > http://www.mosis.org/Technical/Designsupport/std-cell-library-scmos.html > > The problem with this library is that most of the contacts have been > placed in subcells, such as Cnt_ActM1 or Cnt_PolyM1. The problem is that > by placing them in subcells, magic cannot parse them correctly according > to the boolean rules it uses to convert CIF to magic layout types. The > name of the subcell matches what's in the cell. So, Cnt_PolyM1 contains > poly and metal1 and contact. Because magic's cifinput rules for poly > contact requires the presence of poly, metal1, and contact, this cell > reads in correctly, without errors. HOWEVER, Cnt_ActM1 contains contact, > active, and metal1. To magic, this is ambiguous: Magic has at least > four contacts that match this description: ndiffusion contact, pdiffusion > contact, n-well concact, and p-substrate contact. It is possible to > rewrite the cifinput section of the tech file to handle this problem > with generic contacts, or you can regenerate the diffusion contacts by > hand. > > This is a perennial problem because I have seen a lot of layout like > this---mostly originating from L-Edit, I think---with "floating" > contacts in subcells. I will think about a permanent solution to > this problem. > > Regards, > Tim
|
|
|
|