Synchronizing two AD9952's

I have a problem synchronizing two AD9952 DDS chips. Both run from the same clock source (40MHz) and have the PLL multiplier at

10x. Both have the ClrAccumulator bit set, so when both DDS's are loaded with new frequency data (the same), a trigger on the IO_UPDATE signal (both connected together on a mpu IO pin), they are supposed to update the internal registers and at the same time clear the phase accumulator. Still, I have a phase difference between both DDS outputs which is, funny enough, 2 clock cycles (5ns), either leading or lagging or, coincidentally 0. I have done the same trick before with two AD9854, which didn't even have a ClrAccumulator feature, but resetting them once at the same time did the trick.

These AD9952's even have a master/slave mode which is supposed to keep them synchronised, but this doesn't work either. The PCB is laid out as 4 layer, power and ground in the middle, separate digital and analog supplies. All by the book, as as far as I know.

Funny thing is, and it might be a hint like a sledgehammer to others, is that when the slave DDS has it's sync output enabled, the phase difference is changing continuously while when this output is disable, it is contstant. So the whole problem might still be caused by some unwanted crosstalk on some signal trace.

Suggestions anyone?

Meindert

snip

Don't know anything about ad9952s but.. Could it it be a setup/hold violation on IO_UPDATE so the the two chips don't recognize the edge at the same clock cycle?

-Lasse

snip

Don't know anything about ad9952s but.. Could it it be a setup/hold violation on IO_UPDATE so the the two chips don't recognize the edge at the same clock cycle?

-Lasse

As far as I can see on my Tek TDS220, the risetime is around 5 to 6 ns. The trace length from the micro to both DDS chips differs around 40 mm/ 1.5" and that might gove just enough delay to spoil the fun. But in that case, one DDS should always be lagging. And in my case it is both lagging and leading in phase, and sometimes spot on. But that is probably also caused by unequal jitter in both PLL's. But what disturbs me is that I haven't seen this before in an AD9854 design at 300MHz. And this one definately shows the problem from 200 to 400 MHz. I can only get it stable at 160MHz.

Meindert

don't

Might be. And the PLL jitter could also cause it.

Meindert

Technically this violates the spec sheet, which has numbers like 2 or 3 ns.

I think these numbers are obscenely short for what is basically a serial bus. They don't seem to matter too much for non-sync usage... but that leaves me with the conclusion that they do matter for synchronizing multiple DDS's.

Think about it: 5ns is two ticks of the 400 MHz clocks.

Usually all the specs you need are in an AD datasheet, but knowing what spec is relevant for what purpose is hairy.

Tim.

I think you are misinterpreting the setup time of the serial bus signals. I think 3 ns Data setup time means that you have to setup the Data input at least 3ns before applying a clock.

Besides, the serial bus has nothing to do with the synchonisation mechanism. The IO_UPDATE signal clocks the data from the communication registers to the internal DDS registers. And this is what I'm having problems with.

I know. And since one DDS leads *or* lags the other at random, by what appears to be exactly 2 clock cycles makes me think that it's not a problem with the unequal length of the IO_UPDATE trace (only 150ps delay), but more with the PLL jitter. Tomorrow I'm going to try a 100MHz oscillator instead of 40MHz. I found that with a multiplier of 4 the system is stable. So let's see if it is still stable at 100MHz clock with this multiplier.

Meindert

I'm not sure a TDS220 can do 2nS. It's a 100MHz scope.

RL

Correct. So when I see a risetime of 5ns om my screen, I know that it's either 5ns or better :-)

Meindert