Subject: Re: [boost] Fixed point implicity
From: Ravi (lists_ravi_at_[hidden])
Date: 2009-07-02 10:18:43
On Thursday 02 July 2009 09:58:52 joel wrote:
> Ravi wrote:
> > After algorithm development, during fixed point conversion (for
> > implementation on a chip), I find that the following suffices:
> > A = s[2,-3] 7 bits
> > B = s[4,-2] 8 bits
> > C = s[4,-3] 9 bits
> > R = u[7,2] with saturation and truncation 6 bits
> > where s[a,b] is a signed type holding bits for 2^a, 2^(a-1),...,2^b and
> > u[a,b] is the corresponding unsigned type.
> Let me ask a layman question then : are those ranges complex to evaluate?
Yes, if you are asking about how I go from type 'double' to 's[2,-3]'. In
fact, it is probably a black art! Considerable time is spent optimizing the
bit-widths of data paths in a custom ASIC since every extra bit in a
multiplier roughly doubles both the silicon area and the power required.
Usually, you find that truncating one bit at some point in the signal
processing chain seems to have no effect until you reach a point much later in
the chain where it kills you and then you must check whether you really need
to carry that extra bit or whether you can compensate for it by allowing extra
bits in some intermediate computation.
> If not, maybe can we do it at compile-time so we knwo we always
> geenrate the proper sufficent bit enabled representation.
It'd be worthwhile just to get the sort of type promotion Phil mentioned
incorporated into a fixed-point library.
However, if you are looking for a research topic, computing the bits required,
for example, for a simple single-carrier QAM demodulator given the number of
input bits (usually fixed by choice of ADCs), is probably achievable for
someone with knowledge of theoretical computer science since the metric to be
optimized (bit error rate at some signal-to-noise ratio) is well known and
that one could come up with a (computationally infeasible) brute force
approach pretty quickly. Further discussion about this is probably off-topic
for this list, but I am happy to discuss this offline.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk