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.Received on Wed Mar 12 06:20:20 2008
This archive was generated by hypermail 2.1.8 : Wed Mar 12 2008 - 06:21:00 PDT