In order to work in Xyce, several things in the BSIM SOI 4.5.0 code
needed modification.  These are documented here:


- Xyce/ADMS now supports the $port_connected function to specify
  optional nodes, but the BSIM-SOI 4.5.0 model uses it in a manner completely
  inconsistent with Xyce.  We have copied the optional node handling code from
  BSIM-SOI 4.6.1 (which was also modified to work with Xyce and emit fatal
  errors in some invalid use cases) into BSIM-SOI 4.5.0 instead.  This allows
  the 5-, 6-, and 7- node instances of BSIM-SOI to work, but only when the
  optional nodes are actually being loaded by the device (i.e., not when
  SOIMOD=2).

  Further, Xyce cannot support the TNODEOUT option of the BSIM-SOI when
  when fewer than 7 nodes are specified.  It will exit with a fatal error
  message explaining the problem.

  These modified blocks of code are wrapped inside conditional compilation
  blocks checking the definition of "__XYCE__".  The blocks at issue here all
  contain further ifdefs checking "PORT_CONNECTED".

- Attributes have been added to some parameters to make them instance
  or both instance and model parameters.

- Bias-independent code has been wrapped in an ADMS-specific
  "@(initial_instance)" pseudo-event.  Doing so assures that this code
  is only executed when necessary --- at code initialization or
  whenever an instance or model parameter changes as part of a .STEP
  analysis.  As a consequence of this change, a line of code setting
  "DevTemp" to the ambient temperature needed to be duplicated both in
  the initial_instance and main body of the code.

- Explicit use of a multiplicity factor has been introduced.  Xyce
  does not have implicit multiplicity for devices, and requires that
  every device implement it explicitly.

- Several contributions contained both static and dynamic (ddt())
  terms, which ADMS and Xyce/ADMS mishandle.  These contributions were
  broken up into separate static-only and dynamic-only contributions.

- A number of model and instance parameters were defined with no
  parameter range, but in fact the model would behave badly if they
  were ever negative.  Appropriate ranges of either (0:inf) (excluding
  zero) or [0:inf) (including zero) were attached to these parameters.  This
  will result in Xyce emitting warnings if parameters are set outside these
  ranges.  Simulation will likely fail, but at least the user will know what
  they did wrong.

- A number of model and instance parameters were defined with no
  parameter range, but in fact the model divides by them and would
  behave badly if they were ever zero.  Appropriate ranges of either
  (0:inf) or [1:inf) were attached to these parameters.  This will
  result in Xyce emitting warnings if parameters are set outside these
  ranges.  Simulation will likely fail, but at least the user will
  know what they did wrong.
