RE: [sv-ac] 928 Proposal Updated

John,

You are right ... unless we add in the derivation of event_expression
that 

event_expression ::= ...
                    (event_expression) 

(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 

> -----Original Message-----
> From: John Havlicek [mailto:john.havlicek@freescale.com] 
> Sent: Thursday, June 22, 2006 4:49 PM
> To: Eduard.Cerny@synopsys.COM
> Cc: piper@cadence.com; spsaha@cal.interrasystems.com; 
> Brad.Pierce@synopsys.COM; Eduard.Cerny@synopsys.COM; sv-ac@verilog.org
> Subject: Re: [sv-ac] 928 Proposal Updated
> 
> Hi Ed:
> 
> The bad thing about the parenthesis solution is that 
> it spoils a bit the actual argument substitution.  You can't 
> parse parentheses within the production for event_expression.
> 
> E.g., with
> 
>    property foo (ev, r, s);
>       @(ev) r |-> s
>    endproperty
> 
>    assert property foo((posedge clk), a, b);
> 
> we expect to get something equivalent to
> 
>    assert property (@((posedge clk)) a |-> b);
> 
> and "@((posedge clk))" doesn't parse.  
> 
> I know that sometimes there are implicit extra parentheses
> required in argument substitution to avoid operator precedence 
> problems, and so we could just explain that these extra parentheses 
> get stripped away.  But it is still ugly in my view.
> 
> How about using the semantic rule as Lisa suggested?
> 
> Best regards,
> 
> John H.
> 
> > X-Authentication-Warning: server.eda-stds.org: majordom set 
> 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=
> > From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
> > Cc: "Brad Pierce" <Brad.Pierce@synopsys.com>,
> >         "Eduard Cerny" <Eduard.Cerny@synopsys.com>, 
> <sv-ac@verilog.org>
> > X-OriginalArrivalTime: 22 Jun 2006 15:55:32.0488 (UTC) 
> FILETIME=[4AC9A880:01C69614]
> > X-Virus-Status: Clean
> > Sender: owner-sv-ac@eda-stds.org
> > 
> > This is a multi-part message in MIME format.
> > 
> > ------_=_NextPart_001_01C69614.4A85A7B1
> > Content-Type: text/plain;
> > 	charset="US-ASCII"
> > Content-Transfer-Encoding: quoted-printable
> > 
> > I think that the parenthesized solution (2nd one) might be 
> the simplest
> > even though it is only required for the case containing a ",". Would
> > there be a way to require () only in that case?=20
> > ed
> > 
> > 
> > ________________________________
> > 
> > 	From: Lisa Piper [mailto:piper@cadence.com]=20
> > 	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
> > =09
> > =09
> > 
> > 	Surya,
> > 
> > 	=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. =20
> > 
> > 	=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, 
> event_expression" is not
> > allowed as an actual argument in positional binding. =20
> > 
> > 	=20
> > 
> > 	Another possibility is to define:
> > 
> > 	=20
> > 
> > 	            sequence_actual_arg ::=3D
> > 
> > 	                          sequence_instance
> > 
> > 	                        | expression
> > 
> > 	                        | ( event_expression )
> > 
> > 	=20
> > 
> > 	This would allow for having expressions with or without
> > parenthesis, but event expressions would require 
> parenthesis. This might
> > have backwards compatibility issues though, depending on 
> how the 1800
> > was previously interpreted.=20
> > 
> > 	=20
> > 
> > 	lisa
> > 
> > =09
> > ________________________________
> > 
> > 
> > 	From: spsaha@cal.interrasystems.com
> > [mailto:spsaha@cal.interrasystems.com]=20
> > 	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
> > 
> > 	Hi,=20
> > 	I have some comment on inclusion of event_expression as part of
> > sequence_actual_arg. By definition event_expression is:=20
> > 	event_expression ::=3D=20
> > 	[ edge_identifier ] expression [ iff expression ]=20
> > 	| sequence_instance [ iff expression ]=20
> > 	| event_expression or event_expression=20
> > 	| event_expression , event_expression=20
> > 
> > 	So it is already containing ',' separator. And if we see the
> > definition of sequence_list_of_arguments, the ',' separator is again
> > used:=20
> > 
> > 	sequence_list_of_arguments=20
> > 	[sequence_actual_arg] { , [sequence_actual_arg] } { , .
> > identifier ( [sequence_actual_arg] ) }=20
> > 	| . identifier (sequence_actual_arg] ) { , . identifier (
> > [sequence_actual_arg] ) }=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.=20
> > 	 =20
> > 
> > 	Lisa Piper wrote:=20
> > 
> > 		Thanks Brad - you have a good eye!  I have incorporated
> > the changes in the attached and will update Mantis.
> > 
> > 		lisa=20
> > 
> > 	=09
> > 	=09
>