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

I accept the arguments given by Shalom and Steven, and withdraw my
objections to the proposal.  What I consider most important is the LRM
specify a non-ambiguous behavior, which I feel this proposal does.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Steven Sharp
> Sent: Tuesday, April 01, 2008 5:35 PM
> To: shalom.bresticker@intel.com; sv-bc@eda.org; stuart@sutherland-
> hdl.com
> Subject: 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.



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