mark@mips.UUCP (Mark G. Johnson) (08/05/86)
[to the line eater: I typed this on 8/5/86 at 9:45AM PDT] Summary: Tests were performed with UNIX Spice 2G6 to see whether the specification of "level=2.0" caused Spice to use the MOS model for level 1. The results were that "level=2.0" causes Spice to use MOS model level 2. No bug was found. In message <1561@alvin.mcnc.UUCP>, gbn@mcnc.UUCP writes: > I have discovered a serious bug in Spice2G6 that has > plagued us for several years. The problem occurs when specifying > the model parameter "level". The three levels of SPICE model > equations used to calculate current can be set with this model > parameter. If you set "level=2.0", SPICE does NOT use level "2" > model equations, the SPICE parser incorrectly reads the number 2.0 > and defaults to level "1". You must change it to integer "level=2" > for the correct model selection. SPICE prints that it is using > level "2.0", but in actuality level "1" equations are generating > the current. > This bug is likely to be found in various versions of SPICE > since it has been in the code forever. To test out this assertion, I edited the fortran source of Spice 2G6, specifically the subroutines MOSEQ1 and MOSEQ2, which compute the MOSfet drain current for model levels 1 and 2 respectively. In MOSEQ1 I added: write(iofile,377) 377 format('0 EXECUTING MOSEQ1') and in MOSEQ2: write(iofile,337) 337 format('0 EXECUTING MOSEQ2') Then I recompiled the entire Spice 2G6 program and ran it on about 20 input datasets. These datasets tried out both NMOS and PMOS models, and many syntactic variants of "level=xyz", including: LEVEL=2.0 level=2.0 level=2. level=2.1 level=2 level=2.00 level=1.0 level=1.2 etc. I also experimented with subsets of the other model parameters to see whether their presence/absence affected the program's selection of model level. ==> RESULTS: Specifying level=2.0 causes subroutine MOSEQ2 ==> (and not subroutine MOSEQ1) to be executed. ==> This was true for all other syntactic variants ==> "level=2.xxx" as long as the integer part is 2. ==> Similarly, "level=1.xxx" selected MOSEQ1. ==> The bug reported by gbn@mcnc was not observed. Perhaps the failure to replicate gbn@mcnc's results arises from somebody at Berkeley doing "minor revisions" to the major release called Spice 2G6. My tests were performed on virgin Berkeley source code (to the best of my knowledge anyway), using a VAX 11/780 running UNIX 4.2 BSD. This copy of Spice 2G6 prints "spice 2g.6 3/15/83" on the top line of every output page. Here is one of the input files I used in the tests. On my recompiled Spice it calls the modeling subroutine and prints '0 EXECUTING MOSEQ2' five times. The calculated ids for transistor m1n was 8.10E-03 amperes. * try a mos model with level=2.0 .options list * .model n nmos vto=.75 tox=400e-10 nsub=9.5e15 xj=0.35u + ld=0.20u ucrit=.61e5 uexp=0.10 vmax=5e4 uo=650 neff=3.8 + level=2.0 * .op vcc 100 0 dc 5.0 m1n 100 100 0 0 n w=50u l=2.0u .end -- -Mark Johnson UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mark DDD: 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
mark@mips.UUCP (Mark G. Johnson) (08/08/86)
Summary: Tests were performed with UNIX Spice 2G6 to verify an assertion made by gbn@mcnc. He said that if you specify "level=2.0" you actually get Spice model level 1, while if you specify "level=2" you actually get Spice level 2. The results were that specifying level=2.0 gets level 2. So, no bug was found. In message <1561@alvin.mcnc.UUCP>, gbn@mcnc.UUCP writes: > I have discovered a serious bug in Spice2G6 that has > plagued us for several years. The problem occurs when specifying > the model parameter "level". The three levels of SPICE model > equations used to calculate current can be set with this model > parameter. If you set "level=2.0", SPICE does NOT use level "2" > model equations, the SPICE parser incorrectly reads the number 2.0 > and defaults to level "1". You must change it to integer "level=2" > for the correct model selection. SPICE prints that it is using > level "2.0", but in actuality level "1" equations are generating > the current. > This bug is likely to be found in various versions of SPICE > since it has been in the code forever. To test out this assertion, I edited the fortran source of Spice 2G6, specifically the subroutines MOSEQ1 and MOSEQ2, which compute the MOSfet drain current for model levels 1 and 2 respectively. In MOSEQ1 I added: write(iofile,377) 377 format('0 EXECUTING MOSEQ1') and in MOSEQ2: write(iofile,337) 337 format('0 EXECUTING MOSEQ2') Then I recompiled the entire Spice 2G6 program and ran it on about 20 input datasets. These datasets tried out both NMOS and PMOS models, and many syntactic variants of "level=xyz", including: LEVEL=2.0 level=2.0 level=2. level=2.1 level=2 level=2.00 level=1.0 level=1.2 etc. I also experimented with subsets of the other model parameters to see whether their presence/absence affected the program's selection of model level. ==> RESULTS: Specifying level=2.0 causes subroutine MOSEQ2 ==> (and not subroutine MOSEQ1) to be executed. ==> This was true for all other syntactic variants ==> "level=2.xxx" as long as the integer part is 2. ==> Similarly, "level=1.xxx" selected MOSEQ1. ==> The bug reported by gbn@mcnc was not observed. Perhaps the failure to replicate gbn@mcnc's results arises from somebody at Berkeley doing "minor revisions" to the major release called Spice 2G6. My tests were performed on virgin Berkeley source code (to the best of my knowledge anyway), using a VAX 11/780 running UNIX 4.2 BSD. This copy of Spice 2G6 prints "spice 2g.6 3/15/83" on the top line of every output page. Here is one of the input files I used in the tests. On my recompiled Spice it calls the modeling subroutine and prints '0 EXECUTING MOSEQ2' five times. The calculated ids for transistor m1n was 8.10E-03 amperes. * try a mos model with level=2.0 .options list * .model n nmos vto=.75 tox=400e-10 nsub=9.5e15 xj=0.35u + ld=0.20u ucrit=.61e5 uexp=0.10 vmax=5e4 uo=650 neff=3.8 + level=2.0 * .op vcc 100 0 dc 5.0 m1n 100 100 0 0 n w=50u l=2.0u .end -- -Mark Johnson UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mark DDD: 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086