-
- bypass
When bypassing is enabled, which is the default, semiconductor devices
will skip certain computations when terminal voltages are relatively
static. This is a speed optimization. This variable can be set as an
integer to a value of 0 (zero) to disable bypassing. This can perhaps
increase accuracy, at the expense of speed. When set to a nonzero
value, or to no value, there is no effect as bypassing is enabled by
default.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 1 |
0 |
1 |
Simulation Options/Devices |
- fpemode
The fpemode variable can be set to an integer which controls how
the program responds to a floating-point exception, such as divide by
zero or overflow. The accepted values are
- 0 (default)
Halt computation if an error is detected. In many cases, the
computation will be retried, after going to a smaller step size in
simulation (for example), so the halt does not necessarily mean
simulatiuon failure.
- 1
Ignore floating-point errors and just continue. This is what most
other simulators do.
- 2
This is for debugging. A floating-point error will cause a signal
to be emitted, that when caught will terminate the program. Under
control of a debugger, the expression causing the exception can be
located easily, but this is not likely to be useful for the
general user.
In releases prior to 4.1.6, there were two ``signaling'' modes, that
attempted to return to the running program. This is no longer
possible and these would instead hang the program if used.
If set as an option, e.g. ``.options fpemode=1'' then the mode
applies only when the circuit is running a simulation.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 0 |
0 |
2 |
Simulation Options/General |
- gminsteps
This variable controls the gmin stepping used in operating point
analysis (see 2.7.6). The values are integers in the range -1
through 20, with the default being 0. If -1, no gmin stepping will be
attempted. If set to 0 (the default) the dynamic gmin stepping
algorithm is used. This will use variable-sized steps, reattempting
with a smaller step after failure. If positive, the Berkeley SPICE3
gmin stepping algorithm will be used, with a fixed number of steps as
given.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 0 |
-1 |
20 |
Simulation Options/Convergence |
- interplev
In transient analysis, in the default steptype mode, internal
timepoint data are interpolated onto the external (user supplied) time
points. Only the interpolated data are saved. This variable sets the
polynomial degree of interpolation, in the range 1-3. The default is
1 (linear interpolation).
| Default |
Min Value |
Max Value |
Set From |
|---|
| 1 |
1 |
3 |
Simulation Options/Timestep |
- itl1
The itl1 variable sets the dc iteration limit before convergence
failure is indicated.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 400 |
10 |
1000 |
Simulation Options/Convergence |
- itl2
The itl2 variable sets the dc transfer curve iteration limit
before convergence failure is indicated.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 100 |
4 |
500 |
Simulation Options/Convergence |
- itl2gmin
The itl2gmin variable sets the maximum number of iterations to
allow per step during gmin stepping when finding the dc operating
point.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 20 |
4 |
500 |
Simulation Options/Convergence |
- itl2src
The itl2src variable sets the maximum number of iterations to
allow per step during dynamic source stepping when finding the dc
operating point.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 20 |
4 |
500 |
Simulation Options/Convergence |
- itl4
This variable sets the number of timepoint iterations in transient
analysis above which convergence failure is indicated.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 20 |
4 |
100 |
Simulation Options/Convergence |
- loadthrds
WRspice currently supports multi-threaded matrix loading on all
supported platforms. The concept is to use otherwise unused processor
cores to evaluate device model code in parallel, thus reducing
simulation time. This is experimental, and applies to dc (including
operating point) and transient analysis only.
The load function is the function that evaluates all of the device
model code, and sets up the circuit matrix and right-hand side vector,
for subsequent LU factorization and solution. This dominates circuit
simulation time in some circuits, particularly when using complex
device models such as BSIM.
This variable sets the number of helper threads that will be created
to assist the main thread in evaluating device code. If 0 or not set,
no helper threads are used. It has a corresponding entry in the
General page of the Simulation Options panel.
Multiple threads will not necessarily make simulations run faster and
in fact can have the opposite effect. The latter is sadly true in
Josephson circuits tested thus far. The problem is that
multi-threading adds a small amount of overhead, and the load function
may be called hundreds of thousands of times in these simulations.
The model calculation for JJs runs very quickly, and the overhead
becomes significant. The same is true for other simple devices. Work
to improve this situation is ongoing.
On the other hand, if there is a lot of computation in the device
model, this will dominate the overhead and we see shorter load times.
This is true for BSIM MOS models, in circuits with more than about 20
transistors. Such simulations can run 2-3 times faster than a single
thread. One should experiment with the value of the loadthrds
variable. Most likely for best performance, the value plus the main
thread should equal the number of available hardware threads, which is
usually twice the number of available CPU cores.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 0 |
0 |
31 |
Simulation Options/Beneral |
- loopthrds
WRspice currently supports multi-threaded simulation runs when
performing chained-dc analysis (see 1.4). Most analysis
types allow dc analysis chaining. That is, the basic analysis
specification is followed by a dc analysis specification involving one
or two sources or device parameters in the circuit, and the analysis
is run at each dc bias condition. The result will be a family of
multi-dimensional vectors, one dimension per bias condition.
In this release, the dc-point analyses may be run using multiple
threads. All supported operating systems provide multi-threading,
however parallel runs require multiple cores or CPUs. Multiple
threads will be used automatically if:
- The loopthrds variable is set to an integer 1 or larger.
This option variable indicates the number of ``helper'' threads to
use. It can be set to an integer in the range 0 through 31, with 0
being the same as not set (single threading). The ``best'' value can
be found experimentally, but the value plus the main thread probably
equals twice the number of available CPU cores.
- The analysis specification supports multi-threading. Presently
the following analyses can be multi-threaded:
tran, without scrolling, segmenting, and with the ``nousertp''
mode not set.
ac
tf
Concurrent threads in loop/Monte Carlo analysis is not yet available,
but will be be provided in a future release. These analysis require a
rebuild of the circuit object for each trial.
Hint: If your requirements can be met with chained dc analysis
instead of loop analysis, overhead can be minimized. Chained dc can
be used in many instances, since a source voltage can be used in an
expression for a component value, for example.
In chained dc analysis, the same circuit object is re-used multiple
times. In loop analysis, the circuit object must be recreated for
each trial run, since the deck after shell substitution will have
changed.
The loopthrds and loadthrds can be used together. One
should experiment to find the fastest settings.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 0 |
0 |
31 |
Simulation Options/Beneral |
- maxord
This variable sets the maximum order of the integration method
used. Setting this to 1 will always use rectangular integration.
If unset, the value taken is 2, which is the maximum order for the default
trapezoidal integration. If Gear integration is used, the maximum
order is 6.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 2 |
1 |
6 |
Simulation Options/Timestep |
- srcsteps
This variable controls the source stepping used in operating point
analysis (see 2.7.6). The values are integers in the range -1
through 20, with the default being 0. If -1, no source stepping will
be attempted. If set to 0 (the default) the dynamic source stepping
algorithm is used. This will use variable-sized steps, reattempting
with a smaller step after failure. If positive, the Berkeley SPICE3
source stepping algorithm will be used, with a fixed number of steps
as given.
| Default |
Min Value |
Max Value |
Set From |
|---|
| 0 |
-1 |
20 |
Simulation Options/Convergence |
- vastep
This option applies when a .verilog block is present, and the
Verilog simulation is run in parallel with transient analysis.
Precisely how this occurs is controlled by this option. The value is
an unsigned integer.
- 0
The Verilog simulation is advanced by calling the vastep
command, likely through a callback function called from a .stop
line.
- 1 (the default)
The Verilog simulation is advanced at each transient analysis
time step.
- X (positive integer greater than 1)
The Verilog simulation is advanced after X transient time
steps.
