Hi Stu/all, Ok on review of this thread, I'm now on-board with the ordering "correction" in Lisa's 928 proposal (untyped first + inheritance) without needing a full-blown type/default foundation because of following: Legacy is likely largely 3.1a with no or few types, John's opinion that tf_port_list introduction made the 2 interpretations more or less valid (i.e. ambiguity exists), Stu's teaching people to do it like tfs :), and most if not all in discussion agreeing on this rather reasonable consistency cleanup with tfs. That said, the other issues exposed (default, type, type qualifier ...) can go outside of 928. Thx. -Bassam. -----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 17:00:31 2006
This archive was generated by hypermail 2.1.8 : Tue Jun 27 2006 - 17:00:45 PDT