Re: Mfactor proposal

CLC Shekar wrote:
> clc> Sorry about the confusion. The intention is to allow
> access to the "effective" mfactor value within analog
> behavioral blocks. The specifics of how to access it in
> behavioral blocks is being defined by the Device modeling
> sub-committee.

That access method should be part of your proposal. Also, it's
not only in analog behavioral blocks -- there are cases in which
the model writer might want to use it in setting parameters,
possibly with a paramset.

1) to do mismatch simulation, where
   .vth0 = vth0_nom + statistics.dvth/sqrt($mfactor)

2) to manually scale a model by multiplying saturation currents
   by m and resistances by 1/m -- this could be more efficient
   than having the simulator do the multiplies on the currents
   and derivatives

> clc> The issue with using $m is that it becomes a system
> function and the language does not consider it as
> a constant. So, it would not be legal to use it in
> parameter expressions.

SV uses $typeof in a parameter expression in an example in the LRM.

> Is it possible to keep the value access mechanism
> seperate from the value propagation mechanism?

We need to consider both in the proposal.

> In the value access mechanism, looks like there are
> three types of values which the designer might be interested
> in(using the terminology in the doc):
> 1. Explicit or in its absence the implicit mfactor.
> - i.e the local mfactor for that module.
> 2. Effective mfactor within the module
> - i.e the product of all mfactors from top-level to that
> module.
> 3. Effective mfactor of the parent module.
> - i.e the product of all mfactors from top-level to that
> parent's module.
>
> Are you referring to 3. as the one which the module author
> can use to manually scale the mfactor? Or is it 1.?

I think the module author should only have access to 2., the
effective m-factor within the module (or paramset).

As a dumb example, suppose we have
   module resistor(a,b);
       parameter real r;
       real reff = r/$mfactor;
       analog I(a,b) <+ V(a,b)/reff;
   endmodule

The idea here is that reff is calculated once (the compiler figures
out to do this once per analysis) and stored, and that value is
used for the value of the current and its derivative with respect
to V(a,b). Otherwise, the simulator would have to do two multiplies
for every timestep, one of the current and one of the derivative.
By accessing $mfactor, the module author has taken it into his own
hands, and no automatic scaling will be applied by the simulator
to I(a,b).

-Geoffrey
Received on Thu Jun 17 14:23:30 2004