Hi Manisha,
I suggest to request clarification from Brad and Francoise. Brad's suggestion cannot be applied as is, since it is possible to incorporate an enumeration into a class, but not into a function. I will clarify with Neil about sending an issue to other committees.
Thanks,
Dmitry
> I think that this kind of language enhancement should be reviewed by
> the BC or EC committee. It could be complex to try to control
> assertion execution.
> This
> smells like fine grain assertion control. I am wondering if process
> kill,
>
> suspend and resume could be used to the same effect. Have we
> considered the implementation complexity for controlling assertions?
>
-----Original Message-----
From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Monday, November 14, 2011 12:18
To: Korchemny, Dmitry
Cc: sv-ac@eda-stds.org
Subject: FW: [SystemVerilog P1800 0003295]: need a way to control only asserts/covers/assume directives
Hello Dimitry,
I am not sure if I can really make any changes in the proposal based on the feedback. We had considered adding enum types for different int values but could not find any good place to do it without causing any potential clashes with user defined names. The example that Brad has given (9.7 section) is different because they have a class where these enum types can be defined. We do not have any such thing.
I am not sure I understand Francoise's comments. We do have simple (old) versions of the tasks for the users who do not care about the complex options. We do need fine grain control as there are different types of assertions and directives. This is the purpose of this mantis to be able to control assertions based on their types etc.
Could you please forward this email to Brad and Francoise as I do not have their email address. Also, do we need to send this proposal to bc and ec to review ?
Thanks.
Manisha
> -----Original Message-----
> From: Accellera Mantis Bug Tracker [mailto:mantis@eda.org]
> Sent: Monday, November 07, 2011 11:23 PM
> To: Kulshrestha, Manisha
> Subject: [SystemVerilog P1800 0003295]: need a way to control only
> asserts/covers/assume directives
>
>
> The following issue has been REOPENED.
> ======================================================================
> http://www.eda-twiki.org/svdb/view.php?id=3295
> ======================================================================
> Reported By: Manisha_Kulshrestha
> Assigned To: Manisha_Kulshrestha
> ======================================================================
> Project: SystemVerilog P1800
> Issue ID: 3295
> Category: SV-AC
> Reproducibility: always
> Severity: feature
> Priority: normal
> Status: feedback
> Type: Enhancement
> ======================================================================
> Date Submitted: 2010-11-25 03:36 PST
> Last Modified: 2011-11-07 09:52 PST
> ======================================================================
> Summary: need a way to control only asserts/covers/assume
> directives
> Description:
> Currently assertion control system tasks do not provide a way to
> control only specific types of directives. We need a way to control
> only asserts, covers or assumes.
>
> If the committee feels necessary we can also enhance them to control
> only concurrent or only immediate assertions also.
> ======================================================================
> Relationships ID Summary
> ----------------------------------------------------------------------
> has duplicate 0002341 should scope of assert control tasks be...
> related to 0003474 Extend assertion control to apply to 'v...
> ======================================================================
>
> ----------------------------------------------------------------------
> (0011006) Dmitry Korchemny (manager) - 2011-06-01 05:43
> http://www.eda-twiki.org/svdb/view.php?id=3295#c11006
> ----------------------------------------------------------------------
> Passed by email vote 2011-05-30: 6y/0n/0a. Two more positive votes
> were sent late.
>
> ----------------------------------------------------------------------
> (0011126) Neil Korpusik (administrator) - 2011-06-21 18:48
> http://www.eda-twiki.org/svdb/view.php?id=3295#c11126
> ----------------------------------------------------------------------
> Needs to be reviewed by the sv-cc before it can go to the Champions.
>
> ----------------------------------------------------------------------
> (0011156) Neil Korpusik (administrator) - 2011-06-28 16:21
> http://www.eda-twiki.org/svdb/view.php?id=3295#c11156
> ----------------------------------------------------------------------
> Tom Thatcher requested that this mantis item be reopened.
>
> Shalom has provided some feedback to the sv-ac that they would like to
> address in the proposal.
>
> ----------------------------------------------------------------------
> (0011157) Tom Thatcher (developer) - 2011-06-28 16:32
> http://www.eda-twiki.org/svdb/view.php?id=3295#c11157
> ----------------------------------------------------------------------
> Shalom provided the following feedback by e-mail:
>
> -------------------------------
> E-mail dated 6/22/2011
>
> Hi,
>
> I have not been following this issue closely, but I looked at the
> proposal now, and I want to ask whether there is a reason not to
> combine the assert_task and and assert_action_task BNFs.
>
> Similarly, is there a reason not to combine Tables 20-8 and 20-9?
>
> Also, the titles of Tables 20-5 to 20-7 refer to
> "assertion_control_tasks", but it looks like they are specific to
> $assertcontrol.
>
> Also, this proposal refers to "assert", "cover", and "assume" as
> "directives".
> This is not consistent with the terminology in Clause 16.
> ----------------------------------
> E-mail dated 6/23/2011
>
> 'directive' is used in Clause 16 only twice, and never in a general
> sense.
>
>
>
> In 16.4: — Syntax: Deferred assertions use #0 after the verification
> directive.
>
>
>
> In 16.13.9: A followed-by operator is especially convenient for
> specifying a cover property directive over a sequence followed by a property.
>
>
>
> Regards,
>
> Shalom
>
> -------------------------------
> E-mail dated 6/27/2011
>
> The syntax includes list_of_modules_or_assertions.
>
> I realize that this did not originate in the current proposal, but it
> should not be limited to modules. First, it refers to scope names, not
> module names, and second, it is not limited to modules. It also
> applies to other types of design elements.
>
> This would be a good time to fix it.
> ------------------------------
>
> ----------------------------------------------------------------------
> (0011466) Dmitry Korchemny (manager) - 2011-08-16 13:25
> http://www.eda-twiki.org/svdb/view.php?id=3295#c11466
> ----------------------------------------------------------------------
> Amended proposal passed by voice vote 2011-08-16: 9y/0n/0a.
>
> ----------------------------------------------------------------------
> (0012249) Neil Korpusik (administrator) - 2011-11-07 09:52
> http://www.eda-twiki.org/svdb/view.php?id=3295#c12249
> ----------------------------------------------------------------------
> The proposal was opposed by the Champions in the email vote which
> ended October 31, 2011.
>
> Brad
>
> These tables of arbitrary integer codes are not in the spirit of SV.
> These
>
> codes cry out to be named members of an enum type, as in the "process"
> class
> of 9.7.
>
> Francoise
>
> I think that this kind of language enhancement should be reviewed by
> the BC or EC committee. It could be complex to try to control
> assertion execution.
> This
> smells like fine grain assertion control. I am wondering if process
> kill,
>
> suspend and resume could be used to the same effect. Have we
> considered the implementation complexity for controlling assertions?
>
> Issue History
> Date Modified Username Field Change
> ======================================================================
> 2010-11-25 03:36 Manisha_KulshresthaNew Issue
>
> 2010-11-25 03:36 Manisha_KulshresthaType => Enhancement
>
> 2010-11-25 04:05 Shalom BrestickerIssue Monitored: Shalom Bresticker
>
> 2010-11-25 04:54 Daniel Mlynek Issue Monitored: Daniel Mlynek
>
> 2010-11-30 08:41 Erik_Seligman Issue Monitored: Erik_Seligman
>
> 2011-02-14 02:25 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295.doc
> 2011-02-14 02:26 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295.pdf
> 2011-02-14 23:09 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_1.doc
> 2011-02-14 23:10 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_1.pdf
> 2011-03-04 14:12 Dmitry KorchemnyStatus new => assigned
> 2011-03-04 14:12 Dmitry KorchemnyAssigned To =>
> Manisha_Kulshrestha
> 2011-03-07 01:11 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_2.pdf
> 2011-03-07 01:11 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_2.doc
> 2011-03-08 00:47 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_3.doc
> 2011-03-08 00:48 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_3.pdf
> 2011-03-09 00:20 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_4.doc
> 2011-03-09 00:20 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_4.pdf
> 2011-03-09 20:38 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_5.doc
> 2011-03-09 20:38 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_5.pdf
> 2011-03-09 20:39 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295.doc
> 2011-03-09 20:39 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295.pdf
> 2011-03-09 20:39 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_1.doc
> 2011-03-09 20:39 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_1.pdf
> 2011-03-22 02:46 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_6.doc
> 2011-03-22 02:46 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_6.pdf
> 2011-03-23 03:43 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_7.doc
> 2011-03-23 03:43 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_7.pdf
> 2011-04-05 09:12 Erik_Seligman Relationship added related to 0003474
> 2011-04-18 23:27 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_8.doc
> 2011-04-18 23:28 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_8.pdf
> 2011-04-20 03:37 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_9.doc
> 2011-04-20 03:37 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_9.pdf
> 2011-05-03 02:44 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_10.doc
> 2011-05-03 02:44 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_10.pdf
> 2011-05-03 10:59 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_11.doc
> 2011-05-03 10:59 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_11.pdf
> 2011-05-18 03:08 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_2.pdf
> 2011-05-18 03:09 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_2.doc
> 2011-05-18 03:09 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_3.doc
> 2011-05-18 03:09 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_3.pdf
> 2011-05-18 03:09 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_4.doc
> 2011-05-18 03:09 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_4.pdf
> 2011-05-18 03:09 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_5.doc
> 2011-05-18 03:09 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_5.pdf
> 2011-05-18 03:09 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_6.doc
> 2011-05-18 03:09 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_6.pdf
> 2011-05-18 03:09 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_7.doc
> 2011-05-18 03:10 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_7.pdf
> 2011-05-18 03:10 Manisha_KulshresthaFile Added:
> assertion_control_sys_tasks_man_3295_12.doc
> 2011-05-18 03:12 Manisha_KulshresthaFile Deleted:
> assertion_control_sys_tasks_man_3295_12.doc
> 2011-05-18 03:12 Manisha_KulshresthaFile Added:
> 3295_assertion_control_sys_tasks_man_12.doc
> 2011-05-18 03:13 Manisha_KulshresthaFile Added:
> 3295_assertion_control_sys_tasks_man_12.pdf
> 2011-05-23 05:32 Manisha_KulshresthaFile Added:
> 3295_assertion_control_sys_tasks_man_13.doc
> 2011-05-23 05:32 Manisha_KulshresthaFile Added:
> 3295_assertion_control_sys_tasks_man_13.pdf
> 2011-05-25 00:18 Manisha_KulshresthaFile Added:
> 3295_assertion_control_sys_tasks_man_14.doc
> 2011-05-25 00:18 Manisha_KulshresthaFile Added:
> 3295_assertion_control_sys_tasks_man_14.pdf
> 2011-06-01 05:43 Dmitry KorchemnyNote Added: 0011006
> 2011-06-01 05:43 Dmitry KorchemnyStatus assigned => resolved
> 2011-06-01 05:43 Dmitry KorchemnyResolution open => fixed
> 2011-06-01 05:43 Dmitry KorchemnyFile Deleted:
> assertion_control_sys_tasks_man_3295_8.doc
> 2011-06-01 05:43 Dmitry KorchemnyFile Deleted:
> assertion_control_sys_tasks_man_3295_8.pdf
> 2011-06-01 05:43 Dmitry KorchemnyFile Deleted:
> assertion_control_sys_tasks_man_3295_9.doc
> 2011-06-01 05:43 Dmitry KorchemnyFile Deleted:
> assertion_control_sys_tasks_man_3295_9.pdf
> 2011-06-01 05:43 Dmitry KorchemnyFile Deleted:
> assertion_control_sys_tasks_man_3295_10.doc
> 2011-06-01 05:43 Dmitry KorchemnyFile Deleted:
> assertion_control_sys_tasks_man_3295_10.pdf
> 2011-06-01 05:43 Dmitry KorchemnyFile Deleted:
> assertion_control_sys_tasks_man_3295_11.doc
> 2011-06-01 05:43 Dmitry KorchemnyFile Deleted:
> assertion_control_sys_tasks_man_3295_11.pdf
> 2011-06-01 05:44 Dmitry KorchemnyFile Deleted:
> 3295_assertion_control_sys_tasks_man_12.doc
> 2011-06-01 05:44 Dmitry KorchemnyFile Deleted:
> 3295_assertion_control_sys_tasks_man_12.pdf
> 2011-06-01 05:44 Dmitry KorchemnyFile Deleted:
> 3295_assertion_control_sys_tasks_man_13.doc
> 2011-06-01 05:44 Dmitry KorchemnyFile Deleted:
> 3295_assertion_control_sys_tasks_man_13.pdf
> 2011-06-21 18:48 Neil Korpusik Note Added: 0011126
> 2011-06-28 16:21 Neil Korpusik Note Added: 0011156
> 2011-06-28 16:21 Neil Korpusik Status resolved => feedback
> 2011-06-28 16:21 Neil Korpusik Resolution fixed => reopened
> 2011-06-28 16:32 Tom Thatcher Note Added: 0011157
> 2011-08-05 00:11 Manisha_KulshresthaFile Added:
> 3295_assertion_control_sys_tasks_man_15.doc
> 2011-08-05 00:12 Manisha_KulshresthaFile Added:
> 3295_assertion_control_sys_tasks_man_15.pdf
> 2011-08-10 02:52 Manisha_KulshresthaFile Added:
> 3295_2341_assertion_control_sys_tasks_man_16.doc
> 2011-08-10 02:53 Manisha_KulshresthaFile Added:
> 3295_2341_assertion_control_sys_tasks_man_16.pdf
> 2011-08-10 03:09 Manisha_KulshresthaRelationship added has duplicate
> 0002341
> 2011-08-16 13:25 Dmitry KorchemnyNote Added: 0011466
> 2011-08-16 13:25 Dmitry KorchemnyStatus feedback => resolved
> 2011-08-16 13:25 Dmitry KorchemnyResolution reopened => fixed
> 2011-08-16 13:30 Dmitry KorchemnyFile Deleted:
> 3295_assertion_control_sys_tasks_man_14.doc
> 2011-08-16 13:30 Dmitry KorchemnyFile Deleted:
> 3295_assertion_control_sys_tasks_man_14.pdf
> 2011-08-16 13:30 Dmitry KorchemnyFile Deleted:
> 3295_assertion_control_sys_tasks_man_15.doc
> 2011-08-16 13:30 Dmitry KorchemnyFile Deleted:
> 3295_assertion_control_sys_tasks_man_15.pdf
> 2011-11-07 09:52 Neil Korpusik Note Added: 0012249
> 2011-11-07 09:52 Neil Korpusik Status resolved => feedback
> 2011-11-07 09:52 Neil Korpusik Resolution fixed => reopened
> ======================================================================
>
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Nov 14 06:11:56 2011
This archive was generated by hypermail 2.1.8 : Mon Nov 14 2011 - 06:12:04 PST