Re: $mfactor in Verilog-style netlists

Geoffrey.Coram wrote:

>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.
>
>
If you describe a module as "scalable" then the compiler should be able
to work out that if 1 in N instances is different then it can do that 1
in parallel with one scaled by N-1. Even if you don't mark it as
scalable there is no reason the compiler can't work out for itself that
it can collapse the model (it just takes more work).

Mfactor appears to me to be Spice "hack" that doesn't really belong in
a proper HDL.

>>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.
>
>
The "right" answer? Since we are trying to model hardware I suspect that
linear scaling is never the right answer.

>>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.
>
But in a behavioral model the R will not scale only the current scales
so the designer debugging will see 5 for R not 1, so its not any
clearer. If you put it in the model it is clear:

   module my_res(inout a,b);
    parameter real r0 = 5;
    multiplier x = 1.0;
    real res = r0/x; // resistance will be 1 for mfactor 5

    analog V(a,b) <+ I(a,b) * res;

   endmodule

Note: if I was going to tile a cell for the layout of this resistor I
can use "res = r0/F(x)" where F(x) can decrease the effective
multiplier to model the extra wiring resistance.

>>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
>
>
I understand that you would like to import all the functionality of
Spice, but I don't think everything that works in Spice is going to work
as well in Verilog-AMS.

Apart from it being in Spice what is the rationale for adding this
functionality? And under what circumstances would you require a
fractional multiplier?

Kev.

-- 
Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862