ISSUE 20

Number 20
Category errata
Synopsis A.2.8 should prevent all variable declaration assignments in named blocks
State lrmdraft
Class errata-discuss
Arrival-DateAug 19 2001
Originator Dennis Marsa, Xilinx
Release 2001b: A.2.8, 2.8.2, 9.8.1-2, 10.2.1, 10.3.1
Environment
Description
"In section A.2.8 on Block Item Declarations, the rule for
"block_item_declaration" specifically prohibits reg's declared
within named blocks from being initialized, though integer/real/time
variables can be initialized."

"As I recall, people thought it was confusing to have initializations
on regs declared within named blocks because it might look like it
got initialized every time the block was entered. So they probably
tried to disallow that, but failed to cover integer/real/time variables."

A.2.8 should be fixed to prevent all variable declaration assignments.

Note that 6.2.1 says,
"Variable declaration assignments are only allowed at the module level.
Fix
REPLACE the following BNF rules of section A.2.8: 

 
     block_item_declaration ::=
         { attribute_instance } block_reg_declaration
       | { attribute_instance } event_declaration
       | { attribute_instance } integer_declaration
       | { attribute_instance } local_parameter_declaration
       | { attribute_instance } parameter_declaration
       | { attribute_instance } real_declaration
       | { attribute_instance } realtime_declaration
       | { attribute_instance } time_declaration
 
     block_reg_declaration ::=
         "reg" [ "signed" ] [ range ] list_of_block_variable_identifiers ";"
 
     list_of_block_variable_identifiers ::=
         block_variable_type { "," block_variable_type }
 
     block_variable_type ::=
         variable_identifier
       | variable_identifier dimension { dimension }


WITH the following new rules for section A.2.8: 

block_item_declaration ::=
    {attribute_instance} "reg" ["signed"] [range] list_of_block_variable_identifiers ";"
  | {attribute_instance} "integer"  list_of_block_variable_identifiers ";"
  | {attribute_instance} "time"     list_of_block_variable_identifiers ";"
  | {attribute_instance} "real"     list_of_block_real_identifiers ";"
  | {attribute_instance} "realtime" list_of_block_real_identifiers ";"
  | {attribute_instance} event_declaration
  | {attribute_instance} local_parameter_declaration
  | {attribute_instance} parameter_declaration

list_of_block_variable_identifiers ::=
    block_variable_type { "," block_variable_type }
  
list_of_block_real_identifiers ::=
    block_real_type     { "," block_real_type }
  
block_variable_type ::= variable_identifier { dimension }
block_real_type ::=     real_identifier     { dimension }


Note: Syntax items that appear in "quotes" should be
interpreted as being in BOLD font.

These same updates should also be made to the following
syntax boxes which appear within IEEE 1364-2001:

1. Section 2.8.2, Syntax 2-7: The rule for "block_item_declaration"
should be updated as proposed above.

2. Section 9.8.1, Syntax 9-13: The rule for "block_item_declaration"
should be updated as proposed above.

3. Section 9.8.2, Syntax 9-14: The rule for "block_item_declaration"
should be updated as proposed above.

4. Section 10.2.1, Syntax 10-1: The rules for "block_item_declaration",
"block_reg_declaration", "list_of_block_variable_identifiers",
and "block_variable_type" should all be replaced with the
entire set of proposed rules above.

5. Section 10.3.1, Syntax 10-3: The rules for "block_item_declaration"
"block_reg_declaration", "list_of_block_variable_identifiers",
and "block_variable_type" should all be replaced with the
entire set of proposed rules above.

Audit-Trail

From: Dennis Marsa <drm@xilinx.com>
To: btf-bugs@boyd.com
Cc: eft@boyd.com
Subject: Re: errata/20: A.2.8 should prevent all variable declaration assignments
in named blocks
Date: Mon, 26 Aug 2002 14:13:57 -0600

The following is a proposal for addressing errata/20.

Regards,

Dennis Marsa
Xilinx, Inc.

---------------------------------------------------------------------------

In section 6.2.1 "Variable declaration assignment", 1st paragraph, last
sentence, it is stated that:

"Variable declaration assignments are only allowed at the module level."

