RE: [sv-ac] Sketch for the new version of 1756

Hi Manisha, Dmitry,

I like the idea of $assertonce but I don't think it should be restricted
to assertions in initial blocks. The meaning of $assertonce(a) will be
that "a" will have at most one attempt at the first time that such
attempt should occur, based on $asserton/$assertoff, the enabling
condition, the leading clock etc.

$assertonce should not be used in procedural code (like continues
assignment) and cannot be undone.

What do you think?

Doron

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Kulshrestha, Manisha
Sent: Thursday, November 01, 2007 7:09 AM
To: Korchemny, Dmitry; Neil.Korpusik@sun.com; Eduard Cerny
Cc: Bassam Tabbara; sv-ac@server.eda.org
Subject: RE: [sv-ac] Sketch for the new version of 1756

Hi,

Here is more elaborate description:

The $assertoff will work the same way it works now. So, the users can
issue $assertoff to disable the execution of assertions in initial
blocks as suggested in the proposal. But $asserton will not enable the
execution of these assertions (in the initial block). There will be a
new system task (say $assertonce), which will enable the specified
assertions for the subsequent clock tick. The arguments of this system
tasks will be same as $asseton's. The $assertonce will enable the
assertions only for one clocking tick. If the assertion is already
enabled to get executed on the next clocking tick then this task will
not have any effect. Also, this task will work only on the assertions
which are in the initial blocks (we may relax this if we are able to
define it for general case). 

This task can be executed at any time during simulation.

To solve the problem you have, basically $assertonce should be executed
at the same time as $asserton with the same arguments.

Is that clear or more explanation is needed ?

Thanks.
Manisha

-----Original Message-----
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
Sent: Wednesday, October 31, 2007 4:53 PM
To: Kulshrestha, Manisha; Neil.Korpusik@sun.com; Eduard Cerny
Cc: Bassam Tabbara; sv-ac@server.eda.org
Subject: RE: [sv-ac] Sketch for the new version of 1756

Hi Manisha,

Could you elaborate your point?

Thanks,
Dmitry

-----Original Message-----
From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com] 
Sent: Wednesday, October 31, 2007 10:53 AM
To: Korchemny, Dmitry; Neil.Korpusik@sun.com; Eduard Cerny
Cc: Bassam Tabbara; sv-ac@server.eda.org
Subject: RE: [sv-ac] Sketch for the new version of 1756

Hi,

I think we do not need any new tasks to disable/delay the asserts in
initial blocks (as $assertoff can do that). We need something to enable
them for the next clocking tick. This can be more generic than the
current requirement. We can make it work such that it enables the
asserts in initial blocks at the next clocking tick irrespective of the
current simulation time. If the assertion is already enabled to get
executed it will not have any effect.

Thanks.
Manisha

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Korchemny, Dmitry
Sent: Wednesday, October 31, 2007 1:20 PM
To: Neil.Korpusik@sun.com; Eduard Cerny
Cc: Bassam Tabbara; sv-ac@server.eda.org
Subject: RE: [sv-ac] Sketch for the new version of 1756

Hi Neil,

My idea was that if $assertdelay is issued at the first simulation tick
before the first activation of the Observed region, it delays the
activation of the relevant concurrent assertions until the first
$asserton. Therefore the order of execution of the initial blocks should
not be important here.

My intention is that $assertdelay is ignored if issued at any other time
than the first simulation tick before entering the Observed region.

Using $assertallon that you suggest is also an option, and needs to be
discussed. I would choose a different name for this task, though, since
we need a capability to select specific assertions to restart.

Thanks,
Dmitry

-----Original Message-----
From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM] 
Sent: Wednesday, October 31, 2007 2:43 AM
To: Eduard Cerny
Cc: Bassam Tabbara; Korchemny, Dmitry; sv-ac@eda.org
Subject: Re: [sv-ac] Sketch for the new version of 1756

Hi Dmitry,

There is a potential problem with the following approach:

>            1. Introduce a new directive $assertdelay. If it has been
>               issued at the beginning of simulation, all assertion
>               checks are suspended until the first $asserton.

What do you mean by "the beginning of simulation"?

The order of execution of initial blocks is not defined in the LRM.
Because
of this, there is no way to ensure that the call to $assertdelay occurs
before any of the initial blocks that contain assertions start
executing.

Are you also suggesting that $assertdelay has no effect if it is called
later in the simulation?

Maybe it would be better to define a new system task that has the effect
of
turning on all of the assertions, even those that currently "get lost".
Something like $assertallon might work. You could keep the current
behavior
for $asserton to maintain backward compatibility and add this new task
to
do what some of us think $asserton should have been doing, all along.

Neil



