[sv-ac] Email ballot result (Due 25 April)

Below are the results of the email ballot:

3213 3295 3491
Yes Yes Ashok Bhatt
Laurence Bisht
No Yes Yes Eduard Cerny
Dana Fisman
Tapan Kapoor
Yes Yes Jacob Katz
No No Yes Scott Little
No Yes Yes Manisha Kulshrestha
Yes Yes Yes Anupam Prabhakar
Yes No Abstain Erik Seligman
Yes Yes Yes Samik Sengupta
No Yes Yes Tom Thatcher

Issues 3213 and 3295 failed.
Issue 3491 passed.

Comments and friendly amendments

Jacob

3295
The list of control_type, assertion_type, ..., in the body of clause 20.11 should be formatted/indented as a list to improve readability, I believe.

In the text "If assertion_type is not specified, then it defaults to 15 i.e. the system task applies to all types of assertion statements and expect statements. Similarly, if directive_type is not specified, then it defaults to 7 i.e. the system task applies to all types of directives. Multiple assertion_type and directive_type values can be specified at a time by OR-ing different values e.g. a task with directive_type value of 3 (which is same as 1 | 2) shall apply to assert and cover directives. The directive_type value is not checked for assertion_type 8 (expect statement)", commas should precede all the appearances of "i.e." and "e.g.".

I think all the == signs in the definition of the backward compatible task names should be replaced with "is equivalent to", because equality is not defined for tasks (they don't return values).

Erik

3213
Friendly amendment: in 16.9.3, "Evaluating expression in the concurrent context is explained in 16.5.2.", 'expression' è 'expressions'.

3295
Getting closer, but I think it still needs too many small edits to approve at this time.
- The list of arguments at the bottom of the first paragraph of new text on p.3 should be a bulleted list.
¾ control_type...
¾ assertion_type...
              etc.
- Same paragraph: "This system task provides capability" è "This system task provides the capability", "The $assertcontrol" è "$assertcontrol"
- P.4- PassOff bullet: "while the execution of pass action" è "while the execution of the pass action"
- Last paragraph on p.4 needs some rewriting.
o "If assertion_type is not specified, then it defaults to 15 i.e. the system task applies to all types of assertion statements and expect statements."è "If assertion_type is not specified, then it defaults to 15 (Concurrent|Simple_Immediate|Deferred_Immediate|Expect) and the system task applies to all types of assertion statements and expect statements."
o "Similarly, if directive_type is not specified, then it defaults to 7 i.e. the system task applies to all types of directives" è "Similarly, if directive_type is not specified, then it defaults to 7 (Assert|Cover|Assume) and the system task applies to all types of directives
o I think the concept of constructing arguments using ORing needs to be described before the concept is used in the above sentences.
o We should also avoid the mid-sentence run-on i.e.s and e.g.s.
- I think each argument should have its own (possibly short) paragraph for clarity, rather than trying to pack them all into the large one at the bottom of p.4.
In the example on p.5, I think we should say SIMPLE_IMMEDIATE and DEFERRED_IMMEDIATE instead of S_IMMEDIATE and D_IMMEDIATE. If we really need to save characters, we can put a comment next to the symbols stating their full meaning: let S_IMMEDIATE = 2; /* Simple Immediate */

3491
don't understand the formal semantics well enough to figure out if this is ultimately the desired expression, so I'll have to trust you guys!

Tom

3213
I do not agree to the deprecation of the $sampled system function. This function is used by everyone who writes assertions, because any message in an action block must use $sampled to display the value of the variable that was used in the assertion evaluation. The deprecation of this function means re-training everyone who writes assertions.

Most assertion authors are writing assertions for simulation environments, not for formal verification. They will probably never use constructs like random checker variables. The benefits of this change will be seen only be the few people who use these advanced constructs.

Another reason to keep $sampled is that the name is much more intuitive than $concurrent.

Manisha

3213
I need more time to review this.

Ed

3213
I think that $sampled should be maintained for backward compatibility reasons. There are too many designs and tests that use it.

Scott

3213

16.5.1 mentions sampled value functions and references 16.9.3 which defines concurrent value functions. I believe this should be changed to sampled value functions.

I am confused about the definition of what happens when concurrent value functions are called at or before the time when the first clocking even occurs. It says that the concurrent value is compared with the sampled value. How does this work for items who sampled value isn't defined?

I also need more time to carefully go through this proposal.

3295

A few more changes...

In the paragraph before the argument description:
The $assertcontrol has different arguments as follows:
I don't understand why the word different is used. Are the arguments being compared to another similar function? Maybe reword as: The arguments to the $assertcontrol system task are described below.

In general I believe that "$assertcontrol system task" should replace all instances of "system task $assertcontrol"

In the description of Lock, "Once a $assertcontrol" should be "Once an $assertcontrol"

There is a font problem in the description of VacuousOff, "subsequent $assertcontrol with a control_type" the only Courier font should be $assertcontrol.

I would suggest modifying the following paragraph:
The system task $assertcontrol provides finer control over selecting the assertions compared to system tasks $asserton, $assertoff and $assertkill. The system tasks $asserton, $assertoff and $assertkill are provided for convenience and backward compatibility and they can be defined as:

As shown below:
The $assertcontrol system task provides finer grain assertion selection controls than the $asserton, $assertoff and $assertkill system tasks. The $asserton, $assertoff and $assertkill system tasks are provided for convenience and backward compatibility. They can be defined as:

Samik

3295
Friendly (but essential edit):

Unless I am mistaken or looking at an older version of the proposal, the definitions of $asserton/off/kill in page 5 are wrong. For example, the proposal says :

n $asserton[(levels[, list])] == $assertcontrol(2, 7, 7, levels [,list])
whereas it should be

n $asserton[(levels[, list])] == $assertcontrol(3, 7, 7, levels [,list])

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