03-12-2019 09:41 AM
I am trying to configure the ADC on my ZCU111 board for a 1018MHz sampling frequency with 8x decimation. I think I've got everything set up right, but when I sample a known frequency it appears to be shifted by ~1.7MHz from where it should be.
I am generating a 10.335MHz sine wave on DAC Tile 0,Channel 0 (P) of one ZCU111 board using the RF Data Converter User Interface tool at 6389.76MHz with a NCO setting of -400.000MHz. This produces a signal at 410.335MHz as verified by a spectrum analyzer.
On a second ZCU111 I have configured the LMX2594 to output a 1018MHz reference clock based on the output of the TICS Pro tool from NI as shown in the image below. I added the registers generated by this program to the ClockingLmx structure xfdc_clk.c file and call LMK04208ClockConfig & LMX2594ClockConfig from my application.
I have the ADC configured for 1018.000MHz sampling frequency and 8x decimation on ADC Tile 2 Channel 1 (P). The NCO is configured for -400MHz. Currently, I am running without a balun on both the ADC and DAC and am just using the P end of the balanced signal (and expecting a ~6dB loss because of it).
When I capture the sine wave on the receiving RFSoC using chipscope and take the FFT of it in Matlab (exported .csv file) I see a sine wave with a frequency of 12.058MHz, or a difference of 1.723MHz from the expected value.
What am I doing wrong in my process?
03-12-2019 10:14 AM
I don't understand why you are trying to use the DAC and ADC single ended like this. That is not what was intended.
Can you try
Use the evaluation design and gui to loopback the signal from the DAC to an ADC using one of the low frequency balún paths to make sure that this works for a single board then try expand to the second board using the reference design image?
03-12-2019 10:59 AM
@klumsde, I'm operating this way as a quick and dirty test setup because the baluns I have for those ports don't support these low of frequencies but I wanted to have something low enough frequency to where I could see it on the oscilloscope available to me. The fact that I'm only using half of the balanced signal should have no significant impact on the results of the test other than power level.
As for you suggestion, I setup both boards with the RF Data Converter Evaluation User Interface (RFDCEUI) tool (still on DAC T0,C0, P & ADC T2,C1, P) with an ADC sampling frequency of 3194.9MHz (which is the default) and a decimation of 8x. Using this setup, I receive the signal perfectly fine.
Now, the main difference between the two tests is when I use the RFDCEUI tool, the LMX2594 ADC clock is set to 247.760MHz with an internal PLL bumping it up to 3194.9MHz where as in my design the LMX2594 ADC clock is set to 1018MHz and the internal PLL is bypassed.
I would love to load my .tcs file generated from TICS Pro into the clock settings of the RFDCEUI but everytime I adjust the clock settings in the tool (whether pre-defined Xilinx .tcs files or my own) I lose communication with the board.
This seems like a clocking problem but everything appears to be correct.
03-13-2019 05:16 AM
@klumsde, I was finally able to get the RF Data Converter Evaluation User Interface tool to accept clock changes (I thought I could just configure a single RFPLL and was leaving the REF CLK and other RFPLLs blank). I can reproduce the same problem on a single board with the onboard LF baluns.
DAC Tile 1 Channel 3 => ADC Tile 0 Channel 1
Where DAC nco is set to -400MHz, and Fs is set to 6389.76MHz. Still a 10MHz sine wave input with 16K samples (actual 10.335MHz)
The ADC nco is also set to -400MHz, Fs is 1018.00000MHz (internal PLL bypassed), and 8x decimation.
I'm still seeing the same 12.054MHz I was seeing in the previous setups.
I've attached the .tcs file I'm using to generate the 1018.000MHz clock. The extension has been changed to .txt since the forum won't let me upload a .tcs file.
03-13-2019 05:19 AM
I was about to reply and say that it seems to expect all fields to be populated in the advanced mode.
OK Let me give this a try here.
03-14-2019 11:37 AM
03-15-2019 01:45 PM
Unfortunately I haven't had a chance to try this. I've asked a colleague to take a look and try it on our side