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>
To support a simple GMII simulation, skip clock generation and buffer
logic. This allows to operate a GMII interface over sys_clk. Proper
GMII clocking support can still be added in the simulation, this
should work when setting model = False.
It also sets an attribute "model" such that we can avoid adding
Platform constraints in the rest of the ecosystem (such as
litex/litex/soc/integration/soc.py, add_ethernet and add_etherbone).
Signed-off-by: Leon Schuermann <leon@is.currently.online>
Adds support for 64-bit wide XGMII PHYs in LiteEth. A 64-bit wide
XGMII data path is a common method to interconnect multi-gigabit
Ethernet inside FPGAs. This module expects a 64-bit MAC data path,
which is to be added later. It has been tested locally using a
rewritten XGMII module for the LiteX simulator as well as on a KCU116
board.
This work has been inspired by enjoy-digital/liteeth#21 but is
entirely rewritten using Migen FSMs and with respect to
IEEE802.3-2018. Thanks to Florent Kermarrec (@enjoy-digital) and Vamsi
Vytla (@jersey99) for providing the base implementation.
This implementation does not yet support proper 32-bit (DDR) XGMII
PHYs, although support can be easily added by an additional module
which performs the DDR encoding / decoding of the data respectively.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
Since only the reg of the widest engine is needed, the rest can be
removed
reverse_bits is also a bit more readable
The range for the engine data could be removed, but it's more
understandable this way
Per default, the processing should occur with sys_clk and dw, instead of
the phy parameters since it's not that much larger and allows for easier
timing requirements. But on some fpgas saving the few gates could be desirable
On ecp5 `FullMemoryWE` leads to an increase of DP16KD block mem, while
it works better on Intel/Altera devices according to
6c3af746e2.
Simple solution: Make it configurable
Benjamin Herrenschmidt
Florent Kermarrec
Leon Schuermann
David Sawatzke
Anton Blanchard