Re: [boost] Fixed point implicity

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.

Regards,
Ravi