RE: [sv-bc] Ambiguity in function prototype parsing

From: Mark Hartoog <Mark.Hartoog_at_.....>
Date: Mon Nov 14 2005 - 10:18:13 PST
If "function void test(input T[1:0])" was in a function definition,
where the port name must be given, 'T' would be the port name.

I think it is a bad idea to make up different parsing rules so that
the legal, unambiguous function definition header is illegal as
a prototype or means something different in a prototype than
what it means as a function header, so I thing 3 is the best
choice.

By the way, I think allowing unnamed ports in function prototypes
is a bad idea. C/C++ allows this, but C/C++ does not have 
function calls with argument passing by name.

> There appears to be a true ambiguity in SV regarding how to 
> parse function prototypes.  Consider:
> 
>    typedef int T;
>    module top;
>      import "DPI-C" function void test(input T[1:0]);
>    endmodule
> 
>    class C;
>      extern function int test(T[1:0]);
>    endclass
> 
> 
> I think that per the LRM both of these should be legal.  Note 
> that for a function prototype, the name of the formal is not 
> required.  In addition, the type is not required (implicitly 
> logic).  So, what does "T[1:0]" mean?  Does it define a 
> formal named "T" with type of unpacked array of logic or does 
> it define an unnamed formal of type unpacked array of T?
> 
> There are several ways to deal with this:
>    1) if the identifier is a visible type, require a full type
>       and name declaration for the formal
>    2) if the identifier is a visible type, treat the declaration
>       as an explicitly typed unnamed formal
>    3) always treat this as an implicitly typed named formal
> 
> I think that I'd like to require either 1 or 2.
> 
> There are some parallels to this issue in the port 
> declaration space, but I believe that they can all be 
> disambiguously interpreted (although they aren't LALR(1)).  
> If we do go with (1), I'd probably like to take another look 
> at the port declaration rules in order to require full 
> declarations in any cases that might be surprising to the user.
> 
> Gord
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
Received on Mon Nov 14 10:18:25 2005

This archive was generated by hypermail 2.1.8 : Mon Nov 14 2005 - 10:18:49 PST