Previous Thread
Next Thread
Print Thread
Page 6 of 7 1 2 3 4 5 6 7
Joined: Jun 2003
Posts: 58
C
Member
OP Offline
Member
C
Joined: Jun 2003
Posts: 58
So, there's one problem here. Unfortunately, it's a big one, not just with 280-ZZZAP but with op-amps in general in the netlist system.

With the zener noise now being strong enough to saturate the op-amp, what should be happening is that the op-amp's output would be "rail-to-rail": its voltage should be swinging abruptly from values near the power supply voltage to values near the ground voltage, with little time spent in between. This is because the op-amp is amplifying the input noise with practically its full open-loop gain, a factor of several thousand times.

The problem is that in the netlist emulation, the output frequently swings far *beyond* rail-to-rail, producing voltages spikes up to hundreds of volts in magnitude, which is blatantly unphysical. It does this despite the fact that the op-amp model includes specifications which are supposed to limit how closely the output voltage can approach either power rail (power and ground, in this case). These specifications simply aren't working effectively.

The resulting extreme voltages propagate through the rest of the circuit, causing objectionable noise and probably convergence problems as well.

Looking at the details of the op-amp model, it seems that voltage limiting is implemented with a pair of internal diodes associated with the upper and lower power rails, using a model borrowed from the Output Voltage Limiting page in the discussion of op-amps at eCircuit Center. These diodes should divert voltages in excess of the output limits. The trouble with using this model here is that it assumes the gain module G1 (a voltage-controlled current source) can only produce up to a certain maximum amount of current, when one of the amplifier's input transistors is fully on and the other is fully off. The limiting diodes can then be appropriately sized to pass that current in the worst case. But in the netlist implementation, there is no mechanism to limit the gain module's current in that way. The diode can simply be overwhelmed, and the output voltage will not be limited at all.

I noticed the netlist library includes an "LVCCS" (limited voltage-controlled current source), which would seem to be what is required, but this is not presently used by anything. Just as a test, I hacked the op-amp model to use the LVCCS for G1, and set its CURLIM parameter to a low value to see what would happen. The op-amp did limit its voltage better (there were still spikes in the output, but much shorter ones). Unfortunately, performance also went into the toilet, the speed dropping by a factor of 4 or 5. frown

So we still need to come up with a more reasonable means of effectively limiting op-amp output voltage.

Joined: Sep 2004
Posts: 388
A
Senior Member
Offline
Senior Member
A
Joined: Sep 2004
Posts: 388
As a quick hack have you tried using an AFUNC to hard-limit to the output?

AFUNC(LIMITER, 1, "max(min(A0, <rail_voltage>), 0)")
NET_C(LIMITER.A0, <opamp_output>)
NET_C(LIMITER.Q, <downstream_connections>)

It may not work (as I discovered) if there is feedback between multiple AFUNCs, as they will eventually force a super-small timestep, but for one-off cases it could be something to experiment with.

Joined: Jun 2003
Posts: 58
C
Member
OP Offline
Member
C
Joined: Jun 2003
Posts: 58
I tried your suggestion, Aaron, and it does work for clamping the output to following stages. cleaning up the glitchy sounds. So that is a potential workaround for now. Thanks for the tip.

In the long term, something more thorough is necessary, both because the out-of-range voltages will still feed back to the op-amp inputs and thus affect the op-amp circuit's own behavior, and because it is wasteful to include components like the voltage-limiting diodes within the op-amp model if they don't actually perform the function they're supposed to.

Last edited by Colin Howell; 07/16/20 06:52 AM. Reason: More thought-out response.
Joined: Feb 2007
Posts: 507
C
Senior Member
Offline
Senior Member
C
Joined: Feb 2007
Posts: 507
Originally Posted by Colin Howell
The problem is that in the netlist emulation, the output frequently swings far *beyond* rail-to-rail, producing voltages spikes up to hundreds of volts in magnitude, which is blatantly unphysical. It does this despite the fact that the op-amp model includes specifications which are supposed to limit how closely the output voltage can approach either power rail (power and ground, in this case). These specifications simply aren't working effectively.

