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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user