Consider the dc sweep specification
.dc vxxx 0 1.1 0.2WRspice will evaluate at 0.0, 0.2, ... 1.0. If dcoddstep is given, evaluation will also be performed at the end-of-range value 1.1. This is the default for some other simulators, so dcoddstep provides compatibility.
When this option is set, WRspice will use extended precision arithmetic when setting up and solving the circuit equations. With Intel, this mode uses the 80-bit native floating point format for all calculations, rather than the 64-bit ``double precision''. This requires that floating point numbers use 16 bytes rather than 8, however matrix space is allocated assuming complex numbers, which are 16 bytes. Thus, this mode has no memory-use penalty, and may actually cause some circuits to simulate faster.
The mode applies to both KLU and Sparse matrix solvers. It adds about three decimal digits of precision to the calculations. Using extended precision may avoid ``singular matrix'' and other convergence problems with some circuits. See and run the ``precision.cir'' file in the examples for more information.
When set, this will enforce a minimum gmin conductance to ground on all nodes in the circuit (including internal nodes of devices). This may facilitate convergence.
When this boolean option variable is set, during operating point analysis, gmin stepping is attempted before source stepping. This is the default in Berkeley SPICE, however the WRspice default is to apply source stepping first, which seems more effective.
When set, many of the HSPICE parameters and keywords that are not handled are silently ignored. Ordinarily, these produce a warning message. In particular, when set:
This applies only when Josephson junctions are present in the circuit, and performing transient analysis. It causes a faster convergence testing and iteration control algorithm to be used, rather than the standard more comprehensive algorithm suitable for all devices. If the circuit consists of Josephson junctions, passive elements, and sources only, then setting this option may provide a reduction in simulation time. It probably should not be used if semiconductor devices are present.
During transient analysis, at each new time step, Newton iterations are used to solve the nonlinear circuit equations. The first iteration, the prediction step, uses extrapolation from past values to obtain a best guess at the solution for use as input. Additional iterations use the previous output values as input.
In cases where the nonlinearity is weak, or where the internal time step is forced to be small (as when Josephson junctions are present) iterations beyond the predictor sometimes lead to unneeded accuracy. Setting the variable noiter causes skipping of iterations beyond the prediction step, and also skipping of certain other code. This maximizes the simulation rate, but can lead to errors if not used carefully. Much the same effect can be obtained by setting reltol to a large value, however noiter is more efficient as convergence testing and matrix loading are skipped, as there is a-priori knowledge that no iterations are to take place. The iteration count and total internal timepoint count are available from the rusage command.
During transient analysis with Josephson junctions present, the default time step is given by T = /vmax , where = /2 ( = 3.291086546e-16, is the magnetic flux quantum) and vmax = max(Vj, sqrt(Jc/C)) . If the variable nojjtp is set, the timestep is determined from a truncation error calculation, as is the case when Josephson junctions are not present in the circuit. The user should experiment to determine which timestep leads to faster execution.
When this boolean variable is set, KLU will not be used for sparse matrix calculations. Otherwise, if the KLU plug-in is available, KLU will be used by default. The KLU plug-in is provided with all WRspice distributions, and is installed in the startup directory.
When using Sparse (i.e., KLU is unavailable or disabled), this boolean variable when set will prevent using element sorting to improve speed. This corresponds to the legacy WRspice sparse code. It may be interesting for comparison purposes, but setting this variable will slow simulation of most circuits. This variable has no effect if KLU is being used.
This boolean variable applies when one of gminsteps or srcsteps is given a positive value, and thus operating point analysis (see 2.7.5) is using a Berkeley algorithm. In this case, by default a direct iterative solution of the circuit matrix is attempted, and if this fails the stepping methods are attempted. This initial direct solution attempt most often fails with complex circuits and can be time consuming. Setting noopiter> will skip this initial attempt.
If set, do not use WRspice options that have been set interactively through the shell. Use only options that appear in a .options line in the circuit file when running a simulation of the circuit.
When set, the SPICE2 limiting algorithm for MOS devices is used. Otherwise, an improved limiting procedure is used.
.tran tstep tstop [tstart [tmax]]
I.e., tmax now defaults to tstep. Previously if defaulted to (tstop - tstart)/50, which is usually a much larger value.
The oldsteplim boolean option if given will revert the run to the earlier limiting condition.
It is important to understand the consequences of this difference. This change was made to improve results from circuits containing only devices that weakly limit the time step (e.g. MOSFETs, ring oscillator results) which otherwise can be ugly and wrong. This allows users of such devices to get good results without having to set an explicit maximum time step in the tran line.
However, if the printing time increment tstep is too small, the simulation time can dramatically increase, since these points are actually being calculated and not just interpolated. The user in this situation has several options:
When set, the source lines are renumbered sequentially after subcircuit expansion.
If this variable is set, then all device current special vectors are saved in the plot by default during analysis. This enables plotting of device currents using the @device[param] construct.
By default, WRspice uses a custom algorithm for controlling integration order during transient analysis. This algorithm provides the following advantages over the SPICE3 algorithm:
The standard SPICE3 logic can be used if desired, by setting the boolean option variable spice3. WRspice releases prior to 3.2.13 used the SPICE3 algorithm exclusively.
In some circuits, whose equations are ``stiff'' in a mathematical sense, trapezoidal integration may not converge in transient analysis. These circuits likely have a low impedance (voltage source) driving a capacitor, and/or a high impedance driving an inductor. Non-convergence can take several forms:
When using trapezoidal integration, there is a test to check for the oscillatory behavior characteristic of this type of nonconvergence. If nonconvergence is detected, the present time point is rejected, the time step is cut by a factor of eight, and the time point calculation is repeated using backward Euler integration. The circuit will return to trapezoid integration in a few internal time steps.
This is an improvement, but does not solve all convergence problems. In particular, this test will not detect monotonic divergence, which could be detected by other means but too late to do anything about it.
This test is not enabled by default, since it tends to cause circuits to simulate a little more slowly. It tends to produce false-positives which increase the iteration count. When needed, it can be enabled by setting the trapcheck variable.
In WRspice releases prior to 4.1.22, this test was enabled by default, and could be disabled by setting a variable named ``notrapcheck''. The notrapcheck variable is no longer recognized.
This boolean variable is applicable only to the LTRA model. When specified, the simulator tries to condense LTRA transmission line past history of input voltages and currents.
Most of the BSIM device models in WRspice have added code that builds an adjoint matrix which is used to accurately compute device currents. The computed currents are not used in the device models, but are available as simulation outputs. This has a small performance overhead so is not enabled by default, but will be enabled by setting this variable. Without this it may not be possible to obtain device currents during the simulation, using the device[param] ``pseudo-vector''.
In WRspice releases prior to 4.1.23, this feature was enabled by default, and a variable named ``noadjoint'' could be set to disable the feature. The noadjoint option is no longer recognized.