The resulting extreme voltages propagate through the rest of the circuit, causing objectionable noise and probably convergence problems as well.


Without an example to test I can only give limited feedback. If you are observing spikes this is most likely due to the fact that your timestep is too big and the solver can't find a solution. The opamp type 3 model has clamping diodes and works in a all netlists I know. Aaron's tip may work but putting an AFUNC into an opamp feedback loop may have nasty side-effects and can cause ringing.

Please post an example here and I will have a look.

Joined: Jun 2003
Posts: 58
C
Member
OP Offline
Member
C
Joined: Jun 2003
Posts: 58
OK, here's an example to look at. This netlist is for the noise generator for 280-ZZZAP, broken out to stand on its own. H4_2.OUT is the generator's output and is the notable terminal to log. I've included a comment showing how the range of spikes in opamp output declines with decreasing minimum timestep. To get the output range to remain reliably within (or nearly within) the opamp's actual output voltage range requires pushing the minimum timestep down to 10 ns, in the neighborhood of 100 MHz, even though the opamp is specified with a unity-gain frequency of only 2.5 MHz and a slew rate of 1 V/us.

I admit this is a difficult case to deal with. The opamp is deliberately configured to apply practically its full open-loop gain to the AC component of the input signal, producing a near-digital output that randomly flips between 4.5 V and 0 V.

Incidentally, when I run this with netlist, say for an emulated 10 seconds to look at the opamp noise waveform, I do get one or more NEWTON_LOOPS warnings, regardless of the timestep setting. But all of these warnings happens near the very beginning, while the noise generator is still filling its capacitors and is not yet able to generate substantial noise. I'm not getting any NEWTON_LOOPS warnings during the noise-generating part of the run, again regardless of timestep setting. So the warnings seem to have no relationship to the output voltage spikes.

(It would be helpful if such NEWTON_LOOPS warnings included an emulated-time timestamp; I had to deduce the time of the warning through repeated runs with different running times.)

Code
#include "netlist/devices/net_lib.h"

static NETLIST_START(test)

	SOLVER(Solver, 48000)
	PARAM(Solver.DYNAMIC_TS, 1)
	// Minimum dynamic timestep vs. voltage range of opamp output spikes:
	// 20833 ns (static at 48 kHz):	-600 V to +520 V
	// 10000 ns:			-350 V to +280 V
	// 1000 ns:			-30 V to +31 V
	// 100 ns:			-6 V to +9.5 V
	// 50 ns:			-2.5 V to +7.9 V
	// 20 ns:			-1 V to +5.3 V
	// 10 ns:			-0.06 V to +4.66 V
	PARAM(Solver.DYNAMIC_MIN_TIMESTEP, 1e-8)

	ANALOG_INPUT(I_V5, 5)
	ANALOG_INPUT(I_V12, 12)

	// Simple model of a 1N5239 9.1-volt Zener diode; according to
	// datasheets, this diode conducts 20 mA of current at 9.1 V reverse
	// bias.
	ZDIODE(ZD_1N5239, "D(BV=9.1 IBV=0.020 NBV=1)")

	// 24 kHz noise clock for the noise source, chosen to retain noise
	// frequencies as high as possible for 48 kHz sample rate.
	CLOCK(NCLK, 24000)
	NET_C(I_V5.Q, NCLK.VCC)
	NET_C(GND, NCLK.GND)

	// Based on the zener's current of around 25 microamps, its noise will
	// likely be in the range of tens of millivolts, as it needs to be for
	// the noise generation to work as intended.
	SYS_NOISE_MT_N(NOISE, 0.01)

	NET_C(NCLK.Q, NOISE.I)

	RES(RNOISE0, RES_K(100))
	CAP(CNOISE0, CAP_U(10))
	NET_C(CNOISE0.2, GND)

	NET_C(I_V12.Q, RNOISE0.1)
	NET_C(RNOISE0.2, CNOISE0.1, ZD_1N5239.K)

	LM3900(H4_2)

	RES(RNOISE1, RES_K(56))
	RES(RNOISE2, RES_K(47))
	RES(RNOISE3, RES_K(1))

	CAP(CNOISE, CAP_U(10))

	NET_C(CNOISE.1, RNOISE1.1, RNOISE2.1)
	NET_C(CNOISE.2, GND)
	NET_C(H4_2.MINUS, RNOISE1.2)
	NET_C(ZD_1N5239.A, NOISE.1)
	NET_C(H4_2.PLUS, NOISE.2)
	NET_C(H4_2.OUT, RNOISE2.2, RNOISE3.1)
	NET_C(RNOISE3.2, GND)

	NET_C(I_V5.Q, H4_2.VCC)
	NET_C(GND, H4_2.GND)

