Re: Minutes of: VAMS Compact Modeling conf call May 20

Geoffrey.Coram wrote:

>Kevin Cameron wrote:
>
>
>>I view it as implementation specific. In particular I would probably
>>translate spice to Verilog-AMS such that the n/p choice was in the
>>module name and not a parameter at all, and there's no reason why the
>>flag has to be -1.
>>
>>
>
>In compact models, the equations for N and P devices are exactly the
>same, except for the -1 factor. Spice "knows" about devices named
>"nmos" and "pmos" but the equations are only written once. And
>the flag is *always* -1 because that's the right way to convert
>the equations.
>
>
That's just one way to do it.

>>Your using parameters the same way Spice does. There's no particular
>>reason a device modeler would use a model parameter for that purpose in
>>Verilog-AMS - I think it's a particularly bad idea myself.
>>
>>
>
>A device modeler certainly would use a parameter for that purpose,
>rather than maintaining two copies of the module code.
>
>
A device modeler could do that, but there are other ways to avoid
duplicating code.

>>NB: Verilog
>>has different primitives for n & p transistors as (nmos, pmos), so you
>>can't do plug & play between analog and digital very easily if you move
>>the differentiation to a parameter.
>>
>>
>
>Well, the parameter doesn't have to be explicit. If you used paramsets,
>you could have
>
>paramset nmos bsim3v3
> localparam string type="NMOS";
> ...
>endparamset
>
>paramset pmos bsim3v3
> localparam string type="PMOS";
> ...
>endparamset
>
>
You might want to define the multiplier (1/-1) in each paramset too
(and not in the module); you probably still want to get an error if
you have no paramset that matches type or type is not specified.
However (if my reading of the proposal is correct) this still means you
are using a single module (bsim3v3) for both n & p devices which will
make it difficult to swap to digital primitives i.e. you can't drop the
bsim3v3 model from the netlist and substitute the appropriate pmos/nmos:
you would have to add a macromodule with a generate statement dependent
on the type parameter selecting between the two.

>>>Verilog *requires* a default value for all parameters; however,
>>>
>>>
>>That's probably legacy from before there were ranges.
>>
>>
>
>Ranges still aren't part of SV, as near as I can make out
>in the 3.1a LRM. When were they added to 1364 Verilog?
>They were certainly not in 1364-1995, since V-AMS
>notes their addition to that spec; they are present in
>the 1364-2005 draft. But I guess they're not in 1364-2001
>or else they would have made it into SV already.
>
>
Not quiet true, there is a bunch of stuff under "Random Constraints"
(see SV 12.4.3 Set membership), which is doing the same job but with
different syntax (I complained at the time).

>So, I think it would be a big battle to advocate removal of
>the default.
>
>-Geoffrey
>
>
I don't think it would be a big battle since there is no
backward-compatibility conflict, and it adds useful functionality for
the user (they don't have to add code to check their parameter didn't
get set, and less chance of accidental error). The two conflicting
syntaxes for declaring ranges are more likely to be a problem.

Kev.

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