Re: hierarchical system parameters and spice primitives

Marq -
My sense is that, certainly for $mfactor, the simulator should be 
responsible for handling it, as part of connecting the instance.
I say this because the simulator already handles passing the
m-factor for a subcircuit into the elements in that subckt,
whether those elements use "m" or "mult" or "area" (generally,
they end up being aliases for each other).

I haven't seen a compact model that uses $xposition in the model
equations.  If there were such a thing, then I would also expect
the simulator to handle it automatically.  The scenario we had
was that mismatch might depend on $xposition, and the mismatch
variation is handled in the paramset, not in the compact model
itself.

If you allow aliasparam to map $mfactor to mult, then you are
bypassing the automatic rules, and we discussed in committee
that there have been too many mistakes in hand-coding the m-factor.
I would hope that future compact models won't ever have their own
mult.

I think you can do things the other way around: map "area" to
$mfactor so that old netlists with BJTs with instance parameter
area can be used with new compact models that don't have "area"
as a parameter.

  paramset npn hicum2_1;
     parameter real area = 1.0 from (0:inf);
     //...
     .$mfactor = area;
  endparamset

where "hicum2_1" is the name of the module with the Hicum equations.

-Geoffrey


Marq Kole wrote:
> 
> All,
> 
> When using any of the spice primitives defined in Annex E, should these be able to handle the hierarchical system parameters ($mfactor, $xposition, etc.) given that they are automatically added to every module? Linear components can be easily handled, but things are definitely different for more complex built-in components such as MOSFETs and BJTs which often have their own handling of the multiplicity factor, for instance for noise calculations.
> 
> Should the connection between $mfactor and the models own multiplicity factor be made by the user or should it be handled automatically, i.e. similar to the handling of a Verilog-A implementation of the same model.
> 
> Should it be possible to use aliasparam for the hierarchical system parameters, for instance to map $mfactor to a model that already has a similar parameter? As an example, the Verilog-A code of the PSP model already contains the MULT parameter which is equivalent to $mfactor.
> 
> Regards,
> Marq
> 
> Marq Kole
> Competence Leader Analog Simulation, Philips ED&T