Re: errata/483: 4.2: Bit/part-selects of parameters

From: Shalom.Bresticker@motorola.com
Date: Fri Sep 19 2003 - 01:50:00 PDT

  • Next message: Shalom.Bresticker@motorola.com: "Re: errata/208: PROPOSAL - 12.4, A.9.4: no negative indexes in hierarchical_identifiers"

    Precedence: bulk

    The following reply was made to PR errata/483; 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/483: 4.2: Bit/part-selects of parameters
    Date: Fri, 19 Sep 2003 12:32:05 +0300 (IDT)

    > Sections 4.2 and 4.2.1 should mention that it is possible to take
    > the bit- and part-select of parameters that are not declared
    > real or realtime.
     
     This is sort of a side-question, but what is the type of a parameter
     without a type specification? The LRM does not say explicitly (3.11.1).
     I think it should say that it is implicitly declared as a "reg" type,
     like functions.
     
     Also, the last two rules (5 and 6 of 6) in 3.11.1 are confusing.
     
     Rule 5 says,
     
     "A parameter with no range specification, and with either a signed type
     specification or no type specification, shall have ..."
     
     and Rule 6 says,
     
     "A parameter with no range specification, and with either a signed type
     specification or no type specification, and for which the final value
     assigned to it is unsized, shall have ..."
     
     I think Rule 5 should specify also that it is for the case where the
     parameter is assigned a sized value.
     
     Also, the original issue was that in Clause 4, the definition of
     "operand" should include parameters and their bit/part-selects
     (and also bit/part-selects of array elements), or rewrite that paragraph
     entirely.
     
      
    > And in constant_primary the parameter_identifier production should
    > be changed to something like --
    >
    > | parameter_identifier
    > [ {"[" constant_expression "]" }
    > "[" constant_range_expression "]"
    > ]
     
     Why
     
    > [ {"[" constant_expression "]" } ?
     
     There are no arrays of parameters
     (although maybe there should be).
     
     I think
     
         | parameter_identifier [ "[" constant_range_expression "]" ]
     
     is sufficient.
     
     I guess the same should apply to specparam_identifiers as well.
     
     
    > Also, is it true that any constant_primary is also a primary?
    > This is not obvious from the BNF.
     
     It better be.
     And as far as I can tell, it is.
     
     Shalom
     
     --
     Shalom Bresticker Shalom.Bresticker@motorola.com
     Design & 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 : Fri Sep 19 2003 - 01:52:37 PDT and
    sponsored by Boyd Technology, Inc.