RE: [sv-ac] mantis 1550

John wanted to make it illegal, but I now think that might be too
difficult to enforce.

Currently in SV if you write

time t;
assign t = $time + 50;

It is not illegal. This only executes once at time 0 and t will be
constant 50. That might be enough to keep people from using $sample in
an event expression anyway.

Dave


> -----Original Message-----
> From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> Sent: Friday, November 03, 2006 8:09 AM
> To: Rich, Dave; john.havlicek@freescale.com; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] mantis 1550
> 
> Therefore, should I add a statement that no sampled value function can
> be used as the source of a value-change event? Does this mean that the
> following statement would only execute once at time 0?
> assign v = $past(x);
> Isn't that a bit drastic?
> 
> ed
> 
> 
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> > Behalf Of Rich, Dave
> > Sent: Friday, November 03, 2006 10:54 AM
> > To: john.havlicek@freescale.com; sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] mantis 1550
> >
> > I agree with your conclusion.
> >
> >
> > > -----Original Message-----
> > > From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org]
> > On
> > > Behalf Of John Havlicek
> > > Sent: Friday, November 03, 2006 4:53 AM
> > > To: sv-ac@server.eda-stds.org
> > > Subject: Re: [sv-ac] mantis 1550
> > >
> > > Hi Dave:
> > >
> > > My intuition is that the generation of events from changes in the
> > > return values of sampled value functions will be useful as a more
> > > abstract view of the various changes in their arguments.
> > >
> > > Nevertheless, the reluctance to define such generated events is
> > > understandable in the absence of a clear use model.
> > >
> > > In this case, though, I prefer that we make illegal the usage of
> > > sampled value functions in contexts that require the definition of
> > > events generated from their changes.
> > >
> > > In that way, we can preserve the possibility of defining
> > those events
> > > at a later time.
> > >
> > > Best regards,
> > >
> > > John H.
> > >
> > > > X-Authentication-Warning: server.eda-stds.org: majordom set
sender
> > to
> > > owner-sv-ac@eda.org using -f
> > > > X-MimeOLE: Produced By Microsoft Exchange V6.5
> > > > Content-class: urn:content-classes:message
> > > > Date: Thu, 2 Nov 2006 13:19:19 -0800
> > > > X-MS-Has-Attach:
> > > > X-MS-TNEF-Correlator:
> > > > Thread-Topic: [sv-ac] mantis 1550
> > > > Thread-Index:
> > > Acb+pxg/+SSVD5vxR0KCaRZVriKPnwAAE5fgAAJ3xsAAANtMEAABftvQAAIMtPA=
> > > > From: "Rich, Dave" <Dave_Rich@mentor.com>
> > > > X-OriginalArrivalTime: 02 Nov 2006 21:19:27.0754 (UTC)
> > > FILETIME=[940CA6A0:01C6FEC4]
> > > > X-Virus-Status: Clean
> > > > X-MIME-Autoconverted: from quoted-printable to 8bit by
server.eda-
> > > stds.org id kA2LJTb2022874
> > > > Sender: owner-sv-ac@eda.org
> > > >
> > > > Ed,
> > > > Arturo and Stu raise a good point: does it even make
> > sense to allow
> > > > sampled functions to generate an event? $time does not generate
> > event
> > > > when the time changes. The reason for $time's behavior has more
to
> > do
> > > > with historical Verilog-XL and the fact that it only
> > created events
> > when
> > > > the inputs to a function changed, not based on when the
> > result of a
> > > > function changed.
> > > >
> > > > Using that definition, $sample(x) would only be evaluated when
the
> > raw
> > > > signal 'x' changes, and an update event would only be generated
if
> > the
> > > > return value was different from the last evaluation.
> > > >
> > > >
> > > > Dave
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: owner-sv-ac@server.eda.org
> > [mailto:owner-sv-ac@server.eda.org]
> > > > On
> > > > > Behalf Of Eduard Cerny
> > > > > Sent: Thursday, November 02, 2006 12:12 PM
> > > > > To: stuart@sutherland-hdl.com; sv-ac@server.eda-stds.org
> > > > > Subject: RE: [sv-ac] mantis 1550
> > > > >
> > > > > Hi Stu,
> > > > >
> > > > > I guess the question was related to the following: what
> > happens if
> > you
> > > > > write @($smapled(x)) where will it be scheduled. In my
> > view and if
> > I
> > > > > understood what Arturo wrote, if $sampled changed for
> > the current
> > time
> > > > > step and the event control is is in a module, it will unblock
in
> > > > active
> > > > > region, if it is in program it will unblock in reactive
region.
> > > > >
> > > > > ed
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> > > > > > Behalf Of Stuart Sutherland
> > > > > > Sent: Thursday, November 02, 2006 2:55 PM
> > > > > > To: sv-ac@eda-stds.org
> > > > > > Subject: RE: [sv-ac] mantis 1550
> > > > > >
> > > > > >
> > > > > > This message thread has me confused.  I do not understand
how
> > > > > > a "sampled"
> > > > > > value can have an "update" event.  From my user point of
> > > > > > view, I expect
> > > > > > $sampled and $past simply return to me the STABLE value of a
> > > > > > signal as it
> > > > > > exists in the Preponed region of the specified time step.
It
> > > > > > makes no sense
> > > > > > for a STABLE value to need an update event!
> > > > > >
> > > > > > I use currently use $sampled in pass/fail action blocks as a
> > > > > > way to print
> > > > > > the Preponed sampled values used by an assertion to
determine
> > > > > > if a sequence
> > > > > > passed or failed.  If you now tell me that the
> > sampled value can
> > be
> > > > a
> > > > > > changing value, then $sampled and $past become completely
> > worthless.
> > > > > >
> > > > > > Furthermore, if I am reading the message thread correctly,
> > > > > > there seems to be
> > > > > > discussion about acting on changes in the Postponed region.
> > > > > > This region is
> > > > > > very clearly defined as the point in a time step where all
> > > > > > activity for that
> > > > > > time step has been processed, and NO MORE EVENT ACTIVITY CAN
> > > > > > OCCUR.  Once
> > > > > > simulation reaches the Postponed region, there are no more
> > > > > > iterations within
> > > > > > the time step to process the affects of changes, and changes
> > > > > > are strictly
> > > > > > prohibited.  It is a read-only region.
> > > > > >
> > > > > > Can someone please explain to me what the AC
> > committee is trying
> > to
> > > > > > accomplish by looking for changes on a $sampled or
> > $past value?
> > > > > >
> > > > > > Stu
> > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > Stuart Sutherland
> > > > > > stuart@sutherland-hdl.com
> > > > > > +1-503-692-0898
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: owner-sv-ac@server.eda.org
> > > > > > > [mailto:owner-sv-ac@server.eda.org] On Behalf Of Arturo
Salz
> > > > > > > Sent: Thursday, November 02, 2006 11:18 AM
> > > > > > > To: Eduard Cerny; john.havlicek@freescale.com;
> > > > > > > sv-ac@server.eda-stds.org
> > > > > > > Subject: RE: [sv-ac] mantis 1550
> > > > > > >
> > > > > > > I believe a more accurate statement would be:
> > > > > > >
> > > > > > > "Sampled values such as those returned by the $sampled and
> > $past
> > > > > > > functions are updated in the Postponed region"
> > > > > > >
> > > > > > > However, currently writing something like
> > > > > > > 	always @($time) ...
> > > > > > > will not work as expected. If we expect $sampled
> > and $past to
> > > > > > > behave in
> > > > > > > this manner then they must be defined that way explicitly.
> > > > > > >
> > > > > > > 	Arturo
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> > Behalf
> > > > Of
> > > > > > > Eduard Cerny
> > > > > > > Sent: Thursday, November 02, 2006 9:51 AM
> > > > > > > To: john.havlicek@freescale.com; sv-ac@eda-stds.org
> > > > > > > Subject: RE: [sv-ac] mantis 1550
> > > > > > >
> > > > > > > Hi John,
> > > > > > >
> > > > > > > I will try to put something like that in the text...
> > > > > > >
> > > > > > > ed
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org]
On
> > > > > > > > Behalf Of John Havlicek
> > > > > > > > Sent: Thursday, November 02, 2006 12:47 PM
> > > > > > > > To: sv-ac@eda-stds.org
> > > > > > > > Subject: Re: [sv-ac] mantis 1550
> > > > > > > >
> > > > > > > > Hi Ed:
> > > > > > > >
> > > > > > > > Can we have a clear statement somewhere in 17.7.3 that
> > > > > > says that the
> > > > > > > > return values of all of the sampled value functions
change
> > > > > > > only in the
> > > > > > > > postponed region?
> > > > > > > >
> > > > > > > > Also, can we have a statement that update events due to
> > changes
> > > > in
> > > > > > > > sampled value functions are scheduled in the appropriate
> > > > > > > region of the
> > > > > > > > next time slot?  [It is still not clear to me that all
> > > > > > these will go
> > > > > > > > to the active region -- maybe some will go, e.g., to the
> > > > reactive
> > > > > > > > region.]
> > > > > > > >
> > > > > > > > If the redundancy is the bottleneck, one could say
> > > > > > > something like, "It
> > > > > > > > follows from the scheduling semantics (Section 9)
> > that <blah
> > > > > > > > blah blah>."
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > >
> > > > > > > > John H.
> > > > > > > >
> > > > > > > > > X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
> > > > > > > > > Content-class: urn:content-classes:message
> > > > > > > > > Date: Thu, 2 Nov 2006 07:58:41 -0800
> > > > > > > > > Thread-Topic: [sv-ac] mantis 1550
> > > > > > > > > Thread-Index:
> > Acb+j4hFCYP8sfsBR0avmxNqtXjgewABQSDgAADLaVA=
> > > > > > > > > From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
> > > > > > > > > X-OriginalArrivalTime: 02 Nov 2006 15:58:42.0631 (UTC)
> > > > > > > > FILETIME=[C50FED70:01C6FE97]
> > > > > > > > >
> > > > > > > > > That's what I had in mind and tried to explain.
> > > > > > > > > ed=20
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: owner-sv-ac@eda.org
[mailto:owner-sv-ac@eda.org]
> > On=20
> > > > > > > > > > Behalf Of Rich, Dave
> > > > > > > > > > Sent: Thursday, November 02, 2006 10:53 AM
> > > > > > > > > > To: john.havlicek@freescale.com; sv-ac@eda-stds.org
> > > > > > > > > > Subject: RE: [sv-ac] mantis 1550
> > > > > > > > > >=20
> > > > > > > > > > I think the semantics of the return value of these
> > > > > > > function is no
> > > > > > > > > > different then the simple Verilog system function
> > $time.=20
> > > > > > > > > >=20
> > > > > > > > > > You have to distinguish between the values returned
> > by=20
> > > > > > > > > > references to the
> > > > > > > > > > function versus evaluation events scheduled by a
> > > > > > > > processes waiting on
> > > > > > > > > > the event expression. This is somewhat harder to put
> > into=20
> > > > > > > > > > words than to
> > > > > > > > > > actually implement it.
> > > > > > > > > >=20
> > > > > > > > > > I think it is OK to say that the value that will be
> > > > > > > > returned by the
> > > > > > > > > > function is updated in the postponed region because
no
> > > > one=20
> > > > > > > > > > can schedule
> > > > > > > > > > a call in that region. You can also say that an
> > > > > > update event is
> > > > > > > > > > scheduled for the active region of the next time
slot.
> > > > > > > > > >=20
> > > > > > > > > > Dave
> > > > > > > > > >=20
> > > > > > > > > >=20
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: owner-sv-ac@server.eda.org
> > > > > > > > [mailto:owner-sv-ac@server.eda.org]
> > > > > > > > > > On
> > > > > > > > > > > Behalf Of John Havlicek
> > > > > > > > > > > Sent: Thursday, November 02, 2006 6:59 AM
> > > > > > > > > > > To: sv-ac@server.eda-stds.org
> > > > > > > > > > > Subject: [sv-ac] mantis 1550
> > > > > > > > > > >=20
> > > > > > > > > > > Hi Ed:
> > > > > > > > > > >=20
> > > > > > > > > > > In general, I like the semantics for $sampled and
> > $past
> > > > > > > > in your 1550
> > > > > > > > > > > proposal, but I have some concerns that make me
vote
> > > > > > > > "no" at this
> > > > > > > > > > > time.
> > > > > > > > > > >=20
> > > > > > > > > > > 1. I don't think we have yet clarified when the
> > return=20
> > > > > > > > > > values of these
> > > > > > > > > > >    functions change.  You say that $sampled
> > is stable
> > > > > > > > throughout the
> > > > > > > > > > >    simulator timestep and that $past
> > changes in the=20
> > > > > > > > > > postponed region.
> > > > > > > > > > >=20
> > > > > > > > > > >    Can the return value of $past really
> > change in the
> > > > > > > postponed
> > > > > > > > > > region?
> > > > > > > > > > >=20
> > > > > > > > > > >    I think it is bad if there can be
> > calls/references
> > > > > > > > to any of the
> > > > > > > > > > >    sampled value functions between the
> > point that the
> > > > > > > > return value
> > > > > > > > > > >    of one changes and the point that the
> > return value
> > > > > > > of another
> > > > > > > > > > >    changes in the same timestep.
> > > > > > > > > > >=20
> > > > > > > > > > > 2. A related question is that of the semantics of
> > > > > > > > events that refer
> > > > > > > > > > >    to sampled value functions.  The
> > intuition seems to
> > > > > > > > be that the
> > > > > > > > > > >    return values of sampled value functions
> > change "in
> > > > > > > > between" the
> > > > > > > > > > >    simulation timesteps, so when do we schedule
> > > > > > something like
> > > > > > > > > > >=20
> > > > > > > > > > >       @($sampled(p)) S1
> > > > > > > > > > >=20
> > > > > > > > > > >    when written in various contexts (e.g., in a
> > > > > > module, in=20
> > > > > > > > > > a program)?
> > > > > > > > > > >=20
> > > > > > > > > > >=20
> > > > > > > > > > > 3. I would like to see $rose, $fell, and $stable
> > > > > > > > defined in terms of
> > > > > > > > > > >    $sampled and $past.  I think this should be
easy.
> > > > > > > > > > >=20
> > > > > > > > > > > We may need to get some SV-BC or other help with
> > > > > > > items 1 and 2.
> > > > > > > > > > >=20
> > > > > > > > > > > Best regards,
> > > > > > > > > > >=20
> > > > > > > > > > > John H.
> > > > > > > > > >=20
> > > > > > > > > >=20
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >