Post Go back to editing

AD9371 ref design and data offload

Category: Software
Product Number: AD9371

Hello,

I am looking for using this sync script made for AD9081 on the AD9371 ref design with OBS RX : https://github.com/analogdevicesinc/pyadi-iio/blob/master/examples/ad9081_sync_start_example.py

I added the offload Rx and Tx modules in the block design, compiled the newest kernel with offload driver and added rx and tx data offload driver to the device tree. I can now see the registers in the debugfs of the kernel.

But it is not working as expected. On the Tx side, the buffer is written to the Tx offload fifo but it is then constantly sent, even when Tx Cyclic Buffer option is set to false.

On the Rx side, the data is written once to the Rx Fifo, but then the same data are sent everytime there is a dma request from the cpu.

Thanks,

Simon

  • Hello Simon,

    there was a bug related to the Rx path that was fixed in the 2021_r1 and master branch with this commit.

    For HDL make sure to use the latest 2021_r1 branch.

    For the Tx path make sure to put the Tx offload in oneshot mode. In the device tree you need to enable the adi,oneshot property.

    Thank you,

    Laszlo

  • Hello Inagy,
    I directly reported this problem to your support team not too long ago. In the latest added codes this did not fix the problem. I am trying to fix the problem myself, but there is a complex problem in rx_dma interrupt operation. I was able to fix the problem by changing the Rx_dma System to fifo interface but I had to remove the dataoffload block. Many people facing this issue are waiting for a fix. FormerMember 

  •  

    I directly reported this problem to your support team not too long ago.

    Can you be more specific? Please post a link to that thread.

    In the latest added codes this did not fix the problem

    Did you tried the latest 2021_r1 with the fix I pointed to?

    Thank you,

    Laszlo

  • Thanks a lot, oneshot config works for tx offload, and the latest commit fixed the Rx path !

    Now i want to use the sync config option. I set the sync config to 1 on Tx and Rx offload, so it should be set to hardware sync. I connected the two sync_ext of offload modules to the sync output of Tx tpl core. So when i set "manual_trigger" in the python script : 

    - Data is passing in the TPL Tx Core.

    - Data from the Tx offload module is read from the FIFO and sent to the Tx TPL core

    - Data from Rx TPL Core is written to the FIFO of Rx Offload module for further reading by the Rx DMA module

    The problem is that I have a timeout on the rx side in my python script, and nothing seems to happen on the WR_CTRL bus of the Rx offload module, so i guess the fifo is empty, thus the timeout.

    Putting the sync-config back to 0 in the debugfs doesn't seem to have any effect. And write state of the fsm should be in SYNC state, but it is at 0 when checking in the debugfs.

    By the way i think there is a bug, as there is 5 different states in the write fsm, but there is only 2 bits in the register. So if it is in state 5 it will be printed 0 in the debugfs

  • The "manual_trigger"  sync mechanism was built for the TPLs, so there is a gating mechanism also there. In case you armed that logic in the Rx TPL and the syncs are not connected the input data will be gated so the Rx offload can't store anything.

    Make sure you have the dev.rx_sync_start = "arm" and dev.tx_sync_start = "arm" lines commented in the python script.

    The states changed in the hdl so a Linux kernel update is required:

    https://github.com/analogdevicesinc/linux/commit/5501219057f9d505aca7bbddc20ca9a84c647cbd

    Thank you,

    Laszlo

  • Thanks for the kernel fix.

    But I don't understand. I use the manual trigger only with the Tx TPL core anyway, the Rx TPL core is not armed (It is actually the RX OBS TPL core, which doesn't have the driver with triggers) so data is always flowing on the rx side to the Rx offload module (wr_en always 1).

    The issue is that when i set sync_config to 1 in the Rx Offload module, after one transmission the fsm is stucked in theses states

    root@analog:/sys/kernel/debug/adi_axi_data_offload/axi-data-offload-0# cat fsm_debug_state_write
    4
    root@analog:/sys/kernel/debug/adi_axi_data_offload/axi-data-offload-0# cat fsm_debug_state_read
    1

    I don't understand why the read fsm would stay in the RD_STATE_PRE_RD as rd_request_rdy is always 1

    and why is the write fsm stucked in WR_STATE_WAIT_RD ?

    Also, software reset in the debugfs reset the fsm to state 1 for both, but i still get the timeout even tough I reset the fsm and the sync_config to 0. Only a reboot works

  • Ok my bad, the states are defined as power of two. So state 4 for is WR_STATE_SYNC, state 1 is IDLE which make more sense. And the reset needs to be set again to 1 to work.

    Now I understand that the sync needs to be triggered when init_req is up, so during a Rx DMA transfert. Then I don't see how i can solve my problem.

    Is there a way of async read and write with theses ?

    What i need is : 

    1. Transmit data from tx dma to storage of Tx offload
    2. Transmit data when the sync is triggered
    3. Store data in Rx offload storage when the sync is triggered
    4. Read back data from the Rx offload storage through dma transfer

    2 and 3 are simultaneous but otherwise theses events don't occur at the same time

  • The idea would be to prepare the DMA transfers in advance (both for Rx and Tx) then issue the sync.  The example python should do the same thing regardless if it is using TPL sync or data offload sync.

    Laszlo

  • In the script the rx function is called after the sync trigger, i don't know how you're not going in timeout and how the rx offload fifo write is synced to data.

    Anyway I managed to get it to work in bypass mode and with increased bypass fifo size in rx offload IP. I simply connected the dac_valid to the wr_en of rx_upack module