Revision: 0.1

Date: Jan 17, 1998

Update: May 3, 1998, added screenshot NSPICEAC

Update: June 27, 1998, added archive for NSPICEAC (executable NT version)

Author: Marcel Hendrix

NSPICE is to SPICE what Forth is to C. That is, NSPICE is a personalized tool to explore a limited area of the circuit simulation field: off-line switched-mode power supply design for gas-discharge lamps. (If your interests lie elsewhere, read on).
The picture below shows the typical screen layout for NSPICEAC, a variant of NSPICE designed to draw schematics and calculate AC responses. The general NSPICE is designed for TRAN calculations, but its GUI is not ready yet.
*(Screenshot created with nspiceac.frt, iForth NT vsn 2.0)*

Power supply design for gas-discharge lamps is a notoriously difficult area because of the very wide range of time constants involved (mains: 20ms, rectifier-smoother: 200ms, switches 10us - 200ns, lamp 30ms - 10min).
The idea is that we can gain simulation speed by trading in generality for simplicity.
Speed is enormously important for the considered applications, as is uniform convergence.
A breakthrough is needed to enable Monte Carlo or DOE (Design Of Experiments) techniques to be applied in this area.

NSPICE doesn't use variable timesteps. The assumption (to be verified) is that these slow down switching circuits:

- there are so many corrections that the positive (speed) effect is lost
- the maximum stepsize is 1/Tswitch no matter how much cleverness is applied (actually, this is not true)

However, with fixed timesteps it is necessary to synchronize switch transitions with timesteps, to prevent excessive error as described in, e.g., "Behavior-Mode Simulation of Power Electronic Circuits", H. Jin, IEEE Transactions on Power Electronics, Vol 12, no 3, May 1997. There is a problem when the current through a switch reverses. This is a process that by definition can't be synchronized. It is obvious that in essence this is equivalent to the sampling problem in digital filters with feedback. The problem can be reduced by reducing the timestep, but smarter, i.e less costly, algorithms might be possible. Note that resonant circuits normally don't have this problem (all discontinuities in voltages and currents appear at the switching instants), but DC-DC converters with a discontinuous mode cycle-part do suffer (as do power-feedback circuits).

The most popular remedy found in literature is interpolating all state variables back to the point where a current zero-crossing appears and restart from that point in time. This effectively "pretends" that the next timestep appears at the zero-crossing exactly, and prevents accumulating non-linear error at the cost of a small discontinuity on the time-axis. I have implemented this in the current release of NSPICE, but the effect is (disappointingly) minor.

The use of switching functions transforms switched networks into a set of dependent sources (typically 2 sources per switch). The source control voltage is a function of the original switch gate turn-on/off signal. For the basic DC-DC converters the switching functions are trivial and could be made available as standard building blocks.

There are pros and cons to the switching-function concept.

Pro:

- Fast, doesn't compute the fast device level switch behavior that is mostly irrelevant for system design
- Prevents the famous problem that throwing one switch in a network generally leads to a barrage of possibly invalid intermediate states ("time must stop" while we iterate, saving and restoring states, to find the next valid state) (See: D. Bedrosian and J. Vlach, "Time-domain Analysis of Networks with Internally Controlled Switches", IEEE Trans. Circuits Syst. I, Vol 39, no 3. 1992, pp 199-212)
- The average model can be automatically derived from the switching-function description (Jin poses this as obvious)

- Switch current and voltage can get lost when the switching function is complex
- When overlap and dead-time is introduced the concept becomes difficult to use
- discontinuous mode needs a three-valued switching function

- Backward Euler, order 1, u[i+1] = u[i] + h*du/dt[i+1]
- Trapezoidal, order 2, u[i+1] = u[i] + h*(du/dt[i+1]+du/dt[i])/2
- BDF (Gear), order 2, u[i+1] = 4*u[i]/3 + u[i-1]/3 + 2h*du/dt[i+1]/3
- ACF (two-step A-contractive), order 2, u[i+1] = 4*u[i]/5 + u[i-1]/5 + 2h*(5*du/dt[i+1] + 2*du/dt[i] + 2*du/dt[i-1])/15

