next up previous contents index
Next: The WRspice Daemon and Up: The WRspice User Interface Previous: Scripts and Batch Mode   Contents   Index

Loadable Device Modules and Verilog-A Support

It is possible to load device models into WRspice at run time, through use of ``loadable device modules''. These are dynamically loaded libraries containing the device model description in a form which can be read into a running WRspice process. This capability opens up some interesting possibilities for future versions of WRspice in how new device models are distributed. It also gives the user, at least in principle, the ability to generate and use custom device models in WRspice.

Initial support for this important new feature is available in all releases. Microsoft support required partitioning of the wrspice.exe executable into separate exe and dll files, which is true of WRspice release 4.1.5 and later. Support for user-generated loadable device models under Windows is available by request, contact Whiteley Research for more information (technically advanced users only, please).

Loadable device modules are specific to a particular release number of WRspice, and to the operating system. Since the interface may change, user-created loadable modules need to be rebuilt for new releases of WRspice. This will be relaxed in future releases, when the interface stabilizes.

Loadable device modules can be loaded into WRspice in two ways.

  1. On startup, WRspice will look for loadable modules in the directories listed in the modpath variable, or, if that variable is not set, in the devices directory under the startup directory (i.e., /usr/local/xictools/wrspice/startup/devices if installed in the default location). Modules found will be loaded automatically by default.

    If either of the -m or -mnone command line options is given, or if the nomodload variable is set in the .wrspiceinit file, the automatic device loading will not be done.

  2. The devload command can be used to load a module from the command prompt or from a script. The syntax is
    devload [path_to_loadable_module]

    The argument can also be a directory containing loadable modules, all of which would be loaded by the command.

    The ``devload all'' command will load all known modules, as when WRspice starts.

    If no argument is given, a list of the presently loaded modules is printed.

Once a module is loaded, it can't presently be unloaded. The file can be re-loaded, however, so if a module is modified and rebuilt, it can be loaded again to update the running WRspice.

There are two ways to reference a loaded device model.

  1. By traditional SPICE model level and name.
    There are traditional model names in SPICE, which often provide differentiation of device polarity. These are names like ``npn'' and ``pnp'' for a BJT device, and ``nmos'' and ``pmos'' for MOSFETs. The SPICE input file will include lines like
    .model mynpn npn level=N ...
    .model nch nmos level=M ...
    Every device model must have a unique level value (an integer) for its type. If a module is loaded that has a conflicting level, a warning is issued. If the conflict is with a built-in model, the built-in model will always have precedence, and the loaded model will not be accessible by level.

  2. By model name.
    Every loadable module has a given model name. Further, device models of dual-polarity devices have a parameter that sets the device polarity. This is defined in the model code, but most models have standardized on a parameter named ``type'' which is set to 1 for n-type and -1 for p-type.

    The model can be referenced by name, for example

    .model mynpn hicum2 type=1 ...
    .model nch bsim6 type=1 ...
    This requires that the model name be unique. WRspice presently does not check for a unique name, as it is also legitimate to use the level parameter in addition. The user will have to be careful.

The devkit directory in the WRspice installation location (/usr/local/xictools/wrspice is the default) will provide the tools needed to build loadable device modules.

The present release provides support for building loadable modules from Verilog-A model source. Many new compact device models have been released in this format, as it is (theoretically) portable to all simulators. Most commercial simulators now have this capability.

The devkit/README file provides instructions on how to build a module, and there are several examples. Pre-built modules are provided. These can be loaded into WRspice and used.

To build modules from Verilog-A source, the Whiteley Research version of the open-source adms-2.3.0 package must be installed on the system. This is available from the free software repository on This release contains enhancements and bug fixes, and should be used in preference to other versions of this software. You will need to be able to build this package, meaning that you will need to have gcc/g++, make, and other standard tools for program development available. For OS X, this means that the XCode package must be downloaded from Apple and installed.

Under Microsoft Windows, the adms package can be built with Cygwin ( MinGW-w64 ( is required for compiling the modules (in 32-bit mode).

next up previous contents index
Next: The WRspice Daemon and Up: The WRspice User Interface Previous: Scripts and Batch Mode   Contents   Index
Stephen R. Whiteley 2017-11-08