• Previous message: Wes Hansford: "Re: {0011.126} Re: generating vendor rules"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

-------- Original Message --------
Subject: Re: {0011.126} Re: generating vendor rules
Date: Fri, 17 Nov 2000 14:40:02 -0800
From: "Jeff W. Sondeen" <sondeen AT rcf-fs DOT usc.edu>
To: Michael Godfrey <godfrey AT pixeldevices DOT com>
References:
<200011161939.LAA27600@curie.isi.edu><200011171753.JAA08292@curie.isi.edu><14869.36500.478949.423093@mizar.usc.edu><3A15A09B.F7EA9E1D AT pixeldevices DOT com>


Hi Michael, thanks for your help.  can you forward your email to the
magicdev list, tho?  (magic-dev AT csl DOT cornell.edu)

thanks,
/jeff



Michael Godfrey writes:
 > > anyway, i believe we're agreed that Mosis is not stopping magic
 > > support, but that scmos rules can't handle every vendor option, so the
 > > question is, how to get magic techfiles to do vendor rules
 > > "better". (assuming you want every vendor option).
 > 
 > This sounds good. Sorry if I added to the confusion.
 > 
 > In any case, to provide a bit more explanation, here is the flow that works 
 > for us, and which I would say needs to be carried out in some form if you 
 > want to be confident about a layout:
 > 
 > 1. Obtain the vendor's rules on paper and in Dracula. (We always find that
these
 >    two items have significant differences and not all vendors answer the same
 >    way when you ask: is paper or Dracula correct?)
 > 
 > 2. Create a tech27 file that "best" handles the vendor rules. (You pointed
 >    out obvious limitations in Magic in doing this: selects, overlap from
cells,
 >    etc.) 
 > 
 > 3. Write GDS from Magic. (Also, verify that Magic can read the GDS back in
 >    correctly.)
 > 
 > 4. Check the GDS using a DRC tool that understands Dracula or a translation
 >    of Dracula. LEDIT can be made to do this, but not easily. There are
 >    Dracula clone tools if you cannot get the real thing... This step usually
 >    shows a number of DRC problems which can be (almost always) corrected in 
 >    Magic. Typically, this involves moving objects so the Magic-induced 
 >    interactions go away.
 > 
 > Even if Magic claimed to be able to get it right, I would advocate this
 > approach which implements the "do not trust any one tool" attitude. With
 > something as important as a fab run, and the imprecision of DRC definition,
 > a second opinion is essential.
 > 
 > Michael

• Next message: R. Timothy Edwards: "Magic compilation under Linux (esp. RedHat 7.0)"
• Previous message: Wes Hansford: "Re: {0011.126} Re: generating vendor rules"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]