Re: [sv-ec] Re: [sv-bc] Packed arrays


Subject: Re: [sv-ec] Re: [sv-bc] Packed arrays
From: Michael McNamara (mac@verisity.com)
Date: Wed Jan 29 2003 - 09:48:13 PST


Kevin Cameron writes:
>
>
> > From: Steven Sharp <sharp@cadence.com>
> >
> > >Since the bit conversion of reals is defined (for $realtobits) I don't
> > >see any reason why it can't be used in a packed array or union.
> >
> > The bit conversion is not defined and may differ between CPU architectures
> > because of endianness differences. This is not a problem with existing
> > usage as long as $realtobits is only used in combination with $bitstoreal,
> > and nobody relies on the representation when in bit form.
> >
> > Steven Sharp
> > sharp@cadence.com
>
> Sorry, I thought it was IEEE standard format.
>
> In that case shouldn't $realtobits and $bitstoreal be deprecated, I presume
> they're only there to work around not having real type ports - which isn't
> an issue anymore?
>
> Kev.

There is nothing _wrong_ with $realtobits and $bitstoreal; hence no
clear reason to deprecate. Basically the implementer is granted the
freedom to perform a loss less conversion system anyway they choose,
with the further boon that the end user is not supposed to look at the
intermediate form. Hence on a x86 architecture, the intermediate bit
pattern will likely be different that what one would see on a sparc;
and if anyone still has a Vax, the intermediate bit pattern would
likely be different than the x86 or sparc.

It would have been far worse for us to have specified the format of the
intermediate, and then force the x86 implementation to mimic big
endian floating point representation, at which no one would _ever_
look.

You are correct that these system tasks were created as a way to work
around the restriction against passing reals through ports; but again,
there is no bad style encoraged, or significant slowdown imposed by
the existance of these system tasks, (as is the case with defparams,
for example), so I vote for just leaving them alone.

-mac



This archive was generated by hypermail 2b28 : Wed Jan 29 2003 - 09:48:52 PST