RE: [sv-ac] mantis 1550

I think that, as per the current proposal for 1550, there is no need to
have the clocked version of the function, but if you think that this is
operational, I can add it to the prposal. 
ed

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of Arturo Salz
> Sent: Friday, November 03, 2006 6:47 PM
> To: Rich, Dave; john.havlicek@freescale.com; sv-ac@eda-stds.org
> Subject: 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
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > >
> > >
> 
> 
>