This statement forbids variable declaration assignments within tasks,
functions and named blocks. The BNF rules for tasks, functions and
named blocks use the rule "block_item_declaration" to specify which
kinds of declarations are allowed within those constructs.

In the current definition of the "block_item_declaration" rule, variable
declaration assignment of "reg" variables is prohibited by its use of
the "block_reg_declaration" rule. "block_reg_declaration" is similar in
structure to the "reg_declaration" rule, except that the syntax for
specifying an initial value assignment is not present in the rule for
"block_reg_declaration".

The rule for "block_item_declaration" goes on to reference the rules
"integer_declaration", "real_declaration", "realtime_declaration", and
"time_declaration". However, these rules permit the variable
declaration assignment syntax, which contradicts the statement made
in section 6.2.1 that "Variable declaration assignments are only allowed
at the module level."

To fix, the following changes to section A.2.8 are proposed.

For reference, the (current) BNF syntax rules of section A.2.8 (page
717) are specified as follows in IEEE 1264-2001

block_item_declaration ::=
{ attribute_instance } block_reg_declaration
| { attribute_instance } event_declaration
| { attribute_instance } integer_declaration
| { attribute_instance } local_parameter_declaration
| { attribute_instance } parameter_declaration
| { attribute_instance } real_declaration
| { attribute_instance } realtime_declaration
| { attribute_instance } time_declaration

block_reg_declaration ::=
"reg" [ "signed" ] [ range ] list_of_block_variable_identifiers ";"

list_of_block_variable_identifiers ::=
block_variable_type { "," block_variable_type }

block_variable_type ::=
variable_identifier
| variable_identifier dimension { dimension }

The following BNF rules are proposed as a complete replacement for
the contents of section A.2.8:

block_item_declaration ::=
{ attribute_instance } block_reg_declaration
| { attribute_instance } event_declaration
| { attribute_instance } block_integer_declaration (Modified)
| { attribute_instance } local_parameter_declaration
| { attribute_instance } parameter_declaration
| { attribute_instance } block_real_declaration (Modified)
| { attribute_instance } block_realtime_declaration (Modified)
| { attribute_instance } block_time_declaration (Modified)

block_reg_declaration ::=
"reg" [ "signed" ] [ range ] list_of_block_variable_identifiers ";"

block_real_declaration ::= (New Rule)
"real" list_of_block_real_identifiers ";"

block_realtime_declaration ::= (New Rule)
"realtime" list_of_block_real_identifiers ";"

block_time_declaration ::= (New Rule)
"time" list_of_block_variable_identifiers ";"

list_of_block_variable_identifiers ::=
block_variable_type { "," block_variable_type }

list_of_block_real_identifiers ::= (New Rule)
block_real_type { "," block_real_type }

block_variable_type ::=
variable_identifier
| variable_identifier dimension { dimension }

block_real_type ::= (New Rule)
real_identifier
| real_identifier dimension { dimension }


Note: (Modified) identifies existing alternative there were modified
(New Rule) identifies proposed new BNF rules

These notations are not part of the proposal and should not be
included in the updated section A.2.8.

Note: Syntax items that appear in "quotes" should be interpreted as
being in BOLD font.

These same updates should also be made to the following syntax boxes which
appear within IEEE 1364-2001:

1. Section 2.8.2, page 18, Syntax 2-7: The rule for "block_item_declaration"
should be updated as proposed above.

2. Section 9.8.1, page 145, Syntax 9-13: The rule for "block_item_declaration"
should be updated as proposed above.

3. Section 9.8.2, page 146, Syntax 9-14: The rule for "block_item_declaration"
should be updated as proposed above.

4. Section 10.2.1, page 152, Syntax 10-1: The rules for "block_item_declaration",
"block_reg_declaration", "list_of_block_variable_identifiers", and
"block_variable_type" should all be replaced with the entire set of proposed
rules above.

5. Section 10.3.1, page 157, Syntax 10-3: The rules for "block_item_declaration"
"block_reg_declaration", "list_of_block_variable_identifiers", and
"block_variable_type" should all be replaced with the entire set of proposed
rules above.

From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/20: A.2.8 should prevent all variable declaration assignments in named blocks
Date: Mon, 18 Nov 2002 11:53:05 -0800

