[sv-ac] FW: [SystemVerilog P1800 0002205]: $asseroff, $assertkill and $asserton description is ambiguous

Hi guys-- I just uploaded a new version of this proposal that removes the change to 20.13, which caused a conflict with 2476.

>-----Original Message-----
>From: Accellera Mantis Bug Tracker [mailto:mantis@eda.org]
>Sent: Tuesday, October 12, 2010 4:06 PM
>To: Seligman, Erik
>Subject: [SystemVerilog P1800 0002205]: $asseroff, $assertkill and
>$asserton description is ambiguous
>
>
>A NOTE has been added to this issue.
>======================================================================
>http://www.eda-twiki.org/svdb/view.php?id=2205
>======================================================================
>Reported By: Dmitry Korchemny
>Assigned To: Erik_Seligman
>======================================================================
>Project: SystemVerilog P1800
>Issue ID: 2205
>Category: SV-AC
>Reproducibility: always
>Severity: minor
>Priority: urgent
>Status: resolved
>Type: Clarification
>Resolution: fixed
>Fixed in Version: 1800-2012
>======================================================================
>Date Submitted: 2007-11-15 00:59 PST
>Last Modified: 2010-10-12 16:05 PDT
>======================================================================
>Summary: $asseroff, $assertkill and $asserton
>description is
>ambiguous
>Description:
>Stu raised the following issue about $asseroff and $assertkill tasks:
>
>"Do the $assertoff and related assertion controls and assertion action
>controls only affect "assert" directives, or do they also affect
>"assume", and "cover" directives? What about immediate assertions?"
>
>The description in the LRM is ambiguous, need to provide a
>clarification.
>
>
>======================================================================
>Relationships ID Summary
>----------------------------------------------------------------------
>related to 0001806 Introduce "restrict property"...
>related to 0002476 Need clarification about system functio...
>======================================================================
>
>----------------------------------------------------------------------
> (0006509) svadmin (administrator) - 2008-04-09 14:17
> http://www.eda-twiki.org/svdb/view.php?id=2205#c6509
>----------------------------------------------------------------------
>I do not agree that $asserton was intended to apply to immediate
>assertions. In fact it would break a lot of existing code if it did.
>
>----------------------------------------------------------------------
> (0006511) shalom (manager) - 2008-04-10 01:44
> http://www.eda-twiki.org/svdb/view.php?id=2205#c6511
>----------------------------------------------------------------------
>1806 would add restrict directive.
>
>----------------------------------------------------------------------
> (0007199) Lisa Piper (developer) - 2008-07-10 07:43
> http://www.eda-twiki.org/svdb/view.php?id=2205#c7199
>----------------------------------------------------------------------
>this was addressed in 1987 by referencing "assertion statements"
>
>----------------------------------------------------------------------
> (0009654) Erik_Seligman (developer) - 2010-08-23 15:00
> http://www.eda-twiki.org/svdb/view.php?id=2205#c9654
>----------------------------------------------------------------------
>Reading the current text of 20.11, I think it's clearly implied that
>these
>*do* affect immediate assertions, since there is specific info on how
>they
>affect deferred assertions, which are a subclass of immediate
>assertions.
>Annex P defines the term 'assertion statement' to cover immediate &
>concurrent flavors of assume, assert, cover, and restrict-- but this
>text
>doesn't actually use that term. So I will soon post a proposal for a
>slight rewording.
>
>----------------------------------------------------------------------
> (0009655) Erik_Seligman (developer) - 2010-08-24 09:35
> http://www.eda-twiki.org/svdb/view.php?id=2205#c9655
>----------------------------------------------------------------------
>Discussed in meeting. Clause 16 defines "assertion" as covering all 3,
>but
>20.11-20.13 might create some confusion due to both "assertion" and
>"assertion statement" being used in various. Solution agreed on: make
>sure 20.* consistently use "assertion" AND includes references back to
>16.
>
>----------------------------------------------------------------------
> (0009723) Dmitry Korchemny (manager) - 2010-09-01 09:39
> http://www.eda-twiki.org/svdb/view.php?id=2205#c9723
>----------------------------------------------------------------------
>Approved by voice vote 2010-08-31: 8y/0n/0a.
>
>----------------------------------------------------------------------
> (0009761) shalom (manager) - 2010-09-19 07:55
> http://www.eda-twiki.org/svdb/view.php?id=2205#c9761
>----------------------------------------------------------------------
>The proposal for http://www.eda-twiki.org/svdb/view.php?id=2476 completely
>rewrites
>section 20.13 and should
>take priority over the change to that section in this proposal.
>
>----------------------------------------------------------------------
> (0009839) Neil Korpusik (administrator) - 2010-10-12 16:05
> http://www.eda-twiki.org/svdb/view.php?id=2205#c9839
>----------------------------------------------------------------------
>The proposal was opppsed by the Champions in the email vote which ended
>on September 29, 2010.
>
> Brad - opposed (same reasons as Shalom)
> Shalom - opposed
> http://www.eda-twiki.org/svdb/view.php?id=2205 and 2476 both make changes
>to
>Section 20.13.
> 2476 should take precedence and the change to 20.13 in 2205 should
>be
>removed.
> Dave Rich - approve (with the following requirements)
> SV-AC should vote to rescind 2205 before approving 2476.
> 2205 should stand until 2476 comes to the champions.
> Shalom response to Dave
> No, because 2205 contains additional changes not affected by 2476.
>
>Issue History
>Date Modified Username Field Change
>======================================================================
>2007-11-15 00:59 Dmitry KorchemnyNew Issue
>2007-11-15 00:59 Dmitry KorchemnyType =>
>Clarification
>2007-11-15 01:22 shalom Issue Monitored: shalom
>2007-11-15 07:54 Bassam Tabbara Issue Monitored: Bassam Tabbara
>
>2007-12-03 09:44 Lisa Piper Status new => assigned
>2007-12-03 09:44 Lisa Piper Assigned To => Lisa Piper
>2007-12-03 10:08 Lisa Piper File Added: 2205_asserton_071203_lp.doc
>
>2007-12-03 10:08 Lisa Piper File Added: 2205_asserton_071203_lp.pdf
>
>2008-04-09 14:17 svadmin Note Added: 0006509
>2008-04-10 01:44 shalom Note Added: 0006511
>2008-04-10 01:44 shalom Relationship added related to
>0001806
>2008-07-10 07:43 Lisa Piper Note Added: 0007199
>2010-06-29 11:29 Dmitry KorchemnyAssigned To Lisa Piper =>
>Erik_Seligman
>2010-08-23 14:55 Erik_Seligman Issue Monitored: Erik_Seligman
>
>2010-08-23 15:00 Erik_Seligman Note Added: 0009654
>2010-08-23 15:24 Erik_Seligman File Added: Proposal_2205.docx
>
>2010-08-23 15:24 Erik_Seligman File Deleted:
>2205_asserton_071203_lp.pdf
>
>2010-08-23 15:25 Erik_Seligman File Deleted:
>2205_asserton_071203_lp.doc
>
>2010-08-23 15:25 Erik_Seligman File Added: Proposal_2205.pdf
>
>2010-08-24 09:35 Erik_Seligman Note Added: 0009655
>2010-08-24 12:57 Erik_Seligman File Deleted: Proposal_2205.docx
>
>2010-08-24 12:57 Erik_Seligman File Deleted: Proposal_2205.pdf
>
>2010-08-24 12:57 Erik_Seligman File Added: Proposal_2205.docx
>
>2010-08-24 12:57 Erik_Seligman File Added: Proposal_2205.pdf
>
>2010-09-01 09:39 Dmitry KorchemnyNote Added: 0009723
>2010-09-01 09:39 Dmitry KorchemnyStatus assigned =>
>resolved
>2010-09-01 09:39 Dmitry KorchemnyResolution open => fixed
>2010-09-01 09:39 Dmitry KorchemnyFixed in Version => 1800-2012
>2010-09-19 07:55 shalom Note Added: 0009761
>2010-10-12 13:11 Neil Korpusik Relationship added related to
>0002476
>2010-10-12 16:05 Neil Korpusik Note Added: 0009839
>======================================================================
>
>
>--
>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.