07-09-2020 12:16 PM - edited 07-09-2020 12:25 PM
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?
07-09-2020 01:01 PM
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...
07-09-2020 01:27 PM - edited 07-09-2020 01:41 PM
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.
07-09-2020 02:05 PM - edited 07-09-2020 02:10 PM
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?
07-09-2020 02:46 PM
I expect that this is RFSoC Gen1/2.
Can you confirm that is the case?
07-13-2020 02:45 PM
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.
07-14-2020 02:52 PM
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.