Eduard Cerny wrote On 10/30/07 12:06 PM,:
> I think that we would need a separate task, it is not to disable it by
> rather delay its start.
> ed
> 
>
------------------------------------------------------------------------
>     *From:* Bassam Tabbara [mailto:bassamt@synopsys.COM]
>     *Sent:* Tuesday, October 30, 2007 2:51 PM
>     *To:* Korchemny, Dmitry; Eduard Cerny; sv-ac@eda.org
>     *Subject:* RE: [sv-ac] Sketch for the new version of 1756
> 
>     Dmitry, to finish the thought that Ed started towards end of today
>     meeting (or at least my perception). I think a single system task
>     *with no arguments* that applies to all assertions would not fix
the
>     issue in general i.e. all asserts are delayed (dis/en)able or all
not.
>      
>     I suggest that we need to selectively (dis)able assertions. If you
>     agree to this selective approach then we don't really need a new
>     task, do we ?
>      
>     Thx.
>     -Bassam.
>      
> 
>
------------------------------------------------------------------------
>     *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On
Behalf
>     Of *Korchemny, Dmitry
>     *Sent:* Tuesday, October 30, 2007 6:38 AM
>     *To:* Eduard Cerny; sv-ac@eda.org
>     *Subject:* RE: [sv-ac] Sketch for the new version of 1756
> 
>     Hi Ed,
> 
>      
> 
>     I also think that introducing a new directive is cleaner.
> 
>      
> 
>     Dmitry
> 
>      
> 
>
------------------------------------------------------------------------
> 
>     *From:* Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
>     *Sent:* Tuesday, October 30, 2007 3:35 PM
>     *To:* Korchemny, Dmitry; sv-ac@eda.org
>     *Subject:* RE: [sv-ac] Sketch for the new version of 1756
> 
>      
> 
>     Hi Dmitry,
> 
>      
> 
>     I think that solution(2) is not convenient because these tasks
>     already have a variable list of arguments, it is not then easy to
>     distinguish.
> 
>      
> 
>     ed
> 
>      
> 
>          
> 
>
------------------------------------------------------------------------
> 
>         *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On
>         Behalf Of *Korchemny, Dmitry
>         *Sent:* Tuesday, October 30, 2007 9:14 AM
>         *To:* sv-ac@eda.org
>         *Subject:* [sv-ac] Sketch for the new version of 1756
> 
>         Hi all,
> 
>          
> 
>         Since there were objections regarding the solution proposed in
>         1756 I had an action item to send a sketch of other potential
>         solutions for this enhancement.
> 
>          
> 
>         The problem:
> 
>          
> 
>         All concurrent assertions belonging to initial procedures, are
>         suppressed in case that at the initial time $asserton or
>         $assertkill control tasks was issued. However, this behavior
is
>         not always desirable, and there should be a method to start
>         checking these assertions as soon as an appropriate $asserton
>         control task has been called.
> 
>          
> 
>         Consider the following scenario:
> 
>          
> 
>         The assertion is written to check that a eventually happens
> 
>          
> 
>         initial a1; assert property(@clk ##[*0:$] a);
> 
>          
> 
>         but $assertoff has been issued for all assertions at the
>         beginning of the simulation to skip the reset sequences. When
>         $asserton is issued, the above assertion is lost.
> 
>          
> 
>         The original proposal suggested that in case the assertions
have
>         initially been disabled, start checking them when they are
>         enabled for the first time.
> 
>          
> 
>         The objection claimed that this enhancement is not backward
>         compatible, and also, there is a problem when the user
intention
>         was indeed to suppress the assertions in the initial
procedures.
> 
>          
> 
>         Here are two possible backward compatible solutions:
> 
>          
> 
>            1. Introduce a new directive $assertdelay. If it has been
>               issued at the beginning of simulation, all assertion
>               checks are suspended until the first $asserton.
>            2. Introduce an additional optional argument to the control
>               tasks $assertoff and $assertkill. If it is 0, then their
>               behavior is as it is described currently in the LRM. If
it
>               is 1, and these directives were issued at the beginning
of
>               the simulation, the concurrent assertions in initial
>               procedures are checked when they become first enabled.
>               E.g., $assertoff(a1) - initially issued disables the
>               assertion a1 forever, $assertoff(a1, 1) delays checking
>                the assertion a1 until the first $asserton(a1) is
issued. 
> 
>          
> 
>         What is your opinion?
> 
>          
> 
>         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
<http://www.mailscanner.info/>*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.
> *
> 
>     *
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by <http://www.mailscanner.info/>**MailScanner*
>     <http://www.mailscanner.info/>*, and is
>     believed to be clean. *
> 
> 
> -- 
> 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.

-- 
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.
---------------------------------------------------------------------
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.