Use the technology specific multiplier implementation when building for a
Xilinx platform.
This isn't understood by yosys so we can't use it when yosys is used for
synthesis.
Signed-off-by: Joel Stanley <joel@jms.id.au>
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.
This commit optionally implements the deficit idle count algorithm as
described by Eric Lynskey of the UNH InterOperability Lab[1]. It may
not have much or any impact in the XGMII simulation when using a TAP
interface, however when connecting this simulation to another the DIC
mechanism is a valuable implementation for both saturating proper
10Gbit/s linerate and validating the LiteEth PHY (XGMII to stream)
converter implementation.
[1]: https://www.iol.unh.edu/sites/default/files/knowledgebase/10gec/10GbE_DIC.pdf
Signed-off-by: Leon Schuermann <leon@is.currently.online>
The previous state of the xgmii_ethernet module did not insert an
inter-frame gap at all. The IFG is mandated as part of the IEEE802.3
specification for Ethernet and as such the module was incorrect.
This fixes the inter-frame gap insertion by keeping track of the IFG
using a counter.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
The xgmii_ethernet module used to represent internal XGMII interface
signals using 64-bit signals. While this is not incorrect per se, it
makes a standards-compliant implementation of the XGMII significantly
harder in the long run. This is because XGMII fundamentally is defined
as a 32-bit bus, and thus has constraints in relation to that bus
width. For example, it is specified that packets may only ever start
on the XGMII lane 0, that is the first octet of a 32-bit XGMII bus
word. Hence, to properly handle a XGMII start of frame control
character using a 64-bit bus representation, the first and fifth octet
would need to be respected, along with shifting data depending on the
start octet.
Hence this change causes the internal XGMII interface to be
represented as a 32-bit bus. Because it is common for FPGAs to
implement the XGMII as a 64-bit bus given the fact that a DDR bus
cannot be represented in an FPGA and 32 bits without DDR would require
a clock frequency of 312.5MHz, it still permits 64-bit operation. This
is implemented by always transmitting two 32-bit bus words back to
back.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
enjoy-digital
Joel Stanley
Andy Kitchen
Ilia Sergachev
Miodrag Milanovic
Leon Schuermann
Gwenhael Goavec-Merou
Mikołaj Sowiński