Skip to content
Physics and Astronomy
Home Our Teaching Resources CDHW Electronics2 Userguide secD.html
Back to top

SPICE 3 User's Manual - Appendix D


APPENDIX D: SPICE3 BUGS AND PATCHES

This appendix is based, with his kind permission, on Ned Forrester's collection of bugs and patches to Spice 3f4. Please email me further contributions and corrections for inclusion.

Demonstration files

Credit: Berkeley and Paolo Nenzi

There is a useful collection of spice source files which demonstrate known bugs in Spice3f5. They are based on the contents of ftp://ic.eecs.berkeley.edu/pub/Spice3/qxdir.tar.z

The evolution of Spice from 3f4 to 3f5

Credit: Beorn Johnson

The last official version of Spice is 3f5 but for a while it was distributed under the name of 3f4. The last few patches (one of which is actually rather important for initial conditions to work right) were not done in the same way previous sets of patches were done. In particular, the version file (which is in an obscure location) wasn't updated. This causes lots of confusion, since you can't tell if you have an updated version of 3f4 or not -- so when you apply the patches, BE CAREFUL.

The patches from 3f4 to 3f5 are available and from Berkeley, but they move around a bit so there is a copy here [patches1.txt]. Each patch should be applied separately. To update the 'version' to 3f5, change the file 'util/skeleton/make_def.bd'; edit the line with "VERSION = 3f4".

Arbitrary Source state bug

Credit: Beorn Johnson, Eckhard Brass

2 bugs in the arbitrary source code are illustrated by


   ASRC bug test code
   vt 10 0 1
   b1 1 0 v = v(10)
   r1 1 0 1
   b2 2 0 v = 1
   r2 2 0 1
   b3 3 0 i = 1
   r3 3 0 1
   .control
   op
   print all
   show all
   .endc
   .end

Eckhard Brass noted:

  1. The parser works only correctly if you use at least one circuit node. v=2*3 does not work. A quick and dirty fix is to add v(0)=0, e.g. v=2*3+v(0) works!
  2. The 'show' command does not work correctly with ASRC devices, a patch [patches2.txt] which fixes this is available. However, the values that are then reported by show aren't reliable.

Beorn Johnson provided some fixes for the asrc code [patches3.txt]. However, even after these are applied, the branch currents reported by show are unreliable -- this has to do with the fact that the current (amps) output of a current source isn't a state variable.

Interpretation Plot Commands

Credit: CDHW

Bug: plot foo vs -bar is interpreted as plot foo (vs-bar) which is incorrect unless someone has unwisely defined a vector named vs.

Fix: Workround: plot foo vs (-bar)

Where command causes crashes

Credit: CDHW

Bug: where causes crashes if there is no unconverged node to report.

Fix: Provide appropriate tests in where.c [patches10.txt].

Recognition of scale factors in arbitrary source

Credit: Ned Forrester, Beorn Johnson, CDHW

Bug: Scale factors (e.g. m, k, meg, etc.) for constants in arbitrary sources (b devices) are not recognized.

Fix: Changes to inpgtok.c and inpptree.c, as supplied by Berkeley as patch for 3e2. [patches5.txt]

B.J. vaguely recalled that there was some problem/conflict with this patch, possibly occuring when you try to expand a subcircuit containing a nonlinear source that has scale factors in it.

CDHW: The root cause of several problems is the fact that the parser doesn't correctly interpret 'v(44bb)' which is the value of node 44bb, and '44bb*v(3)' which is either a syntax error or 44 times the value of node 3 depending on your philosophy. The patch5.txt version doesn't deal with v(foo,bar) correctly either. A more radical overhaul is needed to sort things out properly.

Current Controlled Switch in subckt, parsing error

Credit: Ned Forrester

Bug: Current controlled switch inside subcircuit does not expand the controlling source correctly: vsrc expands to name:vsrc, not to v:name:src.

Fix: Change src/lib/fte/subckt.c to indicate that w device has only 2 not 3 nodes and 1 not zero controlling sources. [patches4.txt]

Noise analysis bug

Credit: Richard McRoberts

Bug: The ac noise analysis in Spice3f4 has a serious bug. In interactive mode, it fails to reproduce frequency dependence known to exist. In batch (Spice2) mode, it works only if a corresponding ac analysis has been run first.

Fix: Providing a call to CKTload() in noisean.c as shown by the source code patch [patches6.txt].

Save segmentation faults

Credit: Richard McRoberts

To fix various "save"-related segmentation faults, make this one-line patch to outitf.c: line 356, change unique = devname; to unique = copy(devname);

Single point AC analysis crash

Credit: Richard McRoberts

A bug that most users probably wouldn't encounter occurs in an ac analysis using a linear sweep with only one point. (A rather pathological case.) The original code in acan.c uses a frequency increment of "HUGE" (infinity) which causes a crash when stepping to the second point. Fixed by making the increment zero, which is tested for in the sweep, causing it to terminate correctly after the first point.

AC analysis of LTRA device wrong for LC only model

Credit: CDHW

An AC analysis of the LTRA transmission returns incorrect results unless LEN=1.0 . E.g. the two stub models below should be the same


ltra model behavior 
v1 1 0 dc 0 ac 1 
r1 1 2 50 
*.model stub ltra c=0.6663p l=1.6672n len=1.5 
.model stub ltra c=0.995p l=2.501n len=1 
o3 2 0 4 0 stub 
.control 
ac lin 1000 1G 10G 
plot vdb(2) 
.endc 
.end 

Fix: Correct calculation of lambda_r in LTRAacld.c [patches11.txt]

