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.

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.