From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Thu Oct 04 2001 - 07:47:51 PDT
Precedence: bulk
Maq,
I'm traveling, and have not yet seen the review draft. But, I have seen
the BNF that is in the IEEE's hands--the IEEE provided me a copy just a
couple of weeks ago for inclusion in the book I just completed. The change
to tf_* for the task/function i/o declarations made it in. Are there other
differences?
BTW, a typo that is in the BNF that I received, and which should be
corrected, is that all the references to the end-notes have disappeared.
Stu
At 04:31 PM 10/3/2001, you 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 //
> > //*****************************************************************//
> >
> >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:46 PDT
and
sponsored by Boyd Technology, Inc.