MBALAMUT@USC-ECL.ARPA (01/03/86)
SSSSS PPPPP IIIII CCCC EEEEEE RRRRR AAAA CCCC K K S P P I C C E R R A A C C K K S P P I C E R R A A C K K SSSS PPPPP I C EEEE RRRRR AAAAAA C KKK S P I C E R R A A C K K S P I C C E R R A A C C K K SSSSS P IIIII CCCC EEEEEE R R A A CCCC K K The Newsletter of the SPICE Users Group ------------------------------------------------------------------------- Volume 4 Number 1 Fall/Winter 1985 ------------------------------------------------------------------------- Editor: Morris Balamut - mbalamut@USC-ECL ------------------------------------------------------------------------- Electronic Edition ------------------------------------------------------------------------- EDITORS MESSAGE Yes Virginia there is a SPICE Rack. The 1985 issue of the SPICE Rack's time has come. It sometimes amazes me at how fast time goes by. I have been trying to put out a copy of the SPICE Rack for over six months. It is amazing how so many trivial, non-important things, like my job, kept getting in the way. Time does fly when you are hav- ing fun. I am planning to publish next year (hopefully a full set of 4 issues) and I need your contributions. Please send me articles, questions and letters. If you discover a bug but can't fix it, please document it and submit it to me for publication. Clearly identifying bugs and problems with SPICE is almost as important as fixing the bugs. Please share your knowledge and experience it will benefit everyone. The SPICE Rack will be available (when published) electronically via the ARPANET. The SPICE Rack will be sent to the INFO-VLSI special interest bulletin board (BBOARD). It will also be submitted for post- ing on the main BBOARD (may not be available at all sites). ARPANET users can request to be placed on the distribution list for INFO-VLSI by sending mail to INFO-VLSI-REQUEST@SANDIA-CAD. INFO-VLSI is the CAD special interest BBOARD and SPICE User Group members who have access are invited to use this BBOARD to exchange information on SPICE, simulation and CAD in general. I can be reached on ARPANET, or from CSNET via CSNET-RELAY, at MBALAMUT@USC-ECL. I will be happy to receive any submissions to the SPICE Rack sent via ARPANET. Information about the availability of SPICE Rack on other networks will be published when available. I am continually receiving requests for versions of SPICE for every possible CPU imaginable. If you have ported SPICE to a non-standard Volume 4 Number 1 Page 1 SPICE Rack Fall/Winter 1985 CPU and are willing to make it available to others please let me know. I would really appreciate you would cooperate with me in this matter. The 'standard' machines are Burroughs, CDC, DEC, Honeywell, IBM, Sperry and Prime. In this issue we are bringing you a special edition of the column "From the Horses Mouth". This reprint celebrates the release of SPICE3. The information is reprinted from the University of California at Berkeley "EECS/ERL 1985 Research Summary." The purpose of these reprints is to provide an insight into the ongoing research at Berke- ley. Any questions about the research itself should be directed to Ms. Karen Marek who is the coordinator of the EECS Industrial Liaison Pro- gram at Berkeley. Her address is: EECS Industrial Liaison Program, 558 Cory Hall, University of California, Berkeley, CA, 94720. While this newsletter was still in its embyonic state, I received my copy of SPICE3. So far all I did was open up the package. Look for more information about SPICE3 in the upcoming issues. FROM THE HORSES MOUTH A new version of the SPICE circuit simulator, SPICE3, has been written. This version uses the same basic algorithms and device mod- els as previous SPICE2 versions, but is a completely new implementa- tion in the C programming language. The use of C simplifies the program significantly because the language supports complex data structures, dynamic storage allocation, and pointers, all of which were needed by SPICE2 and also required significant additional code and complexity of implement in FORTRAN. This new version breaks the program into a number of independent mod- ules, each of which interacts with the others through a few simple subroutine calls only, thus allowing modules implementing new algo- rithms or devices to be substituted or added with relative ease. A major separation between input, analysis, and output was also made to allow the analysis section to be used as a subroutine package within a much larger program. The program is currently running with almost all the devices supported by SPICE2 at speeds from two to three times that of SPICE2. Additional work is in progress to improve program efficiency, implement the remaining SPICE2 devices, add further devices and models (such as the BSIM model), and improve the convergence characteristics of the pro- gram. [SPICE3 version 3A.5 has been released by UC Berkeley. It is available to run under UNIX or the VMS operating system. To order a copy send a check for $150 (payable to The Regents of the University of California) to Cindy Manly, EECS Industrial Support Office, 461 Cory Hall, University of California, Berkeley, CA 94720. editor] Volume 4 Number 1 Page 2 SPICE Rack Fall/Winter 1985 REMOVAL OF CODE GENERATION __________________________ To convert the distributed IBM version of SPICE to the simplest gener- ic fortran version available, there are 3 major steps that must be taken: replacement of IBM assembler code, removal of code that depends on the assembler code, and removal of an IBMism from the fortran code itself. 1. The troubles some IBMism that permeates the code is the form of subroutine declarations. In a few early IBM fortran compilers, an argument might be treated as a 'copy-restore' argument instead of a reference argument, unless its name was enclosed in slashes in the declaration. This results in subroutine headers like: SUBROUTINE ITER8(/ITLIM/) instead of the more conventional: SUBROUTINE ITER8(ITLIM) This does not cause problems for any of the more recent IBM fortran compilers, but does bother many other fortran compilers. Hopefully, we will remove this problem form the code ourselves one of these days, since none of the IBM fortran compilers currently in use needs this, but it is relatively low on our list of maintenance priorities. The fix for this is to remove all of these unnecessary slashes in subroutine and function declarations. 2. The assembler file on the IBM tape is much more extensive than it was in earlier versions of SPICE because of the addition of the CODGEN option and dynamic memory allocation support to our IBM dis- tribution. When porting this release to another machine, this will all have to be deleted, leaving only the following subroutines to be supplied in the assembler package: second(time) - time is a double precision floating point variables which will be set to the current elapsed CPU time for this job, in seconds. datime(date,time) - date and time are both double precision vari- ables which will be filled in with the current date and the time in fortran 'A8' format for printing in headers. loc(data) - data is an integer, and will be left unchanged while the integer valued function returns the actual memory address of the parameter. Volume 4 Number 1 Page 3 SPICE Rack Fall/Winter 1985 gtmain(address, size) - this routine is optional, and its use depends to a large extent on the philosophy of your operationing system. SPICE needs a large work array for its dynamic memory allo- cation package. Previous versions of the program obtained this pro- gram by including the common block 'BLANK' which contained the array 'VALUE' dimensioned to contain 200000 double precision values. This took up lots of space, and forced you to recompile whenever you came up with a problem bigger than the standard. The IBM version uses the gtmain function to defer the sizing of this array until run time. The array VALUE is now only defined to be of size 64, not 200000, and gtamin obtains all available memory up to your job limit from the operating system and uses this space for the dynamic area. gtmain returns the address in 'integer words' of the space allocated, and its size in 'double precision words' in the variables address and size. If this routine is difficult or impossible to implement on your machine (or the concept of a 'maxi- mum region size' is not well defined for you machine), then it can be deleted completely by making the following changes: 1. Increase the declaration of VALUE throughtout the program to a large value suitable for the largest problem you will run through SPICE - 100000 to 200000 is typical for our releases, but what you need will depend on your machine's capabilities and your needs. 2. Replace the statement maxmem=2*64 in the main program with maxmem=2*(whatever size you used for the array VALUE) 3. Replace the call to gtmain in the subroutine setmem replace the call to gtamin in the subroutine setmemt with the statement IFAMWA = LOCF(IPNTR(1)) 3. The actual codgen code must be deleted. This can be accomplich by removing all but the return and end statement in subroutine CODGEN, changing the assignment LVLCOD=2 to LVLCOD=1 in the subroutine READIN, and replacing code in iter8 as follows: old code: C C SOLVE EQUATIONS FOR NEXT ITERATION C 100 IF (ITERNO.GE.ITLIM) GO TO 200 IF (LVLCOD.EQ.3) GO TO 110 102 CALL DCDCMP IF (IGOOF.NE.0) GO TO 400 IF (LVLCOD.EQ.1) GO TO 105 CALL CODGEN CALL SIZMEM(MACINS,MACPTS) RSTATS(43)=MACPTS 105 CALL DCSOL GO TO 120 110 CALL SECOND(T1) CALL CODEXC(NODPLC(MACINS+1),VALUE(LVN)) CALL SECOND(T2) Volume 4 Number 1 Page 4 SPICE Rack Fall/Winter 1985 RSTATS(44)=RSTATS(44)+T2-T1 120 IF (IGOOF.EW.0) GO TO 130 new code: C C SOLVE EQUATION FOR NEXT ITERATION C 100 IF (ITERNO.GE.ITLIM) GO TO 200 102 CALL DCDCMP IF (IGOOF.NE.0) GO TO 400 105 CALL DCSOL 120 IF (IGOOF.EQ.0) GO TO 130 LETTERS TO THE EDITOR _____________________ Santander, 15th March 1985 Dr. Mr. Morris, I have received a letter from Berkeley University, in which it points you as a contact man of the SPICE user's group. Our Department has succeeded in adapting SPICE2.G1 version to a 16-bit machine Eclipse S/120 and S/230 Data General, and now this version is completely oper- ative. The CPU time is, of course, two orders of magnitude greater than the original version, (table attached), [table is printed on last page of the this newsletter. editor] but as our computer is like to a desk-top one we believe the work has been worth to have done it. We include a table of the CPU time of our version versus the original table from B.Cohen PhD Thesis. Please let us know your opinion about our efforts, and we would like to receive information about SPICE from the user's group. In Spain there are several versions running on 32 bit computers in VAX 11/780 in the Universities of Sevilla, Madrid (Politecnica) and Barcelona (Autonoma) and on a Data General Eclipse MV8000/10000 in the Universi- ty of Comillas in Madrid and in the University of Santander. We are all of them connected and we would like to maintain interchanges of information about new developments in SPICE user's group. Actually we have finished to adapt on a Data General MV10000, the ver- sion G6. Yours Sincerely, S. Bracho Volume 4 Number 1 Page 5 SPICE Rack Fall/Winter 1985 ] ] ] CPU ] Dcx (Trcurv) ] Tran (Tranan) ] Total Circuito ] CDC Eclipse ] CDC Eclipse ] Eclipse ---------------------------------------------------------------------- Difpair ] 2.13 342.07 ] 3.92 276.16 ] 16:03.11 Ktest ] 0 0 ] 1.52 183.85 ] 6:12.58 Rca 3040] 5.02 856.79 ] 10.74 789.05 ] 39:33.63 VA709 ] 9.00 1967.51 ] 15.02 1279.70 ] 1:20:09.95 VA741 ] 11.87 1983.33 ] 19.22 1558.55 ] 1:25:21.77 VA727 ] 9.12 2061.53 ] 22.68 2074.35 ] 1:43:28.80 VA733 ] 0 0 ] 0 0 ] 1:53.18 RTL INV ] 1.39 204.92 ] 3.28 315.81 ] 9:29.77 TTL INV ] 3.65 622.10 ] 12.94 1200.96 ] 32:14.57 TTL 74 ] 3.76 638.16 ] 11.70 1230.56 ] 32:51.92 TTL 74S ] 4.43 864.56 ] 14.26 1737.61 ] 45:46.93 TTL 74L ] 4.02 691.64 ] 13.91 1526.36 ] 38:46.88 TTL 9200] 5.03 812.51 ] 13.14 1401.84 ] 38:49.45 Eclgate ] 4.08 843.97 ] 13.44 1722.25 ] 44:55.30 Mecl III] 6.17 1162.09 ] 16.68 2090.89 ] 57:14.84 Sbdgate ] 7.04 1434.84 ] 21.36 2408.15 ] 1:09:15.73 Cesor ] 0 0 ] 0 0 ] 1:00.37 DcOSC ] 0 0 ] 0 0 ] 1:15.93 Cfflop ] 0 0 ] 0 0 ] 56.61 Stcrc ] 0 0 ] 0.90 49.87 ] 1:18.46 Choke ] 0 0 ] 2.10 125.64 ] 2:36.66 Eclinv ] 0 0 ] 5.80 520.93 ] 9:57.28 Schmitt ] 0 0 ] 6.28 713.85 ] 13:05.41 Astable ] 0 0 ] 9.36 152.57 ] 3:36.66 Satinv ] 6.05 464.52 ] 0 0 ] 9:02:52 Deplinv ] 1.87 141.88 ] 0 0 ] 2:53.10 Ratlog ] 0 0 ] 14.37 1480.34 ] 27:25.07 Bootinv ] 0 0 ] 14.68 490.84 ] 9:55.57 Mosmem ] 0 0 ] 18.76 795.09 ] 16:34.09 MOSamp1 ] 20.68 1935.46 ] 0 0 ] 43:22.13 MOSamp2 ] 0 0 ] 68.86 1931.33 ] 35:59.57 BUG REPORT ON SPICE 2G5 AND 2G6 _______________________________ Dear Sirs, Having been looking for a long time for more information about SPICE and its problems, I'm very glad to find your excellent SPICE-Racks. At the moment, unfortunately, I don't have enough experience to offer solution for the questions published, but I think that I've found a serious bug in the 2G5 and also 2G6 Version of SPICE. It seems to be a numerical problem during the calculation of the matrix and so I would like to know if someone has already fixed it and could share his or her experience with me. The original Versions 2G5 and 2G6 are suffering the problem. We got them from DEC and run them on a VAX with VMS. Just as additional Volume 4 Number 1 Page 6 SPICE Rack Fall/Winter 1985 information: a control simulation with 2G5 on a PRIME showed the same faulty results, while a simulation with SIEMENS SPICE on a SIEMENS computer was successful. According to figure 1, the circuit consists of two capacitors, on ini- tially loaded to 5V, the other one grounded, and a MOSFET for equaliz- ing the voltages. After switching the MOSFET on, the voltages are equalized down to a voltage difference V of about 1E-9 to 1E-12V. As soon as the gate voltage starts to fall, however, the voltage dif- ference rises until the ramp has ended. The remaining ranges between some tens and some hundreds of mV, and is absolutly intolerable for the simulation of a dynamic memory. The following ideas have failed to fix the problem: - dividing the transistor into two identical halves with Drain 1 con- nected to Source 2 and Source 1 connected to Drain 2 Thus any unsym- metric redistribution of charge that might occur is unreasonable. - slow ramp rates - smaller resistor - different tolerances in the OPTION You'll find the input and output on the following pages. [editors note only the input has been reprinted due to space limitations] I would like to join the SPICE Users Group. Are there any possibil- ities for a German to do so or to get direct access to the Conference Tree using our VAX 750? I am looking forward to your reply and would like to thank you in advance for your helpfulness. Yours faithfully Horst Gieser [editors note: see input listing next page] Volume 4 Number 1 Page 7 SPICE Rack Fall/Winter 1985 **** Input file **** ********************** * VBB 4 0 -2v VPEQ 3 0 PULSE(0 8V 2N 2N 5N 10N) M1 1 3 2 4 NMOS1 L=2.28U W=20U + AD=80P AS=80P * Modelle .MODEL NMOS1 NMOS LEVEL=3 VTO=1.22 + GAMMA=1.0 PHI=0.733 NSUB=2.066E16 + UO=702.573 THETA=0.067 VMAX=1.956E5 + ETA=0.321 DELTA=0.045 KAPPA=0.531 + XJ=0.30U TOX=41.7N CGSO=1.5E-10 + CGDO=1.5E-10 CGBO=1.3E-10 JS=1E-3 + CJ=4.18E-4 RD=50 RS=50 * Angangsbedingungen .IC V(1)=5 V(2)=0 * Aughaben .TRAN .5NS 22NS .PRINT TRAN V(1) V(2) V(3) V(1,2) .OPTION OPTS METHOD=GEAR MAXORD=2 .END ********************** Volume 4 Number 1 Page 8