RE: [sv-ec] RE: [sv-bc] 5.15.3 Array reduction methods - result type

Chris Spear wrote me:

> This burned me so many times, I dedicated about 3 pages to it in my 
> book.

Shalom

> -----Original Message-----
> From: owner-sv-ec@server.eda-stds.org [mailto:owner-sv-ec@server.eda-
> stds.org] On Behalf Of Bresticker, Shalom
> Sent: Wednesday, June 28, 2006 8:48 AM
> To: pgraham@cadence.com
> Cc: sv-bc@server.verilog.org; sv-ec@server.verilog.org
> Subject: [sv-ec] RE: [sv-bc] 5.15.3 Array reduction methods - result
> type
> 
> I understand the reasoning, but it is not the Right Thing to do here.
> It is not what users will want.
> 
> You say that in some cases, e.g., a big array of big integers, even 32
> bits might not be enough for the return value. That is true, but that
> case will be much rarer than the current definition. And an explicit
> note in the LRM could warn about that rare case.
> 
> I propose that the return value of sum() and product() should be
32-bit
> integers for integral type array elements.
> 
> A question about the current definition is whether the return type is
> self-determined or context-determined. If I write (array.sum() + 0),
> does that turn sum() into 32 bits before its calculation and prevent
the
> loss of bits, or is sum() first calculated according to the element
type
> and only afterwards bit-extended?
> 
> My intuition expected the 2nd case, meaning that I don't even have a
way
> to prevent or workaround the overflow. But apparently at least one
> simulator does it the first way.
> 
> 
> > > Suppose I have an array of type bit. It would appear that sum()
will
> > > give me a result of 1-bit width, which is not what I want. This is
> at
> > > the least going to surprise users and make them unhappy...
> >
> > If you're familiar with the verilog rules for expression
> > sizing, it won't surprise you to find that adding two bits
> > gives you one bit!
> >
> > But what else can you expect?  Even with an array of integers,
> > you might want the return value to be more than 32 bits wide
> > to accomodate the sum.
> >
> > Paul
> 
> Thanks,
> Shalom