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


Subject: Re: [sv-ec] Re: [sv-bc] Packed arrays
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Jan 29 2003 - 10:13:39 PST


> From owner-sv-ec@eda.org Wed Jan 29 09:46:40 2003
> From: "Michael McNamara" <mac@verisity.com>
> To: "Kevin Cameron" <sv-xx@grfx.com>
> cc: sv-ec@eda.org, sharp@cadence.com
> Subject: Re: [sv-ec] Re: [sv-bc] Packed arrays
> Reply-to: mac@verisity.com
>
>
> 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

I consider it bad style since the design intent is not clear. Verilog-AMS
added "wreal" to avoid using bitstoreal/realtobits and make it clear that
there is only one physical wire.

There is a secondary argument about implementing machine specific floating
point types in SV: I think classes should be based on (packed) structs so
that you can get the appropriate bit representation and overload the
operators, and statically declarable so that you can use them the same
way as struct to create wire bundles.

Kev.



This archive was generated by hypermail 2b28 : Wed Jan 29 2003 - 10:14:26 PST