ADRV9009/ZCU102 Reference Design Loopback


I am trying to modify the ADRV9009/ZCU102 reference design to loopback samples (Rx to Tx) within the fabric.  I have connected the output of the util_adrv9009_rx_cpack module to the input of the axi_adrv9009_tx_dma via a custom module. This custom module receives 64-bit packed rx samples over a FIFO interface and outputs 128-bit packed tx samples over a AXI-streaming interface (tx_0 = rx_ch0i_0 rx_ch0q_0 rx_ch1i_0 rx_ch1q_0  rx_ch0i_1 rx_ch0q_1 rx_ch1i_1 rx_ ch1q_1). I changed the input interface of the axi_adrv9009_tx_dma module to axi-streaming.

It does not appear to be working, so I have a couple of questions:

  • Has anyone managed to get this mode of loopback working? If so, how?
  • What are the xfer_req signals for?

I would be grateful for any advice.


Parents Reply Children
  • Thanks Andrei,

    The ultimate goal is to do some signal processing on the received signal within the fabric (filtering, for example), before sending the conditioned signal to the DACs for transmission. I think I require a more involved solution to do this?  

  • 0
    •  Analog Employees 
    on Nov 27, 2019 2:40 PM 11 months ago in reply to AJohn941


    I took a closer look at the code, what I posted is for ad9361. It will not work with adrv9009.

    You must have equal data rates(sampling rates) on RX and TX.

    As you probably know, the Rx and Tx are in different clock domains. The Rx has 2 lanes in the JESD link, the Tx has 4, this is because of the lane difference(at the same rate). The Tx "device clock" will be (Rx "device clock")/2 and the data path is 2x wider. Your task requires moving the data from one clock on the other. The clock crossing can be done with a fifo.

    The sample arrangement seems ok.

    The xfer_req is generated by the DMA. It indicates when a transfer is made. In your case, I don't see a use case for this signal.

    What is the actual behavior when you say

    It does not appear to be working


  • Thanks Andrei,

    I changed the input interface of the axi_adrv9009_tx_dma from AXI-memory mapped to AXI-streaming. This removed the m_src_axi  interface, and so i removed the associated axi_hp3_interconnect block as well as the S_AXI_HP3_FPD port on the ps block. I then connected the new streaming interface to my custom block. I use the ready signal to read data from the fifo in my module to deal with the clock crossing. However, an system ILA block in the design suggests that the ready signal from the axi_adrv9009_tx_dma never goes high. I am wondering whether I need to modify a downstream block to draw samples from the DMA to the DAC on power up? 

  • 0
    •  Analog Employees 
    on Nov 27, 2019 4:00 PM 11 months ago in reply to AJohn941

    Hi John, 

    as general note, the DMAC never sets ready on the AXI stream interface if it is not enabled and does not have a descriptor to work on.

    Why do you still have a DMA there ? Why not connect your custom block to the axi_adrv9009_dacfifo ?

    Do you have a DMAC with source and destination both set to AXI Stream ? Am I understanding correctly?



  • Hi Laszlo,

    You understand correctly - the DMAC is axi stream for src and dest. I went for this solution as I was trying to make minimal changes to the reference design, but happy to try your suggestion.

    I will wire up my module to the input of the dac fifo using the dma_data, dma_ready, dma_xfer_last and dma_valid signals. I will remove the DMAC and its connections to the PS.

    A couple of queries:

    1) Can I leave the 'dma_xfer_req' of dac_fifo disconnected?

    2) Should I tie 'bypass' of dac_fifo to a constant value to ensure that my samples are passed to the DAC?

    2) When should I assert the last signal? At present I assert it every 1024 128-bit samples.