Subject: Re: [sv-ec] Re: [sv-bc] Packed arrays
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Jan 30 2003 - 10:24:37 PST
> From owner-sv-ec@eda.org Wed Jan 29 18:13:49 2003
>
> >Date: Wed, 29 Jan 2003 17:35:52 -0800 (PST)
> >From: "Kevin Cameron x3251" <Kevin.Cameron@nsc.com>
>
> >The conversion isn't the issue, it's the propagation as bits. Sure you
> >can spend a lot of time optimizing it all away, but it's cheaper just
> >to specify it as a shared real value if that's what you want.
>
> You compared it to a wreal, which costs just as much to propagate as the
> bits do (assuming that you don't do something to force vector expansion
> of the bits).
>
> A shared real variable should be cheaper, because of lower scheduling cost.
>
> I don't see how any of this relates to allowing reals in packed structs.
There were actually two arguments running a) deprecating $bitstoreal etc.
and b) allowing real values in packed unions.
> >> And you have yet to provide a reason why a user needs this.
> >
> >Given that most hardware is going to use IEEE formats, I don't see why I
> >shouldn't be able to do:
> >
> > packed union {
> > double d;
> > bit [63:0] i;
> > } pdi;
> >
> >as well as
> >
> > union {
> > double d;
> > bit [63:0] i;
> > } di;
>
> Your sense of what you should be able to do still doesn't provide a
> real reason why a user needs this.
>
> Also, while C allows a similar union, it does not make any guarantees
> about the resulting behavior when storing one type and reading the other.
>
> >If my wires are carrying a "double" value I'd like to be able to say so.
>
> I agree that wires should be able to carry a real value, and any other
> type that can be defined. As I understand it, this is not possible in
> SV, as all user-defined types are variables, not nets. I think this is
> a flaw in the SV type system.
Packed structs are equivalent to bit vectors, each bit (maybe) representing
a seperate physical wire. What I want to say is that a bundle of 64 wires can
be carrying a double or an integer or some other bit pattern.
> >Which platform does your simulator run on that doesn't use IEEE floating
> >point representation? If you do have one how much information is lost if
> >you assign the platform specific double to the IEEE format?
>
> None at this time, nor do I foresee any. And it turns out that the IEEE
> Verilog standard specifically states that reals will use the IEEE 754
> floating point format. So an implementation that used the native format
> on a platform that did not support IEEE floating point would technically
> not be compliant with the Verilog standard. But it would be foolish not
> to use the native format in that situation. The alternative would be a
> high cost of converting back and forth, or of implementing IEEE floating
> point completely in software.
In that case I see no reason why we can't just consider double/reals as
being the same as:
packed struct {
bit sign,
[10:0] exponent,
[51:0] mantisa;
}
when used in packed structs, and shortreals as
packed struct {
bit sign,
[7:0] exponent,
[22:0] mantisa;
}
[ http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html ]
> At any rate, it is reasonable to assume that any platform running Verilog
> will use IEEE floating point. Differences will involve word ordering,
> and possibly byte ordering. The cost of storing them in a predefined
> order on all platforms is not extreme. I just don't see any need to do so.
It allows you to prefix any struct with "packed" and get a well defined
behavior rather than a compiler error, and lets you describe busses with
floating point fields (useful in a debugger if nothing else).
Kev.
>
> Steven Sharp
> sharp@cadence.com
This archive was generated by hypermail 2b28 : Thu Jan 30 2003 - 10:25:23 PST