RE: [sv-ac] 928 Proposal Updated

Hi John,

yes, I agree. But I think that the definition of event_expression would
allow both forms, w/ and w/o parentheses. The note that you mention
would just enforce it for the particular cae in question.

Best regards,
ed
 

> -----Original Message-----
> From: John Havlicek [mailto:john.havlicek@freescale.com] 
> Sent: Friday, June 23, 2006 7:59 AM
> To: Eduard.Cerny@synopsys.COM
> Cc: john.havlicek@freescale.com; Eduard.Cerny@synopsys.COM; 
> piper@cadence.com; spsaha@cal.interrasystems.com; 
> Brad.Pierce@synopsys.COM; sv-ac@verilog.org
> Subject: 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
>