AD9176 inconsistent PLL lock and output


I have a design using the AD9176-FMC-EBZ tied to an Opal Kelly eval board (so nothing custom).

My design used to work consistently when I had it setup for:
PLL ref clock = "other frequency"
PLL manual ref clock = 300MHz
link mode = dual
JESD mode = 9
channel interp = 1
datapath interp = 8
subclass = 1
input data rate = 1.2GHz
derived DAC clock rate = 9.6GHz

This seemed to be consistently good for my test design and I had no issues.

I then changed things slightly to increase my DAC clock rate:
PLL ref clock = "other frequency"
PLL manual ref clock = 250MHz
link mode = dual
JESD mode = 9
channel interp = 1
datapath interp = 12
subclass = 1
input data rate = 1GHz
derived DAC clock rate = 12GHz

And here is where my issues arise.  I used ACE to generate my register configs like I did for the previous setup.  I then incorporated them into my micoBlaze processor.  When things work, they work perfectly, but I don't see consistent results, I get a lot of unlocked PLL reads.  Once I get past that, I still have about a 1 in 4 chance of seeing any output still.  When I get the output, it is fine.  There seems to be no pattern for how many PLL unlocks I will get, nor when everything will eventually work.  I am thinking that there is something I need to do for better consistency, but I can't figure out what.

Any ideas?

  • +1
    •  Analog Employees 
    on Jan 20, 2021 7:05 PM 1 month ago

    Hello G

    By default, AD9176-FMC-EBZ uses HMC7044 to generate all JESD204B clocks (BR/40 to the FPGA, SYSREF to both FPGA and AD9176). The HMC7044 has two PLLs - PLL1 locks a 122.88MHz VCXO to an external ref, and PLL2 locks an internal VCO to the VCXO. The dual-loop allows for better jitter when using a low-quality external ref. 

    If the AD9176 PLL ref is not frequency-aligned to the HMC7044's PLL2 reference (the 122.88MHz VCXO), the BR/40 will drift relative to the AD9176 DACCLK and all its clock domains, including the SERDES PLL, and the link will be "flaky" if the various PLLs align such that they are on each other's clock boundaries. So having a common reference to all the clocks is important. 

    HMC7044 PLLs, as implemented in ACE, are integer-only. So the ref must be int-mult of 122.88MHz. 

    Easiest in ACE, is to specify datarates that are also int-mult of 122.88MHz. This way all clocks scale accordingly, and satisfy the 122.88 rate.

    You could replace the VCXO to a 100MHz or 120MHz. But ACE would still expect the 122.88MHz rate, so you may have to "hack" ACE to play nice.

    I am somewhat suprised you were able to get condition #1 working. I would not expect it to. My guess is you got lucky with the resulting rates and the relative path lengths of the clock references - but if you were to reset the link repeatedly, it could fail when the SERDES PLL in either the FPGA or the AD9176 is reset.

    I hope the explanation helps. Please let me know if condition #2 works with Fdac=12,042.24 MHz (datarate = 1,003.52 MSPS).

    one more comment. You could also provide an external BR/40. But unfortunately there is no easy way to route an external SYSREF to the AD9176. So would have to operate the link in subclass 0. Or solder a twisted pair onto the input caps, differentially, in hopes that the resulting edge will be clean enough... with careful rework it usually is. 


  • Wow, a lot to unpack there.  I am still getting myself up to speed with the AD917x and the JESD204B and seem to learn something new every week.

    OK, after a first read, it sounds like even though the PLL manual ref clock is letting me fill in whatever I want, it is going to be garbage since 250MHz is not an integer multiple of 122.88Mhz, right?

    From what I can tell, on the FPGA, the DAC clock rate needs to be the lane rate/40 (though for some reason Xilinx give me options that are other multiples as well).  So taking your 12042.24MHz line rate, dividing it by 40 gives me 301.56MHz.  This is an option in the core, so that is great!  But that is NOT a multiple of 122.88MHz, so it seems like I am stuck there. Agreed?

    If I try to work backwards from the 122.88Hz ref clock options, I get 983.04 Msps when using 245.76; but the minimum for the core is >=1 Gbps, so I can't use it.  If I bump up to 368.64MHz, the line rate becomes 14745.6 MHz, but the core tops out at 12.5Gbps, so I can't use that one either.

    While I continue digesting what you wrote, any suggestions on the math?


    Quick edit. I found one set of magic numbers, but it violates the DAC clock rate in ACE.  If I go with he PLL ref clock of 368.64MHz,  the Xilinx core seems to offer x32 as a possibility, so that gives me a line rate of 11.79648 Gbps.  I go back to ACE and start punching things in and when I set the input data rate to 1.179648 so I get the proper lane rate just listed, it complains because the DAC clock rate would be 14.155776 GHz, which is invalid.  So there goes that idea.

  • I was mistaken, the one set of values does meet all the criteria (I was plugging it into the Xilinx core wrong).
    If I set the PLL Ref Clock to 245.76
    Dual Link 9/1/12
    Subclass 1
    input data rate 983.04MHz
    I get a late rate of 9.8304 Gbps
    and a DAC clock rate of 11.79648 GHz

    Those values are all acceptable in the Xilinx JESD PHY core.  Unfortunately, I am still seeing inconsistent results.  I've only run it about a dozen times so far, and I don't think I've seen a DLL/PLL error, but sometimes it seems like it is outputting the data correctly, and other times I don't get anything out.  I check when I am getting no data out of the DAC, and the lights seems to be all green in ACE.  I attached the export of the registers from ACE, but nothing pops out to me as an issue.  For completeness sake, I also included the macro that ACE produces (actually I couldn't figure out how to upload them, so I had to create a Microsoft OneDrive link for them).

  • OK, final update.  Based on your explanation above, the settings I used in my last reply, and setting LMFC_VAR_0 and LMFC_VAR_1 both to 0x09, I seem to get consistent results with no sync issues or lack of data on the DAC when everything looked like it was "working.

    Thanks for the help.