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

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Mon May 18 2009 - 10:27:55 PDT
The BNF is the outer limit to what's legal.  If it's not accepted by the BNF, it's illegal.  There are semantic checks in the LRM that further limit what is legal.  That's not inconsistent.

-- Brad

________________________________
From: owner-sv-ac@eda.org [owner-sv-ac@eda.org] On Behalf Of ben cohen [hdlcohen@gmail.com]
Sent: Monday, May 18, 2009 10:07 AM
To: sv-ac@eda.org
Cc: Korchemny, Dmitry
Subject: Re: [sv-ac] P1800-2009: checker body ; $display/$monitor commands?

I have an issue with the inconsistency in assuming in some instances that the BNF is not the real bible, except in some case; et also assuming that in other cases the LRM text, instead of the BNF is the real bible. For example:
Lisa Piper: On the issue of default disable iff declaration:
"I agree that the text could be more clear.  The BNF is clear that disable iff is allowed in a checker."
In this case, the BNF is the bible!
--
Brad Pierc: On the issue of checker body ; $display/$monitor commands
Yes, the BNF syntax description should not try to express every semantic restriction imposed by the text.
n this case, the BNF is NOT the bible!

For this case on checker, I recommend that we modify the definition of the checker_always_construct
From:
checker_always_construct ::= always statement  // <----
To:
Something more exact that reflects the limitations, such as the use of  subroutine_call_statement

Before writing a Mantis (which I am still not allowed yet), I want to hear your comments.
Is this worthwhile?
Ben Cohen

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_$ ] }  <---



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




--
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 Mon May 18 10:47:50 2009

This archive was generated by hypermail 2.1.8 : Mon May 18 2009 - 10:48:42 PDT