NETLIST_END()

Joined: Feb 2007
Posts: 507
C
Senior Member
Offline
Senior Member
C
Joined: Feb 2007
Posts: 507
10 mV noise seems extremely high. The following post has some measured values and also literature hints: https://groupdiy.com/index.php?topic=52037.msg662729#msg662729

Noise is in the 100nV range for zener diodes. This would also explain why there is a second amplifier stage. If I use 100nV the netlist behaves nicely.

Coming to the spikes again: If an opamp is used like in the netlist you provided every SPICE simulator out there will adjust it's timestep down to 10ns or even below to find a solution. LTSpice forums contain a lot of examples.

The "overshoot" and the clamping diodes only doing their work partially is most likely due to the fact that the relative criterion for convergence (RELTOL, default 1e-3) is met although in fact a stable state is not yet reached -> false positive. Reducing RELTOL to 1e-4 increases the necessary solver loops significantly and the limit of 300 is reached on nearly every step. We are reaching the borders of numerical stability. Netlist support long double and float128 types as well for academic applications. Performance vanishes.
All of this is an issue in all SPICE like applications I am aware of.



Last edited by couriersud; 07/18/20 10:19 AM.
Joined: Feb 2007
Posts: 507
C
Senior Member
Offline
Senior Member
C
Joined: Feb 2007
Posts: 507
Originally Posted by Colin Howell
(It would be helpful if such NEWTON_LOOPS warnings included an emulated-time timestamp; I had to deduce the time of the warning through repeated runs with different running times.)


Thanks for the proposal. Implemented.

Joined: Feb 2007
Posts: 507
C
Senior Member
Offline
Senior Member
C
Joined: Feb 2007
Posts: 507
Digging more into zener noise I need to correct my post above. The measurements in the are 100nV/sqrt(Hz) values, thus most likely from a spectrum analyzer. These need to be integrated over the frequency.

https://scholarsmine.mst.edu/cgi/viewcontent.cgi?article=4491&context=masters_theses

contains some real measurements for a 9V zener diode which is at 4mA current about 400uV noise: Using

  • the formula E^2 = 5e-20 * V^4 / I from "Low noise electronic design" which implies a 1 / sqrt(I) dependency of the noise amplitude
  • the measurements from the link above and a simple regression 1 / sqrt(I) ~ Vpp
  • 30uA reverse current through the diode ( (12-9) / 100k)


the noise amplitude results at about 5mV, thus in the order you calculated.

Which brings us back to the limits of solving multivariate differential equations in time. The UGF of 2.5M in LM3900 model 4 basically causes overshoots if the timestep is too small. My experiments showed that reducing the UGF to 10k due to the fact that the following stage is a low pass filter has no real implications on the result.
In this case you can increase the minimum timestep to 1e-6

