1. 2396 SV-SC Add edge identifier edge for events For the example in 9.4.6, I do not have a problem with the new text, but I do not understand the example that currently exists. The current example says: Even if posedge phi1 and negedge phi2 occurred at the same simulation time, each will be detected separately. What does this mean and how does it affect the accounting of the number of times repeated? Does "separeate detection" imply counting with multiplicity in case a posedge of phi1 and a negedge of phi2 both occur in the same timestep? 2. 2414 SV-SC VPI for let I found the use of "seq formal decl" in "let decl" counterintuitive, but I guess that that item is being reused for let. The changes to Annex O indicate the vpiSeqFormalDecl is new, though. Was it omitted? 3. 2088 SV-SC Allow Checker construct (0001900) to include covergroups I don't understand the rationale for the restriction that the covergroup event cannot reference a checker variable. Couldn't this effect be achieved by created code in the checker that is sensitive to the checker variable and then using an active triggering mechanism (e.g., "->cg_event")? Perhaps there are more restrictions in other checker proposals that forbid this kind of code. 4. 2398 SV-SC More consistent semantics for concurrent assertions in procedural code This proposal strikes the text that says that assertion local variables use current values, not Preponed values. This creates an inconsistency between Clause 16 and Annex F. Local variables do not and have never used Preponed values. The text the provides exception for local variables should be restored. I think that the language discussing the beginning of evaluation of a matured assertion should reference the "leading clocking event" rather than just the "clocking event" of the assertion. 5. 2434 SV-SC Changes to seq/prop defaults and typing of actuals - fixed - Passed in voice vote at SV-SC meeting, 2008-07-22. 9y/1n/0a Mark Hartoog votes no - not needed, creates backwards compatibility issues. Clarification - not 100% sure about the note at the end, but the whole basic idea of casting these expressions to their self-determined type has the potential to create very subtle backwards compatibility issues per the face-to-face. There is a technical change that I do not agree with. The previous language said that an exception is made for substitution of an actual for a reference to the corresponding formal is made if The reference to the formal argument stands as a variable_lvalue in an operator_assignment or inc_or_dec_expression in a sequence_match_item. This has been changed to say The actual argument is a variable_lvalue. These two do not mean the same thing. I think that the actual could be a variable_lvalue in cases for which we do not want this rule to apply. I think that the original wording of this condition should be restored (two places). We also now have an inconsistency between the new wording in 16.8 and 16.8.1 and the wording in the Annex F changes for 1549. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Jul 31 07:55:47 2008
This archive was generated by hypermail 2.1.8 : Thu Jul 31 2008 - 07:55:50 PDT