Ed, Already today, in the 2005 standard, a mintypmax expression such as ( e1 : e2 : e3 ) is allowed in a cycle_delay_range, but it must be arbitrarily enclosed in an additional set of parens. ## ( ( e1 : e2 : e3 ) ) When no tool switches have been set, I would expect this to have the same meaning as using the 'typ' value in isolation ## ( e2 ) I personally think the current LRM is unVerilogish to require the extra set of parens, and to not also allow ## ( e1 : e2 : e3 ) If you want to continue that policy or to completely disallow mintypmax expressions in cycle_delay_ranges, then I think that restriction is best dealt with via a footnote, instead of via complicated BNF productions. For example, to prohibit mintypmax expressions here altogether, even with the extra pair of parens as allowed by the 2005 BNF, the footnote on cycle_delay_range in the 2008 BNF could say something like -- "In a cycle_delay_range, it shall be illegal for a constant_primary to contain a constant_mintypmax_expression that is not also a constant_expression." -- Brad -----Original Message----- From: Eduard Cerny [mailto:edcerny@synopsys.COM] Sent: Wednesday, June 27, 2007 10:58 AM To: Brad Pierce; sv-ac@eda-stds.org Subject: RE: [sv-ac] P1800 - constant primary as delay in ## : Mantis 1901 Brad, yes, but in cycle delay or repetitions, only constant_expression : constant_expression is allowed, not constant_expression : constant_expression : constant_expression How does one deal with that? This is what I could not see how it was resolved in the discussion you pointed me to. ed > -----Original Message----- > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of > Brad Pierce > Sent: Wednesday, June 27, 2007 1:53 PM > To: sv-ac@eda-stds.org > Subject: Re: [sv-ac] P1800 - constant primary as delay in ## > : Mantis 1901 > > Ed, > > In the BNF, a degenerate kind of constant_mintypmax_expression is a > constant_expression. > > constant_mintypmax_expression ::= > constant_expression > | constant_expression : constant_expression : > constant_expression > > So > > constant_primary > ::= ( constant_mintypmax_expression ) > ::= ( constant_expression ) > > This tradition can already be found in the earliest versions of the > Verilog BNF. See, for example, > > http://www.verilog.com/VerilogBNF.html#REF153 > > http://www.verilog.com/VerilogBNF.html#REF147 > > > By the way, the constant_* sublanguage in the BNF was only added by > Verilog-2001. As noted in > > http://www.eda-stds.org/sv-ac/hm/2559.html > > I wouldn't have enforced the semantic restrictions of constantness via > a BNF sublanguage, but would have left constant_expression as it was > in > > http://www.verilog.com/VerilogBNF.html#REF146 > > -- Brad > > -----Original Message----- > From: Eduard Cerny [mailto:edcerny@synopsys.COM] > Sent: Wednesday, June 27, 2007 10:37 AM > To: Brad Pierce; sv-ac@eda-stds.org > Subject: RE: [sv-ac] P1800 - constant primary as delay in ## : Mantis > 1901 > > Brad, > > yes, for constant_expression this will not do , but then I think it > has to be > > cycle_delay_range ::= > ## constant_primary > | ## ( constant_expression ) > | ## [ cycle_delay_const_range_expression ] > > because constant_primary does not allow expression. > > constant_mintypmax_expression does not make much sense in the range. > Somehow from the discussion you pointed me to I could not see what > exactly the conclusion was. Should a note be added that this form of > expression is excluded from ## and the repetitions? > > Thanks, > ed > > > -----Original Message----- > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of > > Brad Pierce > > Sent: Wednesday, June 27, 2007 1:05 PM > > To: sv-ac@eda-stds.org > > Subject: Re: [sv-ac] P1800 - constant primary as delay in ## > > : Mantis 1901 > > > > Ed, > > > > It couldn't be > > > > ## constant_expression > > > > After the ## only a primary could be used, it couldn't for > example, be > > > > ## P + Q > > > > without any parens. For a related example of this problem, see > > > > http://www.eda-stds.org/svdb/view.php?id=1480 > > > > I don't understand why a mintypmax expression would be specially > > disallowed here, since it is already allowed today with an > extra pair > > of parens > > > > ## ((e1 : e2 : e3)) > > > > via > > > > ## ( constant_expression ) > > ::= ## ( constant_primary ) > > ::= ## ( ( constant_mintypmax_expression ) ) ::= ## ( ( > e1 : e2 : > > e3 ) ) > > > > Requiring the extra pair of parens seems arbitrary to me. See also > > > > http://www.boyd.com/1364_btf/report/full_pr/608.html > > > > which is now Mantis 1054. > > > > -- Brad > > > > -----Original Message----- > > From: Eduard Cerny [mailto:edcerny@synopsys.COM] > > Sent: Wednesday, June 27, 2007 9:41 AM > > To: Eduard Cerny; Brad Pierce; sv-ac@eda-stds.org > > Subject: RE: [sv-ac] P1800 - constant primary as delay in > ## : Mantis > > 1901 > > > > > > Brad, however, constant_minTypmax_expression also allows 3 > constants > > which are not allowed in the delay. Perhaps it might be better to > > state it as: > > > > cycle_delay_range ::= > > ## constant_expression > > | ## ( constant_expression ) > > | ## [ cycle_delay_const_range_expression ] > > > > Would you agree? > > > > Thanks, > > ed > > > > > > > -----Original Message----- > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > Behalf Of > > > Eduard Cerny > > > Sent: Tuesday, June 26, 2007 9:11 PM > > > To: Brad Pierce; sv-ac@eda-stds.org > > > Subject: RE: [sv-ac] P1800 - constant primary as delay in ## > > > : Mantis 1901 > > > > > > In that case yes, it can be easily changed. > > > ed > > > > > > > > > > -----Original Message----- > > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > > Behalf Of > > > > Brad Pierce > > > > Sent: Tuesday, June 26, 2007 5:36 PM > > > > To: sv-ac@eda-stds.org > > > > Subject: RE: [sv-ac] P1800 - constant primary as delay in ## > > > > : Mantis 1901 > > > > > > > > The cycle_delay production that is used in > > procedural_timing_control > > > > > > and clocking_drive is independent of the cycle_delay_range > > > production used > > > > in sequence_expr. > > > > > > > > -- Brad > > > > > > > > -----Original Message----- > > > > From: Eduard Cerny [mailto:edcerny@synopsys.COM] > > > > Sent: Tuesday, June 26, 2007 2:07 PM > > > > To: Brad Pierce; sv-ac@eda-stds.org > > > > Subject: RE: [sv-ac] P1800 - constant primary as delay in > > > ## : Mantis > > > > 1901 > > > > > > > > Brad, > > > > > > > > I think that ## can also be a cycle delay in procedural > > > code and there > > > > it is not restricted to a constant primary. This is why > I did not > > > > change the syntax but added a constraint. Is that a good > > reason or I > > > > > > missed something? > > > > > > > > Thanks, > > > > > > > > ed > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > > > Behalf Of > > > > > Brad Pierce > > > > > Sent: Tuesday, June 26, 2007 4:36 PM > > > > > To: sv-ac@eda-stds.org > > > > > Subject: Re: [sv-ac] P1800 - constant primary as delay in ## > > > > > : Mantis 1901 > > > > > > > > > > Ed, > > > > > > > > > > Why not just allow any constant_primary after ##? > > > > > > > > > > Then the rule for cycle_delay_range could be simplified to > > > > > > > > > > cycle_delay_range ::= > > > > > ## constant_primary > > > > > | ## [ cycle_delay_const_range_expression ] > > > > > > > > > > plus a footnote that in a cycle_delay_range it shall be > > > > illegal for a > > > > > constant_primary not to evaluate to a nonnegative integer? > > > > > > > > > > Recall that > > > > > > > > > > constant_primary ::= ( constant_mintypmax_expression ) > > > > > ::= ( constant_expression ) > > > > > > > > > > -- Brad > > > > > > > > > > -----Original Message----- > > > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > > > Behalf Of > > > > > Eduard Cerny > > > > > Sent: Tuesday, June 26, 2007 11:31 AM > > > > > To: sv-ac@eda-stds.org > > > > > Subject: [sv-ac] P1800 - constant primary as delay in ## : > > > > Mantis 1901 > > > > > > > > > > Hi, > > > > > > > > > > I have created a new mantis entry, 1901, and also attached > > > > a proposal. > > > > > > > > > > Best regards, > > > > > ed > > > > > > > > > > -- > > > > > This message has been scanned for viruses and dangerous > > > content by > > > > > MailScanner, and is believed to be clean. > > > > > > > > > > > > > > > -- > > > > > This message has been scanned for viruses and dangerous > > > content by > > > > > MailScanner, and is believed to be clean. > > > > > > > > > > > > > > > > > > > > > > > -- > > > > This message has been scanned for viruses and dangerous > > content by > > > > MailScanner, and is believed to be clean. > > > > > > > > > > > > > > > > > > -- > > > This message has been scanned for viruses and dangerous > content by > > > MailScanner, and is believed to be clean. > > > > > > > > > > > > > -- > > This message has been scanned for viruses and dangerous content by > > MailScanner, and is believed to be clean. > > > > > > > > -- > This message has been scanned for viruses and dangerous content by > MailScanner, and is believed to be clean. > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jun 27 11:52:06 2007
This archive was generated by hypermail 2.1.8 : Wed Jun 27 2007 - 11:52:26 PDT