Re: math functions in 1364

From: Kevin Cameron <kcameron@altera.com>
Date: Thu Dec 02 2004 - 10:47:37 PST

Steven Sharp wrote:

>>Using $<math func> seems like a bad idea to me, regular Verilog usually
>>treats those kind of things as user-supplied or user-replaceable.
>>
>>
>
>These particular functions are built-in, not user-supplied. The user
>can indeed replace them with user-supplied versions, but that doesn't
>mean that a tool doesn't know this has been done. It need not allow a
>user-supplied replacement in all of the situations where the built-in
>ones are allowed. For example, these particular built-in functions are
>allowed to be used in constant expressions (i.e. expressions that must be
>elaboration-time constants), while a user-supplied replacement is not.
>In a similar way, these built-in functions could be allowed in analog
>contexts without allowing a user-supplied replacement there, if that
>causes problems.
>
>
>
>>You'd
>>be as well off using the SV DPI interface and just calling the C math
>>functions directly - you can skip the '$' then.
>>
>>
>
>This is a good point, but there are some flaws in it. As noted above,
>a tool can know whether a built-in system function has been replaced with
>a user-supplied function, and disallow it if necessary. Since all SV DPI
>functions are effectively user-supplied, this may not be possible there.
>It may be that if the C math library is statically linked into the tool,
>and it can be sure that the imported DPI function is using those math
>functions, then this is possible.
>
>As noted above, these particular built-in Verilog system functions can be
>used in constant expressions. As far as I know, SV DPI functions cannot.
>It was my understanding that it was necessary to be able to use these math
>functions in constant expressions.
>
>
I don't see any reason why DPI functions can't be used in constant
expressions,
you can mark imported functions as pure (there's a comment in the SV LRM
about
optimization).

>And DPI is only available in SystemVerilog at present, not in Verilog.
>However, it must be admitted that certain other SystemVerilog features
>would make the system task approach work better too. Being able to
>put the Verilog functions without the '$' into a package or $unit would
>make them much more convenient to use.
>
>Steven Sharp
>sharp@cadence.com
>
>
Verilog-AMS is an evolving language as is SV, I'd rather they merged
than diverged,
so anytime I see an attempt to do something in AMS that's already in SV
I like to
stamp it out :-) - that's not to say I like how SV does everything, but
AMS wil have
to fall in line with SV at some point since AMS has a smaller user
community.

Kev.
Received on Thu Dec 2 09:47:53 2004

This archive was generated by hypermail 2.1.8 : Thu Dec 02 2004 - 09:48:06 PST