[sv-ec] champions feedback - resend

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Champions: email vote

# 2080 SV-EC "::" is ambiguous in parameterized classes
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.

   Brad - opposed
   Mantis should be updated with ?duplicate? link to 1857. If Mantis updated,
   then I approve.

# 2022 SV-EC index value width extension for associative arrays
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.

# 2018 SV-EC Is a queue an array or not?
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.

# 1740 SV-EC Item 1457 did not correct section 10.5.3
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.

# 1672 SV-EC 18.9: "type" should be "option"
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.

   Brad - opposed
   Update Mantis with ?duplicate? link to 1279. If Mantis updated,
   then I approve.

# 0802 SV-EC Assigning too many elements to a queue
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.

   Brad - opposed
   Update Mantis with ?duplicate? link to 802. If Mantis updated,
   then I approve.

# 0251 SV-EC multiple user defined bins for cross
sv-ec unanimously resolved by email vote ending Aug. 28, 2010 to close this issue, duplicated.

   Shalom - opposed (originally abstain) - questioned how 2506 addressed 251
   Brad - opposed (referenced Shalom's feedback)

   Dave - addressing Shalom's comment

   251 is more of a dissatisfaction of the current semantics of crosses without
   a suggested direction. If nothing else, mantis 2506 has a loose proposal
   that should alleviate the concerns raised by 251.

   Shalom-
   The description of 251 says,

   "For cross coverage, the syntax in table 20-4 does not allow multiple bins
    to be created for user defined bins, i.e. using the [] notation with the
    binsof construct. So the only way to track the crosses separately is
    through automatically created bins. Was there any specific reason for not
    allowing that. The syntax should be enhanced to allow multiple bins being
    created for user defined bins. The example in Section 20.5.1 should also
    be suitably enhanced."

    That looks to me exactly like a "suggested direction".

    John Havlicek
    Hmm ... I can't make any specific sense of what is being suggested in
    251.

    One of the restrictions in defining cross bins is that they are limited
    to tuples of bins from the component coverpoints being crossed. One
    does not have full flexibility at the level of the cross to ignore or
    redefine the bin structure that comes from the coverpoints.

    The proposal for 2506 respects this approach and extends it.

    I can't really tell what the reporter of 251 wants. Nevertheless, I
    agree with Dave that the general area of concern is covered or, at
    least, overlaps significantly with 2506, and I would hope that the
    reporter of 251 would participate in resolution of 2506 and/or 2953.

    Shalom -
    But that does not make 251 a duplicate of 2506.

    SV-EC can decide that it does not want to implement the request in 251 and
    close the issue on that basis, but not as a duplicate of 2506.

    I change my vote from "Abstain" to "Oppose".

# 2451 SV-EC Omitting body defaults
There is a proposal - several clarifying statements were added.
Approved unanimously in sv-ec meeting August 30 2010. Proposal2451v2b.pdf

# 1349 SV-EC fork/join_none: what if parent thread terminates without blocking statement?
There is a proposal - a simple clarifying change to one sentence.
Approved unanimously in sv-ec meeting August 30 2010.

# 2794 SV-EC Clarify queue methods return status
There is a 2-page proposal - several clarifying statements added.
Approved unanimously in sv-ec meeting August 30 2010. proposal-2794-2a.pdf

   Brad - opposed (also agreed with Shalom's feedback)
      The multiple "If this method is called on an empty queue" sentences are
      weird.
   Shalom - opposed
   Dave - opposed (same reasons)

   The proposal contains:

   "ADD to the end of 7.10.2.4:

   If this method is called on an empty queue, its return value shall be the
   default initial value for the type of queue element (as described in
   Table 7-1).

   If this method is called on an empty queue, then the method call shall have
   no effect on the queue and may cause a warning to be issued.

   ADD to the end of 7.10.2.5:

   If this method is called on an empty queue, its return value shall be the
   default initial value for the type of queue element (as described in
   Table 7-1).

   If this method is called on an empty queue, then the method call shall have
   no effect on the queue and may cause a warning to be issued."

   As noted in 0001067:

   1. Table 7-1 does not specify values for real and chandle types.
   2. Table 7-1 is labeled "Value read from a nonexistent associative array
      entry", not "Default initial values".

   "default initial value" is not even correct for event types. The default
    initial value for an event is a "new event", as specified in Table 6-7.

   (By the way, it looks awkward to begin two consecutive sentences with the
    same phrase, "If this method is called on an empty queue".)

# 2956 SV-EC clarify class 'process' definition (9.7 vs 18.13.3, 18.13.4, 18.13.5)
There is a one page proposal - fixed a typedef and added missing methods from "class process" in 9.7.
Approved unanimously in sv-ec meeting August 30 2010. NOTE to the editor: Add cross references to the functions listed in this table.

# 2950 SV-EC virtual method prototype matching
Added a one-word clarification to one sentence and added a second sentence.
Approved unanimously in sv-ec meeting August 30 2010. 2950.pdf proposal.

# 2949 SV-EC LRM is silent about the semantics of referencing a clocking block output
What was one sentence in the LRM is now expanded to further clarify clockvars (inout, input, output).
Approved unanimously, sv-ec meeting August 16 2010. proposal 2949-1a.pdf

   Brad - opposed
   I infer from this change that writing to an inout clockvar has no effect on
   a subsequent read from it. If that?s correct, please consider adding a note
   about it.
Received on Mon Oct 11 11:11:08 2010