Relationship between HMC7044 divider and coarse-digital-delay values when using direct clocking

Hi Mike,

During my resynchronization tests, I experienced some occasionally phase ambiguity between devices in this configuration.

So I started to delay the reference clocks a bit. I think every odd number should be fine, since the coarse digital delay delays 1/2 clock input cycle.

What kind of performance are you evaluating? In general clock distribution has some phase noise performance tradeoffs.

And the distribution clock frequency can also make a difference. 

-Michael

Michael, 

Thanks for the clarification on the motivation being some phase ambiguity between devices.

Regarding the phenomenon that we're observing, we previously had a number of devices that we configured with the 491.52 MHz direct clocking configuration and collected data across a sweep of frequency and gain states. We ran with this in the field for several months until this past winter when we started experiencing some cold weather phase sync issues (which we know is currently being investigated by some other folks in your organization). At that time (early Feb 2022) based on recommendations from ADI, we updated from using a build out of the 2019_R2 branch to the latest master and migrated to using the 983.04 MHz direct clocking configuration, which seemed to offer a bit more resiliency to the cold weather phase sync problem.

The curious thing that we've started noticing in our data over the past couple months since shifting to using the 983.04 MHz direct clocking configuration is that we are consistently observing an average group delay of ~1.7us between the SOM and DB channels on multiple systems when compared to the data from the 491.52 MHz configuration on that SAME system.

We have been using the same SDR profile operating at Rx output sample rate of 163.84 MHz across both configurations, and while I realize shifting from 2019_R2 to master represents a nontrivial evolution in capability, the "only" modification we made to the device tree was removing our adi,divider override that forced the 491.52 MHz direct clocking configuration from the default 983.04 MHz. Asking this question was a bit of a shot in the dark to see if not changing the adi,coarse-digital-delay when we moved to 491.52 MHz could have put the clocks in a state that could explain this group delay.

Thanks,

Mike

As a follow up to my previous post, I wanted to mention that our characterization of the 1.7 us group delay was incorrect, and it was actually closer to 4.6 ns, which was fully in the realm of the coarse digital delay. Further, we were able to iterate over some coarse digital delay values in the device tree and observed this group delay changing, and also observed that (as you mentioned) it was a function of the distribution clock frequency. We have a much better handle on this phenomenon now, and thanks for your input!

As a follow up to my previous post, I wanted to mention that our characterization of the 1.7 us group delay was incorrect, and it was actually closer to 4.6 ns, which was fully in the realm of the coarse digital delay. Further, we were able to iterate over some coarse digital delay values in the device tree and observed this group delay changing, and also observed that (as you mentioned) it was a function of the distribution clock frequency. We have a much better handle on this phenomenon now, and thanks for your input!