19:22 <Brinx> Hello all. Quick question: does the current version of LiteEth support a clock < 125 MHz for interfacing with a standalone UDP core?

19:25 <leons> I’d believe it does, do you have 100Mbit/s or 1Gbit/s? And if not, that’s easy enough to fix, just insert a CDC and a PacketFifo in the path

19:25 <leons> You can also increase the data path width

19:27 <leons> Of course your design is going to have to use a clock at the native clock frequency at the PHY, the question is just where you do the CDC and whether you’re fine with throwing away packets if they’d exceed your target clock domain + data width bandwidth or you’d like to increase the data width proportional to the clock frequency decrease

19:28 <Brinx> Alright, thank you. I am using the ECP5 Versa board, and when I use the 125 MHz clock it can't quite make it work.

19:28 <Brinx> but there is a --timing-allow-fail setting for nextpnr I can apparently use. I'd just like it to be clean :)

19:29 <leons> Yeah, I believe for that chip precisely we worked on getting wider data paths supported

22:17 <Brinx> Excellent, I'm getting data through now. I see something odd, though: I have set the FIFO depth to 128 words (4-byte words) for a length of 512 bytes. But the UDP payloads I get are 516 bytes long.

22:18 <Brinx> If I set the FIFO depth to one less (127), the packets have the correct payload length but their FCS are no longer correct (as reported by Wireshark). I also no longer see them appear in my simple UDP receiver anymore in that case.

22:19 <Brinx> (all this is 1000BASE-T, if that matters)