Standalone LiteEth UDP core appears to send premable and SFD at wrong clock frequency?

[a-panella]

Hi,

Apologies if this is not correct place to ask:

I am trying to integrate the standalone (no CPU) liteX LiteEth core into an existing design on a custom board, but I am currently seeing weird TX_D data that looks like it could be a "stretched" preamble + SFD

To do this, I am invoking liteEth gen.py with a .yaml file containing the following:

# PHY Configuration
phy       : LiteEthPHYRMII
vendor    : xilinx
toolchain : vivado
 
# Network Stack Configuration
clk_freq    : 25e6
core        : udp
mac_address : 0x10e2d5000000
ip_address  : 192.168.111.77
# data_width  : 16
 
# UDP Ports
udp_ports :
  "udp0" :
    "udp_port"      : 2000           # Static parameters
    "ip_address"    : "192.168.111.255" # Static destination
    "data_width"    : 16
    "tx_fifo_depth" : 64
    "rx_fifo_depth" : 64

This generates constraints and gateware, which I've added to my design.

In my design, I've added a simple UDP stream AXI4-S generator, that simply sends a constant, like so:

I do see that the liteeth_core is generating data, but incorrect number of bytes preamble, SFD:

tshark does not see any data at all on the host side.

I've checked my I/O timing constraints and the system meetings timing

Does anyone have any suggestions? Is my config wrong somehow? Does sys clock have to be faster than 50 MHz for RMII ? I would have thought sysclk frequency was independent due to use of internal FIFOs

Thanks for your time!

EDIT: I've since recreated the design on a ZC702 eval board, and have the same results when using the same config file for 100mbps RMII

I've tried different UDP core data_width parameters: 8 (default), 32 and 64 all produce the same elongated preamble/SFD
Note: The deepwiki documentation suggests data_width=16 is possible, but there is a possible legacy documentation there, because gen.py asserts false if data width is != 8,32,64 instead of 8,16,32 like the wiki states

I am now wondering if this is something to do with automatic speed detection via CRS, which I am not currently driving. However, 310 cycles of preamble is not a factor of 10x off, so perhaps this is not the case...