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

Geoffrey.Coram wrote:

>What I meant by "keep track of" is that the simulator would
>indeed generate an error if the string is not in the list;
>it does not have to store the value in memory in order to
>be able to test its value against other strings during
>simulation.
>
>Flag for a pchannel device: this is not implementation-specific,
>insofar as every compact model I've ever seen in any C code for
>any simulator uses -1 for p-channel devices. I'm not really sure
>what you're complaining about, because this looks to me just like
>any other specific example in the LRM, whether for a VCO or a
>digital gate or whatever.
>
>
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.

>I don't see how the sentence about translating Spice netlists
>fits in this context.
>
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. 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.

The aim is to support Spice behavior, not replicate it.

>Verilog *requires* a default value for all parameters; however,
>you are right that it would make sense to give the example as
>
>
That's probably legacy from before there were ranges.

> parameter string type = "" from { "NMOS", "PMOS" };
>
>so that, if type were not overridden, there would be an error.
>
Confusing and unnecessary if you just relax the rule when "from" is
present - it's easy enough to parse.

Kev.

>
>-Geoffrey
>
>
>Kevin Cameron wrote:
>
>
>>I don't understand what you mean by "the simulator does not have to keep track of it", I would have thought that if a list of values was given it would be an error for the parameter not to be in the list. If you just wanted to fix the string length that should be part of the type declaration.
>>
>>Section 3.2.5 (String Parameters) needs to be re-written since "Thus, the flag for a pchannel device would be -1" is implementation specific. The part about "flags" should be struck out and the last paragraph needs to be something like -
>>
>>"Verilog-AMS generated by translating Spice netlists could use the first letter of a parameter representing the Spice model name to test whether a model is for an n-channel or p-channel device."
>>
>>BTW, I would have thought it would be wise to not have a default for such a parameter, e.g. you would declare it:
>>
>> parameter string type from { "NMOS", "PMOS" };
>>
>>- and it would be an error not to define it at elaboration. (Might want to do that with other parameters too.)
>>
>>Kev.
>>
>>

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