Synchronizing two AD9952's

M

Meindert Sprang

Guest
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
 
Suggestions anyone?
Click to expand...
Risetime of the IO_UPDATE signal you're driving? All of the serial
timing rise/falltimes on the datasheet are obscenely small (only a few
nanoseconds) and I doubt that most typical microcontrollers will meet
the specs.

I've played around with PIC's driving AD9953's with good results with
rise/falltimes in the tens of nanoseconds, but I've never tried
synchronizing them, and I've seen funny things happen on the serial bus
that I have not fully understood.

Tim.
 
Meindert Sprang wrote:
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.

snip
Click to expand...

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
 
Meindert Sprang wrote:
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.

snip
Click to expand...

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
 
"Tim Shoppa" <shoppa@trailing-edge.com> wrote in message
news:1121798465.673854.58300@o13g2000cwo.googlegroups.com...
Suggestions anyone?

Risetime of the IO_UPDATE signal you're driving? All of the serial
timing rise/falltimes on the datasheet are obscenely small (only a few
nanoseconds) and I doubt that most typical microcontrollers will meet
the specs.
Click to expand...
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
 
"Lasse Langwadt Christensen" <langwadt@ieee.org> wrote in message
news:42DD53A4.1080302@ieee.org...
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?
Click to expand...
Might be. And the PLL jitter could also cause it.

Meindert
 
Meindert Sprang wrote:
"Tim Shoppa" <shoppa@trailing-edge.com> wrote in message
news:1121798465.673854.58300@o13g2000cwo.googlegroups.com...
Suggestions anyone?

Risetime of the IO_UPDATE signal you're driving? All of the serial
timing rise/falltimes on the datasheet are obscenely small (only a few
nanoseconds) and I doubt that most typical microcontrollers will meet
the specs.

As far as I can see on my Tek TDS220, the risetime is around 5 to 6 ns.
Click to expand...
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.
 
"Tim Shoppa" <shoppa@trailing-edge.com> wrote in message
news:1121855664.697055.320470@g14g2000cwa.googlegroups.com...
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.
Click to expand...
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.

Think about it: 5ns is two ticks of the 400 MHz clocks.
Click to expand...
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
 
On 20 Jul 2005 03:34:24 -0700, "Tim Shoppa" <shoppa@trailing-edge.com>
wrote:

Meindert Sprang wrote:
"Tim Shoppa" <shoppa@trailing-edge.com> wrote in message
news:1121798465.673854.58300@o13g2000cwo.googlegroups.com...
Suggestions anyone?

Risetime of the IO_UPDATE signal you're driving? All of the serial
timing rise/falltimes on the datasheet are obscenely small (only a few
nanoseconds) and I doubt that most typical microcontrollers will meet
the specs.

As far as I can see on my Tek TDS220, the risetime is around 5 to 6 ns.

Technically this violates the spec sheet, which has numbers like 2 or 3
ns.
Click to expand...
I'm not sure a TDS220 can do 2nS. It's a 100MHz scope.

RL
 
"legg" <legg@nospam.magma.ca> wrote in message
news:3artd19c41389gliidc0unl27al622lmrb@4ax.com...
On 20 Jul 2005 03:34:24 -0700, "Tim Shoppa" <shoppa@trailing-edge.com
wrote:

Meindert Sprang wrote:
As far as I can see on my Tek TDS220, the risetime is around 5 to 6 ns.

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


I'm not sure a TDS220 can do 2nS. It's a 100MHz scope.
Click to expand...
Correct. So when I see a risetime of 5ns om my screen, I know that it's
either 5ns or better :)

Meindert
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top