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>
Otherwise we don't get the DDROutput overrides and the standalone
core fails to generate when using GMII_MII
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
enjoy-digital
Leon Schuermann
David Sawatzke
Benjamin Herrenschmidt