RE: [sv-ac] 2005

From: Seligman, Erik <erik.seligman_at_.....>
Date: Mon Sep 17 2007 - 06:19:59 PDT
Wouldn't the second version cause problems in locations, such as within
functions, where an always_comb block is normally not permitted?

 

________________________________

From: Bustan, Doron 
Sent: Sunday, September 16, 2007 8:00 AM
To: Bustan, Doron; Korchemny, Dmitry; Seligman, Erik;
sv-ac@server.eda-stds.org
Subject: RE: [sv-ac] 2005

 

BTW, would it be correct to replace the sentence 

 

"If the assertion appears in a context with no defined

clock, it shall be treated as if clocked by a virtual clocking event
that is triggered at the beginning of every

time step."

 

With 

 

"If the assertion appears in a context with no defined

clock, it shall be treated as if they where placed in always_comb block
with no other components."

 

?

 

Doron

 

 

________________________________

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

 

I would use the same mechanism as for assertions with no clock:

 

"If the assertion appears in a context with no defined

clock, it shall be treated as if clocked by a virtual clocking event
that is triggered at the beginning of every

time step."

 

Doron

 

________________________________

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

 

Hi Doron,

 

But how would you infer the clock for the following invocation?

 

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

wire b = test_1(i1, i2);

endmodule

 

Thanks,

Dmitry

 

________________________________

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.
---------------------------------------------------------------------
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 <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.
Received on Mon Sep 17 22:15:19 2007

This archive was generated by hypermail 2.1.8 : Mon Sep 17 2007 - 22:15:42 PDT