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.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.