Re: $mfactor in Verilog-style netlists

Kevin Cameron wrote:
>
> No real reason not to have both. I think SV considers [3] to be equivalent
> to [0:2] in a declaration anyway.

Oh, then this won't work after all. You can override a parameter
for one of the instances with
     defparam X1.M1.l = 1u
and then they're not identical instances in parallel, which is
what the mfactor is for.

> I don't see how you can tell in arbitrary Verilog-A code that I(a,b) should
> be divided and you will always get the right result.

That the whole beauty of the mfactor: there are simple rules, and if
you apply them correctly, then you get the right answer, all the time.

> Your proposal says:
>
> "In addition to the automatic scaling of currents, there are times
> when the multiplicity factor would reasonably expected to affect the
> values of output and operating point parameters (§1.4)."

If you have an instance of a resistor with R=5, but its multiplicity
is 5, then a designer would probably like to see that its effective
resistance is 1, rather than having to look up two numbers and do
the division. However, this is a convenience for the designer, and
does not affect the simulation results. Following the four rules
we outlined (current contribs, current probes, noise currents, and
noise voltages) are *always* sufficient to get correct simulations.

> So I'd prefer to have the user indicate that it is handled, rather than make
> the assumption. There should be an attribute of some sort to indicate that
> just scaling port currents is sufficient.

Again, we don't want to force the model developer to do anything.
The rules are simple for the simulator, but a model developer
might not know how to test that $mfactor is handled properly.

-Geoffrey
Received on Thu Apr 8 05:46:31 2004