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