>Category: errata
>Confidential: no
>Originator: "Brad Pierce" <Brad.Pierce@synopsys.com>
>Release: 2001b
>Class: TBD
>Description:
Instead of the proposed additions, I propose that we
remove the following nonterminals --

block_reg_declaration
list_of_block_variable_identifiers
block_variable_type

and modify the first option to use reg_declaration.

Possibly a footnote could be added pointing out that
6.2.1 says that variable declarations are only allowed
at the module level.

Also note --

1) there should be a semicolon after parameter_declaration
(see ETF issue #114)

2) block_variable_type can be compressed to a single
production --

block_variable_type ::=
variable_identifier {dimension}

-- Brad


From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/20: A.2.8 should prevent all variable declaration assignments in named blocks
Date: Mon, 18 Nov 2002 11:58:03 -0800

>Category: errata
>Confidential: no
>Originator: "Brad Pierce" <Brad.Pierce@synopsys.com>
>Release: 2001b
>Class: TBD
>Description:
I propose that we enhance the standard to remove the
unnecessary restriction of section 6.2.1 ("Variable
declaration assignments are only allowed at the module
level") and allow variable declaration assignments at
the named block level, too.

-- Brad




From: Dennis Marsa <drm@xilinx.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/20: A.2.8 should prevent all variable declarationassignments
in named blocks
Date: Thu, 21 Nov 2002 10:33:57 -0700

>Category: errata
>Confidential: no
>Originator: Dennis Marsa <drm@xilinx.com>
>Release: 2001b
>Class: TBD
>Description:
Brad Pierce wrote:
>
> Instead of the proposed additions, I propose that we
> remove the following nonterminals --
>
> block_reg_declaration
> list_of_block_variable_identifiers
> block_variable_type
>
> and modify the first option to use reg_declaration.
>
> Possibly a footnote could be added pointing out that
> 6.2.1 says that variable declarations are only allowed
> at the module level.

As I mentioned in the ETF meeting of 11/18, there are many
instances in the BNF where pseudo-semantic (yet entirely
syntactic) requirements are expressed using an alternate set
of BNF rules: e.g.:

expression vs constant_expression
statement vs function_statement
module_item vs non_port_module_item

and in this particular situation:

module_item_declaration vs block_item_declaration
reg_declaration vs block_reg_declaration

My proposal for this errata introduces additional
rules of this sort:

integer_declaration vs block_integer_declaration
real_declaration vs block_real_declaration
realtime_declaration vs block_realtime_declaration
time_declaration vs block_time_declaration

If Brad's propsal is attractive to the group, there are many
additional opportunities to simplify the BNF in a similar
manner.

> Also note --
>
> 1) there should be a semicolon after parameter_declaration
> (see ETF issue #114)

Yes, agreed.

> 2) block_variable_type can be compressed to a single
> production --
>
> block_variable_type ::=
> variable_identifier {dimension}

Also, agreed.


Incorporating Brad's observations, my updated proposal for section
A.2.8 is:

block_item_declaration ::=
{ attribute_instance } block_reg_declaration
| { attribute_instance } event_declaration
| { attribute_instance } block_integer_declaration (Modified)
| { attribute_instance } local_parameter_declaration ";" (Modified; adding ";")
| { attribute_instance } parameter_declaration ";" (Modified; adding ";")
| { attribute_instance } block_real_declaration (Modified)
| { attribute_instance } block_realtime_declaration (Modified)
| { attribute_instance } block_time_declaration (Modified)

block_reg_declaration ::=
"reg" [ "signed" ] [ range ] list_of_block_variable_identifiers ";"

block_real_declaration ::= (New Rule)
"real" list_of_block_real_identifiers ";"

block_realtime_declaration ::= (New Rule)
"realtime" list_of_block_real_identifiers ";"

block_time_declaration ::= (New Rule)
"time" list_of_block_variable_identifiers ";"

list_of_block_variable_identifiers ::=
block_variable_type { "," block_variable_type }

list_of_block_real_identifiers ::= (New Rule)
block_real_type { "," block_real_type }

block_variable_type ::= (Modified)
variable_identifier { dimension }

block_real_type ::= (New Rule)
real_identifier { dimension }

