* 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.
This is required to support 64-bit wide data paths using the automatic
Wishbone bus width conversion as discussed in
enjoy-digital/liteeth#75. Otherwise, if the MAC data width deviates
from the 32-bit default set previously, received and transmitted
packets will be broken.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
This is in line with other components of the LiteEth repository using
the `last_be` data qualifier. It is unexpected for last_be to be
asserted on any data word other than the last (i.e. only when `last`
is also asserted). In particular it can confuse the Packetizer and
cause it to pass through `last_be` on words other than the last as
well. This then irritates some parts of the MAC pipeline.
With these changes, ARP works on a 64-bit wide data path (with the
{Dep,P}acketizer changes integrated into LiteX).
Signed-off-by: Leon Schuermann <leon@is.currently.online>
Florent Kermarrec
Franck Jullien
Michael Betz
Leon Schuermann
David Sawatzke