RE: [sv-ac] RE: Mantis 3295: need a way to control only asserts/covers/assume directives

Hi Francoise,

In principle, concurrent assertions do not have to be implemented as processes: they can be folded into automata, or even some hybrid implementation may be possible. Therefore it is dangerous to rely on the fact that the concurrent assertions are processes and to provide a uniform control solution for both.

As for your last question is concerned, this scenario should be possible. If you lock an assertion, it does not react to $asserton/off/kill anymore, and either executes normally or remains inactive depending on its status before the locking. Suspending a process is independent of assertion locking. The assertion behaves the same way whether it is locked or not. For example, if it is active and the process containing it is suspended, no new attempts of the assertion will be started. If the assertion is inactive, it will remain inactive when the process was suspended.

Regards,
Dmitry

From: Francoise Martinolle [mailto:fm@cadence.com]
Sent: Thursday, November 17, 2011 05:30
To: Korchemny, Dmitry; Kulshrestha, Manisha
Cc: sv-ac@eda-stds.org; neil.korpusik@oracle.com; Karen Pieper
Subject: RE: [sv-ac] RE: Mantis 3295: need a way to control only asserts/covers/assume directives

Hi Dmitry,

Thanks for the description of what this additional functionality is.
I am not sure what should be my recommendation here. It seems too late to try to leverage some existing
language features since assertion control was there in 2005. Perhaps I do not understand what is being proposed but I do not understand why an assertion either concurrent or procedural is not considered a concurrent or spawn process (for procedural assertions).
It would have been more natural to be able to get a handle to the process executing the assertion and then define the various methods for killing, suspending, locking etc... an assertion. The advantage of the "process" is that a tool can analyze the code and find where processes are declared and only those could be subject to kill/suspend actions. It seems more difficult to do this kind of analysis for the way the assertion control is defined presently. Processes have the additonal advantage over this proposal that handles to processes can be passed to tasks/functions

Can you answer the following questions:
  1. Why is an assertion (either concurrent or proceducal) not considered a process?
  2. Could the assertion control (kill, suspend, resume) be implemented an alternative way by declaring a process
and controlling the process with kill/suspend/resume.
  3. was the interaction of process control and assertion control reviewed? For example, can you lock an assertion, then suspend the process that contains the assertions and unlock the assertion again?

Thanks
Francoise
       '

________________________________
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Wednesday, November 16, 2011 4:14 PM
To: Francoise Martinolle; Kulshrestha, Manisha
Cc: sv-ac@eda-stds.org; neil.korpusik@oracle.com; Karen Pieper
Subject: RE: [sv-ac] RE: Mantis 3295: need a way to control only asserts/covers/assume directives
Hi Francoise,

Assertion control tasks are heavily used.

If we assume that the behavior of assertion control tasks, existing already in the LRM2005, and of assertion action control tasks ($assertpasson, etc.) introduced in the LRM2009, is given, then Mantis 3295 introduces (almost) nothing new. I will clarify: it introduces the following features:

* One generic control task to cover the functionality of all above tasks to make assertion control parameterizable and to avoid multiplying control tasks each time a new fine grain control feature is introduced.

