Hello

Hi all,

New to this list.
I'm Gerard, Ham Radio operator F6EEQ.

I have a Papilio Pro(Xilinx Spartan 6 LX)development platform since 5 or 6 years.

But did not di much with it.

Read an article in G-QRP club magazine "SPRAT" about DDS with FPGA and this renewed my interest.

Hope to find much help and info here.

See you soon.

Gerard 

On Sunday, March 24, 2019 at 9:00:36 AM UTC-4, F6...@wanadoo.fr wrote:
> Hi all,
> 
> New to this list.
> I'm Gerard, Ham Radio operator F6EEQ.
> 
> I have a Papilio Pro(Xilinx Spartan 6 LX)development platform since 5 or 6 years.
> 
> But did not di much with it.
> 
> Read an article in G-QRP club magazine "SPRAT" about DDS with FPGA and this renewed my interest.
> 
> Hope to find much help and info here.
> 
> See you soon.

I know that for radio work, spurs are very important.  In particular, spurs close to the carrier frequency are important to keep low since it is hard to filter them out.  The biggest cause of spurs close to the carrier in a DDS is truncation of the phase word.  The simple way to avoid phase truncation is to not truncate the phase word.  lol  But often this does not provide adequate frequency resolution. 

In case you are not familiar with the structure of a DDS, let me review.  There is a clock driving an incrementer which adds the phase step on each clock cycle.  The output of this is the phase word.  The incrementer has a modulus at which point the count wraps around.  Often binary, it can be any value and the counter can be any bit width.  The resolution of the phase step determines the frequency resolution of the DDS.  

Not all of the phase word bits are fed to the next section, the sine generator.  This is often a simple look up table (LUT), but to get good resolution and low spurs more complicated methods are needed.  A pair of smaller LUTs appriately combined allow a wider phase word input to minimize phase truncation spurs.  They are combined to approximate the equation

sin(A + B) = sin A cos B + cos A sin B  

cos(A + B) = cos A cos B − sin A sin B

If A and B are the upper and lower bits respectively in a phase word, sin(B) will always be small and cos(B) will always be close to 1.  Both will be relatively linear.  In both equations the cos(B) term can be replaced with 1. 

sin(A + B) = sin A + cos A sin B  

cos(A + B) = cos A − sin A sin B

Using a lookup table for sin/cos of A and another, smaller table for sin(B) (since not all phase bits are needed) the sine and cosine of the full phase word A+B can be calculated with a pair of multiplications and adds.  The same LUT can be used for sin(A) and cos(A) by using two address ports and two output ports which are common on block rams in FPGAs. 

There is a way to not use the smaller LUT for sin(B) by taking advantage of sin(B) being very linear, but I don't recall the details at the moment. 

This more complex sine generator is used to utilize as much of the phase word as possible to minimize the close in spurs caused by phase word truncation.  The remaining spurs caused by the other sources including the DAC, can be minimized by cleaning up the output signal with a PLL if practical and required. 

Other methods of generating the sine wave use various numbers of terms from approximations like the Taylor series.  Then there is the CORDIC algorithm which is about the complexity of a multiplication, but can't be done using the on chip multipliers. 

I hope this helps. 

If you want to get fancy, here is a paper on a combined CORDIC and Taylor series method that seems to be smaller than the CORDIC alone. 

https://hal.archives-ouvertes.fr/hal-00516790/document

Rick C.

Hi Rick,

Thanks for info.
I already have some DDS knowledge from tests with µC and AD9850, but you gave some interesting hints.
Will consider them, when I'll be a little more advanced in my designing the FPGA DDS.

Cheers and have a nice week.
Gerard.

On Monday, March 25, 2019 at 3:33:11 AM UTC-4, F6...@wanadoo.fr wrote:
> Hi Rick,
> 
> Thanks for info.
> I already have some DDS knowledge from tests with µC and AD9850, but you gave some interesting hints.
> Will consider them, when I'll be a little more advanced in my designing the FPGA DDS.
> 
> Cheers and have a nice week.
> Gerard.

Please return to report your results or to discuss issues. 

Rick C.