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

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