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