Re: [sv-ac] 928 Proposal Updated

Hi Ed:

I think adding parentheses to the event expression syntax
is a good thing.  I like giving the user the flexibility
to parenthesize for readability.

However, I still don't like the solution that requires 
parentheses in all cases of positional binding of event 
expression actual arguments.

What about a solution that adds the parentheses to the event
expression syntax _and_ adds the restriction that if an
event expression that contains comma-separated sub event expressions
is passed as an actual argument using positional binding, then
those comma separators must appear within enclosing parenthese.

I'm sure the wording of the restriction could be improved,
but I think it is clear enough for discussion.

The advantage of this is that it doesn't force the parentheses
all the time, but it still allows the comma-separated list
to be passed if parentheses are used.  

What do you think?  

J.H.


> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
> Content-class: urn:content-classes:message
> Date: Thu, 22 Jun 2006 13:58:50 -0700
> Thread-Topic: [sv-ac] 928 Proposal Updated
> Thread-Index: AcaWPV4BntbkijwcSYyKnfHWuMh8CwAAUj/g
> From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
> Cc: <piper@cadence.com>, <spsaha@cal.interrasystems.com>,
>         <Brad.Pierce@synopsys.com>, <sv-ac@verilog.org>
> X-OriginalArrivalTime: 22 Jun 2006 20:58:52.0000 (UTC) FILETIME=[AA8ACE00:01C6963E]
> 
> John,
> 
> You are right ... unless we add in the derivation of event_expression
> that=20
> 
> event_expression ::=3D ...
>                     (event_expression)=20
> 
> (not just for the sequence a property args)
> 
> Would that be a problem?
> 
> I guess the other way as Lisa proposed is OK too.
> 
> ed=20
> 
> > -----Original Message-----
> > From: John Havlicek [mailto:john.havlicek@freescale.com]=20
> > Sent: Thursday, June 22, 2006 4:49 PM
> > To: Eduard.Cerny@synopsys.COM
> > Cc: piper@cadence.com; spsaha@cal.interrasystems.com;=20
> > Brad.Pierce@synopsys.COM; Eduard.Cerny@synopsys.COM; sv-ac@verilog.org
> > Subject: Re: [sv-ac] 928 Proposal Updated
> >=20
> > Hi Ed:
> >=20
> > The bad thing about the parenthesis solution is that=20
> > it spoils a bit the actual argument substitution.  You can't=20
> > parse parentheses within the production for event_expression.
> >=20
> > E.g., with
> >=20
> >    property foo (ev, r, s);
> >       @(ev) r |-> s
> >    endproperty
> >=20
> >    assert property foo((posedge clk), a, b);
> >=20
> > we expect to get something equivalent to
> >=20
> >    assert property (@((posedge clk)) a |-> b);
> >=20
> > and "@((posedge clk))" doesn't parse. =20
> >=20
> > I know that sometimes there are implicit extra parentheses
> > required in argument substitution to avoid operator precedence=20
> > problems, and so we could just explain that these extra parentheses=20
> > get stripped away.  But it is still ugly in my view.
> >=20
> > How about using the semantic rule as Lisa suggested?
> >=20
> > Best regards,
> >=20
> > John H.
> >=20
> > > X-Authentication-Warning: server.eda-stds.org: majordom set=20
> > sender to owner-sv-ac@eda-stds.org using -f
> > > X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
> > > Content-class: urn:content-classes:message
> > > Date: Thu, 22 Jun 2006 08:55:30 -0700
> > > Thread-Topic: [sv-ac] 928 Proposal Updated
> > > Thread-Index: AcaVtHUnlUbBUqJuSGOLC2QfKfLNLwAUf++gAANahoA=3D
> > > From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
> > > Cc: "Brad Pierce" <Brad.Pierce@synopsys.com>,
> > >         "Eduard Cerny" <Eduard.Cerny@synopsys.com>,=20
> > <sv-ac@verilog.org>
> > > X-OriginalArrivalTime: 22 Jun 2006 15:55:32.0488 (UTC)=20
> > FILETIME=3D[4AC9A880:01C69614]
> > > X-Virus-Status: Clean
> > > Sender: owner-sv-ac@eda-stds.org
> > >=20
> > > This is a multi-part message in MIME format.
> > >=20
> > > ------_=3D_NextPart_001_01C69614.4A85A7B1
> > > Content-Type: text/plain;
> > > 	charset=3D"US-ASCII"
> > > Content-Transfer-Encoding: quoted-printable
> > >=20
> > > I think that the parenthesized solution (2nd one) might be=20
> > the simplest
> > > even though it is only required for the case containing a ",". Would
> > > there be a way to require () only in that case?=3D20
> > > ed
> > >=20
> > >=20
> > > ________________________________
> > >=20
> > > 	From: Lisa Piper [mailto:piper@cadence.com]=3D20
> > > 	Sent: Thursday, June 22, 2006 10:42 AM
> > > 	To: spsaha@cal.interrasystems.com
> > > 	Cc: Brad Pierce; Eduard Cerny; sv-ac@verilog.org
> > > 	Subject: RE: [sv-ac] 928 Proposal Updated
> > > =3D09
> > > =3D09
> > >=20
> > > 	Surya,
> > >=20
> > > 	=3D20
> > >=20
> > > 	You are correct that this is an issue.  Does anyone have
> > > suggestions on how to fix this?  It is only a problem for positional
> > > binding since there are parenthesis when name binding is used. =3D20
> > >=20
> > > 	=3D20
> > >=20
> > > 	Breaking the syntax into one for positional and one for name
> > > binding would be messy, but could be done. It might be more clear to
> > > simply state in text that "event_expression,=20
> > event_expression" is not
> > > allowed as an actual argument in positional binding. =3D20
> > >=20
> > > 	=3D20
> > >=20
> > > 	Another possibility is to define:
> > >=20
> > > 	=3D20
> > >=20
> > > 	            sequence_actual_arg ::=3D3D
> > >=20
> > > 	                          sequence_instance
> > >=20
> > > 	                        | expression
> > >=20
> > > 	                        | ( event_expression )
> > >=20
> > > 	=3D20
> > >=20
> > > 	This would allow for having expressions with or without
> > > parenthesis, but event expressions would require=20
> > parenthesis. This might
> > > have backwards compatibility issues though, depending on=20
> > how the 1800
> > > was previously interpreted.=3D20
> > >=20
> > > 	=3D20
> > >=20
> > > 	lisa
> > >=20
> > > =3D09
> > > ________________________________
> > >=20
> > >=20
> > > 	From: spsaha@cal.interrasystems.com
> > > [mailto:spsaha@cal.interrasystems.com]=3D20
> > > 	Sent: Thursday, June 22, 2006 12:30 AM
> > > 	To: Lisa Piper
> > > 	Cc: Brad Pierce; Eduard Cerny; sv-ac@verilog.org
> > > 	Subject: Re: [sv-ac] 928 Proposal Updated
> > >=20
> > > 	=3D20
> > >=20
> > > 	Hi,=3D20
> > > 	I have some comment on inclusion of event_expression as part of
> > > sequence_actual_arg. By definition event_expression is:=3D20
> > > 	event_expression ::=3D3D=3D20
> > > 	[ edge_identifier ] expression [ iff expression ]=3D20
> > > 	| sequence_instance [ iff expression ]=3D20
> > > 	| event_expression or event_expression=3D20
> > > 	| event_expression , event_expression=3D20
> > >=20
> > > 	So it is already containing ',' separator. And if we see the
> > > definition of sequence_list_of_arguments, the ',' separator is again
> > > used:=3D20
> > >=20
> > > 	sequence_list_of_arguments=3D20
> > > 	[sequence_actual_arg] { , [sequence_actual_arg] } { , .
> > > identifier ( [sequence_actual_arg] ) }=3D20
> > > 	| . identifier (sequence_actual_arg] ) { , . identifier (
> > > [sequence_actual_arg] ) }=3D20
> > >=20
> > > 	So there is obvious conflict in BNF. SV 3.1a version had that
> > > conflict earlier, and 1800 fixed it by including only expression as
> > > sequence_list_of_arguments. Now if we again going back, then I think
> > > this conflict should be fixed first.=3D20
> > > 	 =3D20
> > >=20
> > > 	Lisa Piper wrote:=3D20
> > >=20
> > > 		Thanks Brad - you have a good eye!  I have incorporated
> > > the changes in the attached and will update Mantis.
> > >=20
> > > 		lisa=3D20
> > >=20
> > > 	=3D09
> > > 	=3D09
> >=20