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

From: Korchemny, Dmitry <dmitry.korchemny_at_.....>
Date: Wed Jul 15 2009 - 10:45:08 PDT
Hi Ben,

I think, your second question has been answered by Shalom. As for the first one, it depends on the vendor. From a contradictory statement it is possible to infer everything:). Usually an explicit example is a better argument than an abstract statement.

Regards,
Dmitry

From: ben cohen [mailto:hdlcohen@gmail.com]
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.

---------------------------------------------------------------------
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.
Received on Wed, 15 Jul 2009 20:45:08 +0300

This archive was generated by hypermail 2.1.8 : Wed Jul 15 2009 - 10:49:17 PDT