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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.