AnsweredAssumed Answered

What governs ADC sample rate for AD-FMCOMMS1-EBZ?

Question asked by tescott on Jul 29, 2014
Latest reply on Aug 11, 2014 by tescott

I've got a Zedboard and a AD-FMCOMMS1-EBZ.  The AD-FMCOMMS1-EBZ jumpers have been modified to bypass the RF chain.  I've got the no-OS build running successfully on this setup with a rebuild I've done of the HDL repo using the tag fmcomms1_v2013_4_2014_07_25.

 

I have a 1MHz signal going out J4 and a 10MHz signal going out on J7.  For testing purposes, I'm simply routing those back into J11 and J13.  Apart from some attenuating and offset issues that I've created another thread on this forum about, this works fine.  I've also added the NE10 (projectNe10/Ne10 · GitHub) library providing me with the ability to easily perform FFTs.  I use adc_capture() to grab 16384 samples, do some post-processing to separate the adc A/B channels, and then pipe that data into the FFT algorithm.  For a 1MHz signal, I get a peak at FFT bin 67 which makes sense: 245.76MHz sample rate / 16384 samples * 67 = 1.01MHz.  Further, when I look at a plot of the raw A/D values, I see a sine wave that shows 4 cycles every ~1000 samples -- which correlates to a ~250MHz sample rate.  Life is good.

 

A problem crops when I try to run no-OS and Linux in a dual-cpu mode.  It appears the sampling rate slows down from 250MHz to 100MHz in this configuration.  In terms of setup, I've followed the Xilinx XAPP1078 app note and have Linux running on CPU0 with the no-OS application running on CPU1.  All communication is done through OCM memory and simple synchronization flags.  I use the same system_top.bit file in this configuration that I use in the single no-OS CPU configuration.

 

With dual-CPU setup, the 1MHz input now reports a peak at FFT bin 164: 1MHz * 16384 / 164 = 99.9MHz.  When I look at a plot of the raw A/D values, I see a sine wave that shows 10 cycles every ~1000 samples -- indicating to me that the sample rate is indeed at 100MHz.

 

I'm able to delay the execution of the no-OS app until after Linux has completely booted and is sitting at a shell prompt.  This does not make a difference.  Further, the screen output I see from the no-OS app under the dual-cpu config is identical to the single-cpu config -- the reported ADC sampling rate is 245760000, the tests run by adc_tests() all pass, etc.

 

I've probed ADC_CLK_P/ADC_CLK_N and that shows a 250MHz signal.  I half-expected this to show a 100MHz signal.  I've verified that the output from the DAC is truly 1MHz, so that has not been affected.

 

Any idea what factors might be coming into play that I could investigate to correct this?  I'm guessing that Linux or my device tree is initializing something that the no-OS app is making an assumption about.  I don't know enough about the DMA path that adc_capture() uses, but am wondering if something might be going on there also.

 

The funny thing is that if I go back to a pre-generated Xilinx HDL build I have (from: analogdevicesinc/fpgahdl_xilinx · GitHub), the same setup of Linux / u-boot, etc. works fine -- the sample rate is 250MHz as expected and my FFT peak for the 1MHz input is at bin 67.  Go figure.

 

Thanks,

--tim

Outcomes