RE: [sv-ac] New version of 3213 uploaded

Hi Dmitry:

Okay, right. I now see that in the proposal. I missed it on my initial skim.

Thanks,
Scott

> -----Original Message-----
> From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> Sent: Thursday, April 14, 2011 7:24 AM
> To: Little Scott-B11206; thomas.thatcher@oracle.com
> Cc: sv-ac@eda-stds.org
> Subject: RE: [sv-ac] New version of 3213 uploaded
>
> Hi Scott,
>
> Annex C contains a description of deprecated constructs. It is also
> possible to add a note in the appropriate place with a reference to
> Annex C.
>
> Thanks,
> Dmitry
>
> -----Original Message-----
> From: Little Scott-B11206 [mailto:B11206@freescale.com]
> Sent: Thursday, April 14, 2011 15:21
> To: Korchemny, Dmitry; thomas.thatcher@oracle.com
> Cc: sv-ac@eda-stds.org
> Subject: RE: [sv-ac] New version of 3213 uploaded
>
> Hi Dmitry:
>
> Okay, that seems like an odd way to deprecate features. Is there
> anywhere in the LRM where a user can go to find out which features have
> been deprecated in a new version of the LRM and which new features are
> intended to replace the deprecated features?
>
> If that is the way deprecation is done in SystemVerilog I guess I am
> fine with it. I don't see any practical use for $sampled with the
> addition of $concurrent.
>
> Thanks,
> Scott
>
> > -----Original Message-----
> > From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> > Sent: Thursday, April 14, 2011 7:15 AM
> > To: Little Scott-B11206; thomas.thatcher@oracle.com
> > Cc: sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] New version of 3213 uploaded
> >
> > Hi Scott,
> >
> > Deprecation does not require replacing $sampled with $concurrent in
> the
> > existing code, it just says don't use it, but use $concurrent
> instead.
> > Leaving $sampled in the LRM would mean that there are some situations
> > where it is useful. For example, the LRM 2009 deprecates the sequence
> > method ended, but this certainly does not mean that all users had to
> > replace ended with triggered in their existing code. It is expected
> > that the tools continue to support deprecated constructs. It is
> always
> > better to deprecate constructs as early as possible in order to
> > eliminate their usage in the future.
> >
> > Thanks,
> > Dmitry
> >
> > -----Original Message-----
> > From: Little Scott-B11206 [mailto:B11206@freescale.com]
> > Sent: Thursday, April 14, 2011 15:08
> > To: Korchemny, Dmitry; thomas.thatcher@oracle.com
> > Cc: sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] New version of 3213 uploaded
> >
> > Hi Dmitry:
> >
> > The reason to keep it is backward compatibility. Do we really expect
> > everyone to go back and do a search and replace of $sampled with
> > $concurrent in all of their deployed code?
> >
> > Thanks,
> > Scott
> >
> > > -----Original Message-----
> > > From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> > > Sent: Thursday, April 14, 2011 7:05 AM
> > > To: Little Scott-B11206; thomas.thatcher@oracle.com
> > > Cc: sv-ac@eda-stds.org
> > > Subject: RE: [sv-ac] New version of 3213 uploaded
> > >
> > > Hi Scott,
> > >
> > > This was not my initiative to deprecate $sampled though I cannot
> see
> > > any use for it. I can restore $sampled, but what is the reason to
> > keep
> > > it?
> > >
> > > Thanks,
> > > Dmitry
> > >
> > > -----Original Message-----
> > > From: Little Scott-B11206 [mailto:B11206@freescale.com]
> > > Sent: Thursday, April 14, 2011 14:57
> > > To: Korchemny, Dmitry; thomas.thatcher@oracle.com
> > > Cc: sv-ac@eda-stds.org
> > > Subject: RE: [sv-ac] New version of 3213 uploaded
> > >
> > > Hi Dmitry:
> > >
> > > I think you are asking for trouble if you remove $sampled from the
> > LRM.
> > > I don't know if I was present in the meeting where you mentioned
> > > deprecating it, but I don't think it is a good idea to deprecate
> > > $sampled right now. Maybe down the road that idea can be
> > entertained,
> > > but I would not support deprecating $sampled right now.
> > >
> > > Thanks,
> > > Scott
> > >
> > > > -----Original Message-----
> > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
> Of
> > > > Korchemny, Dmitry
> > > > Sent: Thursday, April 14, 2011 4:15 AM
> > > > To: thomas.thatcher@oracle.com
> > > > Cc: sv-ac@eda-stds.org
> > > > Subject: RE: [sv-ac] New version of 3213 uploaded
> > > >
> > > > Hi Tom,
> > > >
> > > > I don't think that this proposal resurrects the sampling
> semantics:
> > > the
> > > > sampling semantics remained exactly as it was. My initial
> proposal
> > > was
> > > > indeed to change the definition of sampling, e.g., to say that a
> > > > sampled value of an automatic variable is its current value. The
> > > > objection expressed by you and Gord in the F2F was that we were
> > > abusing
> > > > the term "sampling" and that it would be confusing to call a
> value
> > > > sampled when it is actually not. Therefore I am introducing a new
> > > > concept of a concurrent context.
> > > >
> > > > Please, see my specific comments below.
> > > >
> > > > Thanks,
> > > > Dmitry
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Thomas J Thatcher [mailto:thomas.thatcher@oracle.com]
> > > > Sent: Thursday, April 14, 2011 02:41
> > > > To: Korchemny, Dmitry
> > > > Cc: sv-ac@eda-stds.org
> > > > Subject: Re: [sv-ac] New version of 3213 uploaded
> > > >
> > > > Hi Dmitry,
> > > >
> > > > I read through the proposal for 3213, and I really don't think
> this
> > > is
> > > > the way we want to go. This proposal resurrects the sampling
> > > semantics
> > > > that we rejected at the face-to-face, but calls them concurrent
> > > > semantics rather than sampled semantics.
> > > >
> > > > I especially don't like the fact that the $sampled function is
> > > > completely deleted from the standard. The changes to 20.13
> delete
> > > the
> > > > $sampled function from the BNF. This would be a huge backward
> > > > compatibility headache for us. This would require that we touch
> > > every
> > > > single assert file we have ever written.
> > > >
> > > > [Korchemny, Dmitry] The previous version of this proposal
> retained
> > > the
> > > > function $sampled. In one of our recent meetings I was asked to
> > > > deprecate the function $sampled, and no objections were
> expressed.
> > > This
> > > > is what I did in the later versions. And indeed, I could not find
> > any
> > > > real life use case where the function $sampled would be the right
> > > > choice. Do you have any supporting example in mind?
> > > >
> > > > The current definition of sampling works for just about
> everything.
> > > > - Design variables are sampled.
> > > > - Checker variables (non-random) don't really need to be
> > sampled,
> > > > because they change after the Observed region, but sampling
> > > them
> > > > doesn't hurt.
> > > > Simulators could do optimization internally to skip the
> > > sampling
> > > > of these variables if that helped performance.
> > > >
> > > > [Korchemny, Dmitry] Non-blocking checker variables do need to be
> > > > sampled since if their value may change several times in the same
> > > > timestep.
> > > >
> > > > The only thing that doesn't work are random checker variables,
> > > because
> > > > they are assigned in Observed, and used in Observed.
> > > >
> > > > [Korchemny, Dmitry] I disagree: there are many exceptions from
> the
> > > > sampling rule, including local and automatic variables, sequence
> > > method
> > > > results, and free checker variables.
> > > >
> > > > I am OK with defining a $concurrent function, for the special
> cases
> > > > where it might be needed, but I don't want to re-write the whole
> > LRM
> > > to
> > > > remove all references to sampling.
> > > >
> > > > [Korchemny, Dmitry] I don't see a feasible alternative.
> > > > Many statements in the LRM are simply wrong when talking about
> > > sampled
> > > > values. Here are some examples:
> > > > * In an assertion, the sampled value is the only valid value of a
> > > > variable at a clock tick.
> > > > * The sampled values are used to evaluate ... Boolean
> > subexpressions
> > > > that are required to determine a match of a sequence.
> > > > * The Boolean expressions used in defining a sequence or property
> > > > expression shall be evaluated over the sampled values of all
> > > variables
> > > > (other than local variables as described in 16.10) and the
> current
> > > > values of local variables and of the sequence Boolean methods
> > > triggered
> > > > and matched (see 16.14.6).
> > > > 16.9.3
> > > > * The use of $sampled in assertions, although allowed, is
> > redundant,
> > > as
> > > > the result of the function is identical to the sampled value of
> the
> > > > expression itself used in the assertion.
> > > > etc.
> > > >
> > > > Also it seems like you are asking
> > > > the compiler writers for magic, if you expect to pass an
> expression
> > > and
> > > > have the function use the sampled value of the first variable in
> > that
> > > > expression, the current value of the second variable, and the
> > sampled
> > > > value of the third.
> > > >
> > > > [Korchemny, Dmitry] I am not asking anything different from what
> we
> > > > have today: if you have in some assertion the following
> expression:
> > > > a[i] & b & seq.triggered
> > > > Where i is an automatic variable, b is a design variable, and seq
> > is
> > > a
> > > > sequence, the current values of i and seq.triggers and the
> sampled
> > > > value of b will be taken.
> > > > Also, what happens now when you pass an expression as an actual
> > > > argument to a checker?
> > > > There might be, indeed, some additional work to compiler writers
> if
> > > > somebody decides to write something like
> > > > assign c = $concurrent(a & b), where a is a design variable and b
> > is
> > > an
> > > > automatic one. But this should be doable as it is doable in
> > > assertions,
> > > >
> > > > Keep in mind that most assertions are written for simulation.
> > These
> > > > assertions will probably not use any random checker variables.
> Any
> > > > changes we make will need to be transparent to these users.
> > > >
> > > > [Korchemny, Dmitry] How is this related? This proposal is
> relevant
> > > for
> > > > simulation not less than for formal verification. Thus, automatic
> > > > variables and embedded assertions are relevant mostly for
> > simulation.
> > > > The changes are absolutely transparent to the users since only
> the
> > > > terminology has changed. Even if the users have an implicit
> > > invocation
> > > > of function $sampled in their code, it will continue to work,
> since
> > > the
> > > > deprecation does not forbid its use.
> > > >
> > > > Tom
> > > >
> > > > On 04/12/11 02:19, Korchemny, Dmitry wrote:
> > > > > Hi all,
> > > > >
> > > > >
> > > > >
> > > > > I uploaded a new version of 3213 incorporating the reviewers'
> > > > comments:
> > > > > http://www.eda-
> > > > stds.org/mantis/file_download.php?file_id=4909&type=bug
> > > > > <http://www.eda-
> > > > stds.org/mantis/file_download.php?file_id=4909&type=bug>.
> > > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Dmitry
> > > > >
> > > > > ---------------------------------------------------------------
> --
> > --
> > > --
> > > > > 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*
> > <http://www.mailscanner.info/>,
> > > > 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.
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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.
> >
>
>
> ---------------------------------------------------------------------
> 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.