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

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