[sv-bc] FW: [sv-ac] mantis 1648

This was bounced by the reflector.  Please respond to John and the
SV-AC.  
(Dave, I thought John was enabled to send to the reflector even if he
is not an SV-BC member?)

Matt
--
Matt Maidment
mmaidmen@ichips.intel.com
  

>-----Original Message-----
>From: owner-sv-ac@server.eda.org 
>[mailto:owner-sv-ac@server.eda.org] On Behalf Of John Havlicek
>Sent: Wednesday, September 05, 2007 10:18 AM
>To: sv-bc@server.eda.org; sv-cc@server.eda.org; 
>sv-ec@server.eda.org; sv-xc@server.eda.org
>Cc: sv-ac@server.eda-stds.org; karen.pieper@synopsys.com; 
>neil.korpusik@sun.com; john.havlicek@freescale.com; Korchemny, Dmitry
>Subject: [sv-ac] mantis 1648
>
>Hi Folks:
>
>SV-AC have passed a proposal for Mantis 1648 that introduces a default
>disable.  The document is
>
>   default_disable_1648.070904_dk.pdf
>
>and is also attached.
>
>A default disable may be declared as an item in a module, interface,
>or program.  It applies to concurrent assertions within that module,
>interface, or program that do not have their own "disable iff" 
>specified.
>
>If a default disable is declared in a nested module, interface, or
>program, then it overrides any default disable declared outside.
>
>This proposal only defines assertion semantics for default disable.
>
>There has been a negative comment from one of the Champions:
>
>   - I am against this enhancement at the current time. I believe this 
>     feature will be useful in a wider context, such as 
>covergroups, but 
>     the committees have not had time to study this. If we add this 
>     feature now, it will be harder to address the other areas due to 
>     backward incompatibilities. For example, suppose the 
>sv-ec decides 
>     that default disable should also disable sampling of 
>covergroups. We 
>     can't add that capability later; we must look at all the 
>other areas 
>     that could be affected. But due to schedules and merge 
>activities, 
>     the other committees have not been able to investigate.
>
>
>I am writing to encourage you to consider with high priority whether 
>you want to add semantics for default disable for other constructs,
>such covergroups as suggested in this comment.
>
>I believe that it is important for assertions to get the default
>disable in the 2008 standard, and we also have other SV-AC
>enhancements that will be made more difficult to implement if the 
>default disable is not approved.  We are trying not to become stalled
>on this item.
>
>I will sincerely appreciate prompt feedback that gives me a general
>idea of what, if any semantics you want to add for default disable 
>for non-assertion constructs and when it will be feasible for you
>to create corresponding proposals.
>
>Best regards,
>
>John H.
>
>
>
>-- 
>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.