ISSUE 123

Number 123
Category errata
Synopsis A.8.4, A.8.5: identifier and indexing syntax
State lrmdraft
Class errata-discuss
Arrival-DateSep 23 2002
Originator Karen Pieper <Karen.Pieper@synopsys.com>
Release 2001b: A.8.4, A.8.5, 4.3 (Syntax 4-2), Syntaxes 9-1, 9-2, 9-3
Environment
Description
An issue in the grammar.

K

>X-Authentication-Warning: max.boyd.com: majordomo set sender to
>owner-etf@boyd.com using -f
>Date: Mon, 09 Sep 2002 16:11:55 -0600
>From: Dennis Marsa <drm@xilinx.com>
>X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
>X-Accept-Language: en
>To: etf@boyd.com
>Subject: identifier and indexing syntax
>X-BigFish: v
>Sender: owner-etf@boyd.com
>
>Precedence: bulk
>
>Karen Pieper wrote:
> >
> > Minutes of the 9/9/02 Errata task force meeting:
> >
> > Dennis to look into Issue 31 to see if there are any other
> issues in
> > the area of the Errata.
>
>I think Issue 31 is fine by itself as is.
>
>
>
>
>The issue I tried to raise during discussion of Issue 31 has to do with
>the syntax rules for "primary" and "hierarchical_identifier".
>
>The rule for "primary" in section A.8.4 includes 4 alternatives that
>reference the rule "hierarchical_identifier". In 3 of these alternatives,
>the syntax for the various indexing operations are defined.
>
>However, the syntax rules for "hierarchical_identifier" also contain
>syntax for indexing operations.
>
>Presumably, the indexing syntax in "primary" is describing array-indexing,
>bit-selects and part-select syntax, while the indexing syntax in
>hierarchical_identifier is describing scope indexing.
>
>The issue I'm trying to point out is, this set of BNF rules are
>ambiguous.
>
>Consider the following expression:
>
> a.b[1]
>
>Is this expression derived (top-down) by the following sequence:
>
> expression
>-> primary
>-> hierarchical_identifier "[" expression "]"
>-> hierarchical_identifier "[" "1" "]"
>-> simple_hierarchical_identifier "[" "1" "]"
>-> simple_hierarchical_branch "[" "1" "]"
>-> simple_identifier "." simple_identifier "[" "1" "]"
>-> "a" "." "b" "[" "1" "]"
>
>or by the following sequence:
>
> expression
>-> primary
>-> hierarchical_identifier
>-> simple_hierarchical_identifier
>-> simple_hierarchical_branch
>-> simple_identifier "." simple_identifier "[" unsigned_number "]"
>-> "a" "." "b" "[" "1" "]"
>
>Both sequences are possible by the rules as defined. There is at
>least one other possible sequence:
>
> expression
>-> primary
>-> hierarchical_identifier "[" range_expression "]"
>-> hierarchical_identifier "[" expression "]"
>-> hierarchical_identifier "[" "1" "]"
>-> simple_hierarchical_identifier "[" "1" "]"
>-> simple_hierarchical_branch "[" "1" "]"
>-> simple_identifier "." simple_identifier "[" "1" "]"
>-> "a" "." "b" "[" "1" "]"
>
>Deciding which sequence to apply requires knowing the exact type of
>"a" and "b", which, in general, is not known until elaboration time.
>
>Dennis Marsa
>Xilinx, Inc.


Fix 
 
  
The following fix incorporates and supercedes issue #181. 
 
In "primary" BNF in Syntax 4-2 and in A.8.4, 
CHANGE the following 4 lines from: 
 
| hierarchical_identifier 
| hierarchical_identifier [ expression ] { [ expression ] } 
| hierarchical_identifier [ expression ] { [ expression ] } [ range_expression ] 
| hierarchical_identifier [ range_expression ] 
 
TO: 
 
| hierarchical_identifier [ {"["expression"]"} "["range_expression"]" ] 
 
 
The following fix partly supercedes issue #53. 
 
In "net_lvalue" BNF in Syntax 9-3 and in A.8.5, 
CHANGE the following 4 lines from: 
 
| hierarchical_net_identifier 
| hierarchical_net_identifier [ constant_expression ] { [ constant_expression ] } 
| hierarchical_net_identifier [ constant_expression ] { [ constant_expression ] }[ constant_range_expression ] 
| hierarchical_net_identifier [ constant_range_expression ] 
 
TO: 
 
| hierarchical_net_identifier [ {"["constant_expression"]"} 
"["constant_range_expression"]" ] 
 
 
The following fix partly supercedes #53. 
 
