*** tpb <[email protected]> has joined #litex | 00:00 | |
zyp | I'd expect the last signal to both mark the end of a received packet and terminate a packet to be sent, but I haven't looked to see if it actually works that way | 00:48 |
---|---|---|
rowang077[m] | at least the transmitting from the FPGA gives no control over sending packets. That's hardcoded by the send_level on the tx side. https://github.com/enjoy-digital/liteeth/blob/master/liteeth/frontend/stream.py#L11 | 00:50 |
rowang077[m] | But I don't know enough about the migen/litex to understand what is going on the receive side | 00:50 |
*** Degi_ <[email protected]> has joined #litex | 01:48 | |
*** Degi <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 01:48 | |
*** Degi_ is now known as Degi | 01:48 | |
*** FabM <FabM!~FabM@2a03:d604:103:600:558c:7400:92c9:b7e2> has joined #litex | 06:27 | |
_florent_ | Hi rowang077[m], the LiteEthStream2UDPTX/LiteEthUDP2StreamRX are packetizing/depacketizing the frames to simplify use, so don't give you delimiter control/status. | 07:41 |
_florent_ | to have them, you have to compose/extract the packet with your logic and then work directly with the UDP Port. | 07:42 |
_florent_ | I could however have a look to see if we could support it in LiteEthStream2UDPTX/LiteEthUDP2StreamRX, but that was not the initial aim | 07:42 |
rowang077[m] | @florent Clear! It's not that big of an issue for me right now. Just wanted to make sure for the RX side. | 07:48 |
rowang077[m] | _florent_: This is the right tag :) | 07:49 |
rowang077[m] | The only thing I'm worried about withouth having control over UDP packets is if a packet is lost. Let's say I transmit 1000 bytes "frame". Liteeth will make 2 udp packets out of that (as an example). The header consists of of some kind of packet id and a length. Now the second udp packet is dropped. The application has no way to detect this dropped packet except by adding a crc check. But even then you are now "desynchronized" in some | 08:13 |
rowang077[m] | unpredictable way. | 08:13 |
rowang077[m] | Basically since you have no control over packets you have to thread it as a lossy bytestream. | 08:14 |
rowang077[m] | instead of a lossy packet stream | 08:14 |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 08:20 | |
*** TMM_ <[email protected]> has joined #litex | 08:20 | |
*** MoeIcenowy <MoeIcenowy!~MoeIcenow@2001:19f0:7002:866:c2b3:ebb5:95e:be08> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 09:57 | |
*** MoeIcenowy <[email protected]> has joined #litex | 10:06 | |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 13:44 | |
*** TMM_ <[email protected]> has joined #litex | 13:44 | |
*** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 268 seconds) | 17:09 | |
mithro | _florent_: The University of Washington people behind bjump.org are looking at replacing their FPGA RTL with LiteX -> https://docs.google.com/drawings/d/1iXQW7JOGi_LUP37g6Y4jMcrJRuAju48vB42z3v-9pm4/edit | 19:54 |
tpb | Title: ASIC with FPGA Harness - Google Zeichnungen (at docs.google.com) | 19:54 |
_florent_ | mithro: good choice :) | 20:30 |
_florent_ | rowang077[m]: sorry, I haven't been able to have a look at your questions today, will do tomorrow | 20:30 |
*** xenador77 <xenador77!~xenador77@user/xenador77> has joined #litex | 20:49 | |
*** peeps <peeps!~peepsalot@openscad/peepsalot> has joined #litex | 23:56 | |
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 244 seconds) | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!