Post Go back to editing

ADRV9009 ORX at 491.52 Msps

Hello,

I would like to know how the timing looks like for the ORX data of a ADRV9009 at 491,52 MHz sampling rate. I understand that both ORX channels are bundled in this mode.

A quick look with Xilinx ILA, clocked with axi_adrv9009_rx_os_clkgen/clk_0, at the adc_data_* output lines of rc_os_adrv9009_tpl_core shows new data at each data line for each clock cycle. That would mean, that the clock is still at 245,76 MHz for 491,52 Msps mode. Is this correct?

The only remaining question then would be, which data values correspond to earlier points in time - data_0/data_1 or data_2/data_3.

Thank you, and best regards,

Erik

Parents
  • 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

Reply
  • 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

Children
  • 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.