Other Parts Discussed in Thread: DP83869, SYSCONFIG
Hi, we are evaluating AM263Px for an application that requires low latency communication with a remote AM64x. Due to the distances involved and bandwidth required, we are limited to using Ethernet for communication (versus FSI or SPI or CAN). On the AM64x side we use custom firmware with the PRU-ICSSG to transmit and receive at gigabit speeds. This works great between AM64x boards and provides very low latency.
Unfortunately, the PWM/ADC peripherals on the AM64x are limited, so we are considering using AM263Px to communicate with the remote AM64x (instead of a 2nd AM64x). Since the AM263Px doesn't include a gigabit-capable PRU we are evaluating the CPSW. See below:
AM64x PRU-ICSSG -> Gigabit Ethernet link -> AM263Px CPSW
Our bandwidth needs are very modest; we need to send one 64-byte packet every 10 microseconds, or approx. 51 Mbps. We also need the total latency between TX and RX to be <1.5 microseconds which requires Gigabit speeds. The SDK v9.01 SDK has a benchmark showing the CPSW can handle <15Mpbs (with 64B UDP datagrams) before it begins dropping packets. Obviously there's a tradeoff between packet size and bandwidth, but even so this is remarkably bad performance. We considered using the PRU Ethernet but because it's limited to 100Mbps there is just too much latency (~5 microseconds just to transmit 64-bytes, not including PHY or processing latencies).
Since AM263Px is a new product, is it possible the low performance is an SDK latency limitation that will be improved in the future? Or is this a hardware bottleneck due to the DMA engine?
Said differently, does ENET-LLD have any APIs that bypass the DMA engine and allow us to interact with the raw packet stream directly to improve latency? Our product doesn't require general networking capabilities and only needs to receive a fixed size packet from a remote AM64x (direct connection, no switch or other devices in between).