AnsweredAssumed Answered

MMCM not locking on Zed + FMCOMMS1 ref. design

Question asked by oppradhan on Apr 17, 2017
Latest reply on Apr 20, 2017 by oppradhan

Hi good folks,


I'm running into some trouble getting my DAC + ADC on the fmcomms1 board work with my ZedBoard. With this same config I have previously run some extensive radar applications.

Some details:

Tools:  Vivado 2016.4

HDL branch:  I use the latest dev branch to build my IP libraries but use the fmcomms1 project from the Master branch and make relevant changes to the scripts to make the project compatible with the dev branch. All of this works and I am able to implement my design without any errors and with NO timing violations.

(the hardware has the ad9122 DAC + ad9643 ADC IPs along with their associated utility IPs and the IIC fmc for SPI comm. with the PIC on the fmcomms1). I have left out all the other IP blocks since they are not necessary for me.


The reference clock ref_clk_out is as defined in the design at 30 Mhz and is output to the 9523.


no-OS software branch:  I use the master branch once again and use the fmcomms1> zed no-OS project to run a simple transmit only. 



1. The drp_locked flag does not set telling me that the mmcm in the ad9122 core is either NOT locking or NOT receiving at all the dac_clk_in. This might mean that the 9523 is not outputting the correct clocks. I tried to wait for a longer time (1000 delay instead of the 100 as timeout in cf_axi_dds.c ). Clearly without this none of the further config happens which means there won't be any dac_div_clk to the core, and I observe this (no clock) by bringing the dac_div_clk out to one of the PMODs


2. So I tried to probe the 9523 DAC clock pins (DAC_DCO, DAC_REFCK, and DACCK) and finding that too cumbersome, for now decided to disconnect the fmcomms1 from the fmc connector and probe the ref_clk_out_p(and n) pins directly on the FMC. I see the following (green) trace. The purple trace is the same ref_clk of 30 MHz that I sent through another ODDR and ODBUF to one of the ZedBoard PMODs (hence the distorted shape)

Green - ref_clk_out_p




I've left the default configs for the clock frequencies as is in the no-OS (122.88 MHz DAC and ADC sample rate and I think the LO PLLs also get the same)


Some observations:

The o/p RF is NOT connected to the i/p RF chain and are simply terminated with 50 ohms. However in one trial when I did hook up the o/p to a scope I could see a severly amp. modulated RF s/g even though the LO frequency was correctly at the Tx frequency value(I verified this by changing it to a few other values and the spectrum was consistent). So I figured this was due to the dac core not setting up correctly and the dds throwing out some indeterminate values? I suspect this because when I tried to zero the output by setting the dds scale (on both I and Q) channels to 0, the output was still present and at something of the order of 11 dBm of power which seems to be about half of the full scale output (I think I remember reading full power out possible is about 14. dBm)




1. Although one can losely say that there's a repeating waveform in the green trace at the same frequency, is the LVDS signal supposed to look quite horrid like this?


2. Am I right in tracing the source of the MMCM unlocked error back to the on-board hardware? or has this been observed in the HDL itself?


3. Should I go ahead and try to bring the dac_clk_in signal after it is single ended back out to one of the PMODs and look at it on the scope? This will require me to modify the ad9122 IP core and before I invest time in that wanted to get some comments on this.


4. Somehow I do not think the 9523 chip itself has a problem, because i tied the adc_clk signal to an LED and it lights up (although the right way to go about this would be to bring this out to one of the PMODs as well, which I will do after some sleep). Moreover the LOs seem to get the right clock as well since there is some RF s/g at the correct frequency that I could see on the scope as mentioned before.


Any thoughts?