Re: errata/474: First class part selection operator

From: Steven Sharp (sharp@cadence.com)
Date: Thu Sep 18 2003 - 15:40:00 PDT

  • Next message: Brad Pierce: "errata/483: 4.2: Bit/part-selects of parameters"

    Precedence: bulk

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

    From: Steven Sharp <sharp@cadence.com>
    To: etf-bugs@boyd.com
    Cc:
    Subject: Re: errata/474: First class part selection operator
    Date: Thu, 18 Sep 2003 19:24:01 -0400 (EDT)

     Note that currently, a bit or part select is applied only to an object.
     It means that you want to reference certain bits of that object, using
     the bit numbering that was specified on the declaration of the object.
     While it could be viewed as an "extraction" operation performed on a
     value, you can also see it as an odd sort of "name" for part of an object.
     So you don't necessarily have to view the current version as a "second
     class operator". It just isn't an operator.
     
     If you do want to view it as an operator and therefore generalize it,
     there are some issues that have to be resolved. When applied to an
     object, there is a specific range on the object declaration which defines
     what the bit numbers mean. With a general expression, there is no such
     declaration, and you have to define something. The obvious choice is to
     treat it as if it had a range of [width-1:0] whenever it is applied to
     something other than an object.
     
     But when exactly is that and how do we specify it? Presumably this is
     anything other than an identifier. This causes some oddities. For
     example, if you declare "reg [0:31] r;", then r[0] refers to the MSB,
     but (r)[0] refers to the LSB, because (r) is not an identifier. What
     about a function call? The function return value was specified with an
     explicit range. Should a function call use the range of its return type,
     or should it be considered an expression and use the default range for an
     object of that width?
     
     Making bit and part selects operators that can act on any vector value
     would also allow some strange syntax. Since the result of a bit or part
     select is a vector, there would be nothing to prevent taking another bit
     or part select of that result. That would allow things like r[i][j][k],
     which might look like a reference to a multidimensional array, but is just
     a bit-select of a bit-select of a bit-select. Or it would allow things
     like r[7:0][6:0] or r[7:0][3], which look like some kind of array slicing
     that isn't legal in Verilog, but are just further selects of the result
     of a part select. You could even use r[i][3:0], which looks like a part
     select of an array reference, but is actually a part select of a bit select,
     with all but one of the selected bits out of range.
     
     This means that if you put too many subscripts on your array reference,
     your tool wouldn't give you an error message any more. This is already an
     issue with allowing bit selects of array elements, since one too many
     subscripts will be treated as a bit select. But this would allow an
     arbitrary number of excess subscripts without any error.
     
     I'm not opposed to this extension, but I want to be sure that everyone
     understands the implications.
     
     Steven Sharp
     sharp@cadence.com
     

    This archive was generated by hypermail 2.1.4 : Thu Sep 18 2003 - 15:42:38 PDT and
    sponsored by Boyd Technology, Inc.