RE: [sv-bc] E-mail Ballot: Respond by 8am PDT, Tuesday, March 25

>From: "Stuart Sutherland" <stuart@sutherland-hdl.com>

>Another already approved Mantis item does allow bit and part-selects of
>abstract expressions.  Therefore it is important that the standard does
>define the bit numbering of a size cast (which the proposal does), and that
>the bit numbering be intuitive (which I feel the proposal fails to do).

As Shalom has pointed out, this is only allowed for concatenations.

A concatenation can contain multiple nets/variables, each with their
own bit numberings.  So you cannot derive an overall bit numbering for
the concatenation from the numberings of the components.  They may even
have different endiannesses, so you cannot even derive an overall
endianness from them.  In this case, it seems pretty clear that you
have to give up on deriving anything from the components, and go to
a normalized numbering.  Such a normalized numbering already exists,
and it is [width-1:0].

Other expression types, including size casts, do not allow bit or part-
selects.  So the description of the numbering has little impact.  But
I will give my response to your comments.


>What I think is intuitive is:
>- A size cast of a little-endian expression (e.g. logic [47:0] foo;) should
>return a little-endian expression (e.g. 32'(foo) returns an expression the
>bit numbering [31:0]).  Note that the LARGEST-numbered LEFT-most bits (the
>MSB's) of foo are what is affected by the cast.

I would have expressed that by saying it is the smallest-numbered,
right-most bits (the LSBs) of foo are what are retained.

Note that this has the nice property that if an expression with this
normalized numbering is size-cast into an expression with the same
normalized numbering, each bit that appears in both has the same index
in both.


>- A size cast of a big-endian expression (e.g. logic [0:47] foo;) should
>return a big-endian expression.  What I am undecided on is if a size cast of
>a big-endian expression affects the SMALLEST-numbered LEFT-most bits (e.g.
>32'(foo) returns an expression with the bit numbering [16:47]) or the
>LARGEST-numbered RIGHT-most bits (e.g 32'(foo) returns an expression with
>the bit numbering [0:31]).

Regardless of the numbering, it must return the least significant bits.
That is how all existing integral conversions work in Verilog (and in
other languages, such as C).  That is the conversion that preserves the
integer value, assuming that it fits into both types.  Anything else
is not intuitive, no matter how the bits are numbered.

That still leaves the issue in your proposed scheme of how those bits
should be numbered.

If you use the bit numbering [0:31], even though you have kept the
right-most bits, then none of the bits have the same index that they
had before the cast.  That doesn't seem intuitive.

If you use the original bit numbers for the bits [16:47], then it is
not zero-based.  As you continue to do operations, you not only have
to keep track of the width, but of what the starting bit number is.  You
cannot just use the width and derive the range by knowing that the
range is zero-based.  Figuring out what bit index is third from the
right is not going to be obvious.  If you know that you want the bit
numbered 40 in the original object, then you are okay (assuming that
bit is still present).  But if you know that you want bit 40 and that
it is still present, then why did you do a size cast before selecting
bit 40 anyway?  Why not just select bit 40 in the first place, without
doing the size cast?


As with concatenations, in most expressions you will not be able to
derive a numbering from the original operands.  What is the proper
bit numbering for "b+c", when b was declared [31:0] and c was declared
[40:80]?  In any expression with more than one operand, you will have
to give up and use a normalized numbering scheme.  In an expression
that is just an identifier, you use the numbering for that identifier.
The question is where you switch from one to the other.

I favor switching to normalized numbering as early as possible.  I
think it keeps things simple.  And once you have switched to the
normalized numbering, any subsequent casting won't have the problem
you raised with figuring out the numbering of the result.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.