RE: [sv-ac] 2005

Hi Dimitry,

 

I do not understand how the two assertions can be considered equivalent
even conceptually. The variable 'z' in the function only gets assigned
the value of 'x' when the function gets called. So, the values of z at
clock ticks (or its sampled values) would be totally different from the
value of 'c' at clock ticks. I feel it will be very confusing for the
users to write assertions in functions as their interpretation will be
very different from what it looks like.

 

Thanks.

Manisha

 

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Korchemny, Dmitry
Sent: Monday, September 17, 2007 8:40 PM
To: Bresticker, Shalom; Bustan, Doron; sv-ac@server.eda-stds.org
Subject: RE: [sv-ac] 2005

 

Hi Shalom,

 

The concurrent assertions are not executed with the flow, even if they
are put directly inside the module. They have their independent threads
of execution, and they just infer their "parameters" from the context,
e.g., the clock and the enabling condition. From this point of view
nothing prevents from putting them into functions, they do not interfere
with the function flow. Let me illustrate it on the following artificial
example:

 

module m;

...

wire a = b && f(c, d);

...

endmodule m;

 

function bit f(bit x, y);

bit z = x;

if (y) begin

  z = !x;

  assert property(@clk ##1 !$stable(z));

end

end

 

This assertion is equivalent to the following assertion:

 

module m;

...

wire a = b && f(c, d); // Function without assertion

assert property(@clk d |-> ##1 !$stable(!c));

...

endmodule m;

 

I would like to stress that I am only illustrating the concept here, and
not discussing whether it makes sense to allow temporal assertions in
functions or just the boolean ones.

 

Thanks,

Dmitry

 

________________________________

From: Bresticker, Shalom 
Sent: Sunday, September 16, 2007 7:30 PM
To: Korchemny, Dmitry; Bustan, Doron; 'sv-ac@server.eda-stds.org'
Subject: 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 <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.