[sv-ac] Closing 2491?

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.