How to calculate the 32bit tuning value for the AD9850 DDS chip.

This Wiki article shows two possible ways to calculate the 32bit tuning value for the AD9850 DDS syntesizer chip using PBP. Modules using the AD9850, including a 125MHz oscillator and required support components can be aquired cheaply on EBAY - I bought two for $9USD including shipping.

In the datasheet for the AD9850 they give us the formula to calculate the output frequency for any given tuning value:
fOut = Tuning Value * RefClk / 2^32

If we know the desired output frequency and want to calculate the tuning value we need to rearange the formula:
Tuning Value = fOut * 2^32 / RefClk

Since the values 2^32 and RefClk (125Mhz) are both known that part of the equation can be precalculated, ie 2^32/125000000=34.359738368:
Tuning Value = fOut * 34.359738368

So, what's the problem?
Well, the obvious problem is that because 2^32/125000000 doesn't result in an integer number we can't simply use the formula as it is. Rounding it down to 34 would give as an error in output frequency of more than 1% which probably isn't acceptable. Besides, how do we store the frequency and tuning value when they are such big numbers?

Before we start looking at how to write the PBP code for this lets do the calculation on paper for a random target frequency of 12.5Mhz:
Tuning Value = 12500000 * 2^32 / 125000000 = 429496729.6 or in our short form 12500000 * 34.359738368 = 429496729.6 same results - great. Obviously we're not going to be able to get that .6 into the AD9850 so lets round that up and call the "ideal" tuning word for 12.5MHz 429496730.

---

The easiest way to tackle this is most likely to use an 18F series PIC and switch on the support for LONGS (32bit variables) in the compiler. This allows us to simply declare a variable called Frequency and assign a nice big number like 125000000 (12.5MHz) to it. But how do we handle that non integer multiplication?

One solution for this application is the ** operator which is great for multiplying with a non integer value. It performs the multiplication of the two values that we give it (which when used on LONGS is stored internally as a 48bit result) and then it discards the two lowest signficant bytes, returning bytes 2 to 5 of the internal 48bit result. This gives the same result as multiplying the two values and then divide the result by 65536. Alternatively we can see it as multiplying our value by units of 1/65536.

OK, so we need to come with a value to use with the ** operator which is as close to a multiplication by 34.359738368 as possible. The easiest way is to simply multiply our "target value" by 65536: 34.359738368 * 65536 = 2251799,813685248. Again we're going to have to have to round that to the nearest integer value and settle for 2251800. If this doesn't make sense then think of it as multiplying by 2251800 "units" where one "unit" is 1/65536: 1/65536 * 2251800 = 34.3597412109375
Tuning Value = Frequency ** 2251800

Worth mentioning here is that we must have the support for LONGS switched on within the compiler in order to use such big numbers with the ** operator. Without support for LONGS switched on the maximum value for the ** operator would be 65535.

Now lets see how this works out on paper. First the value 12500000 gets multiplied by 2251800 and then the two lowest siginificant bytes are discarded. Which, again, is effectively the same as dividing the result by 65536. So what do we get?
12500000 * 2251800 / 65536 = 429496765 which is an error of only 35 LSBs or +0.00000815% compared to our ideal value. That's around 1Hz off target at 12.5Mhz - not bad.

So, all it takes really is the following:It takes a while for the poor little PIC to calculate this though, between 6000 and 14000 cycles depending the frequency value. These are the calculate tuning values for the frequencies shown together with the measured execution time:

Tuning Value for frequency: 50000000Hz: 1717987060.......13862 cycles.
Tuning Value for frequency: 25000000Hz: 858993530.......10160 cycles.
Tuning Value for frequency: 10000000Hz: 343597412.......10156 cycles.
Tuning Value for frequency: 1000000Hz: 34359741.......8516 cycles.
Tuning Value for frequency: 100000Hz: 3435974.......7816 cycles.
Tuning Value for frequency: 10000Hz: 343597.......6988 cycles.
Tuning Value for frequency: 1000Hz: 34359.......6152 cycles.

