ADRV9009 SOM to fmcomms8 DB Relative Phase


I am looking for advice on something we have been observing on a lab bench over the past few days.

Test Procedure

The test setup is an ADRV9009 ZU11EG SOM with fmcomms8 and carrier card (4xADRV9009, 8 channels, 2 chips per board). A constant tone at 5795 MHz from a signal generator is passed through an 8-way splitter, then received on all channels. Multiple data captures are repeated every 5 seconds, and relative phase with respect to a reference channel is measured on each. The relative phase of each channel is plotted with the mean of each channel removed, to emphasize any differences from steady state behavior.

Question #1 – Slowly Varying Board to Board Relative Phase

After starting the system, letting the JESD-FSM sync, and making measurements for several minutes, relative phase plots board_to_board_phase<1-3>.png were formed. From power-on, there exists a board-to-board phase delta that seems to slowly vary on the order of several minutes. In this case the normalizing channel was a DB channel, so the DB appears constant, and the SOM channels change relative to it. Had a SOM channel been chosen as a reference, the opposite would occur.

Is this expected? Are there configuration items that can adjusted to reduce this board-to-board drift?

In terms of root cause, would you suspect clock drift between the HMC7044s on the SOM vs. daughtercard, the temperature loop depicted in UG1295 pg 114 Figure 64, or something else?  

The absolute value of each channel-to-channel phase measurement is not important to us; in this setup the cables are not phase matched, and the splitter delays are not compensated for. What we are interested in is minimizing the time varying behavior, as it translates to an error in downstream signal processing.

Question #2 – Rapidly Varying Board to Board Relative Phase

Taking this one step further, once the system has warmed up, a bench fan was applied to the daughterboard for a few minutes, then removed. A large, rapid jump in board-to-board phase can be observed in the board_to_board_phase_with_fan1.png plot.

Is this expected? This is a dramatic change in phase… is this oscillator instability of the local VCXO external references used by the HMC7044s on the SOM and DB? Temperature vs. time, as in UG1295 Table 46 and Figure 74? Something else?

Appreciate the help. Just trying to understand things a bit more thoroughly as we work through our design, making sure we understand which effects need to be compensated for, and what kind of cooling strategies to avoid with these chipsets.



  • A note on the temperature "ABCD" labels; the legends may be swapped around where chip A temp is not necessarily chip A, etc. I'll try and get some updated data up in a day or two, but the phase plot data and legends are all good, and temperature trends are all similar, so the overall question still stands.

  • The temperature gradients and cooling system from the last setup is a little unusual with chips occupying 3 different distinct temperature regions. 

    Here's some recent data from another test setup where all the temperature labels are fixed, and the temp curves separate into two SOM and DB groups nicely. 

    The system seems to phase track for awhile, as in the first two plots. But then revisiting the same system a few hours later, re-loading a profile -- phase tracking on one board seems to have settled 20 degrees off from the other board, compared to a collect earlier in the same day. 

    Intentional temp change was then introduced (heat gun), and everything shifts. This rate of temp change is fairly rapid compared to most real world scenarios.

    Leaving that aside, mainly trying to determine if all of this is temperature related, and the answer is to store temperature curves and compensate for the board to board shift. Or -- is there a random component; oscillator stability, re-initializing of JESD-FSM, or something else... 

    Have not answered this definitively yet. 

  • 0
    •  Analog Employees 
    on May 17, 2021 4:16 PM in reply to ahelak

    Hi Adam,

    Our Systems engineering team have been looking into this and will provide some feedback this week that will hopefully help. Sorry about the delay in replying.



  • Hi Brian, 

    Appreciate the update. In the meantime as an experiment we took a test setup and replaced all of the local VCXOs on the HMC7044 OSCIN ports, changing from the Crystek series to an SiTimes alternative. The alternative had a little higher phase noise, but better stability over temperature, airflow, etc. 

    Had to print a small interposer board, and even then had a difficult time getting PLL1 and PLL2 to lock in the JESD-FSM builds. We probably would need to dig more into the HMC7044 setup callbacks if we were going to keep this change, but everything locked in the older builds (circa August 2020). 

    Once things were locked, made a few measurements, but I wouldn't say we changed the behavior all that much with this modification. 

    Definitely interested in getting your thoughts, so looking forward to the feedback. If it makes more sense, we can set up a call with our local FAE as well to provide additional details. 


  • 0
    •  Analog Employees 
    on May 18, 2021 1:58 PM in reply to brianol

    Hi Adam,

     - Do you provide an external reference to the carrier HMC7044 or is it using the onboard TCXO?

     - Are there any digital/analog delays enabled on the clock outputs?

    - are all the phase measurements done with a 5795MHz tone? (10 deg on the plots ~ 5ps)