RE: VerilogAMS LRM Committee Meeting - 16 July 2005

Further comments below.

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
Behalf Of Muranyi, Arpad
Sent: Monday, July 25, 2005 2:28 PM
To: VerilogAMS Reflector
Subject: RE: VerilogAMS LRM Committee Meeting - 16 July 2005

Martin,

Thanks for your answers.  Regarding the first one, when you say 
"requires a string", do you mean a fixed, hard coded string literal,
or anything that evaluates into a string?  I may be spoiled by
the vast variety of programming languages which don't care what
shape and form the string comes in, as long as it ends up being
a string after evaluation.  Is the Verilog-AMS language not as
sophisticated yet?  (Sorry but I am also a fairly new student of
the language).

Oleary> yes it means a fixed, hard coded string literal.

Regarding Verilog-D and the macro definition, again I am new to
the Verilog world, but I wonder, did Verilog-D have string parameters
and arguments for `define which could also be string parameters?  If
not, what will be the verdict?

Oleary> Macros support pure text substitution - they don't consider
syntactical objects such as parameters, modules, etc...
Could you send an example of what you mean?

(It seems that arguments are new to
`define in LRM v2.2 as well as string parameters, so I suspect that
Verilog-D may not have them, am I incorrect on that)?

Thanks,

Arpad
====================================================================

-----Original Message-----
From: Martin O'Leary [mailto:oleary@cadence.com] 
Sent: Monday, July 25, 2005 2:14 PM
To: Muranyi, Arpad; VerilogAMS Reflector
Subject: RE: VerilogAMS LRM Committee Meeting - 16 July 2005

Some comments below.
Thanks,
--Martin

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
Behalf Of Muranyi, Arpad
Sent: Monday, July 25, 2005 11:37 AM
To: VerilogAMS Reflector
Subject: RE: VerilogAMS LRM Committee Meeting - 16 July 2005

Hello everyone,

I am a new subscriber to this list, so please forgive me if I
am not following the usual form of discussion, or if what I
say may have been discussed before.  However, looking at the
agenda and the attached spreadsheet, it seems that the topics
below may not have been addressed yet.

By the way, is this meeting tomorrow, the 26th of July?  The
logistics below says 26th, but the subject line says 16th...

1)  $table_model file name argument.  It seems that it would
be extremely useful to be able to parameterize this for cases
when the module's equations (i.e. the model behavior) remains
the same, and only the contents of the data tables change from
instance to instance.  When instantiating such modules, the
calling statement could pass a string parameter into the module
to be used in the $table_model as the file name argument.

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.

2)  `define with arguments.  The LRM v2.2 says that the macro
text can be any arbitrary text.  This includes "(" being the
first character.  On the other hand, the arguments, if present,
are surrounded by "()".  I didn't see anything in the LRM on how
the "(" character is distinguished from being text or argument.
Some tools I tried have problems with this.

Oleary> (answer for both 2,3)
Verilog-AMS inherits the macro language from Verilog-D so that
standard should be considered definitive.

3)  `define with string parameters.  Since the macro text which
is defined is not surrounded by the double quote signs, it is
technically not a string type.  It is "just text".  What happens
if I pass in a string as an argument to be part of this text?
Is it going to get flattened out as "just text", or is it going
to remain a string type?  Since this is a compiler directive, I
would expect that the compiler would take the content of the string
argument, turn it into "just text" and pass it on to the simulator
as such.  However, a tool vendor's opinion is different, they
say that at compile time the string parameters are not evaluated
yet, so the macro expansion is not aware of what the contents
of the string parameters are, therefore it can't be expanded
yet as "just text".  I don't see anything on this in the LRM
v2.2 either.

Please let me know if I missed something, or if these are real
problems, please put these on the agenda for further discussion.

Thanks,

Arpad
================================================================



-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
Behalf Of Chandrasekaran Srikanth-A12788
Sent: Monday, July 25, 2005 1:44 AM
To: 'VerilogAMS Reflector'
Subject: VerilogAMS LRM Committee Meeting - 16 July 2005


Hi all,

After a break of AMS committee meetings, probably its time to re-start
discussions on moving forward with the AMS standards. Also there have
been lot of emails on new topics, work, donations and probably good time
to start the committee meetings.

I have also collated a list of open issues - based on the items that
were sent to me and through the reflector. Hopefully I have covered most
of the issues including the recent issues being discussed - verilog-ams
testsuite, spice compatibility etc. I have not put it in the system that
they use for SV that David Smith suggested (mantis database), since I
havent chased it up with David to get it setup. Hence went back to the
true and trusted excel spreadsheet format.

Agenda:

* How do we move forward - release of AMS versions with minor
enhancements, SV integration, 1364 integration?
* Mixed Signal IC analysis - there has been feedback from Martin on this
* $table_model enhancements - no further updates
* Verilog-AMS validation suite
* Donation of VerilogA versions of spice primivites specified in Table
E.1 from Marq.
* If there is time we can go through the list of open issues - probably
this will be taken up in the next meeting.

With regards to open issues, there are some very simple items that can
be fixed. So we can try to prioritize and see whether there are anybody
who are interested in working on proposals for certain items listed in
the spreadsheet.

Call-In Details:

Time & Date: 26th July, 3pm Pacific Time
Dialin Number & Passcode:
USA Toll Free Number: 877-346-8823
USA Toll Number: +1-203-320-0407 (for international call-in) 
PARTICIPANT PASSCODE: 602538

Regards,
Sri
--
Srikanth Chandrasekaran
Freescale Semiconductor, Inc., Australia
Ph: +61-8-8168 3592 Fax: 3501