Re: gEDA-user: zener diode modeling

[al davis <ad252@xxxxxxxxxxxxxxxx>]

On Monday 18 April 2011, yamazakir2 wrote:
> Does anybody have a nice and simple zener diode model they
> would like to share? The model that I am using has trouble
> with convergence in context of a complicated switching
> circuit with ngspice.

have you tried gnucap?

You will need the spice-diode plugin to get the reverse 
breakdown, or use the parallel combo that Andy suggested, 
because the "native" model doesn't do breakdown.  Several 
plugins do.

The two-diode and battery approach has an advantage that the 
iteration limiting is better behaved that way.  The spice 
junction limiting doesn't work correctly for the breakdown 
region.  The code isn't there.

I don't expect the "B" device approach to help much if any.  
Usually its convergence characteristics are worse than the "C" 
models.

The reason I expect gnucap might work better here is the time 
step control algorithm, which gives much tighter control than 
the algorithm used in Spice.

In a later post, you said that the convergence failures are 
occuring during the transient analysis.  It runs for a while 
then screws up.

Spice time step control is based on three things ..
1. Truncation error in numerical differentiation, storage 
elements only.
2. Iteration count.
3. Pre-determined "break-points", but only in a few places.

The problems:

1. Non-storage devices do not participate in step control, at 
all.  In the simple case, it might not seem like a problem, you 
just get a plot that is rough to look at, and manually reduce 
the step size.  In a complex case, the undersampled waveform 
provides a very wrong input to the storage devices, causing 
incorrect results.  The familiar aliasing you get from sampling 
is one example of this.

2. No handling of analog events.

3. Using iteration count as step control involves many 
failure/recovery cycles.  The failures are not completely 
forgotten, so numeric problems can drive it to neverland.

Gnucap uses these methods as part of the algorithm, and where 
used they work the same, but also has more.  

1. Non-storage devices also participate in step control, based 
on curve fitting.  Step size is chosen such that common 
interpolation will produce a curve, where the whole curve is 
within an error bound.  (Spectre method)

2. Some devices generate analog events, for example on a region 
change.  At an analog event, the time of crossing is error 
controlled.  Unfortunately not all devices do this, but you can 
add switches (S device) to specify places in the circuit where 
you need this extra control.

3. Behavioral devices, including spice-style sources (Sin, sffm, 
etc) generate analog events sufficient that they can be modeled 
correctly, including phase.

Most of the time, you can skip specifying a time step entirely, 
and it will automatically step appropriately.

In this case, if I understand correctly, you have a circuit that 
has some abrupt changes that occur at certain times, but before 
and after that time activitity is slow.

With Spice time stepping, the steps will be large before the 
abrupt change, skipping over it.  In some cases, it seems to 
work and you get believable wrong answers.  In other cases, it 
results in a convergence failure, triggering a step rejection, 
and a retry with smaller time steps.

The Gnucap algorithm helps in several ways ..

First, since all components participate in time step control, it 
is likely that a shape change in the waveform will cause a 
reduction in step size, even if there are no storage devices.  
Often this is enough.

In the future, the semiconductor devices will generate analog 
events on region crossings, but they don't yet.

For now, you can do this explicitly by adding a switch to the 
circuit.  Recall .. the voltage controlled switch has an input 
port, where crossing a threshold causes a resistance change on 
the output port.  The trick here is to just use it to detect the 
crossing.  Ground both output terminals, and connect the input 
across the critical spot, for example across your zener.  Set 
the threshold (in the switch's .model statement) at the critical 
voltage.  It Spice, this won't do anything.  In Gnucap, if you 
use the Spice switch, it will work just like it does in Spice.  
You need to use the Gnucap native switch model.  What it does is 
to force accurate time stepping around the crossing.  There will 
be extra time steps just before and after the crossing, so as to 
provide additional accuracy in the region of the crossing.  The 
additional steps are such that the accuracy of the time of 
crossing is error controlled to the specified tolerances.

How it helps in this case, is that rather than going past the 
critical spot, then going into a recovery cycle, step size is 
reduced leading up to the crossing, so it doesn't go by, and 
doesn't need to fall back to the recovery cycle, hopefully 
solving the convergence problem.

It's not perfect, there is still work to do, but I believe that 
as it is, it provides a significant improvement over the 
traditional algorithm.  I have (in the test suite) several test 
cases that show improvement over the standard algorithm.  I have 
used it to model oscillators.  I have seen cases where spice 
failed to converge, but gnucap simulated it accurately enough to 
measure distortion of a supposedly sine wave oscillator.  I have 
another case, using a switch to make a relaxation oscillator, 
where Gnucap models it accurately, (waveform and frequency are 
correct) but NGspice and LTspice both give identical incorrect 
results (strange waveform, incorrect frequency).  If you just 
look at the output quickly, you may not notice that it is wrong, 
but looking at internal nodes and expanding the waveform around 
critical points, it becomes clear that it is wrong.

Another factor, loosely related, is that it is possible that 
"trapezoidal ringing" is sending it into a condition where you 
get nonsense results.  If this case, you may be able to get 
better results by specifying Gear or Euler differentiation.  
This applies to both gnucap and spice, but the step control in 
gnucap makes it less likely that gnucap will have a problem with 
it.  

"Less likely" does not mean "guaranteed".  When dealing with 
iterative solution and dynamic step control, nothing is 
guaranteed to work, and changes that help sometimes will hurt 
other times.  This is one reason that having two simulators that 
really are different is a lot better than either one alone.



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user