Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30248

Re: Fixed Point Calculations

Show all headers | View raw

On 04/01/2021 03:55, Rick C wrote:
> On Sunday, January 3, 2021 at 9:38:11 AM UTC-5, David Brown wrote:
>> On 03/01/2021 10:45, Rick C wrote:
>> 
>>> I might do the division in a lookup table by multiplying by the 
>>> inverse. The trouble with that is the poor accuracy when the
>>> value is large and the inverse is small. But then that is simply
>>> the natural result of the division, no? Not sure I will actually
>>> have that problem. I need to plan out the calculations better.
>>> 
>> "Multiply by reciprocal" is a very common way of doing division. It
>> is particularly popular if you have several numbers to be divided
>> by the same divisor, or if the divisor is a fixed known value. You
>> need some care to get the scaling right, and to get the LSB's
>> precisely correct, but it is entirely doable.
>> 
>> A lookup table for reciprocals is going to get impractical quite
>> quickly for large ranges. Certainly it would take up a lot more
>> space in an FPGA than putting in a Cortex M1 or RISC-V soft
>> processor and doing the sane thing - implement your maths in
>> software.
> 
> If you would like to participate, please let me know and I will
> connect you with the project lead.  Then you can discuss the use of
> the MCU with him.

No, thank you.  But if you, or anyone else in the project, want to talk
about MCU's (or soft processors, which was what I suggested) here then
I'm happy to join in.

From what I have heard of this project (from your posts here and in
other groups), it sounds like you may have spend an extraordinary amount
of time trying to make things work with an FPGA alone where other
devices would have made the job far easier.  Obviously I am not privy to
the details - I don't know if you have spent months working on things or
merely a few hours spread out over months.  And I don't know the budget
balances between development costs and production costs.  Nor do I know
how much influence you have in the decision processes, nor how fixed the
designs are at this stage.  All I can say is how /I/ would handle
things, or recommend other engineers to handle things, given a similar
situation as well as I can surmise from your posts.

Different technologies have their strengths and weaknesses.  There are
times when an FPGA is clearly better, times when an MCU is clearly
better, times when either will do just as well, and times where one can
be made to work even if it is not ideal for the task.  It is important
for you to know where you stand here.

> 
> Not sure why you think the reciprocal would be so cumbersome.  The
> reality is the values requires are all relatively close to 1.0, so I
> think it may be fairly effective.  This system is not doing general
> arbitrary math, it is doing a well defined set of calculations.  So
> restrictions on range are entirely realistic.
> 

I did not describe reciprocal method as "cumbersome".  You simply need
to be careful with the details to get things accurate - it's very easy
to be a bit off in the lowest bits of the result, and it's very easy to
have bad behaviour in corner cases.  And a lookup table might be fine if
there are only a small number of possible divisors, but if it is needed
for a whole 17-bit range, that's 128K entries of 34 bits each.

A restricted range, as you describe, certainly helps here.  It means you
don't need the whole 128K, and you can have less than 34 bits on each
entry while covering the accuracy you need.  Only you can figure out how
big the table must be, and whether it is affordable or not.

If the alternative is to calculate the reciprocal using an iterative
process - it can be done with each cycle doubling the number of bits,
giving perhaps 5 cycles.

For 17 bit numbers, this is probably not worth the bother.  After all, a
straight-forward long-division in base 2 will give you the answer in 17
cycles.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Fixed Point Calculations Rick C <gnuarm.deletethisbit@gmail.com> - 2021-01-01 02:18 -0800
  Re: Fixed Point Calculations upsidedown@downunder.com - 2021-01-01 13:33 +0200
    Re: Fixed Point Calculations Rick C <gnuarm.deletethisbit@gmail.com> - 2021-01-03 01:45 -0800
      Re: Fixed Point Calculations Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-01-03 12:18 +0200
        Re: Fixed Point Calculations Rick C <gnuarm.deletethisbit@gmail.com> - 2021-01-03 05:33 -0800
      Re: Fixed Point Calculations upsidedown@downunder.com - 2021-01-03 14:48 +0200
      Re: Fixed Point Calculations David Brown <david.brown@hesbynett.no> - 2021-01-03 15:38 +0100
        Re: Fixed Point Calculations Rick C <gnuarm.deletethisbit@gmail.com> - 2021-01-03 18:55 -0800
          Re: Fixed Point Calculations David Brown <david.brown@hesbynett.no> - 2021-01-04 09:26 +0100
            Re: Fixed Point Calculations Rick C <gnuarm.deletethisbit@gmail.com> - 2021-01-17 22:11 -0800
              Re: Fixed Point Calculations David Brown <david.brown@hesbynett.no> - 2021-01-18 08:53 +0100
                Re: Fixed Point Calculations Rick C <gnuarm.deletethisbit@gmail.com> - 2021-01-18 00:42 -0800
                Re: Fixed Point Calculations Anssi Saari <as@sci.fi> - 2021-01-18 22:00 +0200
                Re: Fixed Point Calculations Rick C <gnuarm.deletethisbit@gmail.com> - 2021-01-18 13:46 -0800
                Re: Fixed Point Calculations upsidedown@downunder.com - 2021-01-19 10:44 +0200
                Re: Fixed Point Calculations Rick C <gnuarm.deletethisbit@gmail.com> - 2021-01-19 01:14 -0800
                Re: Fixed Point Calculations Anssi Saari <as@sci.fi> - 2021-01-20 09:50 +0200

csiph-web