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.Received on Tue Jul 14 18:19:05 2009
This archive was generated by hypermail 2.1.8 : Tue Jul 14 2009 - 18:20:05 PDT