ADRV9009 ORX at 491.52 Msps

Addition: a closer look with ILA suggests that data_0 and data_1 represent I and data_2 and data_3 represent Q while the order in time might be 01 and 23. Can you confirm this?

Hello,

Which branch and which carrier are you using ?

For rates over 250MSPS, the M parameter should be set to when building the HDL and a single observation channel should be enabled in the profile. At the output of the transport layer you will have data_0 and data_1, corresponding to I/Q values. The rate of the clock will be 245.76MHz.

Regards,

Adrian

Hi Adrian,

I am using a ZCU102 and reference design hdl.2019.1.

With M parameter, you mean I should set RX_OS_NUM_OF_CONVERTERS to 2 in adrv9009_bd.tcl, right?

I have a custom block inserted between rx_os_adrv9009_tpl_core and util_adrv9009_rx_os_cpack. I am trying to achieve real-time processing of the ORX data at 491.52 MHz. For this purpose I have modified axi_adrv9009_rx_os_clkgen to provide a second clock with double frequency to clock my custom block. It doesn't work yet, though. I am still fighting with Vivado timing constraint violations.

Best regards,

Erik

Hello Erik,

Yes, RX_OS_NUM_OF_CONVERTERS. 

I will update the ADRV9009 projects to have a single observation channel. Most likely will be available in master next week.

Regards,

Adrian

Hmm. As I understood, in 491.52 MSPS mode all 4 ADCs of the ORX are used for stitching.

I guess this will not work if RX_OS_NUM_OF_CONVERTERS is set to 2, will it?

Best regards,

Erik

BTW, the rearrangement of the ORX data to true 491.52 MSPS now works for me. Even the DMA seems to be happy with the double clock frequency.

I need to test in hardware the exact configuration, but to my understanding even though all 4 ADCs are used, from the JESD204 perspective the data will be arranged as if there are only 2 converters, corresponding to I/Q, it's just that you're merging the data manually not in an unified transport layer.

If your setup is working as is, it's probably better to continue with it.

Regards,

Adrian

Hi Adrian,

additional comments:

If I set RX_OS_NUM_OF_CONVERTERS to 2 in the reference project, there is a width mismatch between rx_os_adrv9009_tpl_core/adc_data_0/1 (32 bits) and util_adrv9009_rx_os_cpack/fifo_wr_data_0/1 (16 bit).

Moreover, with only data_0 and data_1 at 245.76MHz clock rate, it would not be possible to transport ADC data at 491.52MHz sample rate.

Best regards,

Erik

I correct myself. You were absolutely right. With

set RX_OS_NUM_OF_CONVERTERS 2 ; # M
set RX_OS_SAMPLES_PER_CHANNEL 2 ; # L * 32 / (M * N)

The design builts correctly. Channel width is now 32 bits, so the data rate fits.

Moreover, the Linux kernel error messages during initialisation of the 491,52 MHz mode are gone and IIO oscilloscope is able to display the stitched data.

Thank you.

We also aim to process the ORx data in real time. Did you run into any problems while processing the ORX output at 491.52 MHz? In our case the application is a PSK demodulator.

Hi,

yes, processing the 492 MHz ORx data within the FPGA in real time is perfectly possible. I am running 128 IQ demodulators in parallel now at that speed on an ZCU102. During design, I frequently run into timing problems, though. In the end, all problems could be cured using heavy pipelining.

Some remarks, still:

- You cannot transfer 492 MSp/s to the Zynq's processor, of course. It cannot handle more than a few MSps/s in real time.

- In 492 MHz mode, the ORx output has increased low frequency noise due to the stitching. If noise is an issue, you might consider using the 246 MHz mode.

- In 492 MHz mode, the ADC data still arrives at the FPGA at 246 MHz, but you get 2 consequitive samples at once. If you want to do real time processing, you either have to process 2 samples in one clock cycle, requiring 2 parallel channels in the FPGA, or you have to create a 492 MHz clock yourself and convert the data stream to real 492 MHz. I have done the latter.

Best regards,

Erik

Hi,

yes, processing the 492 MHz ORx data within the FPGA in real time is perfectly possible. I am running 128 IQ demodulators in parallel now at that speed on an ZCU102. During design, I frequently run into timing problems, though. In the end, all problems could be cured using heavy pipelining.

Some remarks, still:

- You cannot transfer 492 MSp/s to the Zynq's processor, of course. It cannot handle more than a few MSps/s in real time.

- In 492 MHz mode, the ORx output has increased low frequency noise due to the stitching. If noise is an issue, you might consider using the 246 MHz mode.

- In 492 MHz mode, the ADC data still arrives at the FPGA at 246 MHz, but you get 2 consequitive samples at once. If you want to do real time processing, you either have to process 2 samples in one clock cycle, requiring 2 parallel channels in the FPGA, or you have to create a 492 MHz clock yourself and convert the data stream to real 492 MHz. I have done the latter.

Best regards,

Erik