RE: [sv-ac] 928 Proposal Updated

Hi Lisa,

in the current version, you can put untyped and typed ports in any
order. This violates the other port rule where the type extends over
subsequent untyped identifiers. For sequence and properties, the type
was not extended.

ed 

> -----Original Message-----
> From: Lisa Piper [mailto:piper@cadence.com] 
> Sent: Tuesday, June 27, 2006 9:35 AM
> To: Eduard Cerny; Korchemny, Dmitry; Brad Pierce; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] 928 Proposal Updated
> 
> Hi Ed,
> 
> I don't understand what is not backward compatible, though perhaps it
> was my interpretation of what was intended with the previous.  I think
> it is very important that we not be different from other port lists.
> 
> Lisa
> 
> -----Original Message-----
> From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
> Sent: Tuesday, June 27, 2006 9:29 AM
> To: Lisa Piper; Korchemny, Dmitry; Brad Pierce; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] 928 Proposal Updated
> 
> Hi all,
> 
> so... what do we do with it? If we keep any order, we go against other
> port definitions, if we change, we are not backward 
> compatible. I think
> that since we need some adjustment, we could make some enhancement if
> they can be justified as corrections (of a weakness). Suppose that we
> can, then what should it be? Either change may make it backward
> incompatible, no? Restriction on order as now, or "anytype"? 
> Or keep as
> is, even if different from other port lists?
> 
> Best regards,
> ed
> 
> 
> > -----Original Message-----
> > From: owner-sv-ac@eda-stds.org 
> > [mailto:owner-sv-ac@eda-stds.org] On Behalf Of Lisa Piper
> > Sent: Monday, June 26, 2006 11:04 PM
> > To: Korchemny, Dmitry; Brad Pierce; sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] 928 Proposal Updated
> > 
> > Hi Dimitry (and Bassam),
> > 
> > I agree completely, and when we can add enhancements we should
> > definitely add this, along with property, sequence, and const for
> > repetition and delays. 
> > 
> > It is difficult to know what is a "fix" versus an enhancement, but I
> > think that is definitely an enhancement, assuming the others are.
> > Perhaps the team will decide that none are enhancements but 
> rather all
> > are fixes?
> > 
> > lisa
> > 
> > -----Original Message-----
> > From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
> > Sent: Monday, June 26, 2006 6:55 PM
> > To: Lisa Piper; Brad Pierce; sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] 928 Proposal Updated
> > 
> > Hi Lisa,
> > 
> > I think that the requirement "Untyped arguments must 
> > therefore be listed
> > before any typed arguments" is too restrictive. Consider 
> the following
> > example:
> > 
> > property impl (a, b, int rpt = 0, clk=proj_clk, rst='0);
> > 	@(clk) disable iff (rst) (a[*rpt] |-> b);
> > endproperty
> > 
> > The user may want to keep the arguments in THIS order.
> > 
> > Introducing an optional explicit type for untyped arguments (say,
> > "anytype") would solve this problem:
> > 
> > property impl (a, b, int rpt = 0, anytype clk=proj_clk, rst='0);
> > 	@(clk) disable iff (rst) (a[*rpt] |-> b);
> > endproperty
> > 
> > Or even make the declaration required:
> > 
> > property impl (anytype a, b, int rpt = 0, anytype 
> > clk=proj_clk, rst='0);
> > 	@(clk) disable iff (rst) (a[*rpt] |-> b);
> > endproperty
> > 
> > Thanks,
> > Dmitry
> > 
> > -----Original Message-----
> > From: owner-sv-ac@server.eda-stds.org
> > [mailto:owner-sv-ac@server.eda-stds.org] On Behalf Of Lisa Piper
> > Sent: Monday, June 26, 2006 6:02 AM
> > To: Brad Pierce; sv-ac@server.eda-stds.org
> > Subject: RE: [sv-ac] 928 Proposal Updated
> > 
> > One more time!  Here it is with Brad's modification.
> > 
> > lisa
> > 
> > -----Original Message-----
> > From: owner-sv-ac@eda-stds.org [mailto:owner-sv-ac@eda-stds.org] On
> > Behalf Of Brad Pierce
> > Sent: Sunday, June 25, 2006 9:19 PM
> > To: sv-ac@eda-stds.org
> > Subject: Re: [sv-ac] 928 Proposal Updated
> > 
> > John,
> > 
> > Your example would still not be legal under the current proposal.
> > 
> > Was the actual intent then to add the following?
> > 
> >     | ( event_expression )
> > 
> > -- Brad
> > 
> > -----Original Message-----
> > From: John Havlicek [mailto:john.havlicek@freescale.com] 
> > Sent: Sunday, June 25, 2006 10:29 AM
> > To: Brad.Pierce@synopsys.COM
> > Cc: sv-ac@eda-stds.org
> > Subject: Re: [sv-ac] 928 Proposal Updated
> > 
> > Hi Brad:
> > 
> > I think parentheses will be useful.  A user might prefer to
> > write 
> > 
> >   (posedge clk iff enabled) or reset
> > 
> > in place of
> > 
> >   posedge clk iff enabled or reset
> > 
> > 
> > If we don't put the parentheses in the event_expression syntax,
> > we have another problem because our rule for passing actual 
> > arguments to untyped formal arguments is that the result of 
> > replacement of formal arguments with actual arguments be legal.
> > 
> > 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: Sat, 24 Jun 2006 23:39:21 -0700
> > > Thread-Topic: [sv-ac] 928 Proposal Updated 
> > > Thread-Index:
> > AcaUq1rmBGvZmHrHSSKxGG7GuLoqTAAn31vgABTfwPAAfnoY0AAbbB2gAAZU46A=
> > > From: "Brad Pierce" <Brad.Pierce@synopsys.com>
> > > X-OriginalArrivalTime: 25 Jun 2006 06:39:28.0156 (UTC)
> > FILETIME=[1B55DDC0:01C69822]
> > > X-Virus-Status: Clean
> > > Sender: owner-sv-ac@eda-stds.org
> > > 
> > > This is a multi-part message in MIME format.
> > > 
> > > ------_=_NextPart_001_01C69822.1B0E7A63
> > > Content-Type: text/plain;
> > > 	charset="US-ASCII"
> > > Content-Transfer-Encoding: quoted-printable
> > > 
> > > Lisa,
> > > 
> > > =20
> > > 
> > > Is the parenthesized form a useful addition to the 
> event_expression
> > > syntax outside of arg passing?=20
> > > 
> > > =20
> > > 
> > > Maybe it should be allowed only in sequence_actual_arg.  For that
> > > localized change there would be no need to consult with other
> > > subcommittees.
> > > 
> > > =20
> > > 
> > > -- Brad
> > > 
> > > =20
> > > 
> > > =20
> > > 
> > 
> > 
>