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>
- Improve signal names.
- Use re on memories to simplify addressing (still need to anticipate read by 1 cycle).
Also do minor cleanups to LiteEthMACSRAMWriter.
LiteX integration is already able to automatically convert bus data-width: When adding a 64-bit peripheral
to 32-bit SoC, the adapters will automatically be inserted.
When SRAM dw is 64-bit for a 32-bit SoC, automatic convertion can be seen in the build log:
INFO:SoCBusHandler:ethmac Region allocated at Origin: 0x80000000, Size: 0x00002000, Mode: RW, Cached: False Linker: False.
INFO:SoCBusHandler:ethmac Bus converted from Wishbone 64-bit to Wishbone 32-bit.
INFO:SoCBusHandler:ethmac added as Bus Slave.
INFO:SoCIRQHandler:ethmac IRQ allocated at Location 2.
Also fix copyright order.
Adds a wishbone.Converter between the SRAM Wishbone slave and the
wishbone.Decoder connected to the SoC bus, to support SRAM data widths
larger than the system bus Wishbone data width. This is important to
be able to run a 32-bit SoC with a 64-bit MAC data path and SRAM
storage.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
This removes various assumptions about having a 32 bit data width in
the SRAM module. Especially the last_be encoding and decoding have
been seperated into a module, which generates the one-hot encodings
and decodings on the fly.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
They aren't strictly necessary, especially since the MAC can have
a wider data path and thus cope with running slightly slower
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Florent Kermarrec
David Sawatzke
Leon Schuermann
Benjamin Herrenschmidt