From: Don Mills (mills@lcdm-eng.com)
Date: Wed Oct 03 2001 - 21:14:42 PDT
Precedence: bulk
Maybe each of you "BTF Leads" should each get ONE and ONLY ONE personal favorite
clarification fix. (Not that my opinion matters.) That way wording that needs
clarification can get added without going overboard with tons of new updates.
<p><p>Michael McNamara wrote:
> Precedence: bulk
>
> If we are going to clarify just one thing, I'd much rather fix the
> problem with ANSI ports and task declarations. Basically the BNF
> should be changed to read:
>
> (From Annex A - A.2.7)
> task_declaration ::= task [ automatic ] task_identifier ;
> { task_item_declaration } statement endtask
> | task [ automatic ] task_identifier (task_port_list)
> { block_item_declaration } statement endtask
>
> task_item_declaration ::= block_item_declaration
> | { attribute_instance } input_declaration
> | { attribute_instance } output_declaration
> | { attribute_instance } inout_declaration
>
> task_port_list ::= task_port_item { , task_port_item }
> task_port_item ::= { attribute_instance } input_declaration
> | { attribute_instance } output_declaration
> | { attribute_instance } inout_declaration
>
> to be:
>
> task_declaration ::= task [ automatic ] task_identifier ;
> { task_item_declaration } statement endtask
> | task [ automatic ] task_identifier (task_port_list)
> { block_item_declaration } statement endtask
>
> task_item_declaration ::= block_item_declaration
> | { attribute_instance } tf_input_declaration
> | { attribute_instance } tf_output_declaration
> | { attribute_instance } tf_inout_declaration
>
> task_port_list ::= task_port_item { , task_port_item }
> task_port_item ::= { attribute_instance } tf_input_declaration
> | { attribute_instance } tf_output_declaration
> | { attribute_instance } tf_inout_declaration
>
> tf_input_declaration::=input [reg] [signed] [range] list_of_port_identifiers
> | input [tf_io+type] list_of_port_identifiers
> tf_output_declaration::=output [reg][signed][range] list_of_port_identifiers
> | input [tf_io_type] list_of_port_identifiers
> tf_inout_declaration::=inout [reg][signed][range] list_of_port_identifiers
> | inout [tf_io_type] list_of_port_identifiers
> tf_io_type ::= real
> | realtime
> | time
> | integer
>
> This was discussed heavily in December of 2000, and it was stated that
> there wasn't time, et cetera, to get this fixed.
>
> The exiting syntax allows one to declare tasks as:
>
> task foo( wire [31:0] a,b,c );
> endtask
>
> which is clearly illegal.
>
> Clifford E. Cummings writes:
> > Precedence: bulk
> >
> > Dear BTF -
> >
> > While submitting typo corrections to the IEEE, I would also like to try to
> > submit one clarification paragraph in the list. The clarification paragraph
> > has to do with implicit nets and the wording was submitted by Paul Graham
> > of Cadence.
> >
> > PROPOSAL: Add the following indented paragraph to the end of section 3.5.
> > Indenting to match the indenting of the two last paragraphs already in
> > section 3.5:
> >
> > "If an identifier appears as the target of a continuous assignment
> > statement, and that identifier has not been declared previously, then an
> > implicit scalar wire declaration is assumed for that identifier."
> >
> > Please vote YES or NO on the above proposed addition to the end of section
> > 3.5 and e-mail your vote to me no later than Monday, October 15th, 2001.
> >
> >
> >
> > I know I said we could not add any clarification to the IEEE document, but
> > I believe this is an exception for the following reasons:
> >
> > (1) Verilog-1995 required the target of a continuous assignment that did
> > not drive a port to be explicitly declared.
> >
> > (2) Verilog-2001 removes this non-orthogonal restriction. As Mike MacNamara
> > has noted, the BTF tried to remove the restriction by changing the first
> > paragraph in section 6.1.2 to read as follows:
> >
> > "The continuous assignment statement shall place a continuous assignment on
> > a net data type. The net may be explicitly declared, or may inherit an
> > implicit declaration in accordance with the implicit declarations rules
> > defined in 3.5."
> >
> > This was not clear enough as to our intent.
> >
> > (3) As has been noted in earlier threads, Don Mills & Stu Sutherland
> > authored a paper about the Verilog-2001 Standard that incorrectly described
> > the behavior of this change. This paper has been widely distributed
> > (SNUG2001-Europe, SNUG2001-San Jose, SNUG2001-Dallas, others?) and used by
> > many as a brief authoritative tutorial about Verilog-2001 enhancements.
> > Although the paper has been updated, corrected and placed on Don Mills' web
> > site, the damage has been done, which is why I think we need to be more
> > explicit in this description in the published IEEE1364-2001 Standard and
> > not hope that we can verbally correct the confusion as the questions arise.
> >
> > We should be able to say: "This enhancement is described at the end of
> > section 3.5 of the IEEE1364-2001 Standard."
> >
> > Please e-mail me your vote!
> >
> > Regards - Cliff Cummings
> > Behavioral Task Force Chairperson
> >
> > //*****************************************************************//
> > // Cliff Cummings Phone: 503-641-8446 //
> > // Sunburst Design, Inc. FAX: 503-641-8486 //
> > // 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
> > // PMB 501 Web: www.sunburst-design.com //
> > // Beaverton, OR 97005 //
> > // //
> > // Expert Verilog, Synthesis and Verification Training //
> > //*****************************************************************//
> >
> >
-- ========================================================== Don Mills LCDM Engineering (Logic, Coding, & Design Methodology) mills@lcdm-eng.com www.lcdm-eng.com 801-282-6560 Office PHONE 801-641-5882 Mobile PHONE 4158 W. Ben Armine Cir., South Jordan, UT 84095-9101 ==========================================================
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:46 PDT
and
sponsored by Boyd Technology, Inc.