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

From: ben cohen <hdlcohen_at_.....>
Date: Tue Jul 14 2009 - 08:57:37 PDT
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 *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.
Received on Tue Jul 14 09:02:12 2009

This archive was generated by hypermail 2.1.8 : Tue Jul 14 2009 - 09:02:48 PDT