MBALAMUT@USC-ECL.ARPA (12/20/85)
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) ] Totalinfo-vlsi@ucbvax.UUCP (01/02/86)
In article <[USC-ECL.ARPA]20-Dec-85.12:37:40.MBALAMUT> you write: > > > 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. > If you are not the correct person to answer these questions, could you forward this request to the appropriate place. Thanks. ---------- I am interested in the conversion effort from SPICE2 to SPICE3 (I am not familiar at all with the SPICE program). How large is SPICE2 ? lines of Fortran, number of subroutines ... ? How large is SPICE3 ? lines of "C", number of subroutines ... ? How long did the conversion take? how many people? total number of fulltime person months? ---------- Steve Schlesinger {ihnp4, sdcsvax}!ncr-sd!steves