Magic Mailing List |
|
From: Jeff W. Sondeen (sondeen AT rcf-fs DOT usc.edu) Date: Thu Apr 25 2002 - 14:47:11 EDT
Conrad H Ziesler writes: > > A quick look at the recent techfiles from mosis indicates that all of the > via and contact planes are redundantly included (for whatever > reason) reasons are (maybe) buried in ftp.isi.edu/pub/sondeen/magic/new/beta/CHANGELOG > > The point is if all the cut planes are being defined anyways, is there any > legitimate space, time, or code complexity reason to keep the > somewhat broken contact implementation? by 'broken' do you mean the difficulties reading in off-centered stacked contacts? here's how it "works": if the contacts are "centered" (as in, you made the layout using all symbolic contacts (like m123c)), then when you cif-in, all the symbolic stacked contacts will come back. however, if you manually stacked so-called "generic" (gc/gv1/gv2/etc) and placed them off-center, of got layout from some other tool, then you'll get fractured symbolic contacts (and lots of drc errors) when you cif-in USING THE DEFAULT STYLE. instead, you can use one of the so-called generic (*c*) 'cif in styles' to preserve the generic contacts/vias on cif-in. (there is a real sense in which generic contacts *are* broken -- having to do with the 'extres -- extract resistance' command (discussed in the CHANGLEOG file somewhere)) > > The motivation is that planar processes allow stacked vias. Routers > (especially cadence's warp route) seem to work better with fewer > constraints on via/contact placement. > > Magic is currently unable to handle off-centered or differing sized > stacked contacts due to conflicts in the image tile(s). (ie. the image > plane must be a tile of the same dimensions/location as the drawn > contact). > > > Other than > > 1. automatically building nice draw/erase rules > 2. specifying electrical continuity > > is there any place in the magic code that prevents ripping out the image > plane stuff? i'm worried about stuff maybe in the extractor,calma/cif, or > drc that relies on the image planes being drawn? i think 'image planes' have to do with how magic handles its symbolic contacts (by this i mean what's in the 'contact' section of the techfile). the generic contacts don't appear there, showing that you can get contact 'behavior' in magic without anything in the contact section (except you lose 'extres' as i mentioned) ((it's just not as easy as using magic's contacts since you have many more aspects to specify)). so you don't have to get rid of image planes if they're a problem, just have an empty contact section (ie. don't do traditional magic symbolic contacts). > > > I already tried rewriting the techfiles by moving the home plane of all > contacts to via planes, (reordering the planes section to be physically > realistic) and making them all 3-layer contacts (ie. the image > planes fall into the below and above metal layers) > This ridiculously simplifies the techfiles (no more > pm12c,ndm12c,pd12c,m123c,m234c,m345c,etc). However the image plane stuff > still causes trouble because painting say m1 over a corner of a ndc will > split the ndc/m1 image tile and ruin the contact (at least for DRC > purposes), it still gets drawn correctly. > we tried the more sensible 'planeorder' ordering you're talking about (m1 v1 m2 etc) but couldn't get it to work, but i don't remember the specific reasons. anyway, i think what you really want is the more efficient "half-symbolic" contacts concept (based on Andrew's "half-generic" contacts, discussed some time ago (where is this maillist's archive, anyone?)). it implements the 'generic' contacts on the same plane as their lower layer, so eliminating the planes dedicated to generic contacts. they're only partially 'symbolic' (not much really) because they require that you to surround them with the lower layer and cover them with the upper layer. (this gets around a problem Andrew observed with extraction of his more truely half-symbolic contacts in certain flush-edge cases). ((at least you don't have to draw them 2x2 (or whatever) as they do 'squares' on output ok)). would you like to alpha-test some 'half-symbolic' techfiles ? right now i just have the scmos* techfiles, which lambda do you want ? it's too early to put them online in ftp.isi.edu/pub/sondeen/magic/new/alpha but i'm moving all the techfiles into this format. (these alpha techfiles are more primitive -- there's no 'pad' layer for example) but the advantage is that the techfiles can be generated in a table driven way (so using them for non-scmos rules is more feasible). thanks, /jeff > > --------- > also, i have a simple place/route toolflow that works with magic that i'll > be putting out soon if anyone is interested. > > Basically just a set of translators for > specially labeled magic cells --> .LEF (cadence library exchange format) > specially labeled magic cells > + automatic hspice characterization --> .lib (synopsys synthesis library format) > and cell instantiations and wire <--> .DEF (cadence design exchage > format) > > also, UCLA put out a free set of tools including a recursive-bisection > cell placer "Capo" that will read a subset of LEF/DEF. > > I'm not aware of any free source workable over-the-cells router though, > i've just been using the cadence warp-route. > > --conrad > > (cziesler AT eecs.umich.edu) > >
|
|