-- Jim Lewis wrote --
> >> PROPOSAL 5 Sizing of Fixed Point Arithmetic
> --- snip ---
>
> "|+" would solve one specific issue:
> Modulo arithmetic vs Maintain precsion of result
>
>
> I think we have a large number of potential items that
> need to be incorporated into future arithmetic.
> Some of the ones I see are (and this is not a comprehensive
> list):
>
> 1) Error when out of range (like integer)
> 2) Modulo arithmetic (like unsigned/signed)
> 3) Maintain precision (bit growth, ...)
> 4) Saturating arithmetic
> 5) Fixed Point Rounding Style --- embedded in package
> 6) Floating Point Rounding Style --- Constant in package
> 7) Floating Point IEEE Extend --- Constant in package
> 8) Floating Point Check Error --- Constant in package
> 9) Sizing methodology for Real number mantissa and exponent
The easiest way I know of to handle these issues for fixed point is to
return a full precision result and let the user specify how it should be
handled. This approach has several advantages:
A. Clear, (internally) consistent approach (key to productivity).
B. Readable inline indications of how the result is handled (key to code
review and maintenance).
C. Encouraging good DSP design by forcing the designer to specify what
happens to the bits.
I think the current fixed point package, augmented by my proposals already
addresses all of the applicable issues.
1) Error when out of range is flagged in conversion functions and RESIZE
calls. Results cannot be out of range.
2) Modulo arithmetic will be provided by RESIZE (and numeric_std).
3) Maintaining precision is the default behavior.
4) Saturating arithmetic will be provided by RESIZE.
5) Fixed point rounding is provided by RESIZE.
6-9) N/A
I think the current proposed solution is simple and flexible--it's just
different from numeric_std. I liked Mr. Bromley's suggestion in this
regard. If you want the SFIXED/UFIXED to act exactly like SIGNED/UNSIGNED,
why not just use SIGNED/UNSIGNED?
--- Ryan Hinton L-3 Communications / Communication Systems - West ryan.w.hinton@L-3com.comReceived on Wed Jul 7 10:02:28 2004
This archive was generated by hypermail 2.1.8 : Wed Jul 07 2004 - 10:02:35 PDT