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

From: ben cohen <hdlcohen_at_.....>
Date: Thu May 14 2009 - 12:00:28 PDT
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> 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]
> *Sent:* Thursday, May 14, 2009 9:44 PM
> *To:* Abhishek Muchandikar
> *Cc:* Korchemny, Dmitry; 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> 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]
> *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> 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]
> *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> 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.
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu May 14 12:14:19 2009

This archive was generated by hypermail 2.1.8 : Thu May 14 2009 - 12:14:48 PDT