Re: Minutes of VerilogAMS LRM Committee Call - 20/21 Dec 2004

Once we add packages to the language we could go the VHDL route of
all the math functions being in a package and the users selctively
use a package keeping the identifiers in a control scope.

>From owner-verilog-ams@eda.org Tue Dec 21 08:51:16 2004
>From: "Geoffrey.Coram" <Geoffrey.Coram@analog.com>
>To: Brian Mulvaney <mulvaney@adttx.sps.mot.com>
>Cc: Chandrasekaran Srikanth-A12788 <Srikanth.Chandrasekaran@freescale.com>,
> Verilog-AMS LRM Committee <verilog-ams@eda.org>
>Subject: Re: Minutes of VerilogAMS LRM Committee Call - 20/21 Dec 2004
>
>I agree with Brian that this will be a nuisance for backwards
>compatibility: everyone writing compact models, which use sqrt
>and exp, will have to change their models.
>
>I would like to see this postponed until SV-AMS (AMS 3.0?),
>and I would like some thought put into how to address the
>backwards compatibility.
>
>Steve Sharp suggested one could write analog functions:
> analog function real sqrt;
> input x;
> real x;
> sqrt = $sqrt(x);
> endfunction
>
>but all analog functions have to be declared at module scope,
>so you can't put them in a header file.
>
>Macros also don't help, since you'd need to change sqrt(x)
>to `sqrt(x), so you might as well change it to $sqrt(x).
>
>SystemVerilog is considering a proposal for handling keywords
>`keywords "1364-2001"
>that would prevent new keywords from causing trouble with
>existing modules; our problem is somewhat the reverse, but
>I could imagine
>`keywords "VerilogAMS-2.2"
>
>Kevin Cameron suggested using packages or the DPI from SV,
>but I don't have a clear understanding of how that would work;
>it looks like you still need a module-scope
>package_import_declaration.
>
>-Geoffrey
>
>
>"Brian Mulvaney " wrote:
>>
>>Hi Sri,
>>
>>Thanks for the update. One question:
>>
>>Chandrasekaran Srikanth-A12788 writes:
>>> - The issue of reducing keywords in VerilogAMS is currently being
>>> discussed. Changing all the math operators to have a "$" sign
>>> in front of it so that they don't need to be identified as
>>> keywords in the language. This will be consistent with
>>> SystemVerilog which supports external functions and also in
>>> line with 136-2005 ($trig functions is not part of 1995 or
>>> 2001). This issue will be taken up as part of the LRM 2.3
>>> syntax.
>>
>>Is there a compelling reason to do this? As a practical matter it
>>won't make SV-AMS any simpler, because everyone would have to
>>re-implement all these operators as $opertor. This change will make
>>backward compatibility a mess.
>>
>>Brian M.
Received on Tue Dec 21 06:19:10 2004