Re: errata/608: mintypmax_expression usage

From: Eric Mahurin (eric_mahurin@yahoo.com)
Date: Fri Jul 30 2004 - 09:50:00 PDT

  • Next message: eric_mahurin@yahoo.com: "errata/609: string should be a primary not an expression"

    The following reply was made to PR errata/608; it has been noted by GNATS.

    From: Eric Mahurin <eric_mahurin@yahoo.com>
    To: etf-bugs@boyd.com
    Cc:
    Subject: Re: errata/608: mintypmax_expression usage
    Date: Fri, 30 Jul 2004 09:47:19 -0700 (PDT)

     --- Shalom.Bresticker@freescale.com wrote:
     
    > Eric,
    >
    > > Section 4.3 says this: "Values expressed in
    > min:typ:max format can be used in expressions. The
    > min:typ:max format can be used
    > > wherever expressions can appear."
    > >
    > > I think the intent is that these ONLY be used with
    > expressions that are used for generating delays or
    > times. I don't see where it says that.
    >
    > No, mintypmax expressions really can be used
    > anywhere.
     
     
     Interesting. I've never seen examples of it anywhere
     else than under the context of delays. Do the
     simulators actually allow it anywhere? I don't have
     verilog-xl at my disposal (only gpl-cver).
     
     
    > > Secondly, the BNF is inconsistent in its use of
    > mintypmax_expression and expression. As it is now,
    > even an epression can have a mintypmax_expression in
    > it with parenthesis.
    > >
    > > Personally, I think mintypmax_expression should
    > unified expression and then in the text just
    > describe when an expression or portion of it should
    > allow the mintypmax ":" operators.
    >
    > mintypmax expressions are discussed somewhat in
    > issues 174 and 226.
    >
    > We know that the BNF is not completely consistent
    > with where implementations
    > actually require the parentheses and where they
    > don't. We found it to be
    > difficult to research the subject thoroughly and to
    > make the BNF conform to
    > that. If we take the approach that the BNF in the
    > next revision can be more
    > lenient as long as it does not forbid anything which
    > currently works, then it
    > might be easier.
     
     Actually, I take back the idea to completely merge
     mintypmax_expression in expression. There are several
     places where this would cause unnecessary ambiguities
     because of the colons:
     
     - ranges/dimensions
     - case items (including the generate variety)
     statements
     
     You could do the merger everywhere except these
     places. Or, at a minimum, timing_check_limit (and
     threshold?) from A.7.5.2 should be changed to
     mintypmax_expression, since there is code that has it
     for those system timing check commands.
     
     
    > > But, if you don't do this, at least make all of
    > the places that can have delay/time values use
    > mintypmax_expression instead. Here are the ones I
    > found:
    > >
    > > A.2.2.1: variable_type
    > >
    > > A.4.1: ordered_parameter_assignment (named
    > parameters allow mintypmax, but ordered doesn't)
    > >
    > > A.6.5: wait statement
     
     
     nevermind this one. I forgot what the expression was
     in the wait statement was - a condition.
     
     
    > > A.7.5.2: timing_check_limit (found the issue here
    > originally while parsing some example code with a
    > $period statement and colons used direction in these
    > timing_check_limit arguments)
    >
    > I haven't looked at these.
    >
    >
    > > Again, I think expression and mintypmax_expression
    > should be merged (along with constant_expression and
    > module_path_expression) instead.
    >
    > I looked at merging constant_expression and
    > module_path_expression with
    > expression, as you suggested. I found then different
    > enough at the basic
    > element, the primary, that I was reluctant to do
    > that merger.
    >
    > The idea of mintypmax_expression as I remember was
    > to require parentheses
    > everywhere except where specifically allowed without
    > parentheses.
    >
    > Bring on the additional issues.
    >
    > Shalom
    >
    > --
    > Shalom Bresticker
    > Shalom.Bresticker @freescale.com
    > Design & Reuse Methodology
    > Tel: +972 9 9522268
    > Freescale Semiconductor Israel, Ltd.
    > Fax: +972 9 9522890
    > POB 2208, Herzlia 46120, ISRAEL
    > Cell: +972 50 5441478
    >
    >
     
     
     
                     
     __________________________________
     Do you Yahoo!?
     New and Improved Yahoo! Mail - Send 10MB messages!
     http://promotions.yahoo.com/new_mail
     

    This archive was generated by hypermail 2.1.4 : Fri Jul 30 2004 - 09:50:06 PDT and
    sponsored by Boyd Technology, Inc.