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 11:45:21 2006
This archive was generated by hypermail 2.1.8 : Tue Jun 27 2006 - 11:45:29 PDT