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:
I would be grateful for any advice.
Hi,You can do it much easier.https://github.com/analogdevicesinc/hdl/blob/master/library/axi_adrv9009/axi_adrv9009_tx_channel.v#L137
Write 0x08(loopback data) to the REG_CHAN_CNTRL_7 of each channel. See dac channel regmap.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?
Hi,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
AJohn941 said:It does not appear to be working
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?
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?
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.
1. you can set dma_xfer_req to 1
2. tie 'bypass' to 1 if you want to stream contiguously from your module.
3. in bypass mode the 'last' is ignored.