[Magic-dev] help, why capacitance doesn't match?
Jeff Sondeen
sondeen at ISI.EDU
Thu Sep 2 12:43:33 EDT 2004
Hi. there's a whole continuum of capacitance factors to use, which
are really 'layout sytle' dependent (as in dense or sparse), but the
bottom line is that while the techfile documents that its area/fringe
data are from mosis, in fact, not all are, (sorry about that). rather,
some are interppolated from vendor data cases, which are normally
limited to the 'm' ('multi-extract') techfiles.
the Mosis numbers are measurements of large widths and spacings, so
their closest equivalent TSMC interconnect data case is the one that
has the widest spacing (10 um below). here's an excerpt of vendor
data:
Structure A : M2-FOX
width space Ctotal Cc Cbottom Ca Cf Csum/Ctotal
(um) (um) (fF/um) (fF/um) (fF/um) (fF/um) (fF/um)
--------------------------------------------------------------------------
0.40 0.400 8.43e-02 5.28e-03 5.44e-03
0.40 2.000 2.50e-02 5.28e-03 1.39e-02
0.40 10.00 4.27e-03 5.28e-03 2.94e-02
which you can see above (from file 'typ_stra' -- ie. nominal) is
area = 5.28e-03/.4 ff/um**2 = 0.0132 ff/um**2
fringe = 2.94e-02 ff/um
using your 3x75 lambda metal2 case,
0.0132*3*75*.15*.15 + .0294*2*78*.15 = 0.754785
note that even this value assumes parallel fingers, so would be below
Mosis' measurement, as Mosis wouldn't be measuring any of the side-cap
(Cc above). in practice, very few designs have no parallel lines
(side caps).
to see what magic extracts, selecting the Nom:vast case from
ftp://ftp.isi.edu/pub/sondeen/magic/new/beta/2002a/mSCN5M_SUBM.15.light.tech27
which has these extract styles:
style Nom:dense:TSMC0.25um(tsmc25)
style Nom:sparse:TSMC0.25um(tsmc25)
style Nom:vast:TSMC0.25um(tsmc25)
style Max:dense:TSMC0.25um(tsmc25)
style Max:sparse:TSMC0.25um(tsmc25)
style Max:vast:TSMC0.25um(tsmc25)
;ext style Nom:vast:TSMC0.25um(tsmc25)
gives:
C0 m2 GND 0.6fF **FLOATING
which is a little low, compared to the computed 0.754785, so a check of
the techfile data:
fgrep areacap pub/sondeen/magic/new/beta/2002a/mSCN5M_SUBM.15.light.tech27 | fgrep metal2
areacap (m2,m3c,m123c,m234c)/metal2 0.327
areacap (m2,m3c,m123c,m234c)/metal2 0.327
areacap (m2,m3c,m123c,m234c)/metal2 0.327
areacap (m2,m3c,m123c,m234c)/metal2 0.354
areacap (m2,m3c,m123c,m234c)/metal2 0.354
areacap (m2,m3c,m123c,m234c)/metal2 0.354
fgrep perimc pub/sondeen/magic/new/beta/2002a/mSCN5M_SUBM.15.light.tech27 | fgrep metal2
perimc (m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 ~(m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 0.627
perimc (m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 ~(m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 1.722
perimc (m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 ~(m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 3.624
perimc (m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 ~(m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 0.678
perimc (m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 ~(m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 1.851
perimc (m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 ~(m2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,m3c,m234c)/metal2 3.831
shows 0.327 and 3.624 are the relevant techfile factors, and indeed
0.327*3*75 + 3.624*2*78 = 638.919
explaining where the .6 ff result came from.
the reason the factors captured in the magic techfile file are a bit
different than the vendor data is that i interpolate the vendor data
to the lambda values (for example, our 3 lambda spacing would be
.45um, and since there's no .45um spacing value in the table, i
interpolate between the .4um row and the next row (not show above,
0.5um), and likewise for the other factors.
while discussing capacitance, tho, i need to remind everyone that
magic has a severe limitation when it comes to extracting side-caps,
namely, sidehalo, after which spacing magic ignores side caps.
unfortunately, it's not possible to extend side cap beyond
2*spacing+width, without starting to overcompute sidecaps to minimally
spaced min-width metal lines, as magic doesn't account for shielding
of parallel fingers. thus for the most accurate capacitance values,
use the extraction style most closely to your layout spacings: the
README describes that dense/sparse/vast refer to average spacings of
3/9/30 lambdas. you might still want to extend the sidehalo value,
just watch out for the effect on minimally spaced min-width lines.
/jeff
wwu at cs.ucr.edu writes:
> Hello, all,
>
> I use magic to extract the capacitance of metal wire, but the value doesn't
> match with the cap by calculation with MOSIS parametric results.
>
> The tech I used is "SCMOS: SCN5M_SUBM.15 [to process: TSMC25]",
> technology file is SCN5M_SUBM.15.tech27.
>
> The MOSIS parametric results is:
> http://www.mosis.org/cgi-bin/cgiwrap/umosis/swp/params/tsmc-025/t11y_epi-params.txt
>
> For example, a (3 lambda * 75 lambda) Metal2, the capacitance extracted from
> Magic is 171.387, equals to 0.327 *3 *75 + 0.627*(3+75)*2.
> ==================== param number in .tech27 ============================
> #metal2-sub blocked by
> overlap (m2,fm2,rm2,m3c,m123c,m234c)/metal2 ~space/w 0.327 ~space/a,~space/m1
> perimc
> (m2,fm2,rm2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,nwsm12c,m3c,m234c)/metal2
> ~(m2,fm2,rm2,m2c,pdm12c,ndm12c,psm12c,nsm12c,pm12c,m123c,nwsm12c,m3c,m234c)/metal2
> 0.627
> ===========================================================================
>
> However, in MOSIS's file, M2-Sub areacap=19af/um^2, fringecap=60af/um.
> So total cap = 19 *(3*0.15)(75*0.15) + 60*((3+75)*0.15)*2 = 96.187+1404=1500.187.
>
>
> So which one is correct, or do I misunderstand the MOSIS tech file?
>
> Thanks so much,
>
> Wei
>
> _______________________________________________
> magic-dev mailing list
> magic-dev at vlsi.cornell.edu
> http://vlsi.csl.cornell.edu/mailman/listinfo/magic-dev
More information about the magic-dev
mailing list