RE: [sv-ac] mantis 1550

Hi Manisha,
 
yes it is the intention, the assertion must see the $sampled value from
the clock tick before the current one, so it must see the non-updated
value of $past.
 
ed
 


________________________________

	From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
Of Kulshrestha, Manisha
	Sent: Thursday, November 02, 2006 2:14 PM
	To: Rich, Dave; john.havlicek@freescale.com; sv-ac@eda-stds.org
	Subject: RE: [sv-ac] mantis 1550
	
	

	Hi,
	
	I am still confused about these statements. In the proposal it
says that the value of $past is updated in the postponed region of the
simulation time step in which clock tick occurred. Now, if the $past is
used in the assertion, which value it will see: new value or old value.
As per this statement, it should be old value (assertions are evaluated
in Observe region) but that is not the intention (I think). 
	
	Manisha
	
	
	-----Original Message-----
	From: owner-sv-ac@server.eda.org on behalf of Rich, Dave
	Sent: Thu 11/2/2006 7:53 AM
	To: john.havlicek@freescale.com; sv-ac@server.eda-stds.org
	Subject: RE: [sv-ac] mantis 1550
	
	I think the semantics of the return value of these function is
no
	different then the simple Verilog system function $time.
	
	You have to distinguish between the values returned by
references to the
	function versus evaluation events scheduled by a processes
waiting on
	the event expression. This is somewhat harder to put into words
than to
	actually implement it.
	
	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 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.
	
	Dave
	
	
	> -----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
	>
	> Hi Ed:
	>
	> 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.
	>
	> 1. I don't think we have yet clarified when the return values
of these
	>    functions change.  You say that $sampled is stable
throughout the
	>    simulator timestep and that $past changes in the postponed
region.
	>
	>    Can the return value of $past really change in the
postponed
	region?
	>
	>    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.
	>
	> 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
	>
	>       @($sampled(p)) S1
	>
	>    when written in various contexts (e.g., in a module, in a
program)?
	>
	>
	> 3. I would like to see $rose, $fell, and $stable defined in
terms of
	>    $sampled and $past.  I think this should be easy.
	>
	> We may need to get some SV-BC or other help with items 1 and
2.
	>
	> Best regards,
	>
	> John H.