Re: [sv-ac] Closing 2491?

Hi Erik,

Yes, there should be a committee vote before any mantis items get "resolved".
If the committee agrees with your opinion of "no change required" the mantis
item should be placed into the following state. A note should also be
added which shows details of the vote. When the mantis item is moved to the
resolved status, the note can be added at that time.

    Resolution: no change required
        Status: resolved

Mantis items are not officially "closed" until there is approval from the
Working Group.

Neil

On 07/16/10 10:38, Seligman, Erik wrote:
> So, what is the procedure to close this tkt with no change required? Do we need to hold a vote, or can I just do it as the ticket owner?
>
>
>> -----Original Message-----
>> From: Accellera Mantis Bug Tracker [mailto:mantis@eda.org]
>> Sent: Wednesday, July 14, 2010 4:06 PM
>> To: Seligman, Erik
>> Subject: [SystemVerilog P1800 0002491]: Conflicting rules in 16.17 (D7)
>>
>>
>> A NOTE has been added to this issue.
>> ======================================================================
>> http://www.eda-twiki.org/svdb/view.php?id=2491
>> ======================================================================
>> Reported By: Doron Bustan
>> Assigned To: Erik_Seligman
>> ======================================================================
>> Project: SystemVerilog P1800
>> Issue ID: 2491
>> Category: SV-AC
>> Reproducibility: always
>> Severity: minor
>> Priority: normal
>> Status: assigned
>> Type: Errata
>> ======================================================================
>> Date Submitted: 2008-10-05 03:42 PDT
>> Last Modified: 2010-07-14 16:05 PDT
>> ======================================================================
>> Summary: Conflicting rules in 16.17 (D7)
>> Description:
>> 16.17: Rules e and f are not consistent in the sense that rule e imply
>> (not
>> conclusively but in spirit) that any sequence/property with unique
>> semantic
>> leading clock, can be used as a top level property in an assertion
>> statement, while rule f, restricts it to instances. Example c4 is
>> related.
>>
>> ======================================================================
>> Relationships ID Summary
>> ----------------------------------------------------------------------
>> related to 0003145 Need to clearly define "maximal pr...
>> ======================================================================
>>
>> ----------------------------------------------------------------------
>> (0009529) Erik_Seligman (developer) - 2010-07-09 10:42
>> http://www.eda-twiki.org/svdb/view.php?id=2491#c9529
>> ----------------------------------------------------------------------
>> I looked at the rules in the text, and don't think I understand the
>> conflict. (e) refers to inheriting the default clocking event, and (f)
>> talks about cases where there is no default clocking event.
>>
>> Does someone have a concrete example of a SVA fragment for which these
>> two
>> rules conflict?
>>
>> ----------------------------------------------------------------------
>> (0009550) John Havlicek (manager) - 2010-07-14 16:05
>> http://www.eda-twiki.org/svdb/view.php?id=2491#c9550
>> ----------------------------------------------------------------------
>> I don't that there is a conflict. Rule e) says that a multiply clocked
>> property that is top level (i.e., maximal) must have a unique semantic
>> leading clock. Rule f) says that a top level (i.e., maximal) property
>> in
>> a concurrent assertion with no explicit leading clocking event, no
>> default
>> clocking event, and no contextually inferred clocking event must be an
>> instance.
>>
>> In the meeting on 2010-07-13, it was pointed out that Rule f) is really
>> a
>> consequence of other things (like a comment) and could be dropped.
>> Another mantis has been entered to deal with the fact that maximal (and
>> top level) property is not defined.
>>
>> Issue History
>> Date Modified Username Field Change
>> ======================================================================
>> 2008-10-05 03:42 Doron Bustan New Issue
>> 2008-10-05 03:42 Doron Bustan Type => Errata
>> 2008-10-05 07:18 shalom Issue Monitored: shalom
>> 2008-10-23 01:08 Dmitry KorchemnyStatus new =>
>> assigned
>> 2008-10-23 01:08 Dmitry KorchemnyAssigned To => Doron
>> Bustan
>> 2010-06-28 04:46 Dmitry KorchemnyAssigned To Doron Bustan
>> =>
>> Erik_Seligman
>> 2010-07-09 10:42 Erik_Seligman Note Added: 0009529
>> 2010-07-13 10:08 Erik_Seligman Relationship added related to
>> 0003145
>> 2010-07-14 16:05 John Havlicek Note Added: 0009550
>> ======================================================================
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>
>

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