MAGIC Magic Mailing List
 
 

From: Jeff W. Sondeen (sondeen AT rcf-fs DOT usc.edu)
Date: Thu Apr 25 2002 - 14:47:11 EDT

  • Next message: Clinton Gazeley: "running magic"

    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)
     > 
     > 
    


  •  
     
    Questions? Contact Rajit Manohar
    cornell logo