RE: [sv-ac] mantis 1550

That seems like a safe way forward. 

However, I believe that $sampled(x, @(posedge clk) ) is equivalent to
the corresponding clocking block definition:

clocking cb @(posedge clk);
  input #1step x;			// the #1step is optional
endclocking

And, the above declaration enables the use of:

  @(cb.x) ...

It would seem that we can define the semantics of $sampled in terms of
the equivalent clocking block definition. I think that part of the
problem is that $sampled uses a function syntax for a built-in construct
that may not behave as a function.

	Arturo

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Rich, Dave
Sent: Friday, November 03, 2006 7: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
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> >
> >