Pass through last_be or create a new one based on the length if needed
Initialize count at dw//8 and don't subtract source_length since it
could lead to underflow for very short packets. In case source.length is
not dw aligned, count will not be equal, so adjust comparison for that.
Crib last_be Case lookup from mac/sram.py
* only send a ping reply to type 8 (ping request) packets
* otherwise liteeth would send a ping reply to
`destination unreachable` packets too, which is not wanted
Removes a slightly inappropriately named VCD dump created by the XGMII
tests which may or may not have been a result of some frustration
during the test implementation. :)
Fixes: 8da0423f64 ("Add XGMII PHY tests based on captured ...")
Signed-off-by: Leon Schuermann <leon@is.currently.online>
Support passing a stop_cond function which can cause the
stream_collector to exit on a user-defined condition.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
Because XGMII only allows start of frame characters to be placed on
lane 0 (first octet in a 32-bit XGMII bus word), when a packet's
length % 4 != 0, we can't transmit exactly 12 XGMII idle characters
inter-frame gap (the XGMII end of frame character counts towards the
inter-frame gap, while start of frame does not). Given we are required
to transmit a minimum of 12 bytes IFG, it's allowed to send packet
length % 4 bytes additional IFG bytes. However this would waste
precious bandwidth transmitting these characters.
Thus, 10Gbit/s Ethernet and above allow using the deficit idle count
mechanism. It allows to delete some idle characters, as long as an
average count of >= 12 bytes IFG is maintained. This is to be
implemented as a two bit counter as specified in IEEE802.3-2018,
section four, 46.3.1.4 Start control character alignment.
In practice, the previous implementation of the LiteEthPHYXGMIITX made
these issues even more prevalent: because the internal stream
interface is 64-bit wide and stream transactions always start aligned
to the first octet in a bus word, the previous primitive TX
implementation always started transmission on the first octet in the
64-bit XGMII bus word. The IFG inserter operated independently if the
PHY and thus made sure to maintain 12 bytes of IFG on the 64-bit
stream bus. This means that in a worst case scenario, the IFG could
grow to 23 octets. In applications such as Ethernet switches, the
consequences would be frequent buffer overruns or corrupt
transmissions.
Hence this commit introduces a IFG inserter in the LiteEthPHYXGMIITX
module itself. It is significantly more complex compared to the gap
inserter, but inserts the smallest legal gap as defined by
IEEE802.3. Furthermore, it optionally implements the deficit idle
count algorithm as described by Eric Lynskey of the UNH
InterOperability Lab1 to achieve an average IFG of 12 bytes.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
Based on @Based on @david-sawatzke's analysis:
"Otherwise, depending on the caching in the path, a deadlock might occur due to the rx path being
blocked by the tx path, being blocked by the arp request, for which the answers get dropped in the
rx path."
This appears to fix some errors encountered during sending and
receiving of packets where sink.valid dropped to zero immediately
after last and the last_be overflowed onto the current bus word.
It turns out that the last_be FSM's changes to source.last are not
respected by the main FSM due to the way assignments to registers in
procedural blocks work on Verilog.
This introduces a selector for which last signal to use, goverened by
the last_be FSM.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
Co-authored-by: David Sawatzke <d-git@sawatzke.dev>
Also move test_stream/test_packet.
This allow keeping last_be (that will be replaced in the future) self-contained to LiteEth and will
also simplify the rework on Packetizer/Depacketizer in LiteX, application in LitePCIe and
future rework/application in LiteEth.
Florent Kermarrec
Ilia Sergachev
David Sawatzke
Franck Jullien
Michael Betz
Leon Schuermann