RE: [sv-ac] 2005

Let me clarify.  
 
Functions execute with no delay. They may not contain statements that
block.
 
Until now, the list of statements that a function may contain was quite
restricted. 
Mantis 1336 (SV-EC) comes to relax those restrictions and allow
statements that themselves don't block, but spawn processes or events
that execute later.
 
So the question is how this is going to work with assertions within
functions.
 
Now, in static functions this might be simpler, because some aspects of
the function remain in existence after the function ends, but in the
case of an automatic function, everything comes into existence when the
function is called and dies when the function ends (again as excepted by
Mantis 1336). 
 
So it is not clear to me how an assertion works, especially a clocked
one, within a function.
 
Shalom


________________________________

	From: Korchemny, Dmitry 
	Sent: Sunday, September 16, 2007 4:42 PM
	To: Bresticker, Shalom; Bustan, Doron; sv-ac@server.eda-stds.org
	Subject: RE: [sv-ac] 2005
	
	

	Hi Shalom,

	 

	It should be described in Mantis 2005. This proposal is written
in terms of rewriting: how to transform an assertion written in a
function to a standalone assertion in the module. This is the matter of
definition. The discussion is whether this definition is intuitive and
how efficiently these assertions may be simulated.

	 

	Regards,

	Dmitry

	 

	
________________________________


	From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org] On Behalf Of Bresticker, Shalom
	Sent: Sunday, September 16, 2007 3:07 PM
	To: Bustan, Doron; sv-ac@server.eda-stds.org
	Subject: RE: [sv-ac] 2005

	 

	Doron,

	 

	What do you mean by "see" ?

	 

	In fact, the whole meaning of a clocked concurrent assertion in
an automatic function is not clear to me. Is this described somewhere?

	 

	Regards,

	Shalom

		 

		
________________________________


		From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org] On Behalf Of Bustan, Doron
		Sent: Sunday, September 16, 2007 2:43 PM
		To: Seligman, Erik; sv-ac@server.eda-stds.org
		Subject: [sv-ac] 2005

		Hi Erik,

		 

		I have a question about assertions in functions:

		Let's look at the example below:

		 

	
------------------------------------------------------------------------
--

		module m(input clk1, clk2, i1, i2);

		bit b;

		 

		function automatic bit test_1(bit x, y);

		   test_1  = (x == y);

		  a1: assert property (@(posedge clk1) x == y);

		endfunction

		 

		always @ (posedge clk2) b <= test_1(i1, i2);

		 

		endmodule

	
------------------------------------------------------------------------
--

		 

		The assertion a1 is clocked on "posedge clk1" but the
function is called on "posedge clk2".

		Since there is no "ref" on the function's port list, the
arguments values are passed by value.

		This means, that a1 "see" the values of "i1, i2" on
"posedge clk2". It that your intent?

		It looks like the clocking event in the assertion is
misleading. Maybe we should restrict the 

		Clocking event to be inferred from the context of the
function call?

		 

		Doron

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

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

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