Re: errata/192: PROPOSAL - 3.3.1: are real values for ranges allowed?

From: Dennis Marsa (drm@xilinx.com)
Date: Fri May 09 2003 - 09:40:02 PDT

  • Next message: Krishna Garlapati: "Re: generate"

    Precedence: bulk

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

    From: Dennis Marsa <drm@xilinx.com>
    To: Shalom Bresticker <Shalom.Bresticker@motorola.com>
    Cc: etf-bugs@boyd.com
    Subject: Re: errata/192: PROPOSAL - 3.3.1: are real values for ranges allowed?
    Date: Fri, 09 May 2003 10:31:30 -0600

     Shalom Bresticker wrote:
    >
    > I propose the following modification. If it seems reasonable, you can put it in
    > the FIX field.
    >
    > 1. In 3.3.1:
    >
    > REPLACE the 2nd paragraph:
    >
    > "Both msb constant expression and lsb constant expression shall be
    > constant expressions. The msb and lsb constant expressions can be
    > any value -- positive, negative or zero. The lsb constant expresson
    > can be a greater, equal, or lesser value than the msb constant
    > expression."
    >
    > WITH:
    >
    > "Both the msb constant expression and the lsb constant expression
    > shall be constant integer expressions. The msb and lsb constant
    > expressions can be any integer value -- positive, negative or
    > zero. The lsb value can be greater than, equal to, or
    > less than the msb value."
     
     OK
     
    > 2. In 3.9.1, add items to the dashed list:
    >
    > "-- Real number bit range specifications of vectors (see 3.3.1)
    > -- Real number address range specifications of array dimensions (see 3.10)"
     
     I was torn as to whether to propose adding another bullet or two to
     this section. I initially decided against it because the context of this
     section is talking about real operands (not real expressions) and which
     operators can be applied to real operands; i.e. it references table 4-7,
     and additionally states that edge descriptors and bit/part select can't be
     applied to real variables (not expressions).
     
     The third bullet states a restriction on part/bit selects, which I feel
     would be better placed where they are defined in 4.2.1, and which you
     propose in your part 4.
     
     So, if one agrees that the existing 3rd bullet is misplaced, I think
     the two additional ones you propose would be misplaced as well. The
     two restrictions you list are either already there, or you propose
     adding them, so I think that is enough.
     
    > 3. In 3.10, para. 2, change sentence 2 FROM:
    >
    > "The expression(s) that specify the indices of the array shall be constant
    > expressions."
    >
    > TO:
    >
    > "The expressions that specify the indices of the array shall be constant integer
    > expressions."
     
     OK.
     
    > 4. In 4.2.1, in para. 3, CHANGE
    >
    > "Both expressions shall be constant expressions."
    >
    > TO
    >
    > "Both expressions shall be constant integer expressions."
     
     I would propose:
     
     "Both the msb_expr and lsb_expr shall be constant integer expressions."
     
    > In para. 5, CHANGE:
    >
    > "The width_expr shall be a constant expression."
    >
    > TO:
    >
    > "The width_expr shall be a constant integer expression". (Note: see errata/228.)
     
     I would propose:
     
     "Each of the msb_base_expr, lsb_base_expr and width_expr shall be constant integer expressions."
     
    > 5. In 4.2.2:
    >
    > In para. 5, CHANGE
    >
    > "The addr_expr can be any expression;"
    >
    > TO:
    >
    > "The addr_expr can be any integer expression".
     
     OK.
     
    > In para. 9, CHANGE:
    >
    > "The syntax for access to the array ... an expression for each addressed
    > dimension:"
    >
    > TO:
    >
    > "The syntax for access to the array ... an integer expression for each addressed
    > dimension:"
     
     OK.
     
    > In para. 10, CHANGE:
    >
    > "As before, the addr_expr can be any expression."
    >
    > TO:
    >
    > "As before, the addr_expr can be any integer expression."
     
     OK.
     
     
     Dennis

    This archive was generated by hypermail 2.1.4 : Fri May 09 2003 - 09:41:04 PDT and
    sponsored by Boyd Technology, Inc.