sllu@venera.isi.edu (Lien Lu) (11/02/87)
We have discovered that the version of SPICE 2g6 distributed with U of Washington VLSI tools gives different current values in comparison with the SPICE 2g6 (and spice 3) distributed by UC Berkeley. After careful examination, we discovered a difference in the SPICE source codes. On line 1985 of file "dctran2.f" (comes with UW), the last variable used to calculate "FACTOR" is "XW", while the UCB counter part reads "XL". Parameters extraction results from MOSIS matches with the SPICE 2g6 given out by UCB. Shih-Lien Lu Ming Hsu for MOSIS
larry@VLSI.CS.WASHINGTON.EDU (Larry McMurchie) (11/05/87)
The recent note that appeared describing a difference between the version of SPICE 2g6 distributed by Berkeley and the version distributed by us is indeed correct. Some time ago we inadvertantly introduced this bug into the calculation of narrow channel effects on threshhold voltage. On line 1985 of file dctran2.f, the last variable used to calculate FACTOR should be XL (not XW). The line should read: 200 FACTOR=0.125D0*FNARRW*TWOPI*EPSSIL/COX*XL What can I say....we goofed. We appreciate any and all feedback from users on the tools we distribute and will inform everyone of serious problems. Larry McMurchie Univ. of Washington
sgcpal@watdcsu.UUCP (11/06/87)
In article <8711050122.AA14933@vlsi.cs.washington.edu> larry@VLSI.CS.WASHINGTON.EDU (Larry McMurchie) writes: > > >The recent note that appeared describing a difference between the >version of SPICE 2g6 distributed by Berkeley and the version >distributed by us is indeed correct. > >On line 1985 of file dctran2.f, the last variable used to calculate >FACTOR should be XL (not XW). The line should read: > > 200 FACTOR=0.125D0*FNARRW*TWOPI*EPSSIL/COX*XL > >What can I say....we goofed. Maybe you didn't. At least not totally anyway. We noticed this difference when we ran diff on the two distributions and I'm afraid both versions maybe wrong. Here is the original ucb version: C C CALCULATE THRESHOLD VOLTAGE (VON) C NARROW-CHANNEL EFFECT C 200 FACTOR=0.125D0*FNARRW*TWOPI*EPSSIL/COX*XL ETA=1.0D0+FACTOR I think line 200 should be: 200 FACTOR=0.125D0*FNARRW*TWOPI*EPSSIL/(COX*XW) Note the change from XL to XW and the inclusion of the brackets around the (COX*XW). Intuitively one would think that the width (XW) would be a factor in the narrow width calculation. This change is required to conform with the spice mos2 model documents (ERL memo) giving: eta = 1 + fnarrw pi epsilon(silicon) ___________________ 4 Cox W and to ensure that eta is dimensionless rather than something strange (1 + m**2). It would appear to me that the original UW distribution tryed to rectify the UCB error, but only went half way. Am I right, or am I missing something? Paul A. Layman University of Waterloo, Electrical Engineering, Silicon Devices and Integrated Circuits Research Group (SiDIC) INTERNET: playman@phonon.waterloo.edu UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!phonon!playman
larry@VLSI.CS.WASHINGTON.EDU (Larry McMurchie) (11/09/87)
I still believe that the formula appearing in the code originally distributed by Berkeley is correct: 200 FACTOR=0.125D0*FNARRW*TWOPI*EPSSIL/COX*XL ....and that we goofed when we tried to modify it. The key here is that COX already has an XL and an XW factored into it! (see SUBROUTINE MOSFET). In order to leave just an XW in the denominator, an XL is required in the numerator, which is exactly what appears in the formula. If I am overlooking something here, let me know. Larry McMurchie Univ. of Washington
sllu@venera.isi.edu (Lien Lu) (11/09/87)
One more bug discovered in SPICE 2g6.
Recently, we pointed out that Berkely's version of SPICE2g6 differs
from the U of Washington in calculating FACTOR. We agree with
the responses from Xerox and U of Waterloo that FACTOR should be calculated
as:
FACTOR = 0.125D0*FNARROW*TWOPI*EPISSIL/(COX*XW)
where FNARROW = DELTA is a dimensionless parameter
As a result SUXES (paramter extraction program from Stanford) should
also use the same equation to calculate FACTOR for consistency.
Further examination reveals that there is one more problem with the
calculation of VTH. Around line 2039 of the file "dctran2.f" (from U of W)
VTH is calculated as:
CDONCO=-(GAMASD*DSRGDB+DGDDVB*SARG)+FACTOR
XN=1.0D0+CFS/COX*XW*XL+CDONCO
VON=VON+VT*XN
where VON is VTH
We feel that in calculating XN, multipling XL and XW with CFS/COX is NOT
correct. Futhermore, tracing the dimension of the above lines shows an
inconsistency with the final dimension. XN should have been a dimensionless
value. From the defintion we observe that CFS = q*NFS, where
NFS according to SPICE manual has #/cm^2 as its dimension. This gives
CFS a dimension of q/cm^2. Therefore the dimension of CFS/COX is
Volt.
If we were to correct the calculation of FACTOR as suggested above,
we should also correct the XN calculation. We propose the following
changes to line 2039 and line 2040:
XN=1.0D0+CDONCO
VON=VON+VT*XN+CFS/COX
Again, SUXES should be changed to match these changes.
We invite others to comment on our suggestion.
Cheers,
Je-Hurn Shieh
Shih-Lien Lu
Ming Hsu
ARPA: sllu@mosis.edusgcpal@watdcsu.UUCP (11/10/87)
In article <8711091710.AA02296@vlsi.cs.washington.edu> larry@VLSI.CS.WASHINGTON.EDU (Larry McMurchie) writes: >I still believe that the formula appearing in the code originally >distributed by Berkeley is correct: > 200 FACTOR=0.125D0*FNARRW*TWOPI*EPSSIL/COX*XL >....and that we goofed when we tried to modify it. Indeed Larry and Berkley are correct! Unfortunately I only looked at a few lines of code around the calculation of the above FACTOR. I never considered the possibility that COX was the Gate Capacitance(Cox*W*L)(F) rather than the Oxide Capacitance(Cox)(F/m**2). I could go on about this being a poor choice for a variable name when it *traditionally* means something different, but I won't. After all, we can only use 6 character names in standard fortran and I'm sure spice must use most of the 1.5e9 available.(:-) My apologies, Paul A. Layman University of Waterloo, Electrical Engineering, Silicon Devices and Integrated Circuits Research Group (SiDIC) INTERNET: playman@phonon.waterloo.edu UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!phonon!playman
sllu@venera.isi.edu (Lien Lu) (01/14/88)
Has anyone installed SPICE 2g6 with BSIM on SUN3? I ran into some compiling error and would like to find out if someone has squared those away already. Thanks in advance. Shih-Lien Lu sllu@venera.isi.edu
aes@whuts.UUCP (STEVENS) (01/15/88)
In article <4532@venera.isi.edu>, sllu@venera.isi.edu (Lien Lu) writes: > Has anyone installed SPICE 2g6 with BSIM on SUN3? I ran into some compiling > error and would like to find out if someone has squared those away > already. Thanks in advance. > > Shih-Lien Lu > sllu@venera.isi.edu I have compiled this program on several different machines, but not the Sun. Most of these fixes should help you out, though. The BSIM portion of the program added a bunch of bugs. 1) In subroutine DCOP, several new variables are introduced but not dimensioned. These are CDGB, CDDB, CDSB. I DIMed them to 12. 2) In subroutine READIN, there is a spelling error. Change IFELD to IFIELD. 3) In subroutine PROCHK, there is a syntax error. In the line after 395, the function ISIGN is used. It should really be DSIGN. (ISIGN is for integers, DSIGN is for floats.) 4) In subroutine READIN, you might need a REWIND after the OPEN statement. Good luck!! --Andy Stevens aes@zeppo.att.com ...ihnp4!zeppo!aes
Jinfu_Jinfu_Chen@cup.portal.com (01/16/88)
A silly question, what is 'BSIM'? We have a copy of SPICE2g6 with lots of comments of 'BSIM'. I compile it under Apollo Domain and it runs okey in some circuit but crashes in other circuits which have long subcircuit and model files. The IBM VM/CPS version of SPICE2g6 we have is different from the 'BSIM' in some data statement, I wonder if this has something to do with the crash. Jinfu Chen Motorola Inc., Logic Division