[sv-ac] Email ballot result (August 15)

Below are the results of the email ballot:

2328 3033 3295

Ashok Bhatt

Yes Yes Laurence Bisht

Yes Yes Yes Eduard Cerny

Yes Yes Yes Ben Cohen

Tapan Kapoor

Jacob Katz

Yes Yes No Scott Little

Yes No Yes Manisha Kulshrestha

Yes No Yes Anupam Prabhakar

Yes Yes Yes Erik Seligman

Samik Sengupta

Yes Yes Yes Tom Thatcher

Issue 2328 passed with friendly amendments: 7y/0n/0a

Issue 3033 failed: 6y/2n/0a

Issue 3295 failed: 7y/1n/0a

Comments

Erik:

2328
Friendly amendment:
In 16.6.3, "described in (see 16.15.6.1)." ==> "described in 16.15.6.1."

3033

Friendly amendment: we use the term 'static deferred assertion' here, which makes sense to me, but has not been defined or used before. So I think we should enhance the changes to 16.4.3 a bit:

REPLACE

A deferred assertion statement may also appear outside procedural code, used as a module_common_item.

WITH

A deferred assertion statement may also appear outside procedural code, in which case it is referred to as a static deferred assertion.

ADD at the end of the subclause

Although a static deferred assertion is treated as if inside an always_comb, it is not considered procedural code for the purpose of limitations on procedural code in checkers. See 17.3 for static deferred assertions in checkers.

Scott:

3033
This is implemented on top of 3213. The text stating this should be added in a more conspicuous place or colored in some way to draw additional attention to that statement.

In 17.9 there is some new text in the code example that is in black and should be in blue I believe.

I think that the first sentence of C.2.7 would be more clear if reworded as:
The always procedure is allowed in checkers by IEEE Std 1800-2009 in checkers, but always_comb, always_latch, and always_ff were forbidden.

3295
Have Shalom's comments/questions in the Notes section been addressed?

Anupam:

3033
'It shall be illegal to procedurally instantiate a checker if the elaborated checker contains procedural code.'
This change is not backward compatible. We need to clarify this.

Manisha:

3033
I also feel that putting the restriction that procedurally instantiated checkers cannot have any procedural code is a big restriction and also backward incompatible. The example of deferred assertion provided is not a real example as deferred assertions are not used in that way and having this restriction just so that deferred assertions work correctly is not right. In the last LRM, a lot of effort was put to define the functionality of checker instantiations in procedural code. Why are we throwing away all that well defined functionality. This looks like a big restriction as checkers in procedural code will not be able to have any modeling code.

2328
Friendly amendment:

Change the following sentence:
- Any dynamic data type elements captured for assertion evaluation shall continue to exist within the scope of the
assertion until the assertion evaluation completes.

To

- Elements of dynamic arrays, queues, and associative arrays that are sampled for assertion expression evaluation may get removed from the array or the array may get resized before the assertion expression is evaluated. These specific array elements sampled for assertion expression evaluation shall continue to exist within the scope of the assertion until the assertion expression evaluation completes.

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