| Number | 209
|
| Category | errata
|
| Synopsis | 12.4, A.9.3: simple, escaped hierarchical_identifiers difference
|
| State | lrmdraft
|
| Class | errata-discuss
|
| Arrival-Date | Nov 26 2002
|
| Originator | Shalom.Bresticker@motorola.com
|
| Release | 2001b: 12.4 (Syntax 12-7), A.9.3, A.9.4
|
| Environment |
|
| Description |
There is an incorrect difference between simple_hierarchical_identifier and escaped_hierarchical_identifier. simple_hierarchical_identifier may end with an escaped_identifier, but that is an identifier without a range index. escaped_hierarchical_identifier may end with an escaped_hierarchical_branch, which allows a range index. (By the way, this is one place where real numbers and even based numbers are explicitly excluded.) hierarchical_identifier ::= simple_hierarchical_identifier | escaped_hierarchical_identifier simple_hierarchical_identifier ::= simple_hierarchical_branch [ .escaped_identifier ] escaped_hierarchical_identifier ::= escaped_hierarchical_branch { .simple_hierarchical_branch | .escaped_hierarchical_branch } simple_hierarchical_branch ::= simple_identifier [ [ unsigned_number ] ] [ { .simple_identifier [ [ unsigned_number ] ] } ] escaped_hierarchical_branch ::= escaped_identifier [ [ unsigned_number ] ] [ { .escaped_identifier [ [ unsigned_number ] ] } ] simple_identifier ::= [ a-zA-Z_ ] { [ a-zA-Z0-9_$ ] } escaped_identifier ::= \ {Any_ASCII_character_except_white_space} white_space |
| Fix |
The original issue is resolved by going back to basic elements and redefining hierarchical_identifier more simply. DELETE: simple_hierarchical_identifier AND escaped_hierarchical_identifier in Syntax 12-7 and A.9.3 simple_hierarchical_branch AND escaped_hierarchical_branch in Syntax 12-7 and A.9.4 REPLACE hierarchical_identifier in Syntax 12-7 and A.9.3 with the following: hierarchical_identifier ::= { identifier [ "[" constant_expression "]" ] "." } identifier That is, a hierarchical_identifier is composed of an identifier optionally preceded by a sequence of zero or more of the following: an identifier, one optional constant (integer) index, and a period. Each identifier part of an hierarchical_identifier can be either a simple_identifier or an escaped_identifier, and there is no need to distinguish between simple and escaped hierarchical_identifiers or simple and escaped hierarchical_branches. This proposal also assumes the changes proposed in issue #257 and also supercedes the proposal in issue #208. |
| Audit-Trail |
From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/209: hierarchical_identifier Date: Tue, 28 Oct 2003 12:28:21 +0200 (IST) Hi, With respect to the disable_statement form in A.6.5 as "disable" hierarchical_block_identifier ";" I wrote in the attached mail below that "in the disable statement, we would write hierarchical_block_identifier with an optional index (only one,not multi-dimensional, and with a constant value)." But now I think we do not need to allow indexing of the block identifier in the disable statement. My reasoning is that we cannot create an array of named blocks. The closest thing to that is an array of scopes created by a generate-loop. But such scopes are not named parallel or sequential blocks. Such scopes can themselves contain named blocks, but that would be a hierarchical level below that of the generated scope array. Comments? Thanks, Shalom On Sun, 2 Feb 2003, Shalom Bresticker wrote: > Date: Sun, 02 Feb 2003 14:51:59 +0200 > From: Shalom Bresticker <Shalom.Bresticker@motorola.com> > To: Dennis Marsa <drm@xilinx.com> > Cc: etf@boyd.com > Subject: Re: hierarchical_identifier > > Dennis Marsa wrote: > > > > > > {identifier ["["unsigned_number"]"] .} identifier > > > > For the purposes of the BNF, I think this is OK. > > > > However, looking at this again, this definition requires that a > > hierarchical_identifier end with an identifier. That is, it cannot > > end with an index operation: a.b[1]. > > > > The current set of rules for hierarchical_identifier seem to allow it > > to end with an index operation. > > You are correct about this. > > However, my analysis of the BNF shows that the only use of hierarchical_identifier as a scope > and not as a net/variable/event is for hierarchical_block_identifier, which itself is only > used in one place, in the disable statement. > > So what I want to do is define hierarchical_identifier like all other identifiers in the > BNF (after we approved #200), > that is, to end with an identifier name, without indexes. Then, where we need to add optional > indexes, we do so according to the need. So in the disable statement, we would write > hierarchical_block_identifier with an optional index (only one,not multi-dimensional, and with > a constant value). > > I think this makes the BNF much more consistent and unambiguous. -- 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 Fix replaced by Shalom.Bresticker@motorola.com on Wed Oct 29 01:07:04 2003 The original issue is resolved by going back to basic elements and redefining hierarchical_identifier more simply. DELETE: simple_hierarchical_identifier AND escaped_hierarchical_identifier in Syntax 12-7 and A.9.3 simple_hierarchical_branch AND escaped_hierarchical_branch in Syntax 12-7 and A.9.4 REPLACE hierarchical_identifier in Syntax 12-7 and A.9.3 with the following: hierarchical_identifier ::= { identifier [ "[" constant_expression "]" ] "." } identifier That is, a hierarchical_identifier is composed of an identifier optionally preceded by a sequence of zero or more of the following: an identifier, one optional constant (integer) index, and a period. Each identifier part of an hierarchical_identifier can be either a simple_identifier or an escaped_identifier, and there is no need to distinguish between simple and escaped hierarchical_identifiers or simple and escaped hierarchical_branches. This proposal also assumes the changes proposed in issue #257 and also supercedes the proposal in issue #208. |
| Unformatted |
|
Hosted by Boyd Technology