In "variable_lvalue" BNF in Syntaxes 9-1, 9-2, 9-3, and in
A.8.5, 
CHANGE the following 4 lines from: 
 
| hierarchical_variable_identifier 
| hierarchical_variable_identifier [ expression ] { [ expression ] } 
| hierarchical_variable_identifier [ expression ] { [ expression ] }[ range_expression ] 
| hierarchical_variable_identifier [ range_expression ] 
 
TO: 
 
| hierarchical_variable_identifier [ {"["expression"]"} "["range_expression"]" ]

Audit-Trail

From: Shalom.Bresticker@motorola.com
To: etf-bugs@boyd.com
Cc: dan.jacobi@intel.com
Subject: Re: errata/123: Fwd: identifier and indexing syntax
Date: Fri, 10 Jan 2003 12:31:01 +0200 (IST)

Would the following help for 'primary'?

Replace the existing alternatives of hierarchical_identifier
with the following:

hierarchical_identifier [ { '[' expression ']' } '[' range_expression ']' ]

In the case of a.b[1], you would still not know, without checking the
declaration of b, whether it refers to word 1 of the array b or bit 1 of the
vector b, but there is no way to get around that.

But I think it makes the sequence unambiguous.

Shalom


> >The issue I tried to raise during discussion of Issue 31 has to do with
> >the syntax rules for "primary" and "hierarchical_identifier".
> >
> >The rule for "primary" in section A.8.4 includes 4 alternatives that
> >reference the rule "hierarchical_identifier". In 3 of these alternatives,
> >the syntax for the various indexing operations are defined.
> >
> >However, the syntax rules for "hierarchical_identifier" also contain
> >syntax for indexing operations.
> >
> >Presumably, the indexing syntax in "primary" is describing array-indexing,
> >bit-selects and part-select syntax, while the indexing syntax in
> >hierarchical_identifier is describing scope indexing.
> >
> >The issue I'm trying to point out is, this set of BNF rules are
> >ambiguous.
> >
> >Consider the following expression:
> >
> > a.b[1]
> >
> >Is this expression derived (top-down) by the following sequence:
> >
> > expression
> >-> primary
> >-> hierarchical_identifier "[" expression "]"
> >-> hierarchical_identifier "[" "1" "]"
> >-> simple_hierarchical_identifier "[" "1" "]"
> >-> simple_hierarchical_branch "[" "1" "]"
> >-> simple_identifier "." simple_identifier "[" "1" "]"
> >-> "a" "." "b" "[" "1" "]"
> >
> >or by the following sequence:
> >
> > expression
> >-> primary
> >-> hierarchical_identifier
> >-> simple_hierarchical_identifier
> >-> simple_hierarchical_branch
> >-> simple_identifier "." simple_identifier "[" unsigned_number "]"
> >-> "a" "." "b" "[" "1" "]"
> >
> >Both sequences are possible by the rules as defined. There is at
> >least one other possible sequence:
> >
> > expression
> >-> primary
> >-> hierarchical_identifier "[" range_expression "]"
> >-> hierarchical_identifier "[" expression "]"
> >-> hierarchical_identifier "[" "1" "]"
> >-> simple_hierarchical_identifier "[" "1" "]"
> >-> simple_hierarchical_branch "[" "1" "]"
> >-> simple_identifier "." simple_identifier "[" "1" "]"
> >-> "a" "." "b" "[" "1" "]"
> >
> >Deciding which sequence to apply requires knowing the exact type of
> >"a" and "b", which, in general, is not known until elaboration time.
> >
> >Dennis Marsa


From: Shalom.Bresticker@motorola.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/123: PROPOSAL - Fwd: identifier and indexing syntax
Date: Tue, 28 Jan 2003 11:02:18 +0200 (IST)

Somebody re-edited my proposal wrongly.
I am very careful about editing other people's words,
so that such things should not occur.

I re-send the correct proposal, with a few additional explanations.


On Sat, 25 Jan 2003, Shalom Bresticker wrote:

#123 started as a problem with the production of the non-terminal "primary" in
the BNF. Specifically with the 4 lines describing hierarchical_identifiers.
#181 combines those 4 lines into 1 line, but does not solve the problem of #123.
The following proposal builds on #181, but further modifies it to solve as much
as possible the problem of #123, also.

> Replace the existing alternatives of
> hierarchical_identifier in the primary production
> with the following:
>
> hierarchical_identifier [ { '[' expression ']' } '[' range_expression ']' ]
>

