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.
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.
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.
.model mynpn npn level=N ...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.
.model nch nmos level=M ...
The model can be referenced by name, for example
.model mynpn hicum2 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.
.model nch bsim6 type=1 ...
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 wrcad.com. 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 (www.cygwin.com). MinGW-w64 (sourceforge.net/projects/mingw-w64) is required for compiling the modules (in 32-bit mode).