[sv-champions] some comments on mantis items

From: John Havlicek <john.havlicek_at_.....>
Date: Thu Jul 31 2008 - 07:54:57 PDT
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