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

Hi Ben,

I just created a Mantis account for you. You should be
receiving an email with your password in it. It looks like
you have at least two email accounts. I specified your
gmail account (hdlcohen@gmail.com).

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.


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