RE: [sv-ac] P1800 - constant primary as delay in ## : Mantis 1901

From: Eduard Cerny <Eduard.Cerny_at_.....>
Date: Wed Jun 27 2007 - 10:57:54 PDT
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 10:58:24 2007

This archive was generated by hypermail 2.1.8 : Wed Jun 27 2007 - 10:58:36 PDT