|
|
Magic Mailing List |
|
From: Jeff W. Sondeen (sondeen AT rcf-fs DOT usc.edu) Date: Wed Apr 05 2000 - 11:15:00 EDT
> >When we (Tim and I) incorporate all the current changes to magic, test > >it on a few platforms, grab the new tech files, make a release (I'm > >going to try and automate most of this), ask for help/input :), etc > >etc. we plan to send e-mail to <magic-dev AT csl DOT cornell.edu>. The people > >listed above are currently members of magic-dev AT csl DOT cornell.edu. > > Just a couple of caveats regarding the mosis supplied tech files: > 1) These tech files use a plane per metal and via. Although this eases > the job of the tech file developer is probably not the best thing to do > since it uses a lot of memory. well, i believe that each metal layer *must* be on it's own plane, so the issue is contacts to metal. the new techfiles have both traditional contacts, where each resides on the same plane as the metal it connects to (eg. layer 'm2c' resides on the metal2 plane), as well as new (named "generic") contacts and vias (gc, gv1, gv2, etc.), which do reside on their own plane. the main need for these is to read cif/cal files that contain contacts (in subcells) which aren't covered by upper and lower metals: traditional magic misses these (as it has no way to represent them). they also allow the ability to check your chip prior to submission by reading in the cif in a manner more like mosis would read it (cif input style lambda=*(cps)), so you can see if the generated cif contains any contact errors (but this is sort of limited since magic still snaps the layout onto a lambda grid, while mosis only snaps to a half-lambda grid). anyway, it isn't the number of *planes* that slows down magic, it's the number of *types*. in tsmc's 6-metal process with an additional metal layer called MiM (metal-insulator-metal), there are about 180 magic layers (types) plus the 20 or so built-in ones; so magic has to allow 225 types, while many layer operations go as #types**2 and even some go as #types**3. it would be nice if magic didn't use macros to implement its type operations (see database/database.h), rather use function calls (and let gcc optimize them), so that you would only "pay" for the number of types that the techfile uses (so magic would be much faster with techfiles that use few types, while still being able the handle the big ones). by the way, i updated the set of "header" files (see ftp://ftp.isi.edu/pub/sondeen/magic/new/README ) placed on ftp://ftp.isi.edu/pub/sondeen/magic/new/beta/examples/*.h or just get ftp://ftp.isi.edu/pub/sondeen/magic/new/beta/examples/headerfiles.tar.gz they now have the 225-type limit needed for SCN6M_*.tech27 > 2) There is a bug in the files which they never fixed: nnd connects to pdiff > and ppd connects to ndiff. In real silicon this is a zener diode but > given > these techfiles magic treats it as a perfect short. believe me, since i learned this first hand (read that, chip failure), the "diode" between ohmic and diffusion *is* a short in all *silicided* processes; silicide is metal put into the diffusions to lower the resistance. it does it so well that in some of HP's standard library cells, there're no actual contacts to ohmics which abut diffusion (rather the contact to diffusion is enough for both). > I don't know if you guys have time to fix issue #1 above but if you plan on > releasing the techfiles along with magic you should at least fix #2. > > > > -- Stefanos
|
|
|
|