Re: [sv-ac] New proposal for mantis #1646 - generate constructs in sequences and properties

Hi Ed:

I have not yet looked at the proposal.

However, from the first time I saw this idea 
presented I worried a bit about collision between 
the generates and my vision of adding "if-else"
to sequences and adding "case" to both sequences
and properties.

If the requirement to use "generate/endgenerate"
keywords will still allow us to add these operators,
I will be happier.

J.H.

> 
> Is that what Note 1 in the proposal is trying to get at? --
> 
>    "1. As the syntax indicates, it is required to explicitly specify
> generate block within the property.  Omitting could lead to a less
> intuitive code."
> 
> So within properties, although it would not actually be ambiguous to
> omit the generate-endgenerate, it could be confusing, and the same
> syntactic restriction is applied to sequences for consistency with
> properties?
> 
> -- Brad
> 
> -----Original Message-----
> From: Eduard Cerny [mailto:edcerny@synopsys.COM] 
> Sent: Saturday, April 07, 2007 3:44 AM
> To: Brad.Pierce@synopsys.COM; sv-ac@eda-stds.org
> Subject: Re: [sv-ac] New proposal for mantis #1646 - generate constructs
> in sequences and properties
> 
> Generate endgenerate is there to distinguish property if from generate
> if.
> 
> Example can be added.
> 
> Ed
> 
> -----Original Message-----
> From: owner-sv-ac@eda.org <owner-sv-ac@eda.org>
> To: sv-ac@eda-stds.org <sv-ac@eda-stds.org>
> Sent: Fri Apr 06 14:21:38 2007
> Subject: Re: [sv-ac] New proposal for mantis #1646 - generate constructs
> in sequences and properties
> 
> What's the justification for requiring generate/endgenerate keywords
> here, when they are optional in the rest of the language?
> 
> Also, it would be helpful if there were a realistic example of using
> generate loops, in addition to the examples about conditional generate.
> 
> -- Brad 
> 
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Eduard Cerny
> Sent: Friday, April 06, 2007 1:44 PM
> To: Seligman, Erik
> Cc: sv-ac@eda-stds.org
> Subject: RE: [sv-ac] New proposal for mantis #1646 - generate constructs
> in sequences and properties
> 
>  Hello Erik,
> 
> Please find attached a corrected proposal. I did a few more
> "adjustments" too. I have also deposited the proposal on Mantis.
> 
> Thank you,
> ed
> 
> > -----Original Message-----
> > From: Seligman, Erik [mailto:erik.seligman@intel.com]
> > Sent: Wednesday, April 04, 2007 5:17 PM
> > To: Eduard Cerny
> > Cc: Korchemny, Dmitry
> > Subject: RE: [sv-ac] New proposal for mantis #1646 - generate 
> > constructs in sequences and properties
> > 
> > Hi again--
> > 
> > I have a few minor comments/questions on this proposal as well.  Hope 
> > I'm not harassing you too much. :-)
> > 
> > - In sec 17.11.3, the last sentence you add reads
> > 	"It is illegal to refer to locally declared properties of a
> property 
> > from the outside of the enclosing property."
> > This seems kind of awkward, English-wise.   I think I could 
> > interpret it
> > to mean that a 2-deep locally declared property can be referenced from
> 
> > an extra level up -- do we mean the "enclosing property" of the 
> > sub-property, or of the original property?  Maybe rephrase with 
> > something like:
> > 	"If a property is declared within the scope of another property,
> it 
> > is illegal to refer to it outside the scope in which it is declared."
> > 
> > - In the insert for 17.11.4, I think the example weak_until property 
> > has a clarity issue: 'p' is used both as an input, and as a 
> > sub-property name.  The recursion in the second sub-property may also 
> > have an issue-- did we really want to recurse on the top-level 
> > property rather than on the local sub-property?
> > 
> > - In the example at the end of this pdf, within property p1(s,p), 
> > property prop_always is no longer recursive.  Is that really the 
> > intent?
> > Also, I think there's a typo below, where we refer to 
> > "property_always"
> > instead of "prop_always".
> > 
> > 
> >     
> > 
> 
> --
> 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.