Files:
revision1.net -> the netlist of the affected circuit
revision1.sch -> the (gschem) schematic of the affected circuit.
ngspice.revision1.log -> the terminal output of the ngspice session
Process:
1) load ngspice -> `ngspice revision1.net`
2) run transient analysis -> `tran 0.1m 10m`
3) program hangs; ^C does not interrupt analysis
4) trace syscalls -> `dtruss -f ngspice revision1.net > ngspice.revision1.log`
5) run transient analysis -> `tran 0.1m 10m`
6) ^C to kill dtruss/ngspice when ngspice hangs
At the end of the log file, there are 14 lines, all syscalls to gettimeofday(). These 14 lines were repeated many, many times. I removed the repeats for clarity. Other than that, the only modification I made was removing personal data from the log.
I understand that my circuit may be malformed, and that this may be the expected behavior, but it seems reasonable to expect ngspice to do something, including responding to ^C like a transient analysis normally does.
The technical reason for the perceived hang is probably that the max. output of comparator X3 (pin 9) is exactly the same as the max amplitude of the triangle generated by X2 (pin 4). I observe 'normal' operation by adding 1K from pin 9 to pin X (the inverting input of X4), and 100K to ground from this pin X.
(Note that with my NGSPICE the unmodified simulation file finishes without problems.)
Because my ngspice does not have the lT082 model, I had to search for it. The following works (maybe the problem is with your LT082 model).
*============== Begin SPICE netlist of main design ============
X3 2 VOUT Vcc 0 9 TL082
Rs 9 x 1k
Rp x 0 100k
X4 4 x Vcc 0 8 TL082
C2 0 VOUT 1u
X5 2 8 Vcc 0 7 TL082
* .INCLUDE mods/2N3904.mod
R5 VOUT Vcc 1k
R4 7 6 100k
Q1 VOUT 6 0 2N3904
.MODEL 2N3904 NPN (2N3904)
.INCLUDE TL082.sub
X2 2 5 Vcc 0 4 TL082
V1 Vcc 2 DC 6
C1 5 4 50n
R2 5 3 1k
R1 3 1 100k
R3 4 1 100k
V2 2 0 DC 6
X1 1 2 Vcc 0 3 TL082
.tran 1u 1m uic
.end
-- save TL082.sub
* TL082 operational amplifier "macromodel" subcircuit
* created using Parts release 4.01 on 08/08/91 at 13:08
* (REV N/A)
* connections: non-inverting input
* | inverting input
* | | positive power supply
* | | | negative power supply
* | | | | output
* | | | | |
.subckt TL082 1 2 3 4 5
*
c1 11 12 3.498E-12
c2 6 7 15.00E-12
dc 5 53 dx
de 54 5 dx
dlp 90 91 dx
dln 92 90 dx
dp 4 3 dx
egnd 99 0 poly(2) (3,0) (4,0) 0 .5 .5
fb 7 99 poly(5) vb vc ve vlp vln 0 4.715E6 -5E6 5E6 5E6 -5E6
ga 6 0 11 12 282.8E-6
gcm 0 6 10 99 8.942E-9
iss 3 10 dc 195.0E-6
hlim 90 0 vlim 1K
j1 11 2 10 jx
j2 12 1 10 jx
r2 6 9 100.0E3
rd1 4 11 3.536E3
rd2 4 12 3.536E3
ro1 8 5 150
ro2 7 99 150
rp 3 4 2.143E3
rss 10 99 1.026E6
vb 9 0 dc 0
vc 3 53 dc 2.200
ve 54 4 dc 2.200
vlim 7 8 dc 0
vlp 91 0 dc 25
vln 0 92 dc 25
.model dx D(Is=800.0E-18)
.model jx PJF(Is=15.00E-12 Beta=270.1E-6 Vto=-1)
.ends
-marcel
While running analyses on another circuit, I noticed the same hang, but much shorter. That on top of your comment makes it evident that the hang is not an infinite loop as I had thought. All the same, it would be nice to have some kind of status while this is happening.