I agree with Erik. I think it is more important to make language keywords to be short and descriptive for the generations to come, that to keep backward compatibility with poorly written legacy designs that didn't even use naming conventions to make their signal names clear and consistent. --Yulik. -----Original Message----- From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Seligman, Erik Sent: Thursday, March 13, 2008 4:37 PM To: Bustan, Doron; Korchemny, Dmitry; Eduard Cerny; Gordon Vreugdenhil; Brad Pierce Cc: sv-bc@server.eda.org; sv-ec@server.eda.org; sv-cc@server.eda.org; sv-ac@server.eda.org Subject: RE: [sv-cc] RE: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals I've been thinking about this a bit more. Are we sure we want to make changes here? Sure, adding simple English words as keywords will cause a one-time backwards-compatibility glitch. But in the long term, think about the average users of a language: do they want keywords to be long mashup words designed to be awkward (so they are unlikely to be variable names), or simple intuitive English words? I think someone trying to create a new design would consider a simple 'next' a very intuitive and direct LTL implementation. I'm not so sure about the various other proposals we've been throwing around. -----Original Message----- From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org] On Behalf Of Bustan, Doron Sent: Wednesday, March 12, 2008 11:22 PM To: Korchemny, Dmitry; Eduard Cerny; Gordon Vreugdenhil; Brad Pierce Cc: sv-bc@server.eda.org; sv-ec@server.eda.org; sv-cc@server.eda.org; sv-ac@server.eda.org Subject: [sv-cc] RE: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals I also prefer nexttime, I think that future will be a bit confusing because of future_gclk have a very different semantics. Doron >>-----Original Message----- >>From: Korchemny, Dmitry >>Sent: Wednesday, March 12, 2008 9:13 PM >>To: Bustan, Doron; Eduard Cerny; Gordon Vreugdenhil; Brad Pierce >>Cc: sv-bc@server.eda.org; sv-ec@server.eda.org; sv-cc@server.eda.org; sv- >>ac@server.eda.org >>Subject: RE: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC >>proposals >> >>To tell the truth, I like nexttime better, it better expresses the intent. >> >>Thanks, >>Dmitry >> >>-----Original Message----- >>From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On >>Behalf Of Bustan, Doron >>Sent: Wednesday, March 12, 2008 3:24 PM >>To: Eduard Cerny; Gordon Vreugdenhil; Brad Pierce >>Cc: sv-bc@server.eda.org; sv-ec@server.eda.org; sv-cc@server.eda.org; sv- >>ac@server.eda.org >>Subject: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals >> >>Sorry, >> >>I though that you didn't like future because of future_gclk. Reading it >>again, I understand now. >> >>So it is >>1 for nexttime >>2 for future >> >>Doron >> >>>>-----Original Message----- >>>>From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] >>On >>>>Behalf Of Eduard Cerny >>>>Sent: Wednesday, March 12, 2008 3:19 PM >>>>To: Bustan, Doron; Eduard Cerny; Gordon Vreugdenhil; Brad Pierce >>>>Cc: sv-bc@server.eda.org; sv-ec@server.eda.org; sv-cc@server.eda.org; >>sv- >>>>ac@server.eda.org >>>>Subject: RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals >>>> >>>>I seemed to have the same proposal as Dmitry, what is wrong with that >>>>then? >>>>ed >>>> >>>>> -----Original Message----- >>>>> From: Bustan, Doron [mailto:doron.bustan@intel.com] >>>>> Sent: Wednesday, March 12, 2008 8:56 AM >>>>> To: Eduard Cerny; Gordon Vreugdenhil; Brad Pierce >>>>> Cc: sv-bc@eda.org; sv-ec@eda.org; sv-cc@eda.org; sv-ac@eda.org >>>>> Subject: RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals >>>>> >>>>> Hi Ed, >>>>> >>>>> as I said, it is hard to converge. I don't like adding LTL prefix >>>>unless >>>>> we have to, it is a hassle. Further, for people who don't know LTL >>it >>>>is >>>>> not meaningful and people who do, don't need the prefix. >>>>> >>>>> How about "later" ? >>>>> >>>>> I can live with nexttime, next_cycle, coming, ensuing, following, >>>>> succeeding, after, coming up, consequent, consequential, later, >>>>> posterior, postliminary, subsequent, subsequential >>>>> >>>>> Even words in Latin >>>>> >>>>> Doron >>>>> >>>>> >>-----Original Message----- >>>>> >>From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] >>>>> >>Sent: Wednesday, March 12, 2008 2:42 PM >>>>> >>To: Bustan, Doron; Gordon Vreugdenhil; Brad Pierce >>>>> >>Cc: sv-bc@eda.org; sv-ec@eda.org; sv-cc@eda.org; sv-ac@eda.org >>>>> >>Subject: RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals >>>>> >> >>>>> >>Hi Doron, >>>>> >> >>>>> >>we already have the system functions $future_gclk, would s_future >>>>and >>>>> >>future be a possible replacement for next? If on the other hand >>you >>>>> add >>>>> >>LTL to next, perhaps it should be added to all the property >>>>operators >>>>> >>other than all 4 resets, if-else, iff, implies, and, or, not. >>>>> >> >>>>> >>Regards, >>>>> >>ed >>>>> >> >>>>> >> >>>>> >>> -----Original Message----- >>>>> >>> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf >>>>Of >>>>> >>> Bustan, Doron >>>>> >>> Sent: Wednesday, March 12, 2008 2:16 AM >>>>> >>> To: Gordon Vreugdenhil; Brad Pierce >>>>> >>> Cc: sv-bc@eda.org; sv-ec@eda.org; sv-cc@eda.org; sv-ac@eda.org >>>>> >>> Subject: RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals >>>>> >>> >>>>> >>> All, >>>>> >>> >>>>> >>> I will try to be proactive here. Does anybody object to changing >>>>the >>>>> >>> next and s_next LTL operators to LTL_next and s_LTL_next >>>>> respectively? >>>>> >>> >>>>> >>> I know it is not visually attractive, but I am not sure that we >>>>will >>>>> >>be >>>>> >>> able to converge on something else in time. One can always alias >>>>it >>>>> to >>>>> >>> something else. >>>>> >>> >>>>> >>> Doron >>>>> >>> >>>>> >>> >>-----Original Message----- >>>>> >>> >>From: owner-sv-ac@server.eda.org >>>>> [mailto:owner-sv-ac@server.eda.org] >>>>> >>> On >>>>> >>> >>Behalf Of Gordon Vreugdenhil >>>>> >>> >>Sent: Wednesday, March 12, 2008 5:15 AM >>>>> >>> >>To: Brad Pierce >>>>> >>> >>Cc: sv-bc@server.eda.org; sv-ec@server.eda.org; >>>>> >>sv-cc@server.eda.org; >>>>> >>> sv- >>>>> >>> >>ac@server.eda.org >>>>> >>> >>Subject: Re: [sv-bc] RE: [sv-ac] New keywords in SV-AC >>proposals >>>>> >>> >> >>>>> >>> >> >>>>> >>> >>But adding "next" also invalidates the LRM itself (including >>>>2005) >>>>> >>in >>>>> >>> >>the builtin "Iterator" class which has: >>>>> >>> >> >>>>> >>> >>class List_Iterator#(parameter type T); >>>>> >>> >> extern function void next(); >>>>> >>> >> extern function void prev(); >>>>> >>> >> extern function int neq( List_Iterator#(T) iter ); >>>>> >>> >> extern function int eq( List_Iterator#(T) iter ); >>>>> >>> >> extern function T data(); endclass >>>>> >>> >> >>>>> >>> >> >>>>> >>> >>Gord. >>>>> >>> >> >>>>> >>> >> >>>>> >>> >>Brad Pierce wrote: >>>>> >>> >>> Steven, >>>>> >>> >>> >>>>> >>> >>> Thanks for running those tests. Important data. Just a >>short >>>>> >>note >>>>> >>> >>> about your last point -- >>>>> >>> >>> >>>>> >>> >>> The existing built-in enum method 'next()' needn't be a >>>>backward >>>>> >>> >>> compatibility problem for a new keyword 'enum'. See >>friendly >>>>> >>> amendment >>>>> >>> >>> in bullet 11 here >>>>> >>> >>> <http://www.eda-stds.org/sv/sv-champions/hm/att- >>>>> >>> >>0340/pierce_email_vote_Feb2308.txt>. >>>>> >>> >>> >>>>> >>> >>> See also >>>>> >>> >>> >>>>> >>> >>> http://www.eda-stds.org/sv-ac/hm/5668.html >>>>> >>> >>> >>>>> >>> >>> -- Brad >>>>> >>> >>> >>>>> >>> >>> -----Original Message----- >>>>> >>> >>> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On >>>>Behalf >>>>> >>Of >>>>> >>> >>> Steven Sharp >>>>> >>> >>> Sent: Tuesday, March 11, 2008 1:52 PM >>>>> >>> >>> To: stuart@sutherland-hdl.com; sv-bc@eda.org; sv-ec@eda.org; >>>>> >>> >>> sv-cc@eda.org; sv-ac@eda.org >>>>> >>> >>> Subject: Re: [sv-bc] RE: [sv-ac] New keywords in SV-AC >>>>proposals >>>>> >>> >>> >>>>> >>> >>> >>>>> >>> >>> >From: "Stuart Sutherland" <stuart@sutherland-hdl.com> >>>>> >>> >>> >>>>> >>> >>> >I am very concerned about some of the proposed new >>keywords, >>>>> >>> >>specifically: >>>>> >>> >>> > >>>>> >>> >>> > checker, free, global, implies, let, next, restrict, >>>>strong, >>>>> >>> until, >>>>> >>> >>> > weak >>>>> >>> >>> > >>>>> >>> >>> >These are common English words that are likely to be in >>use >>>>as >>>>> >>> >>> >identifiers in existing code. >>>>> >>> >>> >>>>> >>> >>> I have tried compiling a suite of 88 customer designs with >>>>these >>>>> >>> >>> keywords reserved in our parser. 18 (or 20%) fail to >>compile. >>>>> >>This >>>>> >>> >>> figure may be somewhat low, since some of these testcases >>>>appear >>>>> >>to >>>>> >>> have >>>>> >>> >>> been run through obfuscators before being given to us. >>>>> >>> >>> >>>>> >>> >>> The offending keywords were: >>>>> >>> >>> >>>>> >>> >>> next: 7 testcases >>>>> >>> >>> free: 7 testcases >>>>> >>> >>> global: 4 testcases >>>>> >>> >>> checker: 1 testcase >>>>> >>> >>> weak: 1 testcase >>>>> >>> >>> >>>>> >>> >>> Note that the numbers do not add up to 18 testcases, because >>>>> some >>>>> >>> >>> testcases failed with conflicts on more than one keyword. >>>>> >>> >>> >>>>> >>> >>> Also note that 'next' is particularly problematic, since it >>is >>>>> >>> already >>>>> >>> >>> used as an identifier in a built-in method in SV. One of >>>>these >>>>> >>> customer >>>>> >>> >>> tests was SV and ran into this issue. >>>>> >>> >>> >>>>> >>> >>> Steven Sharp >>>>> >>> >>> sharp@cadence.com >>>>> >>> >>> >>>>> >>> >>> >>>>> >>> >>> -- >>>>> >>> >>> This message has been scanned for viruses and dangerous >>>>content >>>>> by >>>>> >>> >>> MailScanner, and is believed to be clean. >>>>> >>> >>> >>>>> >>> >>> >>>>> >>> >>> -- >>>>> >>> >>> This message has been scanned for viruses and dangerous >>>>> >>> >>> content by *MailScanner* >>>>> <http://www.mailscanner.info/>, >>>>> >>> and >>>>> >>> >>is >>>>> >>> >>> believed to be clean. >>>>> >>> >> >>>>> >>> >>-- >>>>> >>> >>>>> >>>>-------------------------------------------------------------------- >>>>> >>> >>Gordon Vreugdenhil 503-685-0808 >>>>> >>> >>Model Technology (Mentor Graphics) >>>>> gordonv@model.com >>>>> >>> >> >>>>> >>> >> >>>>> >>> >>-- >>>>> >>> >>This message has been scanned for viruses and dangerous >>>>> >>> >>content by MailScanner, and is believed to be clean. >>>>> >>> >>>>> >>> >>>>> >>--------------------------------------------------------------------- >>>>> >>> Intel Israel (74) Limited >>>>> >>> >>>>> >>> This e-mail and any attachments may contain confidential >>material >>>>> for >>>>> >>> the sole use of the intended recipient(s). Any review or >>>>> distribution >>>>> >>> by others is strictly prohibited. If you are not the intended >>>>> >>> recipient, please contact the sender and delete all copies. >>>>> >>> >>>>> >>> >>>>> >>> -- >>>>> >>> This message has been scanned for viruses and dangerous >>>>> >>> content by MailScanner, and is believed to be clean. >>>>> >>> >>>>> >>>>> >>--------------------------------------------------------------------- >>>>> Intel Israel (74) Limited >>>>> >>>>> This e-mail and any attachments may contain confidential material >>for >>>>> the sole use of the intended recipient(s). Any review or >>distribution >>>>> by others is strictly prohibited. If you are not the intended >>>>> recipient, please contact the sender and delete all copies. >>>> >>>> >>>>-- >>>>This message has been scanned for viruses and dangerous content by >>>>MailScanner, and is believed to be clean. >>>> >> >>--------------------------------------------------------------------- >>Intel Israel (74) Limited >> >>This e-mail and any attachments may contain confidential material for >>the sole use of the intended recipient(s). Any review or distribution >>by others is strictly prohibited. If you are not the intended >>recipient, please contact the sender and delete all copies. >> >> >>-- >>This message has been scanned for viruses and >>dangerous content by MailScanner, and is >>believed to be clean. >> --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Mar 13 09:18:54 2008
This archive was generated by hypermail 2.1.8 : Thu Mar 13 2008 - 09:20:45 PDT