But performance is still poor. I'd rather HLE this with a noise source followed by a AFUNC which compares the noise source output against a fixed value.

Code

#include "netlist/devices/net_lib.h"

static NETLIST_START(test)

	SOLVER(Solver, 48000)
	PARAM(Solver.DYNAMIC_TS, 1)
	// Minimum dynamic timestep vs. voltage range of opamp output spikes:
	// 20833 ns (static at 48 kHz):	-600 V to +520 V
	// 10000 ns:			-350 V to +280 V
	// 1000 ns:			-30 V to +31 V
	// 100 ns:			-6 V to +9.5 V
	// 50 ns:			-2.5 V to +7.9 V
	// 20 ns:			-1 V to +5.3 V
	// 10 ns:			-0.06 V to +4.66 V
	PARAM(Solver.DYNAMIC_MIN_TIMESTEP, 1e-6)

	ANALOG_INPUT(I_V5, 5)
	ANALOG_INPUT(I_V12, 12)

	// Simple model of a 1N5239 9.1-volt Zener diode; according to
	// datasheets, this diode conducts 20 mA of current at 9.1 V reverse
	// bias.
	ZDIODE(ZD_1N5239, "D(BV=9.1 IBV=0.020 NBV=1)")

	// 24 kHz noise clock for the noise source, chosen to retain noise
	// frequencies as high as possible for 48 kHz sample rate.
	CLOCK(NCLK, 24000)
	NET_C(I_V5.Q, NCLK.VCC)
	NET_C(GND, NCLK.GND)

	// Based on the zener's current of around 25 microamps, its noise will
	// likely be in the range of tens of millivolts, as it needs to be for
	// the noise generation to work as intended.
	SYS_NOISE_MT_N(NOISE, 5e-3)

	NET_C(NCLK.Q, NOISE.I)

	RES(RNOISE0, RES_K(100))
	CAP(CNOISE0, CAP_U(10))
	NET_C(CNOISE0.2, GND)

	NET_C(I_V12.Q, RNOISE0.1)
	NET_C(RNOISE0.2, CNOISE0.1, ZD_1N5239.K)

	LM3900(H4_2)
	PARAM(H4_2.A.MODEL, "OPAMP(TYPE=3 VLH=0.5 VLL=0.03 FPF=2k UGF=10000 SLEW=1M RI=10M RO=100 DAB=0.0015)")

	RES(RNOISE1, RES_K(56))
	RES(RNOISE2, RES_K(47))
	RES(RNOISE3, RES_K(1))

	CAP(CNOISE, CAP_U(10))

	NET_C(CNOISE.1, RNOISE1.1, RNOISE2.1)
	NET_C(CNOISE.2, GND)
	NET_C(H4_2.MINUS, RNOISE1.2)
	NET_C(ZD_1N5239.A, NOISE.1)
	NET_C(H4_2.PLUS, NOISE.2)
	NET_C(H4_2.OUT, RNOISE2.2, RNOISE3.1)
	NET_C(RNOISE3.2, GND)

	NET_C(I_V5.Q, H4_2.VCC)
	NET_C(GND, H4_2.GND)

	// Next stage
	
	LM3900(H4_1)
	CAP(C1, CAP_N(6.8))
	CAP(C2, CAP_P(220))
	CAP(C3, CAP_U(10))
	RES(R1, RES_K(10))
	RES(R2, RES_K(270))
	RES(R3, RES_K(820))
	RES(R4, RES_K(330))
	
	NET_C(GND, C1.2, H4_1.GND)
	NET_C(I_V5.Q, R3.1, H4_1.VCC)
	
	NET_C(H4_2.OUT, C3.1)
	NET_C(C3.2, R4.1)
	NET_C(R4.2, C1.1, R1.1, R2.2)
	NET_C(H4_1.OUT, R2.1, C2.1)
	NET_C(C2.2, R1.2, H4_1.MINUS)
	NET_C(R3.2, H4_1.PLUS)

