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.