This document gives notes that you should read and understand in order to
be able to use the model effectively with different simulators
and Verilog-A compilers. The reason is that there was a significant
change in Verilog-A between LRM2.1 and LRM2.2 versions that directly
affects compact models. There are some older versions of simulators
that are still being used that are based on LRM2.1, there are some newer
versions of simulators that are based on LRM2.2 but are not yet fully
compliant with its syntax, and there are some imprecisions in the LRM2.2
specification that have led to different interpretations, and therefore
different Verilog-A compiler behavior, in different simulators.
The model, and macros used in the model code, are intended to
work with these

If you get warning messages because something is not a supported (or standard)
attribute, ignore them. LRM2.2 defines "desc" and "units" as two standard attributes,
but there is no restriction on any particular attribute.

The most significant thing to be aware of is how the multiplicity factor
is handled. In most SPICE-like simulators this is the known parameter "m"
that is implicit and does not need to be explicitly declared or handled.
Importantly, m is a hierarchical parameter and if you instantiate nested
subckts, then at the "bottom" (model) level of the hierarchy the effective m value
that should be used is the product of all m factors on all instance lines
down the hierarchy. This was overlooked in LRM2.1, and in many simulators
even if "m" were a declared parameter of a Verilog-A model, a value for m
specified on an instance of that model would not get passed through to the
Verilog-A code but would get "intercepted" by the simulator.

If you are using the model with an LRM2.1 compliant Verilog-A compiler,
it is possible that either an instance parameter m will not get passed,
or will get passed with a direct value (as specified on the instance line)
but not with a hierarchically calculated value if the instance is in a subckt.
You need to test your compiler and/or simulator to verify how m is handled.
If m is not handled properly (directly and/or hierarchically), you should ensure
that you do not use the model in a situation where this will cause an error.
Note that this is not a problem with the model, it is an issue with m not being
recognized as needing to be handled in a special manner when LRM2.1 was defined.

If you are using a compiler that is LRM2.2 compliant you may see a warning
about possible double scaling with $mfactor, the special quantity that
was explicitly added for LRM2.2 for multiplicity handling. Do not worry
about the warning, the $mfactor scaling is done automatically and correctly
by LRM2.2 compliant compilers and $mfactor is only used in the model
for calculations for quantities printed to provide operating point information.
If your compiler or simulator generates an error, this is an error in the
compiler so work with your simulator or compiler supplier to have it fixed
and made LRM2.2 compliant.

Up to version mmsim62, the Cadence Spectre(c) simulator does not handle
$mfactor. Rather, there is an attribute inherited_mfactor that is defined
for the parameter that performs the function of m (it does not have to be
named m). Therefore:
**************************************************************************
**************************************************************************
IF YOU USE THIS MODEL WITH A VERSION OF THE CADENCE SPECTRE SIMULATOR
THAT HAS __VAMS_COMPACT_MODELING__ DEFINED FOR Verilog-A, YOU MUST MAKE
SURE THAT THE LINE

`define __SPECTRE__

IS NOT COMMENTED OUT. THIS CAUSES THE MACRO THAT DEFINES THE INSTANCE
PARAMETER m TO BE OF THE FORM THAT WORKS PROPERLY WITH SPECTRE(c)
**************************************************************************
**************************************************************************

NOTE: these notes are ONLY relevant if you or your simulator is doing a
run-time compile of the Verilog-A model code. If the model you are using
has been implemented into your simulator in a pre-compiled manner
then proper handling of the multiplicity parameter m should have been
done as part of that implementation. It is expected that this is the mode
of use that should be used; run-time usage is convenient for quick
evaluation of the model and for parameter extraction as part of
initial application of the model to specific devices and technologies,
but for efficiency a "built-in" (i.e. pre-compiled) implementation
should be used for real parameter extraction and IC design purposes.

If you have further questions regarding the issues described above, please
contact Colin McAndrew at Colin.McAndrew@freescale.com.