Post Go back to editing

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

Category: Software
Product Number: ADRV9009
Software Version: linux master branch


Looking at the fmcomms8 device tree using direct clocking ( you can see the following comment at the top of the file:

#define REFCLK_DIV	4 /* 983.04 MHz via clkin1 / 4 = 245.76 MHz */
#define DEV_DIG_DELAY	5 /* used to be 15 -> now 5 */

When comparing these to the reference clock device tree values that they are overriding (adi,divider value of 12, adi,coarse-digital-delay of 15), I'm assuming that these new values were specifically chosen to support the 983.04 MHz case indicated in the comments. What I don't fully appreciate is the relationship between the divider and coarse digital delay values in this direct clocking configuration.

We configured a system to achieve 491.52 MHz direct clocking configuration by overriding the adi,divider value to 2 in our own system-user.dtsi file but we did NOT modify the adi,coarse-digital-delay value. Could this have fundamentally misconfigured the hmc7044 part in some way or caused unexpected performance? Should we have also modified adi,coarse-digital-delay? We are attempting to compare system performance differences that we have observed between the 983.04 MHz and 491.52 MHz cases and are trying to eliminate variables.



  • 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, 

    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.



  • 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!