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
> > 
> 
> 
>