Re: $mfactor in Verilog-style netlists

Geoffrey.Coram wrote:

>Kevin Cameron wrote:
>
>
>>You could tweak the syntax to be either a range or a multiplier, and you could add extra functionality/syntax to the module declaration to indicate that it will handle multipiers internally when possible (rather than actually having multiple instances).
>>
>>
>It would be nicer to have the multiplier, [constant_expression],
>rather than a range such that [expr1:expr2] means you have
>(expr2 - expr1 + 1) instances in parallel.
>
No real reason not to have both. I think SV considers [3] to be
equivalent to [0:2] in a declaration anyway.

>As to the second half of your statement: we DO NOT want the module
>to have to have anything special set up inside, the model writer
>should be oblivious to this (unless he/she is doing something
>special).
>
The price of moving things from vendor compiled C code into user
defined HDL is that things like this are harder to handle. However, the
benefit is that you are not stuck with a single implementation, if the
modeler wants to they can can use non-linear scaling.

>>The advantage of the integer range is that it is compatible with both analog and digital module instantiation, so the parent module doesn't need to differentiate - and it's backward compatible.
>>
>>
>
>Hmm ...
>
That means if you want to parallel up (say) a bunch of pass transistors
you can, and if you change the pass transistor model from something with
a Verilog-D built-in to a Verilog-A model nothing needs to change. You
also have the option of using the syntax I suggested in non Verilog-A
contexts (Verilog-D strengths don't scale or add linearly), to enable
faster digital simulation.

>>>3. Some voltage sources (like inductors) will not converge in DC in many simulators
>>> due to a voltage source loop.
>>>
>>>
>>>
>>How is that related?
>>
>>
>
>If you set m=3 for an inductor, you don't want to put three in
>parallel, because they are shorts at dc, so you can't solve the
>dc operating point (you can have an arbitrary loop current
>through any two).
>
Hmm...

>
>However, if you look at the Verilog-A contribution statement:
>
> V(a,b) <+ ddt( L * I(a,b));
>
>then our rules say: I(a,b) is divided by m. (This is equivalent
>to saying the effective inductance is L/m.) You no longer have
>the loop problem. The simulator should be able to figure this
>out automatically, without requiring "multiplier" to be
>declared in the module.
>
>
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. 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)."

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. E.g. instead of
the module/multiplier approach you say something like:

     scalable module bsimX (inout ...);
     endmodule
or
     module (* scalable *) bsimX (inout ...);
     endmodule

Kev.

>-Geoffrey
>
>

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