From: Michael McNamara (mac@verisity.com)
Date: Thu Oct 04 2001 - 08:45:18 PDT
Precedence: bulk
<p>This makes me very happy.
<p>Stuart Sutherland writes:
> 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.