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

Unfortunately, the error is in the Mantis 1900 proposal. So I guess this requires Neil's approval to fix.

Shalom

________________________________
From: Stuart Sutherland [mailto:stuart@sutherland-hdl.com]
Sent: Tuesday, July 14, 2009 8:12 PM
To: Bresticker, Shalom; Korchemny, Dmitry
Cc: 'sv-ac@server.eda.org'
Subject: 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<mailto: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> [mailto: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<mailto: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<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.