From: Dennis Marsa <drm@xilinx.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/20: A.2.8 should prevent all variabledeclarationassignments
in named blocks
Date: Thu, 21 Nov 2002 10:37:43 -0700

>Category: errata
>Confidential: no
>Originator: Dennis Marsa <drm@xilinx.com>
>Release: 2001b
>Class: TBD
>Description:
Brad Pierce wrote:
>
> I propose that we enhance the standard to remove the
> unnecessary restriction of section 6.2.1 ("Variable
> declaration assignments are only allowed at the module
> level") and allow variable declaration assignments at
> the named block level, too.

Presumably, there was some reason for disallowing variable
declaration assignments in named blocks, tasks & functions.

Anyone familiar with this decision?

Dennis

From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/20: A.2.8 should prevent all variabledeclarationassignments in named blocks
Date: Thu, 21 Nov 2002 13:59:13 -0800

>Category: errata
>Confidential: no
>Originator: "Brad Pierce" <Brad.Pierce@synopsys.com>
>Release: 2001b
>Class: TBD
>Description:
In my opinion, that's not a strong enough reason.
If we removed every feature from Verilog that
could confuse a user, there wouldn't be much left.

-- Brad


From: Shalom.Bresticker@motorola.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/20: A.2.8 should prevent all variable declaration
assignments in named blocks
Date: Fri, 22 Nov 2002 13:16:03 +0200 (IST)

>Category: errata
>Confidential: no
>Originator: Shalom.Bresticker@motorola.com
>Release: 2001b
>Class: TBD
>Description:
> I propose that we enhance the standard to remove the
> unnecessary restriction of section 6.2.1 ("Variable
> declaration assignments are only allowed at the module
> level") and allow variable declaration assignments at
> the named block level, too.

What about in tasks and functions ?

And while on the subject, does anyone see benefit in allowing specparam, task,
and/or function declarations within named blocks?




From: Shalom.Bresticker@motorola.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/20: A.2.8 should prevent all variabledeclarationassignments
in named blocks
Date: Fri, 22 Nov 2002 13:19:06 +0200 (IST)

>Category: errata
>Confidential: no
>Originator: Shalom.Bresticker@motorola.com
>Release: 2001b
>Class: TBD
>Description:
> In my opinion, that's not a strong enough reason.
> If we removed every feature from Verilog that
> could confuse a user, there wouldn't be much left.

Note that this would be a substantive enhancement change, not an errata fix.


From: Michael McNamara <mac@verisity.com>
To: Shalom.Bresticker@motorola.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/20: A.2.8 should prevent all variable declaration
assignments in named blocks
Date: Fri, 22 Nov 2002 09:35:22 -0800

Shalom.Bresticker@motorola.com writes:
> Precedence: bulk
>
> The following reply was made to PR errata/20; it has been noted by GNATS.
>
> From: Shalom.Bresticker@motorola.com
> To: Brad Pierce <Brad.Pierce@synopsys.com>
> Cc: etf-bugs@boyd.com
> Subject: Re: errata/20: A.2.8 should prevent all variable declaration
> assignments in named blocks
> Date: Fri, 22 Nov 2002 13:16:03 +0200 (IST)
>
> >Category: errata
> >Confidential: no
> >Originator: Shalom.Bresticker@motorola.com
> >Release: 2001b
> >Class: TBD
> >Description:
> > I propose that we enhance the standard to remove the
> > unnecessary restriction of section 6.2.1 ("Variable
> > declaration assignments are only allowed at the module
> > level") and allow variable declaration assignments at
> > the named block level, too.
>
> What about in tasks and functions ?
>

I am OK with this change, for both named blocks in procedural code,
and also for named blocks (as well as local declarations) within
tasks and fucntions.

> And while on the subject, does anyone see benefit in allowing
> specparam, task, and/or function declarations within named blocks?

First, this really isn't a related topic, in my opinion.

Declarations inside of named blocks allows an item to come into
existance for a limited time, and then disappear until that block is
again active. This is useful for registers used in a local scope.

Specparams:

Specparams are special variable that was created for asic signoff,
primarily to give delay calculators a limited way to insert corrected
timing information into a simulation. We did allow this beast to
crawl out and become a full fledged parameter, partially based on
Cadence never correctly constraining where its declaration could
occur; and subsequently due to users finding real value in using SDF
to affect more than timing.

I do not see any value to allowing specparams to come into existance,
and then disappear: as when one runs the timing tool, quite likely
few of the named blocks are actually active.

Task/Functions

All I can imagine that it might mean to have a task or function
declared inside a named block is that these tasks and functions can
only be called by code inside the named block? This seems to be of
fairly limited value; imposing a small modicum of method
encapsulation, but likely far less than one would really want.

So I am unconvinced of the need to allow task, function or specparam
declataions inside named blocks.

-mac

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/20: A.2.8 should prevent all variable declarationassignments
in named blocks
Date: Tue, 26 Nov 2002 18:29:44 +0200

Michael McNamara wrote:

> > > I propose that we enhance the standard to remove the
> > > unnecessary restriction of section 6.2.1 ("Variable
> > > declaration assignments are only allowed at the module
> > > level") and allow variable declaration assignments at
> > > the named block level, too.
> >
> > What about in tasks and functions ?
> >
>
> I am OK with this change, for both named blocks in procedural code,
> and also for named blocks (as well as local declarations) within
> tasks and fucntions.

Note that in contrast to named blocks, which are static,
tasks and functions can be automatic as well as static.

I imagine there would be no problem to do the obvious:
In a static task/function, the declaration assignments would be
executed at time 0, together with all the initial statements of the design,
and in automatic tasks/functions, the declaration assignments would
be executed when the task/function is entered.


--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478

"The devil is in the details."




From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/20: A.2.8 should prevent all variable declarationassignments
in named blocks
Date: Wed, 27 Nov 2002 13:12:47 +0200

Note that named blocks, tasks, and functions can define parameters,
but the parameters can not be redefined in instantiations because they
are not instantiated. They can be redefined only by defparams.

The LRM does not note this.


From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Dennis Marsa <drm@xilinx.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/20: A.2.8 should prevent all variable declarationassignments
in named blocks
Date: Wed, 27 Nov 2002 15:43:12 +0200

As Dennis writes, these requirements are "entirely syntactic".
In my opinion, they have to be kept.
Otherwise, you wipe out the basis for the entire BNF.
What is syntax if not context-based ?

The semantic restrictions come into play where the requirements are
based on the value/meaning of the terms. For example, the requirement
in an old-style port list that the port declaration statements inside the
module need to match the module port list.

> > 1) there should be a semicolon after parameter_declaration
> > (see ETF issue #114)

While true, I would not mix #114 into this. This change has to go with the rest of #114.

> > 2) block_variable_type can be compressed to a single
> > production --
> >
> > block_variable_type ::=
> > variable_identifier {dimension}

While true, it might be wiser to leave it in the original form,
to emphasize the similarity to variable_type.

> Incorporating Brad's observations, my updated proposal for section A.2.8 is:

It could be simplified as follows:

> block_item_declaration ::=
> {attribute_instance} reg [signed][range]
> block_variable_type {, block_variable_type} ;
> | {attribute_instance} integer block_variable_type {, block_variable_type} ;
> | {attribute_instance} time block_variable_type {, block_variable_type} ;
> | {attribute_instance} real block_real_type {, block_real_type} ;
> | {attribute_instance} realtime block_real_type {, block_real_type} ;
> | {attribute_instance} event_declaration
> | {attribute_instance} local_parameter_declaration
> | {attribute_instance} parameter_declaration

> block_variable_type ::= variable_identifier {
> dimension }
> block_real_type ::= real_identifier {
> dimension }


From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: mac@verisity.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/20: A.2.8 should prevent all variable declarationassignments
in named blocks
Date: Wed, 27 Nov 2002 15:50:03 +0200

Michael McNamara wrote:

> > And while on the subject, does anyone see benefit in allowing
> > specparam, task, and/or function declarations within named blocks?
>
> First, this really isn't a related topic, in my opinion.
>
> Declarations inside of named blocks allows an item to come into
> existance for a limited time, and then disappear until that block is
> again active. This is useful for registers used in a local scope.

I don't think so.
9.8.3 explicitly states.
"All variables shall be static-that is, a unique location exists for all
variables and leaving or entering blocks shall not affect the values stored in
them. "

Furthermore, they can be referenced from outside the block using hierachical
names.

Anyway, I also do not see the need.


--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478

"The devil is in the details."




From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/20: A.2.8 should prevent all variable declaration
Date: Tue, 10 Dec 2002 19:16:25 -0800

Summary of the four main options for issue #20 --

Preserve the existing semantics --

1) Simplify the BNF, add a semantic check.

2) Expand the BNF in exactly the spirit of the current BNF.

3) Expand the BNF, but compress the productions where possible.

