RE: strings, string variables, string parameters

Generally I also "LURK" on this list.. 

While perhaps not "defined" in the LRM, if I recall correctly a
parameter could be declared 
that could be used as a string..

parameter myString = "ABCDEFG";

The actual type is integer, and the size derives from the number of
characters.. 
I have used this a number of times in the discrete (digital) context,
but was disappointed when
I tried to use it to define the path to a file I wanted to open in the
continuous (analog) context.

Using a variable for $table_model file names might be nice as long as we
stipulate that changes to the variable after time starts will (or
[simulator dependent] might) be ignored, as I assume that loading a new
table would be a fairly big discontinuity to the continuous simulators.

however a string localparam that is the concatenation of string
parameters (name, extension, path, + environment variable value)
would certainly be nice, and all of that evaluation would be guaranteed
to happen at time 0..
 


Jonathan David   Mixed-Signal IC 
jbdavid@cadence.com Ph (408)894-2646

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
Behalf Of Geoffrey.Coram
Sent: Tuesday, July 26, 2005 3:33 AM
To: Martin O'Leary
Cc: Muranyi, Arpad; VerilogAMS Reflector
Subject: strings, string variables, string parameters

Arpad -
A "string variable" is a different animal entirely, see 2.6.1
of the 2.2 LRM (string variable declaration).

String parameters are new in the 2.2 LRM; I think they're not
in 1364, we took them from SystemVerilog.

Probably many of the places where a string is used in the LRM,
one should be allowed to use a string parameter.

-Geoffrey


Muranyi>
> I was not able to do this, because the tools I tried it with
> expected a "constant string".  However, I am not aware that
> Verilog-AMS can distinguish between string constants and
> string variables.  Is this a tool implementation problem or
> a language definition problem?
> 
> Oleary>
> The BNF explicitly requires a string for a file so it is
> language issue.
> 
> I do agree however that parameterized filenames would be
> a useful addition.