| Number | 174
|
| Category | errata
|
| Synopsis | 3.2.1, A.2.2.3 -- delay_value ambiguous
|
| State | lrmdraft
|
| Class | errata-simple
|
| Arrival-Date | Oct 24 2002
|
| Originator | "Brad Pierce" <Brad.Pierce@synopsys.com>
|
| Release | 2001b: 3.2.1 (Syntax 3-1), A.2.2.3
|
| Environment |
|
| Description |
The productions delay_value ::= unsigned_number | ... | ... | mintypmax_expresion are ambiguous because an unsigned_number is also a number, hence also a primary, hence also an expression, hence also a mintypmax_expression. For example, these delay_control are unambiguous # 2'b10 # (2'b10) but this delay_control is ambiguous # 2 To fix the ambiguity, remove the unsigned_number option from the delay_value production. -- Brad |
| Fix |
Sections 3.2.1, A.2.2.3: 11/18/02 - Passed by ETF REPLACE (note '()' are bold): delay3 ::= # delay_value | #( delay_value [ , delay_value [ ,delay_value ] ] ) delay2 ::= # delay_value | #( delay_value [ , delay_value ] ) delay_value ::= unsigned_number | parameter_identifier | specparam_identifier | mintypmax_expression WITH (note '()' are bold): delay3 ::= # delay_value | #( mintypmax_expression [, mintypmax_expression [, mintypmax_expression]]) delay2 ::= # delay_value | #( mintypmax_expression [, mintypmax_expression]) delay_value ::= unsigned_number | real_number | identifier |
| Audit-Trail |
From: Dennis Marsa <drm@xilinx.com> To: Brad Pierce <Brad.Pierce@synopsys.com> Cc: etf-bugs@boyd.com Subject: Re: errata/174: 3.2.1, A.2.2.3 -- delay_value ambiguous Date: Thu, 24 Oct 2002 14:08:20 -0600 >Category: errata >Confidential: no >Originator: Dennis Marsa <drm@xilinx.com> >Release: 2001b >Class: TBD >Description: Brad Pierce wrote: > > Precedence: bulk > > >Number: 174 > >Category: errata > >Originator: "Brad Pierce" <Brad.Pierce@synopsys.com> > >Environment: > >Description: > > The productions > > delay_value ::= unsigned_number > | ... > | ... > | mintypmax_expresion > > are ambiguous because an unsigned_number is also a number, > hence also a primary, hence also an expression, hence also > a mintypmax_expression. > > For example, these delay_control are unambiguous > > # 2'b10 > # (2'b10) > > but this delay_control is ambiguous > > # 2 > > To fix the ambiguity, remove the unsigned_number option > from the delay_value production. I suspect the real problem with the "delay_value" rule is the presence of the mintypmax_expression alternative. This would seem to allow syntax such as the following: wire #1:2:3 a; Howver, this syntax is not accepted by Verilog-XL, NC-Verilog or MTI, which suggests to me that these tools do not implement the delay_value -> mintypmax_expression alternative. One has to use parentheses to get these tools to accept a mintypmax form of delay: wire #(1:2:3) a; It seems that only a simple delay value (single constant or indentifier) can be expressed without using parentheses, while anything more complicated (mintypmax or other expression) requires parentheses. I believe removing the mintypmax_expression alternative reflects the syntax that is accepted by the above tools. The rule for delay_value would become: delay_value ::= unsigned_number // Section A.2.2.3 | parameter_identifier | specparam_identifier while the other rules in section A.2.2.3 that use delay_value would need to be changed to: delay2 ::= '#' delay_value | '#' '(' mintypmax_expression [ ',' mintypmax_expression ] ')' delay3 ::= '#' delay_value | '#' '(' mintypmax_expression [ ',' mintypmax_expression [ ',' mintypmax_expression ] ] ')' The only other rule that uses delay_value is the delay_control rule in Section A.6.5: delay_control ::= '#' delay_value | '#' '(' mintypmax_expression ')' It would not have to be changed. I believe this also removes the ambiguity Brad points out. Dennis From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/174: 3.2.1, A.2.2.3 -- delay_value ambiguous Date: Sun, 27 Oct 2002 16:43:51 +0200 >Category: errata >Confidential: no >Originator: Shalom Bresticker <Shalom.Bresticker@motorola.com> >Release: 2001b >Class: TBD >Description: This is closely related to errata/63. From: Dennis Marsa <drm@xilinx.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/174: 3.2.1, A.2.2.3 -- delay_value ambiguous Date: Mon, 28 Oct 2002 08:40:17 -0700 >Category: errata >Confidential: no >Originator: Dennis Marsa <drm@xilinx.com> >Release: 2001b >Class: TBD >Description: Dennis Marsa wrote: > > I suspect the real problem with the "delay_value" rule > is the presence of the mintypmax_expression alternative. > > This would seem to allow syntax such as the following: > > wire #1:2:3 a; > > Howver, this syntax is not accepted by Verilog-XL, NC-Verilog or > MTI, which suggests to me that these tools do not implement the > delay_value -> mintypmax_expression alternative. > > One has to use parentheses to get these tools to accept > a mintypmax form of delay: > > wire #(1:2:3) a; > > It seems that only a simple delay value (single constant or indentifier) > can be expressed without using parentheses, while anything more > complicated (mintypmax or other expression) requires parentheses. > > I believe removing the mintypmax_expression alternative reflects > the syntax that is accepted by the above tools. The rule for > delay_value would become: > > delay_value ::= unsigned_number // Section A.2.2.3 > | parameter_identifier > | specparam_identifier > > while the other rules in section A.2.2.3 that use delay_value would need > to be changed to: > > delay2 ::= '#' delay_value > | '#' '(' mintypmax_expression [ ',' mintypmax_expression ] ')' > > delay3 ::= '#' delay_value > | '#' '(' mintypmax_expression [ ',' mintypmax_expression [ ',' mintypmax_expression ] ] ')' > > The only other rule that uses delay_value is the delay_control > rule in Section A.6.5: > > delay_control ::= '#' delay_value > | '#' '(' mintypmax_expression ')' > > It would not have to be changed. > > I believe this also removes the ambiguity Brad points out. > > Dennis If acceptable, the above suggested BNF changes would need to be reflected in Syntax box 3-1 in Section 3.2.1 as well. Dennis From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Dennis Marsa <drm@xilinx.com> Cc: etf-bugs@boyd.com Subject: Re: errata/174: 3.2.1, A.2.2.3 -- delay_value ambiguous Date: Wed, 13 Nov 2002 18:28:51 +0200 >Category: errata >Confidential: no >Originator: Shalom Bresticker <Shalom.Bresticker@motorola.com> >Release: 2001b >Class: TBD >Description: I think there may be a problem with the proposed solution. I have found that Verilog-XL does accept "#q" where 'q' is a variable identifier, and not just a parameter identifier. Shalom Dennis Marsa wrote: > I suspect the real problem with the "delay_value" rule > is the presence of the mintypmax_expression alternative. > > This would seem to allow syntax such as the following: > > wire #1:2:3 a; > > Howver, this syntax is not accepted by Verilog-XL, NC-Verilog or > MTI, which suggests to me that these tools do not implement the > delay_value -> mintypmax_expression alternative. > > One has to use parentheses to get these tools to accept > a mintypmax form of delay: > > wire #(1:2:3) a; > > It seems that only a simple delay value (single constant or indentifier) > can be expressed without using parentheses, while anything more > complicated (mintypmax or other expression) requires parentheses. > > I believe removing the mintypmax_expression alternative reflects > the syntax that is accepted by the above tools. The rule for > delay_value would become: > > delay_value ::= unsigned_number // Section A.2.2.3 > | parameter_identifier > | specparam_identifier > > while the other rules in section A.2.2.3 that use delay_value would need > to be changed to: > > delay2 ::= '#' delay_value > | '#' '(' mintypmax_expression [ ',' mintypmax_expression ] ')' > > delay3 ::= '#' delay_value > | '#' '(' mintypmax_expression [ ',' mintypmax_expression [ ',' mintypmax_expression ] ] ')' > > The only other rule that uses delay_value is the delay_control > rule in Section A.6.5: > > delay_control ::= '#' delay_value > | '#' '(' mintypmax_expression ')' > > It would not have to be changed. > > I believe this also removes the ambiguity Brad points out. > > Dennis -- 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: Dennis Marsa <drm@xilinx.com> To: Shalom Bresticker <Shalom.Bresticker@motorola.com> Cc: etf-bugs@boyd.com Subject: Re: errata/174: 3.2.1, A.2.2.3 -- delay_value ambiguous Date: Wed, 13 Nov 2002 09:54:32 -0700 >Category: errata >Confidential: no >Originator: Dennis Marsa <drm@xilinx.com> >Release: 2001b >Class: TBD >Description: Shalom Bresticker wrote: > > I think there may be a problem with the proposed solution. > I have found that Verilog-XL does accept "#q" where 'q' > is a variable identifier, and not just a parameter identifier. Yes, I see. Perhaps this could be addressed by simplifying the BNF rule for delay_value to: delay_value ::= unsigned_number // Section A.2.2.3 | identifier Dennis From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/174: 3.2.1, A.2.2.3 -- delay_value ambiguous Date: Sun, 24 Nov 2002 13:03:15 +0200 In the last ETF meeting, we voted to change delay_value to: delay_value ::= unsigned_number | real_number | identifier On further thought, I do not like the generic "identifier" there. It does not say what type of identifier. There are many types and this is important information. The generic term "identifier" is used in the BNF only to define in A.9.1 and A.9.3 various types of identifiers, such as attr_name ::= identifier block_identifier ::= identifier etc. The one exception is module_path_primary in A.8.4. Therefore, I propose to reconsider this issue and change delay_value to: delay_value ::= unsigned_number | real_number | parameter_identifier | specparam_identifier | net_identifier | variable_identifier |
| Unformatted |
|
Hosted by Boyd Technology