Subject: Re: [sv-bc] LRM-46
From: Stefen Boyd (stefen@boyd.com)
Date: Fri Apr 11 2003 - 09:46:08 PDT
Francoise,
A better way to look at it is that the dpi prototype is a
superset of the namd_function_proto. They need to be able to
do things that wouldn't be allowed for normal functions like
a function "foo(a,b,c[][][])" Note that not only can the dpi
function have no direction, but arrays can be given without
a size. If we allowed these things for a regular function, we
would have to add considerable semantic restrictions in the
lrm to make it clear that it's only there for the DPI. Hope
that clarifies why I created the separate dpi_function_proto.
Stefen
At 09:59 AM 4/11/2003 -0400, Francoise Martinolle wrote:
>If the only issue is that DPI does not use the ref mode, I think it could
>be okay to
>use the same production and put a foot note that for DPI functions, ref
>mode is not
>allowed. It is acceptable to have these kinds on restriction on the BNF.
>It is silly to have almost exactly the same production for DPI and Verilog
>functions.
>
>Francoise
> '
>
>At 09:07 AM 4/11/2003 +0300, Jacobi, Dan wrote:
>>I looked at the possibility to merge the dpi_function_proto production with
>>the named_function_proto production.
>>
>>Even though the dpi_function_proto production includes the
>>named_function_proto
>>I do not recommend to merge these production due to the fact the
>>dpi_proto_formal is not the function_proto_formal. The main difference is
>>that the function prototype formal argument includes directions (or ref)
>>descriptor.
>>
>>Note the merging can be done (by changing the BNF) but I just don't
>>recommend it
>>
>>
>>
>>Dan Jacobi
>>Tel : (972)-4-8655855
>>INet : 465-5855
This archive was generated by hypermail 2b28 : Fri Apr 11 2003 - 09:46:26 PDT