Below are the results of the email ballot:
2476 2578 3033 3113 3206 3385
Yes Yes Yes Yes Ashok Bhatt
Laurence Bisht
Yes Yes Yes Yes Yes Yes Eduard Cerny
Yes Yes Yes Yes Yes Ben Cohen
Tapan Kapoor
Yes Yes Yes Yes No No Scott Little
Yes Yes Yes Yes Yes Yes Manisha Kulshrestha
Yes Yes No Yes Yes Yes Anupam Prabhakar
Yes Yes Yes Yes Yes Yes Erik Seligman
Samik Sengupta
Yes Yes Yes Yes Yes Tom Thatcher
Issue 2476 passed with friendly amendments: 8y/0n/0a.
Issue 2578 passed with friendly amendments: 7y/0n/0a.
Issue 3033 failed: 4y/1n/0a.
Issue 3133 passed with friendly amendments: 8y/0n/0a.
Issue 3206 failed: 7y/1n/0a.
Issue 3385 failed: 7y/1n/0a.
Comments
Erik:
2578
Friendly amendment: need an 'and' after the comma.
Ben:
3113
Friendly amendment: don't split the comment line; put in a separate line below unless it will fit in one line in the final document
Is there a way of telling if it will fit in one line in the file LRM?
a1: assert property (@(posedge clk) delay_example(x, y, 3, $, 2)); // this is legal
int z, d;
a2: assert property (@(posedge clk) delay_example(x, y, z, $, d)); // this is illegal, z and d are not elaboration-time constants
Scott:
2476
I assume a new pdf version with the track changes stuff removed.
3206
In the changes to 16.4:
-begin-end construct -> begin-end block
-begin should be Courier font (it is already bold)
-The previous text stated that the variable capture happens at the instant the deferred expression is evaluated. You change that to the word time. Is there a reason for this change?
-You use the terms pending report and pending report queue. I believe those should be pending assertion report and deferred assertion report queue respectively.
-The final reference to A2 is in the wrong font.
3385
-The fonts of the () don't match in the first sub-bullet of the first bullet where it talks about error_type
-"The first time each assertion fails, the arguments of the action block are evaluated, even though the action block itself is not executed." Isn't this statement true every time a deferred assertion fails? Maybe change to "Upon each deferred assertion failure, "
-I think it would add clarity to state that the pending reports are flushed from the deferred assertion report queue.
-I would like to see the structure of the bullets for the first and second failure more symmetric (and I would like to adjust the wording for a2 as I find the current wording awkward). Maybe something like:
*Upon the second failure of a1, function error_type is called with opcode == 0, so assertion func_assert passes.
*Upon the second failure of a2, the value of 0 is used for the expression opcode.
-In the final paragraph you talk about the evaluation of action block arguments. Isn't it more precisely action block subroutine arguments? I would suggest adjusting things in two spots "action block arguments" -> "action block subroutine arguments" and "their arguments" -> "their subroutine arguments". This is also a problem in several other places in the proposal. Please fix those as well.
Anupam:
3033
Can a checker port be driven from inside a checker ? There does not seem to be any text restricting this.
Tom:
2578
Friendly amendment: add an "and" to the sentence
. . . the underlying evaluation attempt of property_expr1 is true and nonvacuous, and the underlying evaluation attempt of propertey_expr2 . .
^^^
Manisha:
3033
Friendly amendments:
I think the following should be fixed in 17.3.1:
If the checker is procedural, all static concurrent assertions assertion statements in the checker are added to the pending procedural assertion queue for their process when the checker instantiation is reached in process execution, and then may mature or be flushed like any procedural concurrent assertion (see 16.15.6.2). All static deferred assertions in the checker are monitored each time the checker instantiation is reached in procedural execution.
To:
If the checker is procedural, all static concurrent assertions assertion statements in the checker are added to the pending procedural assertion queue for their process when the checker instantiation is reached in process execution, and then may mature or be flushed like any procedural concurrent assertion (see 16.15.6.2). Similarly all static deferred assertions in the checker are added to the pending deferred assertion report when the checker instantiation is reached in process execution, and then may mature or be flushed like any procedural deferred assertion (see 16.4.1)
Also, I think the statement "For example, concurrent assertions will be queued in this case." Should be removed from the third bullet as also deferred assertions are queued.
In "Except for the variables mentioned in the event control...", I think it should be 'used' instead of 'mentioned'.
Sent later:
One more change: The word 'queue' should be there in the sentence "....in the checker are added to the pending procedural assertion queue ...".
Also, please remove word 'then' from the sentence I suggested "
Similarly all static deferred assertions in the checker are added to the pending deferred assertion report when the checker instantiation is reached in its process execution, and then may mature or be flushed like any procedural deferred assertion (see 16.4.1).
3206
Amendment:
Looks like the full stop at the end of sentence is gone now: "The subroutine can be a task, task method, void function, void function method, or system task". I asked to remove extra fullstop but there is none now (both are in red now).
---------------------------------------------------------------------
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.Received on Tue Aug 30 01:49:03 2011
This archive was generated by hypermail 2.1.8 : Tue Aug 30 2011 - 01:49:07 PDT