[sv-cc] Re: [sv-sc] Results of Champions email vote ending Aug 13th

Hi folks,

Here are replies to the remaining Champions issues with 1900 - I believe I replied to all of Shalom's issues earlier. Doc attached, doc & pdf in Mantis.

--Mike

Neil Korpusik wrote:
> The details are attached.
> 
> Neil
> 
> 

> Detailed feedback:
> ------------------
> 
> Dave: 
...
>    3. 1900  Approve part2, pages 10-16            Yes ___ No _X__ 
> 
>    [DR] I echo Stu's comments. Although the SV-SystemC has made great
>    progress (and none of that effort will go to waste) I am not comfortable
>    going to ballot in its current state. 
> 
> Stu:
> 
...
> 3. 1900  Approve part2, pages 10-16            Yes ___ No _X_ Abstain ___
> 
>    I vote No because there has been a lot of very recent e-mail traffic with
>    questions and issues, which indicates that the proposal needs further
>    clarification and review.  To the SC committee's credit, they have been very
>    quick to fine tune the proposal in response to some of the e-mail traffic,
>    but I am concerned that these revisions are bypassing the review and
>    approval process of the full SC committee.

[MB] Just a comment - I believe that, while there have been a lot of changes recently, they have all been editorial changes and clarifications; I don't think there has been anything that changes the intent of the committee. SV-SC will be reviewing everything tomorrow and voting on the (hopefully) final version of 1900.

> Brad: 
>    I vote 'Yes' on all 3, with the comments that
> 
...
> 
>    --- 1900-1 ---
>    The following formulation is strange 
> 
>    "A checker may be instantiated wherever a concurrent assertion may
>    appear (see 16.15).
>    It shall be illegal to instantiate checkers in fork...join,
>    fork...join_any, or fork...join_none
>    blocks."
> 
>    I assume the first sentence is intended to imply that a checker may
>    not appear in places where concurrent assertions may not appear.  But
>    then wouldn't the second sentence be redundant?   Shouldn't it be "In
>    particular, it is illegal to instantiate ..."?  It's also strange that
>    this second sentence begins a new paragraph.

[MB] If I am not mistaken, the only text that forbids concurrent assertions in fork blocks occurs in 16.5, and is being stricken by 2398. Therefore I think we need to keep this as-is; I'll combine the paragraphs. If I'm missing something, please point me to where I should be looking.

>    --- 1900-2 ---
>    Because these are redundant
> 
>    "modules, interfaces and programs shall not be either declared or
>    instantiated inside
>    checkers"
> 
>    "Modules, interfaces and programs shall not be instantiated inside
>    checkers."
> 
>    In the first sentence it would be better to delete "either" and "or
>    instantiated".

[MB] I removed both of these due to redundancy. I moved the remainder of the first sentence lower down (see 1900-4 below). 

>    --- 1900-3 ---
>    A checker can be declared within a checker, yet checker declarations are 
>    not listed after
> 
>         "A checker body may contain the following elements ..."

[MB] I added an item for "Checker declarations".

>    --- 1900-4 ---
>    Why is there no mention of packages in this sentence?
> 
>    "Checkers may be declared inside modules, programs, interfaces, and other 
>    checkers, but modules, interfaces and programs shall not be either declared 
>    or instantiated inside checkers."

[MB] Because packages are not instantiated. This sentence is mostly redundant; as stated in 1900-2 above, I've stricken the first part. The second part has been moved a few paragaphs down to the part where checker contents are described; that's where it belongs. I've clarified that packages cannot be declared in checkers.

--Mike

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