Subject: Re: [sv-ec] Re: [sv-bc] Packed arrays
From: Michael McNamara (mac@verisity.com)
Date: Wed Jan 29 2003 - 12:45:05 PST
Kevin Cameron x3251 writes:
> > 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.
I submit, that other than for AMS, the real datatype, and the need to
pass reals through ports was entirely a test bench feature, not
intended for synthesis or for accurate modeling of analog interfaces.
Supporting this is the fact one does not get to choose the width of
the mantissa, the exponents, or the rounding modes.
Those of us actually design floating point hardware (I was indeed one
of these people) instead fully specified our wallace trees and
fp_inexact bits setting logic and the like 100% in bits and vectors.
So for the test bench purpose (likely test bench code that might track
cache hit ratios, or adherence to guaranteed quality of service
metrics, and the like), reals work just fine, and $r.t.b and $b.t.r
are just fine for stuffing these things through the ports of test
bench code.
Making a change the requires these folks instead use the AMS required
wreals for this purpose seems to be huge overkill.
Taking away $rtb and $btr, and hence forcing folks to go into existing
test benches and re-code them seems to be a huge waste of time with no
benefit.
Going further and making simulator vendors insert extra code to
shuffle the bits to get a mandated intermediate representation would
make the simulators go slower (as currently is the case as one must do
this to support the what I always assumed was the VAX represenation of
byte strings used for memories that Verilog-XL made visible to end
users in the tf_nodeinfo() call in the pli), with no benefit to
anyone.
> 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 - 12:45:51 PST