RE: PROPOSAL (BNF) for empty tf_port_list (Was: [sv-bc] task/func tion_declaration with empty port_list)


Subject: RE: PROPOSAL (BNF) for empty tf_port_list (Was: [sv-bc] task/func tion_declaration with empty port_list)
From: Hermann.Ilmberger@infineon.com
Date: Mon Nov 17 2003 - 06:21:16 PST


This fixes the grammar so that it allows zero args.
However, with respect to functions and tasks,
the grammar is rather inconsistent in wording and structure:
With the proposed fix we get
A.2.6 and A.2.7
task/function declaration::= ... ( [ tf_port_list ] )

In other parts of the language we have the square brackets for the arguments
shifted down:

named_function_proto::= [ signing ] function_data_type function_identifier (
list_of_function_proto_formals )
list_of_function_proto_formals ::= [ { attribute_instance }
function_proto_formal { , { attribute_instance } function_proto_formal } ]

And a third form here (and zero args again not allowed):

named_task_proto ::= task_identifier ( task_proto_formal { ,
task_proto_formal } )
task_proto_formal ::= tf_input_declaration | tf_output_declaration |
tf_inout_declaration | tf_ref_declaration

It would be nice to have a common look and feel.
Cheers,
-Hermann

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On
> Behalf Of Brad
> Pierce
> Sent: Thursday, November 13, 2003 6:39 PM
> To: sv-bc@eda.org
> Subject: PROPOSAL (BNF) for empty tf_port_list (Was: [sv-bc]
> task/function_declaration with empty port_list)
>
>
> Yes, this is a bug in the BNF, not in the example. Already in V2K,
> many tools (e.g., NC-Verilog and VCS) support empty port lists in the
> declaration of user-defined tasks with no arguments.
>
> Attached is a proposal to fix this bug.
>
> -- Brad
>
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On
> Behalf Of Karen
> Pieper
> Sent: Wednesday, November 12, 2003 2:35 PM
> To: sv-bc@eda.org
> Subject: Fwd: FW: [sv-bc] task/function_declaration with
> empty port_list
>
>
>
> >From: Hermann.Ilmberger@infineon.com
> >X-Authentication-Warning: server.eda.org: pieper set sender to
> >Hermann.Ilmberger@infineon.com using -f
> >To: owner-sv-bc@eda.org
> >Subject: FW: [sv-bc] task/function_declaration with empty port_list
> >Date: Wed, 12 Nov 2003 15:18:55 +0100
> >X-Message-Flag: Follow up
> >X-Mailer: Internet Mail Service (5.5.2653.19)
> >X-Spam-Status: No, hits=-2.4 required=5.0
> > tests=NO_REAL_NAME,ORIGINAL_MESSAGE
> > autolearn=ham version=2.52
> >X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)
> >X-Loop: pieper@eda.org
> >X-pstn-levels: (S:40.1914 R:95.9108 P:95.9108 M:98.9607
> C:78.1961 )
> >X-pstn-settings: 1 (0.1500:0.1500) r p m C
> >X-pstn-addresses: from <Hermann.Ilmberger@infineon.com> [381/10]
> >
> >Hi,
> >I sent this to the list two days ago, but it never made it.
> I am member of
> >the list.
> >Best regards,
> >-Hermann
> >Hermann Ilmberger, Infineon Technologies AG
> >
> >-----Original Message-----
> >From: Ilmberger Hermann (CL DAT TDM VM)
> >Sent: Monday, November 10, 2003 3:32 PM
> >To: sv-bc@eda.org
> >Subject: [sv-bc] task/function_declaration with empty port_list
> >
> >
> >Hi,
> >
> >is this a bug in the formal syntax of SV3.1?
> >The formal syntax for function_declaration does not allow
> >
> >function juhu(); // with empty function_port_list
> >...
> >endfunction
> >
> >However, it seems that this is desirable for functions that
> >do not take arguments. Examples appear in section 11.3:
> >
> >class Packet;
> >function new();
> >...
> >endfunction
> >task clean();
> >...
> >endtask
> >endclass
> >
> >However, in 19.6.2:
> >import task slaveRead(),
> > task slaveWrite());
> >This is o.k. since named_function_proto allows an empty
> >list_of_function_proto_formals.
> >
> >Section 10.5.5 "Optional argument list" seems to refer only to
> function/task
> >call and
> >not to declaration.
> >
> >Cheers,
> >-Hermann
> >Hermann Ilmberger, Infineon Technologies AG
>
>



This archive was generated by hypermail 2b28 : Mon Nov 17 2003 - 06:22:13 PST