Hi Faisal: As I indicated to Ed, I don't think the current LRM clearly describes the rules for attachment of types to formal arguments in sequence and property declarations. I think Stu's interpretation, in analogy with tf_port_lists, is reasonable given what is written. I think it is important at this juncture to do the right thing for the language. I think that this is to make the sequence and task port lists follow the same conventions as other port lists. Best regards, John H. > X-Authentication-Warning: server.eda-stds.org: majordom set sender to owner-sv-ac@eda-stds.org using -f > X-IronPort-AV: i="4.06,185,1149490800"; > d="scan'208"; a="302007007:sNHT42552936" > X-MimeOLE: Produced By Microsoft Exchange V6.5 > Content-class: urn:content-classes:message > Date: Tue, 27 Jun 2006 18:42:37 -0700 > X-MS-Has-Attach: > X-MS-TNEF-Correlator: > Thread-Topic: [sv-ac] 928 Proposal Updated > Thread-Index: AcaaDNZwVdRAZQUnSKCvR9WVy8Q16wAA6K/gAAEiy4AAAMLdIAAHtgMwAAc/EaA= > From: "Faisal Haque (fhaque)" <fhaque@cisco.com> > X-OriginalArrivalTime: 28 Jun 2006 01:42:39.0768 (UTC) FILETIME=[23F2C180:01C69A54] > DKIM-Signature: a=rsa-sha1; q=dns; l=20577; t=1151458960; x=1152322960; > c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; > d=cisco.com; i=fhaque@cisco.com; z=From:=22Faisal=20Haque=20\(fhaque\)=22=20<fhaque@cisco.com> > |Subject:RE=3A=20[sv-ac]=20928=20Proposal=20Updated; > X=v=3Dcisco.com=3B=20h=3DnIUml806+/xmT9fpsOOJJz03v88=3D; b=R6WKT08RuzAHR7293HMG5B/vMgfjLUFLSzo+spWaDFiuW9mKvICs3BGRoi982E3NnJXAoiFb > DWsMj/nyTJ+txq/EU5ftw7JzF1MB5ucx7vf2hAxWvXfmMB0wP2sR98vm; > Authentication-Results: sj-dkim-4.cisco.com; header.From=fhaque@cisco.com; dkim=pass ( > sig from cisco.com verified; ); > X-Virus-Status: Clean > X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda-stds.org id k5S1ggDu029518 > Sender: owner-sv-ac@eda-stds.org > > Stuart, > We are not going to risk backward compatibility without exploring > alternatives. There are thousands of users out there who are writing SVA > code and breaking backward compatibility is not an option to be > considered lightly. > > We should explore all other alternatives before we consider this > scenario. > -Faisal > > > -----Original Message----- > > From: owner-sv-ac@eda-stds.org > > [mailto:owner-sv-ac@eda-stds.org] On Behalf Of Stuart Sutherland > > Sent: Tuesday, June 27, 2006 3:51 PM > > To: sv-ac@eda-stds.org > > Subject: RE: [sv-ac] 928 Proposal Updated > > > > > > >From this user's perspective, I already thought that once a type was > > specified in the property/sequence formal argument > > definitions, all subsequent formal arguments were of that > > type, until another type was specified. That, as has been > > noted, is consistent with Verilog and SystemVerilog > > task/function formal argument definitions. I have been > > teaching all along in my SVA course that any untyped formal > > arguments had to be listed first. Of course, not everyone > > using SVA has taken my course...yet :) > > > > I think keeping as much consistency as reasonable between > > property/sequence formal arguments and task/function formal > > arguments is important. Having the last defined type carry > > forward to subsequent arguments should be made the rule, even > > at the risk of backward compatibility. This is an exception > > from my usual strong position regarding backwards > > compatibility. As Karen noted, we are early in the user > > adoption of SVA, and it is better to make this rule now, > > rather than later. I would be curious as to how many EDA > > vendor regression tests would be affected by this rule. If > > it is a lot, and those regressions are based on customer > > code, I might change my mind about breaking backward > > compatibility in this case. > > > > I also agree that sequence/property formal augments need to > > support more types than task/functions. I don't think, > > however, that adding those types has to be part of defining > > whether each formal argument has to be typed, or if the last > > defined type carries forward. > > > > Regarding a default type, I think this has to be different > > that task/function formal arguments. For sequence/property > > arguments, shouldn't the default be to inherit the type of > > the actual argument instead of a logic type? This default > > would only apply if no formal argument type has been > > specified. If I am missing something here, and a default > > type is needed even when no types have been specified, could > > not the default formal type for a property be property, and > > the default formal type for a sequence be sequence? That > > would allow the actual to be just about anything that is > > likely to be passed into the property or sequence. > > > > Stu > > ~~~~~~~~~~~~~~~~~~~~~~~~~ > > Stuart Sutherland > > stuart@sutherland-hdl.com > > +1-503-692-0898 > > > > > > > -----Original Message----- > > > From: owner-sv-ac@server.eda-stds.org > > > [mailto:owner-sv-ac@server.eda-stds.org] On Behalf Of Bassam Tabbara > > > Sent: Tuesday, June 27, 2006 11:45 AM > > > To: Kulshrestha, Manisha; Bassam Tabbara; > > john.havlicek@freescale.com > > > Cc: Eduard.Cerny@synopsys.com; piper@cadence.com; > > > dmitry.korchemny@intel.com; Brad.Pierce@synopsys.com; > > > sv-ac@server.eda-stds.org > > > Subject: RE: [sv-ac] 928 Proposal Updated > > > > > > Hi Manisha, > > > > > > In my opinion, untyped is NOT the same as default type. > > Untyped means > > > here in current form an implicit type (that of > > declaration). As I say > > > below we can indeed carry thru all of type > > default/inheritance etc ... > > > But we must first add the types in question and define all these > > > defaults/inheritance/mix of seq/prop/typecasting. A default is one > > > type, not a set of seq/prop/... By the argument below everything we > > > pass is logic and that's it. > > > > > > Again to adopt something we should do it right and think the > > > consequences thru, try to minimize backward > > incompatibility/changes, > > > otw keep status quo, people ARE using this today. > > > > > > Thx. > > > -Bassam. > > > > > > -----Original Message----- > > > From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com] > > > Sent: Tuesday, June 27, 2006 11:20 AM > > > To: Bassam Tabbara; john.havlicek@freescale.com > > > Cc: Eduard.Cerny@synopsys.COM; piper@cadence.com; > > > dmitry.korchemny@intel.com; Brad.Pierce@synopsys.COM; > > > sv-ac@eda-stds.org > > > Subject: RE: [sv-ac] 928 Proposal Updated > > > > > > Hi, > > > > > > I also think that it is important to preserve the same semantics as > > > port list in other places. The functions/tasks also have a default > > > type (which is logic) for the ports and users have to > > specify all the > > > ports with default types before any explicitly typed ports can be > > > specified. > > > We have a similar case. In case of properties and > > sequences, default > > > is untyped. I think having different semantics for > > > properties/sequences is going to be confusing for the users. > > > > > > Thanks. > > > Manisha > > > > > > -----Original Message----- > > > From: owner-sv-ac@server.eda-stds.org > > > [mailto:owner-sv-ac@server.eda-stds.org] On Behalf Of Bassam Tabbara > > > Sent: Tuesday, June 27, 2006 11:00 AM > > > To: john.havlicek@freescale.com; Bassam.Tabbara@synopsys.com > > > Cc: Eduard.Cerny@synopsys.com; piper@cadence.com; > > > dmitry.korchemny@intel.com; Brad.Pierce@synopsys.com; > > > sv-ac@server.eda-stds.org > > > Subject: RE: [sv-ac] 928 Proposal Updated > > > > > > Hi John, > > > > > > The part I have serious reservations about as I motivated > > below is the > > > " > > > ...once a type is introduced, the type can apply to multiple, > > > comma-separated formal arguments, as in a tf_port_list", > > particularly > > > because of its consequence of barring free intermixing > > since backward > > > compatibility (see qualification below) is paramount in my opinion. > > > > > > I think that this change in itself is ok *but* because of the > > > consequence above (stemming from lack of types) it should > > go hand in > > > hand with introducing new seq/prop types. If we do have the > > seq/prop > > > types then this will break compatibility but won't be that bad -- > > > users/library providers would add some extra tags to make explicit > > > what is implicit today (the "no type" means an implicit type), > > > linters/automation/tool options can help flag/alleviate. > > But you are > > > not forced to switch the order of declaration the syntax > > error forces > > > you to make explicit the typing (strongly typed version). > > > > > > Bottom line this extra change today is not worth the effort, if we > > > want to do this let's do it "right" or not at all, hope this helped > > > clarify the different considerations and my take on them :). > > > > > > Thx. > > > -Bassam. > > > > > > -----Original Message----- > > > From: John Havlicek [mailto:john.havlicek@freescale.com] > > > Sent: Tuesday, June 27, 2006 10:11 AM > > > To: Bassam.Tabbara@synopsys.COM > > > Cc: john.havlicek@freescale.com; Eduard.Cerny@synopsys.COM; > > > piper@cadence.com; dmitry.korchemny@intel.com; > > > Brad.Pierce@synopsys.COM; sv-ac@eda-stds.org > > > Subject: Re: [sv-ac] 928 Proposal Updated > > > > > > 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/i0gAQHvIgAAPF0CAAKVMuQAAIOAAAABaZwGAAADfm > > > > > MAAAgIWQ > > > > > 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 20:08:45 2006
This archive was generated by hypermail 2.1.8 : Tue Jun 27 2006 - 20:08:58 PDT