[vhdl-200x-ft] RE: [vhdlsynth] Bit Rules & methodology for handling math issues

> "|+" would solve one specific issue:
> Modulo arithmetic vs Maintain precsion of result

I can see the sense in this, but what are the use cases?
UNSIGNED is very commonly used to represent hardware
idioms such as counters, for which modulo arithmetic
is the obvious default. Consequently the present
behaviour of numeric_std makes good sense.

Contrariwise, fixed-point arithmetic is likely used
in DSP applications where rounding and truncation should
be specified explicitly somehow. It's clear to me that
the correct default behaviour for fixed-point types should
be lossless. Modulo arithmetic is easily handled, clearly
and explicitly, by a RESIZE operation.

If we were to have lossless arithmetic operations for
fixed point types, and therefore bit-growth for addition,
you can eat your cake and have it: use UNSIGNED/SIGNED for
modulo arithmetic, and use fixed-point with no fractional
part if you want lossless "bit-growth" arithmetic.

Creating new operators leads us down a slippery slope. If
we add operators to control bit growth, then why not even
more operators to control rounding? Then how do we handle
the "cross products" of all the various behaviours that are
controlled by these new operators?

-- 
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com
This e-mail and any  attachments are  confidential and Doulos Ltd. reserves 
all rights of privilege in  respect thereof. It is intended for the use of 
the addressee only. If you are not the intended recipient please delete it 
from  your  system, any  use, disclosure, or copying  of this  document is 
unauthorised. The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.