Extend the language --

4) Allow variable declaration assignments in named blocks,
tasks and functions.

-- Brad





From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/20: A.2.8 should prevent all variable declaration
Date: Wed, 11 Dec 2002 11:59:38 +0200

With respect to #4, the last sentence in the first paragraph of 6.2.1 would
have to change.
It would also be necessary to define and add text there explaining what
happens in automatic tasks and functions, and also in 10.2.3 for tasks. In
fact, I think that 10.3 (on functions) should contain a subsection
similar to 10.2.3, which would explain memory usage in functions.

Shalom


> Summary of the four main options for issue #20 --
>
> Preserve the existing semantics --
>
> 1) Simplify the BNF, add a semantic check.
>
> 2) Expand the BNF in exactly the spirit of the current BNF.
>
> 3) Expand the BNF, but compress the productions where possible.
>
> Extend the language --
>
> 4) Allow variable declaration assignments in named blocks,
> tasks and functions.

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478

"The devil is in the details."




From: Shalom.Bresticker@motorola.com
To: drm@xilinx.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/20: PROPOSAL - A.2.8 should prevent all variable declaration
assignments in named blocks
Date: Sat, 14 Dec 2002 19:16:00 +0200 (IST)

I remind everyone that there are several alternate proposals to #20,
so this is not THE proposal to #20.

