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

Since this is an error in a code example, and technically code examples are
only "informative text" in the standard, I have no problems with correcting
the coding error as an editorial change.  I will make the change in the
final version of draft 9.

Stu
~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
(503) 692-0898


> -----Original Message-----
> From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM]
> Sent: Tuesday, July 14, 2009 6:18 PM
> To: stuart@sutherland-hdl.com
> Cc: Bresticker, Shalom; Korchemny, Dmitry; 'sv-ac@server.eda.org'
> Subject: Re: [sv-ac] Checker instantiation in always procedures
> 
> Hi Stu,
> 
> Shalom is correct, the example comes straight out of the text in part2 of
the
> proposal for mantis 1900. The Editor did not introduce this mistake.
> 
> I do agree with Shalom in that this example must have been "copy-pasted
from
> 17.3.1, but instead of deleting in1 from the copied example, 'posedge clk'
> was
> deleted instead."
> 
> The purpose of this example has to do with argument 'a' to the c3_proc
> checker
> instantiation, as described in the paragraph below the example. The
specific
> way that 'event clk' is shown in the example is not germane to the point
> being
> made.
> 
> Because of this, and the fact that it is only an example that is being
> changed, I am ok with the proposed change. It is now up to you as the
> Editor to decide if you are willing to make the change.
> 
> I suspect that most readers will not be confused by the example, as is. A
> bunch of us reviewed this before it was approved and no one noticed this
> problem. That is most likely due to the fact that the focus of the example
> is on argument 'a' and not 'clk'.
> 
> 
> Neil
> 
> On 07/14/09 13:09, Bresticker, Shalom wrote:
> > 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* <http://www.mailscanner.info/>, and
is
> > believed to be clean.


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