--- Quote Start ---
I am using the TSE interface to transfer large blocks of data using UDP. To cut the overhead I am not using the TCP stack. I generate the fixed ethernet/IP/UDP headers in one part of memory with the payload data in a separate contiguous section of memory and use two SGDMA transfers to send each UDP packet to the MAC. The first sends the headers, the second the data payload. This is working well in 1Gbps mode, but if I try to run it at 100Mbps the system hangs up. What I have found is that at 1Gbps the MAC sinks the data faster than the SGDMA can source, so I had to use the store and forward transfer mode through the Tx fifo. This insures that the MAC waits until a full packet is available to transmit. In 100Mbps mode the SGDMA can source the data faster than the MAC can sink, and once the almost full flag (ff_tx_a_full) is set by the fifo to exert back pressure to the DMA, it never clears. The SGDMA still has the wren signal set as it has more data to transfer, but the fifo will not accept anything more until I fully reconfigure the FPGA. A soft reset of the MAC will not fix it. I have tried various settings and configurations of the MAC but this issue persists. It may also affect 1Gbps mode, but since the MAC sinks the data much faster the almost full flag never gets set in 1Gbps mode (as confirmed in signal tap). There are some timing closure issues in the core, but we are already using the fastest speed grade so I don't know that we can do anything about them. And since the problem has persisted through multiple builds with various TSE MAC configurations I am not convinced that issue is related to a timing issue. Any insight or recommendations would be appreciated.
--- Quote End ---
I currently also have this problem, the signal
ff_tx_a_full
after some point is never deasserted again and the core gets stuck. Did you find a solution?
Honored Contributor
