RE: [sv-ac] P1800-2009: checker body ; $display/$monitor commands?

Yes, this is correct.

Thanks,
Dmitry

-----Original Message-----
From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM]
Sent: Tuesday, May 19, 2009 2:54 AM
To: Korchemny, Dmitry
Cc: ben@systemverilog.us; Abhishek Muchandikar; sv-ac@eda.org
Subject: Re: [sv-ac] P1800-2009: checker body ; $display/$monitor commands?

I believe that Dmitry meant to say # 2743.

Neil




On 05/18/09 03:35, Korchemny, Dmitry wrote:
> Done, this is item # 2478.
>
>
>
> Neil,
>
>
>
> Could you please, grant Ben a member access to Mantis?
>
>
>
> Thanks,
>
> Dmitry
>
>
>
> *From:* ben cohen [mailto:hdlcohen@gmail.com]
> *Sent:* Thursday, May 14, 2009 10:21 PM
> *To:* Korchemny, Dmitry
> *Cc:* Abhishek Muchandikar; sv-ac@eda.org
> *Subject:* Re: [sv-ac] P1800-2009: checker body ; $display/$monitor
> commands?
>
>
>
> Dmitry,
>
> .. consistent in LRM .. but inconsistent in BNF!
>
> Anyway, I don't want to fight this. It's beyond my scope.
>
> However, could you please file  an enhancement request on my
> and Abhishek behalf in allowing subroutine_call_statement in a checker?
>  If there is an issue in using user-define subroutine, then at least
> allow the use of system calls, such as $display.
>
> Thanks,
>
> Ben
>
> On Thu, May 14, 2009 at 12:13 PM, Korchemny, Dmitry
> <dmitry.korchemny@intel.com <mailto:dmitry.korchemny@intel.com>> wrote:
>
> I don't think this is an error, at least it is consistent with the rest
> of the LRM. For example, in 9.2.2.4 Sequential logic always_ff procedure
> it is written:
>
>
>
> The always_ff procedure imposes the restriction that it contains one and
> only one event control and no
>
> blocking timing controls.
>
>
>
> But it is not reflected in the BNF.
>
>
>
> Regards,
>
> Dmitry
>
>
>
> *From:* ben cohen [mailto:hdlcohen@gmail.com <mailto:hdlcohen@gmail.com>]
> *Sent:* Thursday, May 14, 2009 10:00 PM
> *To:* Korchemny, Dmitry
> *Cc:* Abhishek Muchandikar; sv-ac@eda.org <mailto:sv-ac@eda.org>
>
>
> *Subject:* Re: [sv-ac] P1800-2009: checker body ; $display/$monitor
> commands?
>
>
>
> Dmitry,
>
> Since procedure calls are illegal in checkers, then there is an error
> in A.1.8 Checker item.
>
> Specifically, the defintiopn of a checker_always_construct.
>
> *checker_always_construct ::= always statement // <----*
>
> *statement ::= [ block_identifier : ] { attribute_instance }
> statement_item statement_item ::= ... | *subroutine_call_statement *<---
> ....*
>
> *subroutine_call ::=  ... tf_call | system_tf_call <--*
>
> *system_tf_call ::= system_tf_identifier [ ( list_of_arguments ) ] |
> system_tf_identifier ( data_type [ , expression ] ) *
>
> *system_tf_identifier46 ::= $[ a-zA-Z0-9_$ ]{ [ a-zA-Z0-9_$ ] } <---*
>
>  Ben Cohen
>
>
>
> On Thu, May 14, 2009 at 11:51 AM, Korchemny, Dmitry
> <dmitry.korchemny@intel.com <mailto:dmitry.korchemny@intel.com>> wrote:
>
> Hi Ben, Abhishek,
>
>
>
> Procedure calls are indeed forbidden in checkers except for assertion
> action blocks and final procedures. I can file an enhancement request on
> your behalf.
>
>
>
> Regards,
>
> Dmitry
>
>
>
> *From:* ben cohen [mailto:hdlcohen@gmail.com <mailto:hdlcohen@gmail.com>]
> *Sent:* Thursday, May 14, 2009 9:44 PM
> *To:* Abhishek Muchandikar
> *Cc:* Korchemny, Dmitry; sv-ac@eda.org <mailto:sv-ac@eda.org>
>
>
> *Subject:* Re: [sv-ac] P1800-2009: checker body ; $display/$monitor
> commands?
>
>
>
> Per Abhishek conversations (see below), there is an error in the
> following statement in LRM 17.5. Note that the syntax is OK.
>
> Dmitry could you write a Mantis for Abhishek or I for the following:
>
>
>
> P1800-2009 17.5 states:
>
> "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."*
>
>
>
> This seems to exclude the * subroutine_call_statement. *Actually, the
> "all other" is ambiguous to a reader. It needs to be clarified. Perhaps
> we _should explicitly specify _what shall not appear inside and always
> procedure.
>
> Ben Cohen
>
> -----
>
>
>
> On Thu, May 14, 2009 at 8:12 AM, Abhishek Muchandikar
> <Abhishek.Muchandikar@synopsys.com
> <mailto:Abhishek.Muchandikar@synopsys.com>> wrote:
>
> Hi Ben,
>
>
>
> Yup, this part I missed.
>
>
>
> I was referring to the below LRM statement 17.5 :
>
>
>
> "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."
>
>
>
> Thanks
>
> Abhishek
>
>
>
>
>
> *From:* ben cohen [mailto:hdlcohen@gmail.com <mailto:hdlcohen@gmail.com>]
> *Sent:* Thursday, May 14, 2009 7:12 PM
>
>
> *To:* Abhishek Muchandikar
> *Cc:* Korchemny, Dmitry
> *Subject:* Re: [sv-ac] P1800-2009: checker body ; $display/$monitor
> commands?
>
>
>
> Abhishek,
>
> I fail to understand why you say that a $display is not allowed on a
> checker variable. Where do you see that in the LRM?
>
> I see the following though:
>
>
>
> checker_or_generate_item ::= checker_or_generate_item_declaration |
> initial_construct *| checker_always_construct // <----*
>
> *...*
>
> *checker_always_construct ::= always statement // <----*
>
>
>
> *statement ::= [ block_identifier : ] { attribute_instance }
> statement_item statement_item ::= ... | subroutine_call_statement <--- ....*
>
>
>
> *system_tf_call ::= system_tf_identifier [ ( list_of_arguments ) ] |
> system_tf_identifier ( data_type [ , expression ] ) subroutine_call ::=
> tf_call | system_tf_call <--*
>
> *... *
>
> *system_tf_identifier46 ::= $[ a-zA-Z0-9_$ ]{ [ a-zA-Z0-9_$ ] } <---*
>
>
>
> Thus, the following should be legal:
>
> checker X;
>
>    logic clk, a;
>
>  always @ (posedge clk) $display("a= %b", a);
>
> endchecker;
>
>
>
> Ben Cohen
>
>
>
> On Thu, May 14, 2009 at 5:39 AM, Abhishek Muchandikar
> <Abhishek.Muchandikar@synopsys.com
> <mailto:Abhishek.Muchandikar@synopsys.com>> wrote:
>
> Hi Ben,
>
>
>
> Thanks for the reply.
>
>  As pointed out by you, we can always use action blocks  to make sue of
> $display but that would be sort of a WA.
>
> Would it not be a value add to have a $monitor on a checker var  as
> such. In this way we could actually track  checker data types.
>
> As of now there is no direct way to do this.
>
>
>
> Thanks
>
> Abhishek
>
>
>
>
>
>
>
> *From:* ben cohen [mailto:hdlcohen@gmail.com <mailto:hdlcohen@gmail.com>]
> *Sent:* Wednesday, May 13, 2009 8:25 PM
> *To:* Abhishek Muchandikar
> *Cc:* Korchemny, Dmitry
> *Subject:* Re: [sv-ac] P1800-2009: checker body ; $display/$monitor
> commands?
>
>
>
> Hi Abhishek,
>
> $display/$monitor are system functions, and are not disallowed.  In
> fact, on Page 428 *17.9 Complex checker example, *you can see the
> application of $display.
>
> generate if (coverage_level != cover_none) begin : cover_b
>
> cover_window_open: cover property (start_flag && !window)
>
> *$display("win_open_covered");*
>
> cover_window: cover property (
>
> start_flag && !window
>
> ##1 (!end_flag && window) [*0:$]
>
> ##1 end_flag && window
>
> ) *$display("window covered");*
>
> end : cover_b
>
> endgenerat
>
>
>
> On Wed, May 13, 2009 at 4:05 AM, Abhishek Muchandikar
> <Abhishek.Muchandikar@synopsys.com
> <mailto:Abhishek.Muchandikar@synopsys.com>> wrote:
>
> Hi Ben,Dmitry
>
>
>
> A generic question :
>
>
>
> In regards to checkers  , LRM 17.2 does not  mention use of
> display/monitor  statements in checker body.
>
> Do we plan to allow these commands in the checker body?
>
>
>
> Without the use of these command the debugging of checker variable would
> be tedious in my opinion.
>
> Add to the fact that use of checker vars  outside the checker body is
> illegal.
>
>
>
> Please comment.
>
>
>
> Thanks
>
> Abhishek
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
>
> 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.
>
>
>
> ---------------------------------------------------------------------
>
> 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.
>
>
>
> ---------------------------------------------------------------------
> 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.