[sv-ac] Email ballot results (Due October-04)

2328 2386 2904 3134 3135
Yes Yes Yes Yes Yes Eduard Cerny
Yes Yes Yes Yes Yes Ben Cohen
Surrendra Dudani
Yes Yes Yes Yes Yes Dana Fisman
No Yes Yes Yes Yes John Havlicek
No Yes No Yes Yes Tapan Kapoor
Manisha Kulshrestha
No Yes Yes Yes Yes Scott Little
No Yes Yes Yes Yes Anupam Prabhakar
Yes Yes Yes Yes No Erik Seligman
Yes Yes Yes Yes Yes Samik Sengupta
No Yes Yes Yes Yes Tom Thatcher

Issues 2386 and 3134 passed. Issues 2328, 2904,

 and 3135 failed.

Comments.

2328

Dave Rich

The existing restriction against non-integer types made the other restrictions (like string, event) redundant as they were already non-integer types. By removing the restriction against non-integer types, you are opening up the door to unmentioned and yet to be defined additional types.

A better way to describe this is similar to the restrictions on event and constraints expressions. You can use any type in an expression as long as the result is an integral type. That means if you want to use a real variable in an assertion, you must either cast it to an integral value, or compare it using a recreational/equality operator to yield an integral result.

There are already restriction on reference members of classes in non-procedural contexts, but there should be nothing wrong with asserting (class_handle != null)

Scott, John, Tapan, Anupam, Tom
Need to address Dave Rich's comments.

2904

Tapan

I think it sort of contradicts the following para on page 318 (Section 16.6 - the para just before 16.6.1)
------
The disable condition specified in the disable iff clause will preempt the evaluation of the assertion in a
time step where a is 1 and the sampled value function returns a 1 as determined by the rules of evaluation
for use outside sequences described in 16.9.3.
-----------

Scott

Friendly amendment: evaluation attempt, inclusive,

3134

John

I was confused about whether the citation of nexttime [constant_expression] from 16.13.10 is indicating that a space should be removed before the "_". If so, this change needs to be clearer in the proposal.

3135

Ed

Minor correction: "Note thus that nexttime[0] and s_nexttime[0] acts as alignment operators."
Should read: "Note thus that nexttime[0] and s_nexttime[0] act as alignment operators."

Also, should "When the nexttime property is evaluated on cycle ..." be "When the nexttime property is evaluated on a cycle..." Similarly in the text for always

Ben

Please make the corrections below. Delete the "which", add "a" and "that"

... When the nexttime property is evaluated on a cycle which that is not a tick of the clock of the nexttime property then an alignment to the tick of the clock of the nexttime property should be applied before the above description. ...

...When the always property is evaluated on a cycle which that is is not a tick of the clock of the always property then an alignment to the tick of the clock of the always property should be applied before the above description....

Scott, John

Friendly amendments:

For both paragraphs: refer to the case where the cycle of evaluation of the always property begins in a timestep that is a tick of the clock of the always property.

For both paragraphs: In other wordsFor instance, it is more precise to say, for instance, that

For the second paragraph: Note that as in nexttime properties the above explanation

Erik

I think the explanation paragraphs of 3135 need some work; they don't sound very clear to me right now. I think it might make more sense to incorporate the possibility of the property and nexttime tick being different into the original descriptions, rather than amending with a paragraph below.

Something like this perhaps?: " The weak nexttime property nexttime property_expr evaluates to true if, and only if, either the first evaluation of property_expr on its clock, on or after the next tick of the nexttime clock, evaluates to true beginning at the next clock tick or there is no further clock tick.

---------------------------------------------------------------------
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.