|
|
Magic Mailing List |
|
From: erik peterson (erik AT yanntek DOT com) Date: Wed Oct 24 2001 - 15:14:59 EDT
hiya,
we used to extract some devices in MAGIC as FETs as well, since you
can
go back with scripts/C-code and identify the "special" FETS you
extracted
and convert them to the proper device. we did this for 2 terminal
devices
that had polarity: flipping the terminals had to trigger LVS errors
(caps,
diodes, ESD-structures). we also used the FET trick for extracting
resistor networks, especially those where you need to "control" which
nets are interesting. what we end up is a techfile filled with flag
layers to help magic extract the information out of the layout. these
flags can be autogenerated, but most of the time they end up being
painted by a human being.
i try to minimize the amount of data in magic that WONT make it to
final
tapeout. it makes the techfile smaller (good!) and it allows LVS to
operate
on a final tapeout, not a tapeout-with-flags-and-drc-helper-layers-etc.
magic is an amazing layout tool. we have done many wierd things with
it to solve problems that people with cadence thought impossible (unless
you have the $$$, even then, prob not). the option of "tweaking" the
tool and techfiles on the fly, in front of customers, or off-site at the
foundry (on a laptop!) makes you look like a wizard.
but..
when it comes time to do a proper LVS of the final GDS, you cant
afford
to let these things go unchecked:
1. who (using what?) has tortured my DRC and cifout sections?
2. who is doublechecking my final tapeout?
3. how will i know if the foundry cells i have to parachute into
the design are placed correctly.
4. how strong is my LVS? did i check everything? did a human
have to "touch" the GDS for my extraction to work?
5. how many cifout sections do i have in my techfile? is there
a 'tapeout' AND a 'lvs' section? ('drc' sections are ok, thats
a different beast..)
6. besides LVS, do i have enough backannotation information to
shove back into the simulator?
7. ...
dont have time to write more, i am staring at a salami sandwich with
my
name on it and im running out of lunchbreak. a big part of my solution
to
the list above is to use magic for layout, and use ANOTHER tool to help
validate my magic techfiles and designs. i dont use magic to extract,
since
sometimes magic is NOT the last tool to touch the database. I use a
tool
that can operate on GDSII that *could have been* "assembled" from
different
sources (such as foundry cells parachuted at the last minute, or cells
that
contain non-rectangle/45deg polygon monstrosities).
bah! out of lunchbreak. here is the page for 'space'. its free, skip
lunch and install it :) its an active project, and the guys that make
the
tool are no fools.. read the papers they gave ;)
http://cas.et.tudelft.nl/~space/space_soft.html#space_full
-erik
"R. Timothy Edwards" wrote:
>
> Dear John,
>
> This may be an end-run around your problem, but this is how I have
> dealt with resistor extraction in the recent past (also for a DAC
> circuit). For this application, I first tried looking at extres, but
> as I had similar problems getting it to do what I wanted, I took the
> approach outlined here (to any magic-dev people listening in to this
> discussion: Is extres broken, and if so, what can we do about it?
> If extres is not broken, or else once we fix it to our satisfaction,
> is there any reason for it to be separate from the regular "extract"?).
>
> 1) Use the appropriate tech file. I was using the AMI tech file
> SCN3ME_SUBM.30.tech27 from Jeff Sondeen's "2000 beta" set. Most
> if not all of these *.tech27 files contain a layer type "rpoly" which
> represents nothing more than "poly" used as a resistor (sort of like
> using a "resistor ID box" in other layout editors). "rpoly" requires
> another layer called "pseudo_rpoly", which looks sort of like a well
> or implant, to overlap the "rpoly" layer by at least one unit on all
> sides ("rpoly" acts like "poly" + "pseudo_rpoly").
>
> 2) Draw "pseudo_rpoly" on top of poly wherever you want to define a
> resistor. A typical resistor looks like:
>
> ppp
> ppp
> rRRRr p = polysilicon
> rRRRr r = pseudo_rpoly
> rRRRr R = rpoly (poly + pseudo_rpoly)
> rRRRr
> rRRRr
> ppp
> ppp
>
> 3) Extract. The "extract" section of the 2000b tech files contains the
> line:
>
> fet rpoly poly,pc 2 polyResistor Gnd! nwell,pwell 0 0
>
> which after ext2spice gives you something like this:
>
> m1005 rtap a_536_60 rout Gnd zpolyResistor w=21 l=20
> + ad=0 pd=0 as=0 ps=0
>
> This means that resistors get extracted as FETS. However, it is not
> too much trouble to look for the lines in the resulting SPICE netlist
> containing the model name "polyResistor" and run a "sed" script or
> somesuch to replace the transistor with a resistor. Here is where
> the use of "pseudo_rpoly" comes into effect: Due to the overlap,
> the "pseudo_rpoly" acts like a transistor gate for the purposes of
> transistor extraction. Therefore, the gate node in the SPICE deck
> can be ignored, and the w=(value) and l=(value) terms give the
> proper width and length of the transistor, which in turn can be
> used to compute squares, and in conjunction with the polysilicon
> resistivity for the technology, the resistance. If the pseudo_rpoly
> layer runs as close to contacts as possible, then the computed
> resistance will be reasonably accurate. In the above example from
> my DAC, the SPICE line defines a 0.95-square resistor between nodes
> "rtap" and "rout". Node "a_536_60" (the pseudo_rpoly "gate") is
> ignored, and the "substrate" connection Gnd is meaningless.
>
> I hope this explanation helps!
> Regards,
> Tim
|
|
|
|