RE: [sv-ac] 1698 sampled value functions

From: Korchemny, Dmitry <dmitry.korchemny_at_.....>
Date: Sun Feb 03 2008 - 08:05:23 PST
Hi Lisa,

 

One minor comment: Page 5:

 

"In the case of $past(x,number_of_ticks,,@clk), updates occur in the
timestep in

which the clocking event occurs, and the value is the value that
$sampled(x) had in the

timestep number_of_ticks prior in which the clocking event @clk
occurred."

 

"$sampled" should be in courier 9.

 

Thanks,

Dmitry

 

________________________________

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Lisa Piper
Sent: Saturday, February 02, 2008 9:21 PM
To: john.havlicek@freescale.com; eduard.cerny@synopsys.com;
Manisha_Kulshrestha@mentor.com
Cc: sv-ac@server.eda.org
Subject: [sv-ac] 1698 sampled value functions

 

<<1698_sampled_value_functions_2008_02_02.pdf>> 

Hi Manisha, Ed, John, and anyone else willing,

I have updated the 1698 proposal to try to address the feedback from
Manisha.  Thanks to John for helping me with this. As it turns out,
Mantis 1731 was where those earlier discussions were. That text had not
been accounted for in this proposal since it is not in draft 4 and I had
forgotten about it.  In any case, that proposal relaxed the restrictions
on clocks used in sampled value functions in assertions.  The wording
that was used was re-applied here.  Below is the synopsis of what was
changed in this proposal and the updated proposal is attached.  I would
appreciate your review.  I will be traveling but hope to be able to have
this ready for vote by Tuesday. It will probably need to be a whole new
vote given the significance of the changes.

Lisa

Changes:

Synthesis is not discussed since the standard does not address this.
What is important is that the functions retain their value between
updates. Implementation is not discussed since any implementation will
raise questions about the region in which the update occurs, where in
fact, it is irrelevant since sampled value functions use sampled values
that do not change throughout the timestep. There can be varying
implementations depending on the context from which the sampled value
function is used - all that is important is that it is updated prior to
the expression in which it is used. So what is stated in the proposal
is:

a.      $sampled(x) will always return the value of x from the Preponed
region of the timestep.

b.      Change value functions like $rose(x,@clk), when triggered by the
associated clocking event, will compare the sampled value of the current
timestep to the value that $sampled(x) had in the most recent strictly
prior timestep in which the clocking event @clk occurred.  (this was
what Mantis 1731 said)

c.      In the case of $past(x,no_of_timesteps,,@clk), updates occur in
the timestep in which the clocking event occurs, and the value is the
value that $sampled(x) had in the timestep no_of_timesteps prior in
which the clocking event occurred.

d.      Functions retain their value between updates. Should the clocks
be the same for the sampled value function and the assignment or
expression in which it is used, the sampled value function shall always
be updated first.The restriction that the sampled value function outside
of assertions must use the same clock as the inferred clock was
therefore removed.


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sun Feb 3 08:06:02 2008

This archive was generated by hypermail 2.1.8 : Sun Feb 03 2008 - 08:06:32 PST