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