Hello everyone, let me first share with you the situation of my project:
1. I use IMX6ULL and FPGA for communication(NO_SYS,SDK 2.2 for windows), which includes two parts: control instructions (bidirectional receiving and sending) and a large amount of data (only receiving, with a rate requirement of approximately 5MB/s), as shown in the following figure,
My colleague's design is an EIM interface to implement this function,0x50000000--0x50000018 with a total of 9 addresses for instruction transmission
0x50000020 address receives a large amount of data (SDMA Burst)
As I am just starting this field of work, I would like to ask if this design is reasonable and if there is a better design?
2. The communication method for a large amount of data between FPGA and 6uLL is:
(1) The FPGA keeps writing data to the FIFO, and when the FIFO is half full, an interrupt is generated to 6uLL
(2) After receiving the interrupt signal, 6ULL uses SDMA to read FIFO data to ensure that FIFO is not satisfied and data is not lost.
The current situation is
(1) If EIM is configured as asynchronous read and write, a maximum of 20 bytes can be received per 6ull interrupt.
(2) If EIM is configured to read synchronously, write synchronously, and cannot read data at 6ull, the program will get stuck waiting for SDMA's transferdone signal.
3. My program uses SDMA to read data, and the transmission method should be set to fixed source address and incremented target address. The corresponding method was not found in SDK2.2.
Can you provide some suggestions for those who have worked on related projects? Thank you
已解决! 转到解答。
As I am just starting this field of work, I would like to ask if this design is reasonable and if there is a better design?
As I used such designs successfully in the past (on AT91SAM9), I would say this is ok. FPGA developers seem to prefer FIFOs for data transfer (as a FIFO usually helps to synchronize between clocking domain). From the µC's view, a RAM interface (with incrementing addresses) would also be fine.
The communication method for a large amount of data between FPGA and 6uLL is:
(1) The FPGA keeps writing data to the FIFO, and when the FIFO is half full, an interrupt is generated to 6uLL
(2) After receiving the interrupt signal, 6ULL uses SDMA to read FIFO data to ensure that FIFO is not satisfied and data is not lost.
The current situation is
As an alternative, you could wire one or two of the SDMA's external event lines to the FPGA. In that case, the FPGA could inform the SDMA that new data is available without any CPU intervention.
(1) If EIM is configured as asynchronous read and write, a maximum of 20 bytes can be received per 6ull interrupt.
(2) If EIM is configured to read synchronously, write synchronously, and cannot read data at 6ull, the program will get stuck waiting for SDMA's transferdone signal.
Sorry, but I haven't any experience using synchronous bus modes. Maybe you could get better data throughput in such modes (comparing to asynchronous modes). But in any case: You'll have to carefully synchronize data between the EIM in the FPGA.
I could also make sense to use two different chip select lines between EIM and FPGA. So you could use different bus modes (sync vs. async) or timings for the register interface and the FIFO interface.
3. My program uses SDMA to read data, and the transmission method should be set to fixed source address and incremented target address. The corresponding method was not found in SDK2.2.
As I already answered to your colleague, the SDK routines seem not to be suitable for your use case. You can either modify the code in the SDMA, our you could simply ignore the lower address lines on the FPGA when accessing the FIFO.
Can you provide some suggestions for those who have worked on related projects?
Your application looks reasonable to me, but this is far beyond what other people you the SDMA for.
As I am just starting this field of work, I would like to ask if this design is reasonable and if there is a better design?
As I used such designs successfully in the past (on AT91SAM9), I would say this is ok. FPGA developers seem to prefer FIFOs for data transfer (as a FIFO usually helps to synchronize between clocking domain). From the µC's view, a RAM interface (with incrementing addresses) would also be fine.
The communication method for a large amount of data between FPGA and 6uLL is:
(1) The FPGA keeps writing data to the FIFO, and when the FIFO is half full, an interrupt is generated to 6uLL
(2) After receiving the interrupt signal, 6ULL uses SDMA to read FIFO data to ensure that FIFO is not satisfied and data is not lost.
The current situation is
As an alternative, you could wire one or two of the SDMA's external event lines to the FPGA. In that case, the FPGA could inform the SDMA that new data is available without any CPU intervention.
(1) If EIM is configured as asynchronous read and write, a maximum of 20 bytes can be received per 6ull interrupt.
(2) If EIM is configured to read synchronously, write synchronously, and cannot read data at 6ull, the program will get stuck waiting for SDMA's transferdone signal.
Sorry, but I haven't any experience using synchronous bus modes. Maybe you could get better data throughput in such modes (comparing to asynchronous modes). But in any case: You'll have to carefully synchronize data between the EIM in the FPGA.
I could also make sense to use two different chip select lines between EIM and FPGA. So you could use different bus modes (sync vs. async) or timings for the register interface and the FIFO interface.
3. My program uses SDMA to read data, and the transmission method should be set to fixed source address and incremented target address. The corresponding method was not found in SDK2.2.
As I already answered to your colleague, the SDK routines seem not to be suitable for your use case. You can either modify the code in the SDMA, our you could simply ignore the lower address lines on the FPGA when accessing the FIFO.
Can you provide some suggestions for those who have worked on related projects?
Your application looks reasonable to me, but this is far beyond what other people you the SDMA for.