BSIM1 model xpart parameter random

Credit: Al Davis

Bug: the BSIM1 model, the parameter "xpart" behaves randomly.

Fix: In the file "b1mpar.c" line 290, change "iValue" to "rValue".

BSIM3v3.1 model note

Credit: Peter Hunt

The bsim3 code available from Berkeley was written for spice 3e2. In the node setup code the BSIM3instance is cast as a GENinstance so the first part of both structures have to line up. This means the fourth member needs to be the "states". Apparently, the GENinstance changed between 3e2 and 3f4. [patches7.txt]

BSIM3v3.2 model TNOM parameter

Credit: Mike Smith

BSIM3v3.2 gives wrong results unless TNOM parameter is omitted. [patches8.txt]

Diode model breakdown behaviour

Credit: Various

When a breakdown region is specified for a diode by setting the IBV and BV parameters any value of emission coefficient othe than 1.0 (the default) leads to a characteristic that doesn't pass through I=-ibv when V=-bv.

MOSFET initialisation

Credit: Thomas Leitner (ECS 97 paper)

Most standard MOSFET models have a bbug in the initialisation code for the drain bulk junction. The initial current at t=0 during a transient run has a spike that gets smaller as the initial timestep is increased.

Tran analysis default TSTEP

Credit: CDHW

Bug: Spice 3 by default seems to set TMAX to TSTOP/50.0, instead of the smaller of either TSTEP or (TSTOP-TSTART)/50.0 as stated in the manual.

Fix: Specify TMAX explicitly. [patches9.txt]

MOS6 model note

Credit: Stephen Gilardi

This is some code from the Spice 3f5 source file mos6load.c:


                vdshere = vds * here->MOS6mode;

von=(here->MOS6tVbi*model->MOS6type)+model->MOS6gamma*sarg
                    - model->MOS6gamma1 * vbsvbd;
                    - model->MOS6sigma  * vdshere;

The value of expression is not used. It looks like there's an unintended extra semicolon after vbsvbd.

Macquarie University Patches

Credit: Anthony Parker

The Macquarie University Patches include:

  • level 0 patch: Applies the Berkeley 3f4 patches.
  • level 1 patch: Minor fixes for compiling on hpux, and fix to mos6 model.
  • level 1a patch: Rehash of the Macintosh port.
  • level 2 patch: Installs the spec command for detailed spectral analysis.
  • PSmodel patch: Patches for adding the PS JFET/MESFET model as a level=2 JFET.

MOS3 Bulk-Source Capacitance

Credit: Thomas Leitner (ECS 97 paper)

The bulk-source junction capacacitance has some nasty discontinuities due to an error in the thermal dependence calculation, illustrated by the following comparison with the MOS1 model.


Bulk-Source junction capacitance bug in MOS3 model
vd1 d1 0 sin 5 8 160k
vg1 g1 0 sin 0 3 100k
vs_level1 s1 0 sin 0 1 90k
vd3 d3 0 sin 5 8 160k
vg3 g3 0 sin 0 3 100k
vs_level3 s3 0 sin 0 1 90k
m1 d1 g1 s1 0 mmod1 temp=150
m3 d3 g3 s3 0 mmod3 temp=150
.model mmod1 nmos level=1 cbs=10n
+rs=10 rd=10 is=0 vto=20
.model mmod3 nmos level=3 cbs=10n
+rs=10 rd=10 is=0 vto=20
.tran .1u 15u
.plot tran i(vs_level3) i(vs_level1)
.end

Front-end command processor

Credit: CDHW

Bug: There are several problems with the code for this. e.g repeat loops only work once and breaks and continues are problematic.

Fix: Still work in progress, but I have a version of front.c that is much better than the original. It will be posted here after a bit more checking. The command processor is of limited use until the memory leaks that plague 3f5 are fixed.

Truncation error calculation

Credit: Steve Hamm

The trtol value is a fudge factor, originally introduced by Nagel as a estimate of how much the local truncation error is overestimated by the divided difference formulas. But, after looking at this in detail some years ago, it is just a bug. The formula for estimating derivatives by divided differences includes, for the third divided difference, 3!. Nagel dropped the 3! somewhere along the way; the factor of 7 is a fairly close replacement -- but only for second order integration, which uses the third divided difference.

Note that the spice code has a number of other problems:

  • the business of trying to use abstol to ensure that truncation error is no tighter than the nonlinear solution is buggy, and basically means that absol controls the timestep.
  • the gear code uses fixed-timestep truncation error coefficients
  • there are arithmetically better ways to estimate truncation error than using divided difference formulas; Brayton's method is good.

Back to trtol: After the above bugs are fixed, a fudge factor is still useful, but a value of 1.5 or 2.0 is more typical.

Interactive command: let

Credit: CDHW

Bug: The let command doesn't handle references to subranges reliably.

Fix: Various a couple of tweaks to com_let() in postcoms.c

Interactive command: set

Credit: CDHW

In the original 3f4/5 release, simulator variables specified with the set command are ignored by interactive simulations. This behaviour is because interactive commands have their own 'special' set of options that only exist while the the command is being executed and are distinct from the 'current' options for the circuit. 'Set' only affects the 'current' options because the 'special' ones don't exist at the time it is invoked and are created using the application defaults.

The original code also defines a 'default' set of options for a circuit which seem to serve no useful purpose. The cleanest fix would be to make 'set foo' change both the current and default values and to create new tasks using the circuit defaults, not the application defaults.

                                                                                                                                                                                                                                                                       

Validate   Link-check © Copyright & disclaimer Privacy & cookies Share
Back to top