RE: [sv-ac] mantis 1550

Ed,

Let me clarify what I meant.

If you write
   always @($time) $display( "Boo" );
the $display statement is never executed. This is regardless of when the
statement will unblock. If those functions are defined such that they do
produce an event (using Stu's terminology) and are able to unblock a
calling process then that must be explicitly defined. I don't believe
there is any problem regarding what region the process will unblock. As
you wrote, if the process executing the statement is Reactive then it
wakes up in the Reactive region otherwise it wakes up in the Active
region. This, BTW, is exactly how things work today. For example:

	reg sig;
	module m;  initial @sig; endmodule
	program p; initial @sig; endprogram

Both module and program statements are triggered by a change in sig,
but, the module statement wakes up in the Active region whereas the
program statement wakes up in the Reactive region.

	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 12:12 PM
To: stuart@sutherland-hdl.com; sv-ac@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
> > > 
> > 
> > 
> > 
> 
>