SPICE3 version 3e2 19-Oct-91 DISTRIBUTION SPICE3 is in the public domain and may be freely redistributed as long as all references to the University of California remain intact. INTRODUCTION SPICE is a program for analog circuit simulation. SPICE3 is a version of SPICE for the Amiga. It is based on SPICE3e2 from the University of California at Berkeley and is written in C (see Fred Fish #177 and #278 for FORTRAN based versions of SPICE2). The executables are based on the MSDOS version UC Berkeley defined. This version, as opposed to the UNIX version, is broken down into a number of smaller programs to get around memory limitations. SYSTEM REQUIREMENTS Two system requirements that I know of exist. First, about 1 MB of RAM is required for smaller circuits. The amount of memory required will grow as the circuit size increases. Second, because of the size of the executables I would strongly recommend a hard disk. For generality (and because I don't have one), this version DOES NOT utilize the 68881 math coprocessor. In case I have forgetten something, my system consists of: Amiga 1000 (512 KB) 1 MB Insider memory expansion C-LTD SCSI controller Seagate ST251N 40 MB hard drive AmigaDos V1.3 (KS 34.5, WB 34.20, ARP 39.1) EXECUTABLES The following is a brief description of the executables included, note that more complete descriptions can be found in the 'man' directory and with the 'help' utility. bspice - batch SPICE, raw file output for nutmeg cspice - batch SPICE, ascii output like SPICE2 help - interactive help makeidx - creates index files for help utility nutmeg - interactive printing/plotting program sconvert - converts between raw file formats The bspice and cspice programs support the following SPICE3e2 devices asrc, bjt, cap, cccs, ccvs, dio, ind, isrc, jfet, mos1, mos2, res, sw, vccs, vcvs, vsrc and the following analyses op, dc, tf, ac, tran, pz The default raw file type has been set to binary. Although this file type is less transportable, it is much faster and produces much smaller files. If you need to tranfer raw files to other systems, you should be able to use the program sconvert to convert the file to ASCII. EXAMPLES There are several example SPICE netlists in spice3/ckt and SPICE models in spice3/models. An example of using SPICE3 follows, my comments follow that semi-colon and should not be typed: > execute spice3/setup ;assign SPICE3: and set path > cd spice3/ckt/rcfilt ;change to directory containing netlist > bspice nutmeg ;run nutmeg (reads rawspice.raw) nutmeg> display ;display analysis variables nutmeg> print v(2) ;print voltage at node 2 (complex) nutmeg> plot vdb(2) xlog ;plot magnitude of voltage at node 2 nutmeg> quit DIFFERENCES FROM SPICE2 The main advantage of SPICE3 over SPICE2 is the backend analysis provided by nutmeg. This backend analysis is interactive and handles equations containing node variables and allow graphical plots. Also, SPICE3 is reported to have better convergence properties than SPICE2. For the most part, SPICE3 will handle SPICE2 netlists without modifications. The only difference I have seen is with the format for non-linear voltage and current sources. These sources typically appear in opamp models. The conversion is straightforward, see spice3/models/tl082ti.mod for an example of the new format. LIMITATIONS AND BUGS The following are limitiations and bugs that I know of: 1) The pathname SPICE3:spice3/bin and SPICE3:spice3/lib are hardcoded into the executables. Features such as the online help and reading macro definitions require that these paths exist. 2) SPICE3 has some Unix (or MSDOS) features that involved the directories "." and "..". These features do not have equivalents in AmigaDos. Utilities such as UnixDirs on FF #321 might (?) provide a workaround for any missing features. 3) Resizing a nutmeg shell window once nutmeg is running can corrupt some of the plotting attributes. Upon startup, the graphics initialization routines determine the size of the window. There is no easy means within the SPICE3 graphics drivers to detect when the window is resized. 4) The graphics routines leave about one row of pixel residue in the upper right hand corner of the window. I believe that this is due to an "off-by-one" bug in the placement of the text but I have not changed it for fear of mis-aligning other text. 5) Warnings are generated because resource information such as elapsed time is not available. This is due to the lack of BSD or SYSV time and usage functions on the Amiga. Other than the warnings, there doesn't appear to be any negative side affects. 6) The JFET parameters KF and AF are documented but don't seem to be supported. 7) Some of the SPICE2 .OPTIONS parameters (ACCT, LIST, ...) seem to be supported but are not documented. Be careful of the OPTS option which appears to bring a visit from the GURU. COMPILER The executables were created with the MANX 5.0b compiler and linker. Suprisingly few problems were encountered, probably due to the high quality of the MANX compiler and the adherence of SPICE3 to standard (K&R) C. The two minor issues were that MANX libraries are limited to 262K and several "expression too complex" error messages were encountered. Both of these were solved by rearranging the code. REFERENCES Steven C. Hageman, "Spice techniques facilitate analysis of feedback circuits", EDN, pp. 173-182, Sep. 29, 1988. Graeme R. Boyle, et. al. "Macromodeling of Integrated Circuit Operational Amplifiers", IEEE Journal of Solid-State Circuits, Vol. SC-9, No. 6, pp. 353-364, Dec. 1974. Ian E. Getreu, Andreas D. Hadiwidjaja, Johan M. Brinch, "An Integrated-Circuit Comparator Macromodel", IEEE Journal of Solid-State Circuits, Vol. SC-11, No. 6, pp. 826-833, Dec. 1976. Ed Oxner, "Parameter extraction and estimation produce accurate JFET models", EDN, pp. 137-144, Aug. 19, 1991. Dr. Vicent G. Bello, "Electrical models of mechanical units widen simulator's scope", EDN, pp. 139-144, Mar. 28, 1991. Dr. Vicent G. Bello, "Servo analysis gets a boost from parametric models", EDN, pp. 123-134, Apr. 11, 1991. OTHER Although I greatly appreciate source code being supplied with public domain software (for instructional purposes and to allow bug fixes and enhancements), I have not included the source code here. The primary reason is the amount of information. The source alone consumes about 5.8MB on my hard disk and three floppy disks when compacted using LHARC. Additionally, 12.8MB is consumed when the object files and library files are created and it took over 7.5 CPU hours to compile everything once I got a lot of little problems figured out. If you strongly desire the source code you can write me at the address below. I would appreciate three disks and the necessary postage. Also, you can contact me to report bugs, but there is no guarantee that I will have the time to fix them. Brett Larson 10500 Xylon Rd Bloomington, MN 55438 (612) 942-7696