Let's double check the 10kHz as well. Calculated tuning value: 343597, ideal tuning value = 10000 * 2^32 / 125000000 = 343597.

---

OK, that turned out to be quite easy but what if we can't use an 18F chip or cant use LONGS for whatever reason? Then it gets a bit more complicated.
First of all we have no easy way to store our target frequency because the largest number we can store in a single variable is 65535. What I've opted to do is to use two WORD sized variables called kHz and Hz. So if we want to set the frequeuncy to 12.5MHz all we need to do is kHz=12500, Hz=0 (12500kHz = 12.5MHz). Not as straight forward as with LONGS but still pretty managable. But what about the calculations?

Fortunately PBP wizard Darrel Taylor found a set of assembly math routines that he tweaked into a format which allows them to, quite easily, be used inside a PBP program. These are called N-Bit_Math and allows us to declare variables of basically any size and perform math operations on the values assigned to them. With the help of these routines I've managed to get the calculated tuning value to within +/-1LSB of the "ideal" value. The obvious drawbacks are that it takes longer to execute, uses more RAM and occupies more space in FLASH.

The first thing we need to do is to specify the number of bytes in our working variables and include the math routines in our program. Then we declare the variables that we're going to need for doing the calculations:(The file N-bit_Math.pbp should be located in you PBP folder or in the same folder as the current source file.)

Now we can start working on the actual calculations. The first thing to do is to create a single "large" variable out of our kHz and Hz variables:At this point MathVar1 contains our desired frequency in Hz. Now we need to multiply it by 34.359738368. The math routines are great but they doesn't allow non integer numbers. What I came up with though is that 2199 is pretty close to 64*34.359738368 so lets multiply by that first and then divide the result by 64 at the end. Before dividing it down though we add 32 to the result to round it off to the nearest integer:At this point the error on the calculated value is still around 0.0011% "short" of the ideal value and that error comes from the fact that 2199/64 isn't exactly equal to 2^32/125000000. But if we add in a portion of our original frequency value to compensate for that we'll get quite close:The final result of the calculations are now available in the BYTE array MathVar1 with the least significant byte in MathVar1[0]. If we want we can create an alias to that variable, likeNow we can access the result thru the TuningValue[0]...[3]

The above subroutine will calculate the tuning word to within 1LSB of the "ideal" value, here are some example numbers:
As have been said it comes at price though. It takes between 25000 and 27000 cycles to execute and the math routines adds a bit to the footprint but it might be worth it.

---

OK, but how do we get the value from the PIC into the AD9850. Well, the AD9850 can be "loaded" in two ways, parallel using a 8bit bus or serial using a clock, a single data line and a strobe line. Using the serial interface fits PBP's SHIFTOUT command just perfectly so that's what I used when testing the routines.

The AD9850 requires 40 bits to shifted in, first the 32 bit frequency tuning value which we've just calculated then a control word (or Byte rather) consisting of 8 bits which are (kind of vaguely) described in the datasheet.

One note though: When the AD9850 powers up it defaults to parallel mode. In order to change it serial you have to send a "serial load enable sequence" which is described in the datasheet. An alternative aproach is to tie pin 2 to GND and pins 3 & 4 to Vcc. This forces the AD9850 into serial load mode when it powers up. (Please note that pin numbers are the pins on the actual chip, if you've bought a finished module you need to "translate" that into the proper pin number on your specific module.)

If using PBPL and LONGS to calculate the tuning value we can send it to the AD9850 with something like:If we're using to more complicated method to calculate the tuning value we need to change the output slightly because the tuning value is now stored in an array of bytes instead of in a single 32bit variable (which of course is an array of bytes in itself but anyway....):Attached to this post is a .zip file containing the code shown above. Please note that the code is setup to run on my target device and you will likely need to change, add, remove stuff so it matches your specific device and setup.

Finally, here's a scope-shot of the AD9850 generating a 10MHz signal:


/Henrik.

EDIT: Here's a forum thread for questions and discussions around the article.