Below are the results of the email ballot:
2328 2476 2578 3033 3206 3385
Yes Yes Yes Ashok Bhatt
Yes Yes Yes Yes Yes Laurence Bisht
Yes Yes No Yes Yes Yes Eduard Cerny
Yes Yes Yes Yes Ben Cohen
Tapan Kapoor
Yes Yes No No Yes Yes Scott Little
Yes Yes No No No Yes Manisha Kulshrestha
Yes Yes Yes Yes Yes Yes Anupam Prabhakar
Yes Yes Yes No Yes Yes Erik Seligman
Yes Yes Yes Yes Yes Yes Samik Sengupta
Yes Yes No Yes Yes Yes Tom Thatcher
Issue 2328 passed: 9y/0n/0a
Issue 2476 passed: 9y/0n/0a
Issue 3385 passed with friendly amendments: 9y/0n/0a
Issues 2578, 3033, 3206 failed
Comments
Erik:
2578
Friendly amendment:
"underlying evaluation attempts of property_expr2 is nonvacuous." ==> "underlying evaluation attempt of property_expr2 is nonvacuous."
3033
A couple of concerns here:
- Does section 17.3.1 still exist but no longer have a title?
- 17.3.1 has three bullet points to clarify behavior of static concurrent assertions in a checker-shouldn't we have similar bullet points for static deferred assertions, or also mention those in the current ones?
Samik:
2578
I am confused about the following, hence a possible amendment: "the underlying evaluation attempt of property_expr1 is true" should be "the underlying evaluation attempt of property_expr1 is nonvacuous" - no? At least that's what seems to be proposed in F.5.3.3.
Tom:
2578
Am I looking at the correct proposal? I thought that we had agreed to revert to Ben's original definition: "prop_expr1 implies prop_expr2" is nonvacuous if prop_expr1 is nonvacuous, prop_expr1 is true and prop_expre2 is nonvacuous Also, the formal syntax in the proposal for F.5.3.3 does not seem to match the text. I am interpreting this as P1 implies P2 is nonvacuous iff P1 is nonvacuous and P2 is nonvacuous
3033
17.5 checker procedures:
The text says, "An =always= procedure in a checker body . . ."
Since the "always" is set in courier type, one would assume that it is referring to the "always" keyword, not to a class of procedures including always, always_ff, always_latch, and always_comb. Yet, always is the one example of this class that will not be allowed within checkers after this proposal is passed. Set the two Courier type always to regular font.
Ed:
2578
The text explaining nonvacuous implication is not consistent with the formal definition change proposed for annex F5.3.3.
3033
minor comment: in 17.3.1, it says "
If the checker is statically instantiated inside another checker ..." But it cannot be instantiated othwerwise than statically, so is the If ... needed? May lead to confusion.
3385
Correct terminology according to mantis 3206? I.e., in 3385, use observed deferred assertion? Would it be better to merge the two proposals?
Ben:
2578
Friendly amendment:
The default sampled value of the triggered event property (see 15.5.3) and the sequence methods triggered and matched is 1'b0.
Mantis 2578 ___ Yes ____ No
w |=non P1 implies P2 iff w |= non P1and w |=non P2. should it be ?
w |=non P1 implies P2 iff w |= P1and w |=non P2.
Laurence:
2578
Typo in the formal syntax in the proposal for F.5.3.3. (also please add a space before the and)
w |=non P1 implies P2 iff w |= non P1 and w |=non P2
Manisha:
2578
Text and formal do not match
3033
1. "If an actual argument contains any subexpression that is a const cast or automatic value from procedural code, then the corresponding formal argument shall be used only in static assertion statements (see 16.15.6) or static checker instances not be used in a continuous assignment or in the procedural code within the checker." Why is this part changing ? What all is being included to use const cast/automatic variables now ? Also the following sentence "whenever a static assertion statement in the checker or a statically instantiated subchecker is added to the pending procedural assertion queue (see 16.15.6.1 and 17.3.1)." , now that checkers can only be instantiated statically inside another checker, is it required to state it ? Also, this checker which is instantiated in another checker, may not be a subchecker. In fact I did not find any other place where subchecker term is used.
2. In 17.3.1, the rules for concurrent assertions should be extended for deferred assertions also.
3. In 17.5, the paragraph "An always procedure in a checker body may contain deferred and concurrent assertions, nonblocking variable assignments (see 17.7.1) and a procedural timing control statement using an event control. All other statements shall not appear inside an always procedure." Should be striken. Currently it is in blue.
4. In 17.5, the example shows that clk and rst are not sampled, but there is no text to support this exception.
5. "The always procedure in checkers allowed by IEEE Std 1800-2009, but always_comb, always_latch, and always_ff were forbidden. " has 'was' missing.
6. Message: DELETE subclause 17.3.2 Nested checker instantiations" should be color coded as it is not visible.
3206
I think the example at the end is not complete. It does not show how clock is ticking. Also, there is default clocking in program block, which is not needed.
In 16.4 , paragraph starting with "The pass and fail statements in a deferred assertion's action_block, if present, shall each consist of a single
subroutine call. The subroutine can be a task, task method, void function, ..." has extra '.' And also extra spaces. Also, same paragraph is changed in 3385. So, this proposal should be written taking that into account.
Scott:
2578
We need to sort out what we want and make sure the Annex F definition is consistent w/ the textual definition (it isn't in this version of the proposal). This has all been pointed out by others already.
3033
In the changes to 16.4.3 you define the term static deferred assertion. Why not use it in the final change for that section? For example, "Static deferred assertions in checkers are described in 17.3."
In the changes to 17.3.1 please move the WITH out of the itemized list.
In the changes to 17.3.1 toplevel is missing a hyphen in the original and changed text.
In the code example in 17.3.1 you should fix the ' as it has been changed in D2.
In the final change to 17.3.1 it states that p3 is checked continuously. I don't really like that description. My understanding is that it is checked whenever a changes. To me continuously implies that I need to check it at every cycle which I don't believe is the case.
In the changes to 17.5, I believe that the language is too loose. I think that in the first paragraph the term general purpose always procedure should be used (see 9.2.2) as it is more precise. I would also prefer to see the final sentence in the second paragraph before the itemized list read, "These forms of checker always procedures may contain the following statements:"
In 17.7.1 it looks like example missed the red strikethrough for some reason.
In 17.7.1, why is the final item (The left hand side...) not bulleted?
In regard to C.2.7 I am confused. I thought that the first paragraph in 17.5 states that always procedures are allowed then this section seems to say they are not. This needs to be clarified.
3206
You may want to add a note to the editor indicating that some new items in the BNF changes are colored red.
Quote from a mail from Stu on 05/11/2011
"As the editor, my preference for BNF changes is that when the actual BNF
requires something to be in red, the proposed change also use red, even when
it is a new addition. Any new text between the bold-red tokens should still
be in blue.
The change can be followed with a "note to the editor" stating that some of
the BNF changes are an addition to the BNF, even though it is not in blue."
I wonder if adding "for observed deferred assertions" to the end of the final sentence in the change set for 16.4.1 would add a bit of clarity?
The final A2 in the changes to 16.4.2 is in the wrong font.
---------------------------------------------------------------------
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 23 02:08:01 2011
This archive was generated by hypermail 2.1.8 : Tue Aug 23 2011 - 02:08:21 PDT