Further, I cannot accept the addition of the semicolons as part of #20,
because they cannot be separated from the rest of #114.
Adding them without the rest of #114 makes the BNF wrong.
They should be left off here and treated separately in #114.

Shalom



From: Dennis Marsa <drm@xilinx.com>
To: Shalom.Bresticker@motorola.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/20: PROPOSAL - A.2.8 should prevent all variable
declarationassignments in named blocks
Date: Fri, 10 Jan 2003 15:14:59 -0700

Shalom.Bresticker@motorola.com wrote:
>
> ************************************************************
> Shalom's proposal:
>
> 
 > block_item_declaration ::=
 >     {attribute_instance} "reg" ["signed"] [range] list_of_block_variable_identifiers ";"
 >   | {attribute_instance} "integer"  list_of_block_variable_identifiers ";"
 >   | {attribute_instance} "time"     list_of_block_variable_identifiers ";"
 >   | {attribute_instance} "real"     list_of_block_real_identifiers ";"
 >   | {attribute_instance} "realtime" list_of_block_real_identifiers ";"
 >   | {attribute_instance} event_declaration
 >   | {attribute_instance} local_parameter_declaration
 >   | {attribute_instance} parameter_declaration
 > 
 > list_of_block_variable_identifiers ::=
 >     block_variable_type { "," block_variable_type }
 > 
 > list_of_block_real_identifiers ::=
 >     block_real_type     { "," block_real_type }
 > 
 > block_variable_type ::= variable_identifier { dimension }
 > block_real_type ::=     real_identifier     { dimension }
 >


Shalom's alternative proposal is OK with me. The proposal should
also include the references to all the syntax boxes that need
to be updated as well.

> NOTE: I do NOT add the semicolons after the parameter
> declarations. These should be left for issue #114.

Fine.

> By the way, doesn't Dennis's proposal require a definition
> of block_integer_declaration as well?

Yes, it does. Thanks.

Dennis

From: Shalom.Bresticker@motorola.com
To: Dennis Marsa <drm@xilinx.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/20: PROPOSAL - A.2.8 should prevent all variable
declarationassignments in named blocks
Date: Sat, 11 Jan 2003 22:08:50 +0200 (IST)

> Shalom's alternative proposal is OK with me. The proposal should
> also include the references to all the syntax boxes that need
> to be updated as well.

The references are the same as in the original proposal, except that,
as noted, list_of_block_variable_identifiers does not change.


Unformatted


Hosted by Boyd Technology