"Tricky" <> wrote in message
news:1c48615c-5d8a-4c85-8f26-...
On 10 Sep, 09:59, Tricky <trickyh...@gmail.com> wrote:
> > Quick question for everyone: is there an easy way to work out how many
> > bits are require to store the sum of N numbers at M bits per number.
> >
> > In my case, I need to store the sum of 2^20 (1mill) 18bit numbers.
> >
> > Theres probably another 2^n number in there, but I cant figure it out.
> >
> > Thanks for the help.
>
> Lol - Im so stupid..please ignore my ramblings
>
> 38
Hi Tricky, that's not as dumb a question as it seems.
Sure, 38 bits will work, but unless every number is expected to possibly be
full scale all at once, it's gross overkill. If your numbers are signed,
they may average to zero. If you know the expected mean (over at least some
reasonable number of cases) and the expected variance, you can design things
to use far fewer bits. For instance, if these are A/D input samples, you may
wish to make them nominally zero mean by subtracting 2^17 first (with a
little analysis of representation it can take trivial gates; the synthesizer
will likely figure this out). Then, based on the expected variance (standard
deviation), you can multiply that by sqrt(N) to get a measure of how the
variance grows; take that number and multiply by 4 or so (2 bits) and you
now have a representation that has something like a one in a billion chance
of saturating.
Say this is A/D input of a fairly random signal. You likely set the gain to
keep most of the samples from saturating the A/D, so the standard deviation
may be at most 1/8th of full scale, or about 2^14. Summing 2^20 of these
increases the variance by 2^10, so you are at 2^24. So, you should be able
to easily make it with something like 26 or 27 bits. Making it 32 bits for
compatibility for readout on some bus will give you oodles of margin; it's
still less resources (and a faster Fmax given the shorter carry chain) than
a 38 bit accumulator.
Just something to think about...
-Marty
|
Similar Threads
