Brad, yes, that's exactly what I want to do and meant - a note. I will use your phrase, better than what I had there. Please see attached file. Regards, 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 2:27 PM > To: sv-ac@eda-stds.org > Subject: RE: [sv-ac] P1800 - constant primary as delay in ## > : Mantis 1901 > > 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. > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
This archive was generated by hypermail 2.1.8 : Wed Jun 27 2007 - 12:27:26 PDT