errata/527: Re: errata/527: Replication operator on concats involving function calls

From: Shalom.Bresticker@motorola.com
Date: Thu Jan 08 2004 - 11:40:00 PST

  • Next message: Steven Sharp: "Generate proposal"

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

    From: Shalom.Bresticker@motorola.com
    To: Brad Pierce <Brad.Pierce@synopsys.com>
    Cc: etf-bugs@boyd.com
    Subject: Re: errata/527: Replication operator on concats involving function
     calls
    Date: Thu, 8 Jan 2004 21:48:56 +0200 (IST)

     But you need very good justification in order to break back-compatibility.
     
     In 402, Steven Sharp wrote:
      The situation where XL appears to re-evaluate the case expression is quite
      limited, and is due to a particular optimization. It only occurs if the
      case expression is an identifier. If it contains any operators, even ones
      that don't affect the value (e.g. {i}), then the expression only gets
      evaluated once. Even implicit operations, such as extending the width
      of the value to match a wider expression in one of the case item expressions,
      will ensure it is only evaluated once.
     
      It appears that this is an optimization that determines that the value of
      the expression is identical to the value of the identifier, and uses the
      value held in the identifier for the comparisons, to save making a copy.
      Applying this optimization in this situation, where other expressions
      will be evaluated and have side effects before this value is used, results
      in the behavior are seeing. This behavior is not intentional, and should
      be considered an obscure bug in XL.
     
      If XL is run with all optimizations turned off, this does not happen. The
      case expression is only evaluated once. Note that there are other situations
      in which XL changes behavior at different optimization levels. In these
      cases, turning off all optimizations gives the most consistent and "standard"
      behavior.
     
     So 402 was not even really breaking XL.
     All the more so because 402 was talking about a case where the LRM was silent,
     and here you talk about a case where the LRM explictly allowed more than one
     behavior.
     
     Shalom
     
     
    > It may have been a good enough reason in the past, but backward
    > compatibility with every detail of every corner case of Verilog-XL
    > should not necessarily be a requirement for Verilog-2005. If it
    > is, then we should revisit issue 402 (also regarding function side
    > effects) in which Verilog-XL did not implement the intended behavior.
    >
    > Verilog-XL was a great tool. But it was software, so it wasn't
    > perfect.
     
     You mean software is not perfect?????
     
     --
     Shalom Bresticker Shalom.Bresticker@motorola.com
     Design, Verification & Reuse Methodology Tel: +972 9 9522268
     Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
     POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
     
     

    This archive was generated by hypermail 2.1.4 : Thu Jan 08 2004 - 11:40:03 PST and
    sponsored by Boyd Technology, Inc.