* Ability to control assertion statements according to their kinds, e.g., to switch off all cover statements in the module leaving all assertions and assumptions untouched. In the LRM2009 it was possible to switch on and off all assertions in a module (assertions, assumptions, and cover together. The only alternative was to switch them on and off individually by name. This feature should not introduce any tangible performance overhead.

* Ability to lock and unlock assertions, i.e., to make them insensitive or sensitive to other control tasks. This operation should not be costly since it should suffice to keep a bit per assertion indicating whether this assertion is locked or not. Before enabling or disabling this assertion, the implementation could check the value of this bit and if it is set, to do nothing with the assertion. Of course, one can think about even more efficient implementations. This feature is missing badly for power control. Assume that there is an hierarchy A and a sub-hierarchy B. A may go to sleep, but B remain awake. It may be desirable to disable all assertions in A, but keep all assertions in B active. Unless we turn on and off all assertions individually, we need to switch off all assertions in A without touching assertions in B. The existing means do not work: if we first switch off all assertions in A and then re-enable all assertions in B, all active attempts of assertions in B will be killed. If we first lock the assertions in B and then switch off the assertions in A, then we will get a desired behavior.

What actions should SV-AC take to address your concerns?

Thanks,
Dmitry

From: Francoise Martinolle [mailto:fm@cadence.com]
Sent: Wednesday, November 16, 2011 20:25
To: Kulshrestha, Manisha; Korchemny, Dmitry
Cc: sv-ac@eda-stds.org; neil.korpusik@oracle.com; Karen Pieper
Subject: RE: [sv-ac] RE: Mantis 3295: need a way to control only asserts/covers/assume directives

Manisha,

I see that this is already defined for $asserton, $assertoff and $assertkill. I am concerned about this as well.
The whole reason why we added the process control and the ability to create processes
was to facilitate acess to threads and processes. It may be too late to change this given this is in the LRM.
It just occurs to me that it may be easier to create tthreads for the assertions and control the threads with processes
rather than using the $assert_control API.

Francoise
       '

________________________________
From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Wednesday, November 16, 2011 12:02 PM
To: Francoise Martinolle; Korchemny, Dmitry
Cc: sv-ac@eda-stds.org; neil.korpusik@oracle.com; Karen Pieper
Subject: RE: [sv-ac] RE: Mantis 3295: need a way to control only asserts/covers/assume directives
Hi Francoise,

Please see my comments below:

Thanks.
Manisha

Hi Dimitry,

My concern with the assertion control additions is that I am
afraid that this functionality is going to be extremely difficult to implement. The reason is that it is expected to be
able to kill, stop, lock etc any assertion that has been started or has not yet started during simulation.

MK> The above functionality is already there in the existing system tasks ($asserton, $assertoff and $assertkill). We are not adding any new functionality. We are only providing control over what type of assertions will be affected.
For an event driven simulator with a distributed kernel, finding the assertions to kill or suspend is going to be
a challenge because assertions can be concurrent, immediate, deferred or final assertions, they can be embedded in initial blocks, always or tasks.

MK> Yes, this is difficult but existing tasks (above mentioned) already do that so nothing new here.

Not only it is going to be difficult to implement but it may end up slow down the simulation because the state of the assertion
will need to be checked every time, we have to traverse scopes to find these assertions and we do not know at priori
which assertions may be killed, locked, suspended etc....

MK> The above is implementation dependent and this issue is already there in the existing tasks ($asserton/off/kill).

So I was wondering why instead of defining this assertion control, if you could not use the process fine grain control
and perhaps enhance it. The LRM provides the ability to associate a process with an initial, always or threads of for join.
Killing a process terminates the given proven and all its subprocess (process spawned using for statements by the process being killed.
Has the sv_ac looked at the process find grain control (section 9.7 of the LRM).
My suggestion is that the sv-ac consult with the sv-ec to see if they can leverage the existing process fine grain control
to apply to assertions.

MK> For the assertions that are inside processes (initial, always etc.), they are already controlled by the controls of the process (e.g. if the process is disabled the assertion inside it is also disabled). Using process related controls for all the assertions (irrespective of if it is inside process or not) may require a lot of extra work. Here we are trying to provide a better way to filter out assertions on top of what is already there in the existing LRM.
Francoise
       '

________________________________
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Tuesday, November 15, 2011 1:24 PM
To: Francoise Martinolle
Cc: sv-ac@eda-stds.org; 'neil.korpusik@oracle.com'; Karen Pieper
Subject: Mantis 3295: need a way to control only asserts/covers/assume directives
Hi Francoise,

Could you clarify what actions are required from SV-AC to address your feedback to Mantis 3295:

"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?"

We already have fine grain control of assertion execution (see 20.12 Assertion control tasks), the additional control options introduced by this proposal do not introduce anything completely different, and should not be difficult to implement. What kind of feedback should we get from SV-BC and SV-EC?

Thanks,
Dmitry
---------------------------------------------------------------------
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<http://www.mailscanner.info/>, 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.
---------------------------------------------------------------------
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.