NETLIST_END()

Joined: Jun 2003
Posts: 58
C
Member
OP Offline
Member
C
Joined: Jun 2003
Posts: 58
Originally Posted by couriersud
Digging more into zener noise I need to correct my post above.

You wrote this while I was writing a rebuttal to the zener noise claim in that post, so I've altered my remarks to reply here. The timestep issues can be discussed separately.

Originally Posted by couriersud
The measurements in the are 100nV/sqrt(Hz) values, thus most likely from a spectrum analyzer. These need to be integrated over the frequency.

Also those measurements are for lower-voltage zeners, which have a different mechanism of noise generation that is less intense, and they are at higher levels of current. The noise we are talking about tends to decrease with current.

Originally Posted by couriersud
https://scholarsmine.mst.edu/cgi/viewcontent.cgi?article=4491&context=masters_theses

contains some real measurements for a 9V zener diode which is at 4mA current about 400uV noise: Using

  • the formula E^2 = 5e-20 * V^4 / I from "Low noise electronic design" which implies a 1 / sqrt(I) dependency of the noise amplitude
  • the measurements from the link above and a simple regression 1 / sqrt(I) ~ Vpp
  • 30uA reverse current through the diode ( (12-9) / 100k)


the noise amplitude results at about 5mV, thus in the order you calculated.

I appreciate the confirmation. Interesting way to derive a figure. I don't have Low-Noise Electronic Design, so I never found this formula. I remember coming across the paper you linked to, but I never gave it a good look, for reasons I don't recall—maybe by that point I had already found enough other sources and was getting tired of my never-ending, marginally productive studies of zener noise.

There are two different breakdown mechanisms found in zener diodes: the Zener effect for which they are named, and avalanche breakdown. For zeners with voltages of 5.6 V and below, the Zener effect dominates. Above that voltage, the avalanche effect becomes increasingly important, and by the time you reach 9.1 V, it dominates. Such "zeners" are really avalanche diodes and are much noisier than their lower-voltage cousins, especially when run at low currents. The amount of noise they generate increases as their current drops, up to a point, below which the noise drops with further reductions in current.

It's hard to find really good descriptions of this behavior, though this technical note from Vishay Semiconductors gives a decent intro and a nice plot of a typical avalanche diode waveform at microsecond timescales. One of the most informative discussions I found was in a 1997 thread in the USENET newsgroup sci.electronics.design, in postings titled "ZENER DIODE OSCILLATION", discussing the results of several participants' oscilloscope observations of zeners at low currents. (One of the participants was Winfield Hill, one of the two co-authors of The Art of Electronics, which gave the discussion a bit more authority.) Although the entire thread is quite long, with occasional derailings, it is nevertheless worth going over if you're interested in this subject. Here are some of the most informative postings of observations: here, here, here, here, here, here, here. This posting gives references to academic publications from the 1950s and 1960s which studied the dynamics of avalanche breakdown in detail.

I've found a few other more recent discussions of the subject by people who are interested in zener noise generation as a potential source of random bits for cryptography, but those tend to be more interested in the randomness of the noise than its magnitude. Wishlist: a detailed study on the use and performance of zener diodes for generating audio electronic noise, as in arcade machines, analog synthesizers, etc.

Joined: Jun 2003
Posts: 58
C
Member
OP Offline
Member
C
Joined: Jun 2003
Posts: 58
Originally Posted by couriersud
I'd rather HLE this with a noise source followed by a AFUNC which compares the noise source output against a fixed value.

That ... makes a lot of sense. Thanks for the suggestion—I'll definitely try it!

Page 6 of 7 1 2 3 4 5 6 7

Link Copied to Clipboard
Who's Online Now
5 members (Pernod, Olivier Galibert, Golden Child, AJR, pmackinlay), 31 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,836
Posts116,222
Members4,921
Most Online890
Jan 17th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.5