Geoffrey.Coram wrote:
>Martin -
>The string parameter as proposed does have its type defined
>in the declaration statement.
>
>If I have a string parameter like
>
> parameter string type = "nmos" from {"nmos", "pmos"};
>
>then I am saying that the simulator should allocate a 4-character
>string (plus \0 ?) for that parameter; any string that is longer
>than 4 characters must be considered as outside the allowed range
>and thus the simulator does not have to keep track of it.
>
>-Geoffrey
>
>
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.
>Martin O'Leary wrote:
>
>
>>>4. String parameters
>>>
>>>Sri asked if the range (from {"a", "b"}) is mandatory.
>>>This tells the simulator how much space to allocate for the string,
>>>(similar to how digital reg variables have a size), so I believe
>>>it should be mandatory.
>>>
>>>
>
>
>
>>Could someone elaborate more on this point? If the point is that the module should indicate the maximum number of chars the string should have - this is not correct. In Verilog, parameter sizes and indeed types are not finally determined until elaboration time.
>>
>>
Received on Thu May 20 10:10:02 2004
This archive was generated by hypermail 2.1.8 : Thu May 20 2004 - 10:10:03 PDT