[sv-ac] FW: PROPOSAL for statement_expr BNF


Subject: [sv-ac] FW: PROPOSAL for statement_expr BNF
From: David W. Smith (david.smith@synopsys.com)
Date: Mon Dec 08 2003 - 15:39:08 PST


Here is a proposal from Brad Pierce.

Regards
David

-----Original Message-----
From: Brad Pierce [mailto:bpierce@Synopsys.COM]
Sent: Monday, December 08, 2003 2:57 PM
To: David W. Smith
Subject: PROPOSAL for statement_expr BNF

Attached is a BNF proposal for sequence expressions that attempts to use
factoring to remove a few ambiguities, i.e., multiple
derivations for the same sequence expression, and to provide more intuition
to users. The intent is not to eliminate any of the existing language of
sequence expressions, but only to eliminate some of the possible derivations
for those sequence expressions.

Summary --

  1) Highlights the low precedence of the concatenation
      operator ##

  2) Make more obvious that "##ce1 ##ce2 b" is a legal way
      to express "##(ce1 + ce2) b".

  3) Makes clearer that, conceptually, [* is applied only
      to sequence expressions and sequence instances, which
      the proposal groups into sequence_factor. To apply [*
      to a boolean expression, it must be promoted to a
      sequence_factor.

  4) Likewise, makes clearer that [*= and [*-> can only be
      applied to boolean expressions or parenthesized boolean
      expressions, which the proposal groups into
      sequence_primary.

  5) Allows a () to be used around an event control expression
      when it is used as an argument and mandates such () for
      disambiguation in the case that the event control expression
      uses commas. An example from
      http://www.eda-twiki.org/sv-ac/hm/0928.html is

           sequence s (a = b, c, d);
              a ##1 d;
           endsequence

Side-note --

   I've heard some unnecessary concerns about parsing the
   operators in Table 17-1 of the SV 3.1 LRM. In particular,
   there has been the worry that maybe the ## operator should
   be parsed as two # tokens and that it could be possible
   for whitespace or comments to separate them. However, this
   would violate the 1364 Verilog standard, section 2.1,
   which clearly states that one of the types of lexical tokens
   is Operator. (For example, the && operator cannot be parsed
   as two & tokens.) Hence the ## operator is a single token,
   and neither # # nor #/**/# could legally be substituted for it.

-- Brad




This archive was generated by hypermail 2b28 : Mon Dec 08 2003 - 15:36:40 PST