AM623: How to configure the Main_SPI0 of AM623 as the host and the FPGA as the slave, and configure the Main_SPI0 of AM623 as the dma mode, and configure the passive receiving mode to actively read the data of the fpga buffer through dma after the fpga giv

Hi,

What OS do you use on AM623, Linux or RTOS?

I use Linux

Hi,

I am routing your query to our Linux SPI expert for comments.

Hi Bu,

some guidance on your question below...

bu yuying said:

How to configure the Main_SPI0 of AM623 as the host and the FPGA as the slave,

On the AM6x side what you'd probably want to do is the following, requiring some custom Kernel development:

1. Use an existing, preferably basic SPI peripheral driver as a baseline for your new driver. For this I'd recommend drivers/spi/spidev.c. It's basic and pretty well understood/used, and you can find resources including userspace access examples easily (e.g., ./tools/spi/spidev_test.c). Clone/copy this driver to a new file, and add a new CONFIG option and build support for your new file (need to edit Kconfig and Makefile in drivers/spi for that).
   
   
2. Add the related device tree entries. Also extend the main_spi0 DTS node to add the properties needed to enable DMA transfers. See here for details: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1356551/faq-am6x-optimizing-spi-transfer-inter-byte-gaps-using-the-dma-in-linux
   
   
3. The last piece would be allowing the external FPGA to trigger an interrupt, so you know when to fetch data from the FPGA from Linux. One way to do that would be to leverage UIO (Userspace I/O) functionality of the Kernel, see https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html. Basically look at an existing UIO driver like drivers/uio/uio_cif.c and incorporate the related interrupt functionality into your custom driver.

As a simpler alternative, you could also do the following:

1. Use the spidev.c driver discussed earlier as-is. There are device tree examples readily available that you can just leverage, see the end of this page here: https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/09_02_01_10/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/SPI.html
   
   
2. Use a gpiod-based library approach (https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/) to capture GPIO interrupts and propagate them to userspace. There's actually an E2E thread that was just posted on this topic, so you can just follow this along for a solution: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1378524/tmds64evm-gpio-falling-edge-interrupt-configuration

Regards, Andreas

OK,thanks

I think it is too slow at the user level, because the subsequent speed needs to be increased by three times, so I want to complete the transmission in the driver layer, so I still want to continue to use the fpga to automatically transmit data to the cpu A core, I think the difference should be in the clock, as long as the clock configuration is successful, it should be possible to achieve even if the host does not control, fpga can still actively send data to the host and transfer it to memory through dma, so I would like to ask whether dma will have such a configuration item?

Hi Bu,

bu yuying said:

I think it is too slow at the user level, because the subsequent speed needs to be increased by three times, so I want to complete the transmission in the driver layer,

If you handle the interrupt processing / SPI transfer at the Kernel level developing a custom driver (based on existing kernel sources, as suggested earlier) the latencies should not be too bad, especially if you use an RT kernel.

bu yuying said:

it should be possible to achieve even if the host does not control, fpga can still actively send data to the host and transfer it to memory through dma,

Sounds like you want to operate SPI/DMA in a continuous cyclic type of mode/operation. While we think this is possible from a HW POV this would require some non-trivial custom Linux kernel/driver development to make this work and happen. Specifically, one of our engineers came up with a high-level method / scheme (shown below) which they said can be implemented in bare metal  (MCU+ SDK), but Linux would be a lot more challenging to do the same.

Flow : Peripheral – Peripheral FIFO’s – PDMA – RCP / TCP Buffers – PSI-L – BCDMA/PKTDMA(UDMA) – Memory

From left to right, the data moves from peripheral to memory.

From right to left, the data moves from memory to peripheral.

It might be easier to come up with a different scheme to exchange the data on a system level. For example, you could use the GPMC interface and move data in a parallel fashion w/ FPGA for throughput. We have a solution that allows triggering GPMC-based transfers based on external interrupts, it's not public yet but can be made available I think if that's something you want to consider. But this also would require some custom kernel driver development.

Regards, Andreas

OK,thanks

I use Linux system.Do you have any suggestions?

Can I send an instruction to the DMA of the A-core CPU each time, inform the DMA to fetch 1k data from the fpga, and then ask the dma to notify the CPU after obtaining 1k data, and re-inform the DMA to continue to read the data, if any, can you give relevant examples for reference?

Hi,

Andreas is currently out of office and please expect delay in responses.

Regards,
Krunal