[hpsdr] A sin & cos sample calculation algorithm

[Graham / KE9H]

Hi David:

As I understand it from Kirk's school, one advantage of the CORDIC is
that there are NO multiplies, just shifts and adds, so very easy for 
logic or
for simple microprocessors.  It takes 32 iterations or 32 system clock 
cycles to
reach the level of accuracy currently delivered in Mercury, which is around
1 part in 2^22, or about 2*10^-7, so less than a part per million error.

Since the FPGA has to deliver one set of I and Q results every clock cycle,
the CORDIC in Mercury is a pipeline structure, 32 layers deep, so that
every clock cycle, it calculates an incremental iteration for each of 
the next
coming 31 cycles, as well as pops out the final result for this cycle.

A very busy algorithm. The clock is 122.88 MHz.

The algorithm you refer to may be suitable for processors with a fast
co-processor multiplier, but not for straight logic or bare microprocessor,
and even then, you might not beat the CORDIC's speed.  And you would
need a LOT of hardware multipliers, if they took more than one cycle
to do a multiply.

--- Graham / KE9H

==


David McQuate wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> An iterative algorithm that calculates sin & cos samples,
> requiring only two adds, and two multiplies per sample,
> is as follows.
> Use four variables, A, B, C, and D.
> Initialize A, B, and C to 1 (or whatever peak value you want)
> Given a number of samples per cycle, N, calculate two multipliers,
> M1 = - (2 pi / N)^2
> M2 = N / (2 pi)
>
> (note M1 is always negative, generally between zero and -1/2)
> For each sample, calculate new values:
> A' = M1 * C
> B' = B + A'
> C' = C + B'
> D = M2 * C'
>
> B' is the cos wave
> D is the sin wave
>
> B integrates the calculated A' values.
> C integtrates the calculated B' values.
> It seems to be numerically solving the second-order differential equation
> d2/dx2( f(x) ) = -f(x)
> which has solutions like sin(x) and cos(x).  This explains the value 
> of M1.
>
> I wonder how this algorithm compares to CORDIC ?
> How would it do when used for digital down-conversion?
> (For instance, if it were used in Mercury's FPGA...)
>
> I've looked at it using Excel.  The calculated values are not 
> perfect.  The sum of the squares
> of sin & cos varies from 0.9969 to 1.003
> This seems to indicate that the calculations require a large number of 
> bits.
>
> (ref:  EDN magazine january 7, 2010, p50, a "design idea" by Daniele 
> Danieli, of Venice, Italy)
>
> 73,
> Dave
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: 
> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>


 1263957288.0