RE: [sv-ac] Call to vote: Due May 2

Hi Manisha,

Please, see my comments below. I uploaded a new version http://www.eda-stds.org/mantis/file_download.php?file_id=4976&type=bug addressing your and Ed's comments.

Please, see also my comments below.

Thanks,
Dmitry

From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Friday, April 29, 2011 09:38
To: Korchemny, Dmitry; sv-ac@eda-stds.org
Subject: RE: [sv-ac] Call to vote: Due May 2

Mantis 3213 ____ Yes __ X __ No

http://www.verilog.org/mantis/view.php?id=3213

http://www.eda-stds.org/mantis/file_download.php?file_id=4961&type=bug

This document needs more work. Here are my comments:

1. In 16.2, instead of 'evaluate their variables' it should be 'evaluate their expressions'.

[Korchemny, Dmitry] Fixed.

2. In 16.5.1, the second sentence of first paragraph is incomplete.

[Korchemny, Dmitry] I think this sentence is complete. It reads "The notion of sampled values introduced here is used in 16.5.2 in the definition of a concurrent context."

 Also, last sentence of the last paragraph is incomplete.

[Korchemny, Dmitry] Same comment. "For example, the sampled value y at time 0, where y is of type logic, is X." I agree that this sentence is a bit clumsy, but from the grammar point it should be correct.

3. In 16.5.2, it mentions 'such as checker arguments', it would be better to get rid of this reference as this will require changes again when checker argument sampling changes.

[Korchemny, Dmitry] I wanted to make this proposal self-contained. This statement is correct at the current stage. The future proposals will have to modify it in any case (e.g., always procedures in checkers + new reference).

4. In the same section, the value of an automatic variable in concurrent context is not its current value. The value of automatic variable is its const value (which you get by doing const'()). This const value is picked up at the time statements corresponding to concurrent assertion or checker instantiation are reached in the procedural evaluation. So, the explanation of const cast expression has to be re-written.

[Korchemny, Dmitry] I would separate the definition of a concurrent value of an automatic variable and its stability during the evaluation attempt. The proposal has the following sentence: "A procedural concurrent assertion shall save the value of any const expression or automatic variable at the time the assertion evaluation attempt is added to the procedural assertion queue." What language would you suggest?

5. In 16.6, it is not clear if automatic variables are allowed in disable iff condition. If they are, then their constant value has to be used.

[Korchemny, Dmitry] Good catch. It should be useful to allow automatic variables in disable iff clauses, such as disable iff (rst[i]) something(i). I could not find any restriction in the current LRM and it should have different value in different attempts. This issue certainly deserves clarification, but I don't think it should be part of this proposal.

6. 16.9.3, In the paragraph after example, sentence "This is because in action blocks are evaluated .." seems to be missing something.

[Korchemny, Dmitry] "in" is redundant. Fixed.

7. 16.9.4, the deleted part for $rising_gclk() is wrong.

[Korchemny, Dmitry] Fixed.

Also, I do not understand the meaning of 'from the postponed region of' in the sentence.

[Korchemny, Dmitry] Changed "from" to "in" in this and similar sentences.

8. 16.15.6.1, the deleted part at the beginning is not completely redundant as it tries to remove any confusion. It should be mentioned that concurrent values of the expressions are used for procedural assertions also. Now, explanation of const expression can follow that statement.

[Korchemny, Dmitry] I would like to have more discussion on this comment. The current version of the LRM contrasts static and procedural assertions since there is a difference in their behavior. This proposal says that the assertions use concurrent values. Why should this be confirmed for procedural assertions?

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.