• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 210 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AM623: using PRUSS to transfer data

AM623: using DM R5F to continuously read data from FPGA

Kiung Chung Wong
Prodigy 230 points

Part Number: AM623

The discussion spawns from below e2e thread.

e2e.ti.com/.../am623-using-pruss-to-transfer-data

Below is the brief description of our use case.

The FPGA will generate 1M samples per second (8 bytes per sample) continuously until user stops it, and we need to transfer those samples continuously from FPGA into the memory that A53 Linux can access.

The front end will fill the FIFO at the rate of 1M samples per second (8 bytes per sample) continuously, and DM R5F will need to pull the samples into the memory by reading the data register continuously for further processing by A53 Linux.

So, we want DM R5F to act like DMA for A53 Linux.

But the concern to implement this in R5F is, how to prevent DM task and the sample reading task from stepping on each other?

We don't want sample reading to cause DM task to fail. At the same time, we also don't want DM task to slow down the sample reading that eventually causing FIFO overflow.

  • 0
    TI__Guru** 109900 points

    Hello KC Wong,

    Apologies for the delayed responses here, this thread got misassigned.

    Are you still evaluating this as a potential option for your design?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 230 points

    Hi Nick,

    Yes.

    The interface needs to support 

    (a) read/write FPGA registers 

    (b) transfer samples from FPGA, the front end sample rate can be varying 

  • 0 in reply to Kiung Chung Wong
    TI__Guru 54068 points

    Hello K C Wong,

    The DM R5F can access the FPGA over the GPMC interface (similar to NOR/PSRAM usage) using DMA.

    For example, if the DM R5F needs to read a 1 MB sample set from the FPGA, it can initiate a GPMC DMA transfer, which will continuously fetch data until the full buffer is received.

    Once the transfer completes, the DM R5F can notify the A53 core via IPC to consume the data. After processing, the A53 sends an IPC response back to the DM R5F to trigger the next DMA transaction.

    For continuous data processing, a ping-pong (double-buffer) scheme can be used. The application logic should run in a separate task from the DM task, allowing both to operate independently without contention.

    This approach is supported and does not introduce functional issues..

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    Prodigy 230 points

    Ok noted, thanks Anil.

    Our team still want to try the OSPI because the current hardware is with OSPI.

    So, the plan now is to emulate the FPGA as flash to use mem-to-mem DMA copy on top of OSPI/QSPI memory mapped port during read from flash for maximum throughput and reduced CPU load as stated in the SDK documentation.

    https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/latest/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/QSPI.html




  • 0 in reply to Kiung Chung Wong
    TI__Guru 54068 points

    Hello K C Wong,

    Yes, if you want to use the OSPI interface, there is no problem.

    However, we do not officially support this interface, so we may not be able to assist if you encounter issues.

    In the MCU+SDK/PROCESSOR SDK , the OSPI/QSPI interface is primarily intended for memory devices, not FPGAs.

    Apart from this, once the A53 reads data over OSPI, it sends an IPC notify to the DM core, and the DM core consumes the data.

    The DM core then sends another IPC notify to the A53 core after consume the data.

    For continuous data processing, a ping-pong (double-buffer) scheme can be used.

    The application logic should run in a separate task from the DM task, allowing both to operate independently without contention.

    This approach is supported and does not introduce any functional issues.

    Regards,

    Anil.