Then I said that what is good for "primary" is also good for "net_lvalue" and
"variable_lvalue", which we modified in #53 the same way we did to "primary" in
#181.

> ************************************************************
>
> Shalom's addition (2003-01-23):
>
> If this change is accepted,
> then presumably the same change should be made to
> net_lvalue and variable_lvalue, modifiying the fixes to
> issues #53 and #181:
>
> CHANGE from (after the fixes in #53):
>
> net_lvalue ::=
> hierarchical_net_identifier {'['constant_expression']'}
> ['['constant_range_expression']']
> | '{' net_lvalue { ',' net_lvalue } '}'
>
> variable_lvalue ::=
> hierarchical_variable_identifier {'['expression']'}
> ['['range_expression']']
> | '{' variable_lvalue { ',' variable_lvalue } '}'
>
>
> TO:
>
>
> net_lvalue ::=
> hierarchical_net_identifier [{'['constant_expression']'}
> '['constant_range_expression']']
> | '{' net_lvalue { ',' net_lvalue } '}'
>
> variable_lvalue ::=
> hierarchical_variable_identifier [{'['expression']'}
> '['range_expression']']
> | '{' variable_lvalue { ',' variable_lvalue } '}'
>
> ************************************************************
> http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&pr=123
>



From: Dennis Marsa <drm@xilinx.com>
To: Shalom.Bresticker@motorola.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/123: PROPOSAL - Fwd: identifier and indexing syntax
Date: Fri, 31 Jan 2003 08:57:33 -0700

Shalom.Bresticker@motorola.com wrote:
>
> On Sat, 25 Jan 2003, Shalom Bresticker wrote:
>
> #123 started as a problem with the production of the non-terminal "primary" in
> the BNF. Specifically with the 4 lines describing hierarchical_identifiers.
> #181 combines those 4 lines into 1 line, but does not solve the problem of #123.
> The following proposal builds on #181, but further modifies it to solve as much
> as possible the problem of #123, also.

The proposal for this errata does not address the issue I tried to describe
when this issue was opened.

First, in #181, we reduced the 4 alternatives involving hierarchical_identifier down
to the following one alternative for the "primary" rule:

hierarchical_identifier { '[' expression ']' } [ '[' range_expression ']' ]
*
> > Replace the existing alternatives of
> > hierarchical_identifier in the primary production
> > with the following:
> >
> > hierarchical_identifier [ { '[' expression ']' } '[' range_expression ']' ]
*
This just moves the opening [ earlier in the production. I don't think this changes
anything, so don't see any benefit in making the above change. Note that it also
places a {} group within a [] group. Haven't we undone several occurrences of that
in recent erratas since it is redundant?


The original issue I was trying to get at with this errata was that the definition of
"hierarchical_identifier" itself also includes syntax for indexing (presumably to
describe indexing into generated for-loops), as well as the above alternative of
"primary", which leads to an ambiguity in the BNF. So, if trying to derive a "primary"
from a.b[1], is the [1] consumed as part of applying "hierarchical_identifier", or is
it consumes as an optional index that follows "hierarchical_identifier" in the
alternative of "primary" shown above?

In the time since this issue was opened, I have pretty much concluded that there
isn't much that can be done to remove this ambiguity from the BNF, so I no longer
think we should attempt it.


Independently however, I believe the syntax for "hierarchical_identifier" can be
vastly simplified as Shalom indicated in:

http://boydtechinc.com/etf/archive/etf_2003/0943.html

However this should be addressed as a separate issue.

> Then I said that what is good for "primary" is also good for "net_lvalue" and
> "variable_lvalue", which we modified in #53 the same way we did to "primary" in
> #181.

These following changes to net_lvalue and variable_lvalue also simply reposition the
opening [ making all the indexing syntax optional. But, as it is already optional,
so this change has no real effect.


I think we should close this issue and take no action.

Dennis


> > ************************************************************
> >
> > Shalom's addition (2003-01-23):
> >
> > If this change is accepted,
> > then presumably the same change should be made to
> > net_lvalue and variable_lvalue, modifiying the fixes to
> > issues #53 and #181:
> >
> > CHANGE from (after the fixes in #53):
> >
> > net_lvalue ::=
> > hierarchical_net_identifier {'['constant_expression']'}
> > ['['constant_range_expression']']
> > | '{' net_lvalue { ',' net_lvalue } '}'
> >
> > variable_lvalue ::=
> > hierarchical_variable_identifier {'['expression']'}
> > ['['range_expression']']
> > | '{' variable_lvalue { ',' variable_lvalue } '}'
> >
> >
> > TO:
> >
> >
> > net_lvalue ::=
> > hierarchical_net_identifier [{'['constant_expression']'}
> > '['constant_range_expression']']
> > | '{' net_lvalue { ',' net_lvalue } '}'
> >
> > variable_lvalue ::=
> > hierarchical_variable_identifier [{'['expression']'}
> > '['range_expression']']
> > | '{' variable_lvalue { ',' variable_lvalue } '}'
> >
> > ************************************************************
> > http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&pr=123
> >
>
>

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Dennis Marsa <drm@xilinx.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/123: PROPOSAL - Fwd: identifier and indexing syntax
Date: Sun, 02 Feb 2003 14:39:12 +0200

Dennis,

I think what you write is not completely accurate.

If you compare the "old" (after #181)

> hierarchical_identifier { '[' expression ']' } [ '[' range_expression ']' ]

and my proposed "new"

> hierarchical_identifier [ { '[' expression ']' } '[' range_expression ']' ]

then you say

> This just moves the opening [ earlier in the production. I don't think this changes
> anything, so don't see any benefit in making the above change.

But it does change something.
If for example, you have a.b[1],
then in the "old", you have an ambiguity: is it "hierarchical_identifier expression" or
"hierarchical_identifier range_expression" ?
Because both "expression" and "range_expression" are optional AND INDEPENDENT OF EACH
OTHER.

Whereas in the "new", it is definitely a range_expression.

In other words, if you have one or more indices after the identifier, then in the "old",
the last can be either
an expression or a range_expression, whereas in the "new", it is always a range_expression.

So this removes the syntactical ambiguity, at least partly.
But see below for more before you raise your hand to object.

> Note that it also
> places a {} group within a [] group. Haven't we undone several occurrences of that
> in recent erratas since it is redundant?

Again, the outer [] enclose the range_expression, which is not enclosed in {}.

> The original issue I was trying to get at with this errata was that the definition of
> "hierarchical_identifier" itself also includes syntax for indexing (presumably to
> describe indexing into generated for-loops), as well as the above alternative of
> "primary", which leads to an ambiguity in the BNF. So, if trying to derive a "primary"
> from a.b[1], is the [1] consumed as part of applying "hierarchical_identifier", or is
> it consumes as an optional index that follows "hierarchical_identifier" in the
> alternative of "primary" shown above?

Now there is one more possible syntactic ambiguity.
That is, as you say, that '"hierarchical_identifier" itself also includes syntax for
indexing'
(although it could be for module instance arrays as well as named generate scopes).
But in fact, that would not be legal, because if "a.b[1]" is a scope, then it is not legal
as a primary.
A primary needs to be some sort of a net/variable, so "b" must be a net/variable
identifier,
not a scope identifier.

As I wrote earlier, I believe my proposed change reduces the ambiguity even if it does not
solve it entirely.

Shalom


>
>
> In the time since this issue was opened, I have pretty much concluded that there
> isn't much that can be done to remove this ambiguity from the BNF, so I no longer
> think we should attempt it.
>
> Independently however, I believe the syntax for "hierarchical_identifier" can be
> vastly simplified as Shalom indicated in:
>
> http://boydtechinc.com/etf/archive/etf_2003/0943.html
>
> However this should be addressed as a separate issue.
>
> > Then I said that what is good for "primary" is also good for "net_lvalue" and
> > "variable_lvalue", which we modified in #53 the same way we did to "primary" in
> > #181.
>
> These following changes to net_lvalue and variable_lvalue also simply reposition the
> opening [ making all the indexing syntax optional. But, as it is already optional,
> so this change has no real effect.
>
> I think we should close this issue and take no action.
>
> Dennis
>
> > > ************************************************************
> > >
> > > Shalom's addition (2003-01-23):
> > >
> > > If this change is accepted,
> > > then presumably the same change should be made to
> > > net_lvalue and variable_lvalue, modifiying the fixes to
> > > issues #53 and #181:
> > >
> > > CHANGE from (after the fixes in #53):
> > >
> > > net_lvalue ::=
> > > hierarchical_net_identifier {'['constant_expression']'}
> > > ['['constant_range_expression']']
> > > | '{' net_lvalue { ',' net_lvalue } '}'
> > >
> > > variable_lvalue ::=
> > > hierarchical_variable_identifier {'['expression']'}
> > > ['['range_expression']']
> > > | '{' variable_lvalue { ',' variable_lvalue } '}'
> > >
> > >
> > > TO:
> > >
> > >
> > > net_lvalue ::=
> > > hierarchical_net_identifier [{'['constant_expression']'}
> > > '['constant_range_expression']']
> > > | '{' net_lvalue { ',' net_lvalue } '}'
> > >
> > > variable_lvalue ::=
> > > hierarchical_variable_identifier [{'['expression']'}
> > > '['range_expression']']
> > > | '{' variable_lvalue { ',' variable_lvalue } '}'
> > >
> > > ************************************************************
> > > http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&pr=123
> > >
> >
> >

--
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




From: Dennis Marsa <drm@xilinx.com>
To: Shalom Bresticker <Shalom.Bresticker@motorola.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/123: PROPOSAL - Fwd: identifier and indexing syntax
Date: Tue, 04 Feb 2003 14:49:34 -0700

Shalom Bresticker wrote:
>
> Dennis,
>
> I think what you write is not completely accurate.
>
> If you compare the "old" (after #181)
>
> > hierarchical_identifier { '[' expression ']' } [ '[' range_expression ']' ]
>
> and my proposed "new"
>
> > hierarchical_identifier [ { '[' expression ']' } '[' range_expression ']' ]
>
> then you say
>
> > This just moves the opening [ earlier in the production. I don't think this changes
> > anything, so don't see any benefit in making the above change.
>
> But it does change something.
> If for example, you have a.b[1],
> then in the "old", you have an ambiguity: is it "hierarchical_identifier expression" or
> "hierarchical_identifier range_expression" ?
> Because both "expression" and "range_expression" are optional AND INDEPENDENT OF EACH
> OTHER.
>
> Whereas in the "new", it is definitely a range_expression.

Ah, I see your point. Thanks for setting me straight. I withdraw my objection.

> Now there is one more possible syntactic ambiguity.
> That is, as you say, that '"hierarchical_identifier" itself also includes syntax for
> indexing'
> (although it could be for module instance arrays as well as named generate scopes).
> But in fact, that would not be legal, because if "a.b[1]" is a scope, then it is not legal
> as a primary.
> A primary needs to be some sort of a net/variable, so "b" must be a net/variable
> identifier,
> not a scope identifier.
>
> As I wrote earlier, I believe my proposed change reduces the ambiguity even if it does not
> solve it entirely.

Agreed, and I think the discussion:

http://boydtechinc.com/etf/archive/etf_2003/0943.html

could ultimately result in resolving the remaining ambiguity.

Thanks,

Dennis

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Stefen Boyd <stefen@boyd.com>, etf-bugs@boyd.com
Cc:
Subject: Re: errata/123: PROPOSAL - identifier and indexing syntax
Date: Tue, 25 Feb 2003 14:38:03 +0200

Stefen,


Please replace FIX field of 123 with the following,
which correctly reflects what was passed by ETF: 

 
 The following fix incorporates and supercedes issue #181.
 
 In "primary" BNF in Syntax 4-2 and in A.8.4,
 CHANGE the following 4 lines from:
 
 | hierarchical_identifier
 | hierarchical_identifier [ expression ] { [ expression ] }
 | hierarchical_identifier [ expression ] { [ expression ] }[ range_expression ]
 | hierarchical_identifier [ range_expression ]
 
 TO:
 
 | hierarchical_identifier [ {"["expression"]"} "["range_expression"]" ]
 
 
 The following fix partly supercedes issue #53.
 
 In "net_lvalue" BNF in Syntax 9-3 and in A.8.5,
 CHANGE the following 4 lines from:
 
 | hierarchical_net_identifier
 | hierarchical_net_identifier [ constant_expression ] { [ constant_expression ] }
 | hierarchical_net_identifier [ constant_expression ] { [ constant_expression ] }[
 constant_range_expression ]
 | hierarchical_net_identifier [ constant_range_expression ]
 
 TO:
 
 | hierarchical_net_identifier [ {"["constant_expression"]"}
 "["constant_range_expression"]" ]
 
 
 The following fix partly supercedes #53.
 
 In "variable_lvalue" BNF in Syntaxes 9-1, 9-2, 9-3, and in A.8.5,
 CHANGE the following 4 lines from:
 
 | hierarchical_variable_identifier
 | hierarchical_variable_identifier [ expression ] { [ expression ] }
 | hierarchical_variable_identifier [ expression ] { [ expression ] }[
 range_expression ]
 | hierarchical_variable_identifier [ range_expression ]
 
 TO:
 
 | hierarchical_variable_identifier [ {"["expression"]"} "["range_expression"]" ]


Unformatted


Hosted by Boyd Technology