Subject: Re: [sv-ec] Re: [sv-bc] Packed arrays
From: Steven Sharp (sharp@cadence.com)
Date: Wed Jan 29 2003 - 18:15:24 PST
>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.
>> 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.
>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.
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.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Wed Jan 29 2003 - 18:16:11 PST