RE: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals

I think that this freevar was once proposed, but not used to make it
more difficult for people to write nondeterministic checker variables.
But I agree with the name change.

ed


> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Bustan, Doron
> Sent: Thursday, March 13, 2008 2:20 AM
> To: Korchemny, Dmitry; Brad Pierce
> Cc: sv-ac@eda.org
> Subject: RE: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC
> proposals
> 
> I agree
> 
> Doron
> 
> >>-----Original Message-----
> >>From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
> On
> >>Behalf Of Korchemny, Dmitry
> >>Sent: Wednesday, March 12, 2008 11:26 PM
> >>To: Brad Pierce
> >>Cc: sv-ac@server.eda.org
> >>Subject: FW: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC
> >>proposals
> >>
> >>I agree with Brad. What do other people think?
> >>
> >>Thanks,
> >>Dmitry
> >>
> >>-----Original Message-----
> >>From: Brad Pierce [mailto:Brad.Pierce@synopsys.com]
> >>Sent: Wednesday, March 12, 2008 10:11 PM
> >>To: Korchemny, Dmitry
> >>Subject: RE: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC
> >>proposals
> >>
> >>Dmitry,
> >>
> >>Another option with 'free' is to use
> >>
> >>     freevar
> >>
> >>Instead of
> >>
> >>     free checkvar
> >>
> >>-- Brad
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> >>Korchemny, Dmitry
> >>Sent: Wednesday, March 12, 2008 12:11 PM
> >>To: Steven Sharp; stuart@sutherland-hdl.com; sv-bc@eda.org;
> >>sv-ec@eda.org; sv-cc@eda.org; sv-ac@eda.org
> >>Subject: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC
> proposals
> >>
> >>Hi all,
> >>
> >>Adding any new keyword brings potential backward compatibility
> problems.
> >>I can just mention that introducing "priority" keyword required
> changing
> >>our every second design, therefore this is feasible. As I can
> understand
> >>from the feedback I saw, the most problematic keywords are "next"
and
> >>"free". The suggestion I prefer is to rename "next" to "nexttime",
> maybe
> >>"free" can also be renamed into something like "nondet". I suggest
we
> >>discuss this at the next SV-AC meeting first, and then we can send
the
> >>new keywords to other committees for review.
> >>
> >>Thanks,
> >>Dmitry
> >>
> >>-----Original Message-----
> >>From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
> On
> >>Behalf Of Steven Sharp
> >>Sent: Tuesday, March 11, 2008 10:52 PM
> >>To: stuart@sutherland-hdl.com; 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
> >>
> >>
> >>>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.
> >>
>
>>---------------------------------------------------------------------
> >>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.