cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
431 Views
Registered: ‎04-06-2020

RFSoC ADC Calibration issue

Hello,

I have a design where I connect one of the DACs on my RFSoC board through an 8-way splitter to all 8 ADCs.  There are no other devices in the signal paths.  The ADC/DAC clock frequency is 3932.16 MHz (not using internal RFSoC PLLs) and the signal I'm transmitting on the DAC is a tone at 700.08 MHz.  I've set the RFDC IP to use the 1st Nyquist zone and calibration mode 2.  I'm using Vivado/Vitis/Petalinux 2020.1 and am seeing higher spurs in the ADC data versus previous versions of the same design (2019.2 and earlier).  The most significant spurs are only about 50 dB down from the tone at fin=700.08 MHz and are located at fin +/- (fadc*k/8), indicating that the gain or time skew calibration may not be working correctly.  I am careful to mute the DAC signal before calls to XRfdc_Shutdown and XRfdc_Powerup for all the ADC tiles.  The power in the tone is well-above the required -40 dBFs (power in tone is approx. -21 dBFs).  I've attached an FFT plot for all 8 ADC channels.  Could anything have changed in the ADC startup/calibration procedure in version 2020.1?

Thanks!

sine.png
0 Kudos
7 Replies
Highlighted
Moderator
Moderator
415 Views
Registered: ‎04-18-2011

Given that the input tone is not located at an offset spur bin there should be no need to mute the DAC output when starting up the ADC tiles. 

Can you try this? It shouldn't really matter since in this case you seem to be impacted by GTIS spurs. 

I don't think anything should have changed between 2019.2 and 2020.1

I can check this...

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
404 Views
Registered: ‎04-06-2020

Thanks for the quick response!

I had been seeing strong content at (k*fadc/8) bins if I did not mute the tone before running XRfdc_Shutdown and XRfdc_Startup on the ADC tiles.  See attached plot.  I'm not sure how the FG OCB cal works.  Is it performed in the frequency domain?  If it just took the mean of the time domain data on the individual ADCs, it could explain the attached plot.

Also, FYI, I do have a 100-ms sleep after calling XRfdc_Startup on the ADC tiles.

Thanks.

sine_no_mute.png
0 Kudos
Highlighted
Visitor
Visitor
393 Views
Registered: ‎04-06-2020

I found that if I increase the sleep time after enabling the DAC sine wave output after the XRfdc_Startup calls, but before capturing the ADC data, the spurs gradually go away.  Here are plots for sleep times of 0.1, 0.5, 1, 2, 5, 10 seconds before acquiring the data.  That's a much longer convergence time than the 2^22 ADC clocks mentioned in pg269 (v2.3) on page 56.

Is it possible that the default integration time was increased from 2019.2 to 2020.1?

sine_sleep_0pt1_secs.png
sine_sleep_0pt5_secs.png
sine_sleep_1_sec.png
sine_sleep_2_secs.png
sine_sleep_5_secs.png
sine_sleep_10_secs.png
0 Kudos
Highlighted
Moderator
Moderator
379 Views
Registered: ‎04-18-2011

I expect that this is RFSoC Gen1/2. 

Can you confirm that is the case?

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
372 Views
Registered: ‎04-06-2020

Yes, ZU28DR (Gen 1).  Although I did not see such a long settling time with the same device until 2020.1.

0 Kudos
Highlighted
Moderator
Moderator
243 Views
Registered: ‎04-18-2011

I checked here and there should be no difference between how the calibration works between 2019.2 and 2020.1

It does seem genuine enough what you are seeing. Is it consistently slower than before when observed over many power cycles?

It might be tricky for me to reproduce it here since all i really have access to is RF analyzer which won't trigger and re-arm this fast. 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Moderator
Moderator
221 Views
Registered: ‎04-18-2011

I am thinking about a way to investigate this a little bit more. 

Maybe we could do something like this

Create the RF Analyzer design. 

Add a programmable counter to the canvas and use it to drive the hardware trigger on the the capture memory. 

We can trigger the analyzer from the GUI with a converged ADC channel. This will give us an idea of where the GTIS spur level is when the calibration is converged. 

After this we can stop the tile and make the capture mode the hardware trigger driven from the fabric counter. 

Set the counter to be the equivalent of the 2^22 sample clock cycles. 

Restart the tile and the capture should fill the buffer. 

We can then look in the GUI and see if it is converged or not. 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos