|
|
Magic Mailing List |
|
From: Jeff W. Sondeen (sondeen AT rcf-fs DOT usc.edu) Date: Fri May 12 2000 - 17:29:19 EDT
Andrew Lines writes: > This is a multi-part message in MIME format. > --------------B5CAF4DB0B9E32B2ED293417 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > I take it I've now been added to the Magic mailing list? Thanks Rajit! > > Our approach to the contact issue is to only use the CCC layer. I > belive MOSIS offers a cif in/out style with a "c" in it which does the > same. The advantage is that this corresponds better to the actual > masks. The disadvantage is that if you read CIF you get a whole bunch > of generic contacts instead of pc,ndc,etc. You can fix the DRC so that > these generate no errors. As long as you don't expect to heavily edit > the resulting magic layout, this isn't really a big deal. > > A neat trick is to make a tech file which has lambda=0.01um, separate > planes for all CIF mask layers, and no geometry processing of any > layers. Viola, open source CIF editor! We've been using this to > combine our own layout (based on SCN6M_DEEP rules) with an outside > vendor's pad library in GDS2 format. sorry for the late reply. this would be nice, and is used in NO_DRC.00.tech27, but has the problem that magic is limited to only 32 planes, 6 of which are dedicated to 'system' things, so the user gets only 25 or 26 planes (or layers in this case). many drc rules don't work across planes, and (current) magic couldn't extract transistors. > > One final issue for the Magic-dev community: Has anybody figured out a > GOOD way to stack contacts? Most modern processes with planarization > can have arbitrarily stacked and staggered contacts between all wiring > layers. The problem is that contacts in Magic project a tile of contact > paint into all the planes that they span. Therefore, two contacts can't > overlap on any planes because of Magic's data structure. Strangely, > some contacts seem to overlap (pc and m123c) apparently because the > overlap occurs only between two image planes and not on either home > plane. However, despite the fact that this configuration raises no > local DRC errors and generates correct CIF, the subcell DRC checker will > still flag it as a DRC error. This is an inconsistency (BUG?) that > results from the 3-layer contacts. 'pc' (generating CCC or CCP) is DRC ok under 'm123c' (CVA and CVS), whether done in the same cell or by overlapping subcells (with a 'pc' in one cell, and an 'm123c' in another). magic won't let you overlap compatible contacts (such as an 'm2c' (CVA) in one cell, and an 'm123c' in another) because it may generate the CVA 'squares' differently (it generates CVA's per cell), so that each cells' generated 2x2 CVA's might not line up exactly therefore adding up to combined CVA's that aren't 2x2 in the final layout. (let me know if you need an example to see this). it shouldn't ever be a problem when all symbolic contacts are ONLY an exact multiple of the 'squares' overlap-size-space tripplet (so it wouldn't matter which "way" (left-right or top-bottom) each cell was traversed to generate the squares), but magic isn't that 'smart' -- so it just plays safe. one solution would be to require all contacts to always be an exact multiple, but then of course layout isn't quitre as 'multi-vendor-rules' friendly. > > The solutions to stacked contacts that we have explored involve: > > 1) The new MOSIS style generic contacts. Versatile, but a pain to edit. > > 2) Half-generic contacts. These don't actually use the Magic contacts > at all, but simply live as different paint in the lower plane, and also > have electrical connectivity to the upper plane. You still need to > paint the upper metal layer, but there is less tedious editing than the > generic contacts, with no loss of versatility. There is no need to > paint every cut or have metal overhangs. a great idea, can you send me an example techfile so i can try it out? (however, you don't have to 'paint every cut' now -- you can draw generic contacts larger than 2x2 and magic will generate 2x2 shapes into the cif file) > > 3) A mixture of Magic-style and half-generic contacts. You could use > the Magic contacts by default, and only use the others when you need > them to be overlapped. i improved the 'connect' section (for release 2000d) so that generics will 'connect' to symbolics ok; so you could put a 'gc' under an m123c for example (at any offset). the problem is that on cif input you must use one of the 'preserve contacts' input styles else magic's generation of it's symbolic stacked contacts will be messed up unless all the CCC/CVA/CVS etc are aligned. this is the problem of your "mixture" method -- how can it be preseved across cif ? (what input style would know which contact stacks to make pure symbolic and which to make half-generic). > > Does anybody have any other ideas on how to introduce easily editable > stacked contacts to Magic, > either through clever tech files or a code patch? > > Andrew Lines > Asynchronous Digital Design, Inc. > > > > --------------B5CAF4DB0B9E32B2ED293417 > Content-Type: text/x-vcard; charset=us-ascii; > name="lines.vcf" > Content-Transfer-Encoding: 7bit > Content-Description: Card for Andrew Lines > Content-Disposition: attachment; > filename="lines.vcf" > > begin:vcard > n:Lines;Andrew > tel;fax:(626) 844-2951 > tel;home:(626) 568-4928 > tel;work:(626) 844-2941 > x-mozilla-html:FALSE > url:www.avlsi.com > org:Asynchronous Digital Design Inc. > adr:;;1010 E. Union #202;Pasadena;CA;91106;USA > version:2.1 > email;internet:lines AT avlsi DOT com > title:Founder > x-mozilla-cpt:;11936 > fn:Andrew Lines > end:vcard > > --------------B5CAF4DB0B9E32B2ED293417--
|
|
|
|