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 don't see how the sentence about translating Spice netlists
fits in this context.
Verilog *requires* a default value for all parameters; however,
you are right that it would make sense to give the example as
parameter string type = "" from { "NMOS", "PMOS" };
so that, if type were not overridden, there would be an error.
-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.
Received on Thu May 20 10:27:22 2004
This archive was generated by hypermail 2.1.8 : Thu May 20 2004 - 10:27:23 PDT