Hi Bassam: I voted "yes" on 928 with support for your friendly ammendment. That means I believe that untyped arguments should be required first in a port list that has both typed and untyped arguments. I also believe that once a type is introduced, the type can apply to multiple, comma-separated formal arguments, as in a tf_port_list. Are you saying that you do not agree with these things? Later, we can add some syntax for specifying untyped arguments, property types, etc., and then users will have more flexibility in the order of the items in the port lists for sequences and properties. My opinion is that it is more important for the port list mechanics to be similar across the constructs than to preserve any backward compatibility with mixing of typed and untyped arguments in sequences and properties. Best regards, John H. > X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 > Content-class: urn:content-classes:message > X-Former-Content-Transfer-Encoding: base64 > Date: Tue, 27 Jun 2006 08:26:35 -0700 > Thread-Topic: [sv-ac] 928 Proposal Updated > Thread-Index: AcaZ+dzvKQTK7YwiRViSzG8IpDTA/AABDDk4 > From: "Bassam Tabbara" <Bassam.Tabbara@synopsys.com> > Cc: <piper@cadence.com>, <dmitry.korchemny@intel.com>, > <Brad.Pierce@synopsys.com>, <sv-ac@eda-stds.org> > X-OriginalArrivalTime: 27 Jun 2006 15:26:36.0580 (UTC) FILETIME=[142BDE40:01C699FE] > > Hi John, > > It is always the case, in order to keep things simple, available syntax is used with semantic clarification on top. In particular here going with the original wording of semantics does not: > - cause backward issues with free mixing > - add extra baggage to deal with in future when sequence or property type tags are added. > > The argument of similarity to other port lists is weak because here things can be untyped. My motto keep things crisp and clean, users would rather have clear intent at the cost of some extra typing ... Where saving it risks being too restrictive in the end. > > THX. > -Bassam > > -----Original Message----- > From: owner-sv-ac@eda-stds.org <owner-sv-ac@eda-stds.org> > To: Eduard.Cerny@synopsys.COM <Eduard.Cerny@synopsys.COM> > CC: piper@cadence.com <piper@cadence.com>; Eduard.Cerny@synopsys.COM <Eduard.Cerny@synopsys.COM>; dmitry.korchemny@intel.com <dmitry.korchemny@intel.com>; Brad.Pierce@synopsys.COM <Brad.Pierce@synopsys.COM>; sv-ac@eda-stds.org <sv-ac@eda-stds.org> > Sent: Tue Jun 27 07:54:28 2006 > Subject: Re: [sv-ac] 928 Proposal Updated > > Hi Ed: > > I'm not sure that the current version of the LRM is free from > ambiguity about the mixing of typed and untyped arguments in > sequence and property declarations. > > I think that the language of the first paragraphs of 17.6.1 > and 17.11.1 suggests that each typed argument requires its own > type specifier and that typed and untyped can be interleaved. > > However, the syntax uses tf_port_list, so it also reasonable > to expect the rules of task and function port lists to apply > insofar as they make sense. > > I agree with Lisa that we should be consistent with the rules > of other port lists. > > J.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: Tue, 27 Jun 2006 06:46:59 -0700 > > Thread-Topic: [sv-ac] 928 Proposal Updated > > Thread-Index: AcaYfPvzxbMcHaPfT7ezSwGbXs/i0gAQHvIgAAPF0CAAKVMuQAAIOAAAABaZwGAAADfmMAAAgIWQ > > From: "Eduard Cerny" <Eduard.Cerny@synopsys.com> > > X-OriginalArrivalTime: 27 Jun 2006 13:47:00.0977 (UTC) FILETIME=[2A6F3610:01C699F0] > > X-Virus-Status: Clean > > X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda-stds.org id k5RDlCDu023453 > > Sender: owner-sv-ac@eda-stds.org > > > > 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 > > > > > > > > > > > > > > > > > >Received on Tue Jun 27 10:11:50 2006
This archive was generated by hypermail 2.1.8 : Tue Jun 27 2006 - 10:12:05 PDT