On the basis of this analysis Trapezoidal Integration should be the best choice (fastest). The disadvantage of the trapezium rule is that a DC-analysis is needed before the start of a transient analysis (both Vprev and Iprev of L's and C's must be known).

For a 100 kHz halfbridge on a 50 Hz mains, the tank equations are periodically solved 2,000 times per mains period (typically using 100 steps per HF-cycle). This is clearly excessive. Intuitively (sampling theorem) one would expect that a minimum of 100 full evaluations per second (2 per mains period) suffice. This is not realistic given the current SOA (1997). But even 100 evaluations per mains cycle will reduce computation time by a factor of 20.

The idea is to simulate the "fast part" accurately with a small step, over its Fast Cyclical Interval FCI (i.e. one HF switching period). For this FCI the average voltage and current applied to the "slow part" can be computed. The computation advances by

- assuming slow source values (these are DC input sources for the fast part)
- computing FCI with timestep Thf
- computing the slow sources (averaging over FCI at the ports to the slow part) and the new source values for the HF part
- computing the next Tlf step of the slow part
- continue at 1 (*skipping* Tlf seconds)

Note that the described method is related to state-space averaged modeling. However, we don't require the user to derive switch and converter models analytically, the simulator does this numerically, on-the-fly. Moreover, this technique doesn't require low ripple, a periodical steady state is all that is required. Also, contrary to SSA we get HF detail and LF response at the same time while current-mode control and discontinuous mode aren't problematic (when the proper switch models are being used).

16 Nov 1997: For the first try we disregarded the HF-PSS problem (assume high damping). First we solve the equations over the [given, required] FCI using Thf. The SLOW circuit parts are identified and the C, L values scaled down by RATE=Tlf/Thf. RATE is entered by the user, Tlf is an internal parameter. The main loop advances ntime by Tlf when ntime = k*Tlf+FCI. There's of course a (user interface) problem when plotting the results (plot the FCI-averaged values of the state variables when k*Tlf+FCI < ntime < (k+1)*Tlf)

The extensions listed above don't seem to matter much, for the practical circuits tried up to now.
The visual feedback from the simulator immediately points out wrongly assigned FCI or RATE constants, and the user can almost instantly correct this.
Specifically, I do not believe that having perfect state-event signalling/handling, or higher-order multistep integration (with non-constant state matrix) will bring much *for SMPS simulation* (simulating switched capacitor filters would be an entirely different kettle of fish).

NSPICE speed can be increased for special problems. I now keep Tlf constant, but could design some sort of "quality-controlled" Tlf stepper. The system matrix must be recomputed if Tlf changes, on the other hand the positive effect is high when analyzing, e.g., the impulse response of a SMPS. The VRES component implementation has already shown how to handle a "database" of system matrices, so this might be an easy job.

[pss] FAST( )FAST -- Pseudo Steady-State interval of fast process

[rate] SLOW( )SLOW -- # of PSSs the slow process skips

NEW-FCI -- helps with current-mode control, FM and such

(more) ... plotwindows

[Tbegin] [Tend] [Tstep] TRAN-PLOT-FAST

[Tbegin] [Tend] [Tstep] TRANSIENT-TABLE

REFRESH

REPAINT -- refresh display (needed when simulator is inactive)

<#ms> TO FRAMERATE

TRUE | FALSE TO ERASE?

TRUE | FALSE TO RMS?

WHEN ( "name" -- bool )

LABELS" fname"

SHOW1 CLIP1 PRINT1 ( CLIPnnn PRINTnn only available for Windows )

SHOW2 CLIP2 PRINT2 SHOW2x2 CLIP2x2 PRINT2x2

SHOW3 CLIP3 PRINT3 SHOW3x2 CLIP3x2 PRINT3x2

SHOW5 CLIP5 PRINT5 SHOW5x2 CLIP5x2 PRINT5x2 (>-versions of all these)

.INFO .REPORT .STATIC .SOLUTION .DUMPS" filename"

%TOL %TOLG %TOLG-LOW %TOLG-HIGH -- tolerances Monte-Carlo analysis

S" include fname" #cases #bins CASES -- perform Monte-Carlo run