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.