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

I think it is just lack of undestanding of the complete language, which
is understandable given its complexity. I don't think people realize
that by not reusing existing semantics, they are making the language
more complex, even if they don't see an immediate usefulness of the
feature.

Dave
 

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Bresticker, Shalom
Sent: Thursday, June 28, 2007 2:53 AM
To: sv-ac@server.eda-stds.org
Subject: RE: [sv-ac] P1800 - constant primary as delay in ## : Mantis
1901

I do not understand the justification for not allowing mintypmax
expressions here. It seems arbitrary. Note that a delay range must be
enclosed in brackets.

Also, if the syntax is '## constant_primary', then ## (e1:e2:e3), will
work, without additional parentheses.

Shalom


> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
> On Behalf Of Eduard Cerny
> Sent: Wednesday, June 27, 2007 10:27 PM
> To: Brad Pierce; sv-ac@server.eda-stds.org
> Subject: RE: [sv-ac] P1800 - constant primary as delay in ## : Mantis
> 1901
> 
> 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

--
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.