Subject: Re: [sv-ec] Re: [sv-bc] Packed arrays
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Jan 29 2003 - 13:48:35 PST
> From: "Michael McNamara" <mac@verisity.com>
>
...
>
> 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.
A lot of the extensions in AMS are useful for behavioral modelling
in a purely digital environment. None of your chips got PLLs?
>
> 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.
I meant "deprecate" as in "you are advised not to use this", taking
anything out of the language is always painful. I'll be doing the
same for "wreal" when we combine SV and AMS.
>
> 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.
You would only have to do that with packed structs/unions, and the
overhead difference is likely to be marginal.
Using $rtb/$btr is definitely slower regardless of bit order than
using wreal or a shared variable.
> > 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.
No takers :-(
> > Kev.
Kev.
This archive was generated by hypermail 2b28 : Wed Jan 29 2003 - 13:49:37 PST