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