Re: errata/608: mintypmax_expression usage

From: Brad Pierce (Brad.Pierce@synopsys.com)
Date: Fri Jul 30 2004 - 10:50:00 PDT

  • Next message: eric_mahurin@yahoo.com: "errata/610: operand/operator relationship is ambiguous for event_expressions"

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

    From: "Brad Pierce" <Brad.Pierce@synopsys.com>
    To: <etf-bugs@boyd.com>
    Cc:
    Subject: Re: errata/608: mintypmax_expression usage
    Date: Fri, 30 Jul 2004 10:45:43 -0700

     There's usually a simulator switch to control whether to pick up
     min, typ or max, with typ as the default. A common use is explore
     the potential impact of the library cell delay factors. (Mintypmax
     expressions have no meaning in synthesis.)
     
     -- Brad
     
     
     -----Original Message-----
     From: owner-etf@boyd.com [mailto:owner-etf@boyd.com]On Behalf Of Eric
     Mahurin
     Sent: Friday, July 30, 2004 9:50 AM
     To: etf-bugs@boyd.com
     Subject: Re: errata/608: mintypmax_expression usage
     
     
     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 - 10:50:05 PDT and
    sponsored by Boyd Technology, Inc.