Post Go back to editing

ADRV9009 ORX at 491.52 Msps


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,


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



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


  • Hello Erik,


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



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


    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.



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


  • I correct myself. You were absolutely right. With

    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,


  • Hello 

    where can i find the ADRV9009 projects with a single observation channel?