RE: [sv-ac] Checker instantiation in always procedures

Shalom or Dmitry,

 

Was this an editing error I made when implementing some previous Mantis
item?  If so, I should be able to correct this as an editorial correction in
the final version of draft 9.

 

Stu

~~~~~~~~~~~~~~

Stuart Sutherland

stuart@sutherland-hdl.com

(503) 692-0898

 

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of ben
cohen
Sent: Tuesday, July 14, 2009 8:58 AM
To: Bresticker, Shalom
Cc: Korchemny, Dmitry; sv-ac@server.eda.org
Subject: Re: [sv-ac] Checker instantiation in always procedures

 

Submitted  mantis 


0002807 <http://www.eda-stds.org/svdb/view.php?id=2807> 

LRM, 17.3.2 Change from "c2 check_loop(in1, d [const'(i)]);" TO: "c2
check_loop(posedge clk, d [const'(i)]);"

On Tue, Jul 14, 2009 at 8:45 AM, Bresticker, Shalom
<shalom.bresticker@intel.com> wrote:

About in1, I think you are correct. I think in1 was copy-pasted from 17.3.1,
but instead of deleting in1 from the copied example, 'posedge clk' was
deleted instead.

 

Shalom

 

  _____  

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of ben cohen
Sent: Tuesday, July 14, 2009 6:32 PM
To: Korchemny, Dmitry
Cc: sv-ac@server.eda.org
Subject: Re: [sv-ac] Checker instantiation in always procedures

 Dmitry,  

Agree that it should be revisited in the future.  The question I have though
right now is: 

What should a tool vendor implement?  He could implement what is in 17.3.2 

"However, a checker shall be evaluated statically or procedurally depending
on its placement in the parent checker".

Specifically, as shown in (a modification to what is in 17.3.2)

checker c3(event clk, logic a);  p3: assert property (@clk a); endchecker

checker c2(event clk, logic a);

  c3 c3_stat(clk, a);

  always @(clk) begin

    c3 c3_proc(clk, a); // LEGAL if c2 is instantiated as below

  end

endchecker

 

module m2(logic clk, logic [3:0] d);

  always @(posedge clk) begin

  c2 check_d1(posedge clk, d[1]);  // OK here ? 

  end

endmodule : m2

 

On a separate issue, in current LRM, 17.3.2 shows the following.  Where is
"in1"  declared?  Don't we mean "posedge clk" instead? 

module m2(logic clk, logic [3:0] d);

  always @(posedge clk) begin

    for (int i = 0; i < 4; i++) begin

      c2 check_loop(in1, d [const'(i)]);

   end

  end

endmodule : m2

Ben Cohen 

 

On Tue, Jul 14, 2009 at 7:45 AM, Korchemny, Dmitry
<dmitry.korchemny@intel.com> wrote:

Hi all,

 

In 17.5 Checker procedures it is written: 

 

An always procedure in a checker body may contain deferred and concurrent
assertions, nonblocking variable

assignments (see 17.7.1) and a procedural timing control statement using an
event control. All other

statements shall not appear inside an always procedure.

 

From here I understand that a checker cannot be instantiated in an always
procedure of another checker.

 

Nevertheless, 17.3.2 Nested checker instantiations explicitly discusses what
happens if one checker is instantiated in another checker.

 

It looks to be a contradiction that should be fixed (in the future).

 

What do you think?

 

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. 

 


-- 
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  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.