If the Builder class is not used to build the projet, platform sources
is still a list of tupples with 4 elements.
For now, we don't handle file copy when Builder is not used but at least
it won't crash.
If a project needs a custom verilator module, it can now
specifies the path where the module's directory is.
SimPlatform can now look for extra modules:
builder.build(
extra_mods = ["mymodule1", "mymodule2"],
extra_mods_path = os.path.abspath(os.getcwd()) + "/modules",
sim_config=sim_config
)
Modules must be subdirectories of extra_mods_path:
.
├── modules
│ ├── mymodule1
│ ├── mymodule2
│ ├── ...
Removes a leftover debug message for validating correct XGMII IFG DIC
behavior. Useful for development, but gets annoying quickly while
running the simulation.
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.
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>
This was removed in
3b78fd928d fhdl/verilog: Remove blocking_assign (not used with LiteX).
However that breaks litedram gen.py which passes regular_comb=False
to all toolchain builders
The rewritten XGMII Ethernet module generates proper frame check
sequences (FCS) on Ethernet frames received by the simulation, such
that the unmodified MAC pipeline including CRC checking can be
used. However, the byte order of the generated frame check sequence
has been inverted. This becomes apparent when one specifies that the
CRC should be calculated in the LiteX BIOS.
This fixes the byte order to be correct. The similar GMII Ethernet
module did not contain this mistake.
Fixes: 7b533a032d ("litex_sim: rewrite XGMII verilator...")
Signed-off-by: Leon Schuermann <leon@is.currently.online>
This renames the `clk_edge_t` struct to `clk_edge_state_t`, given it
only tracks the previous clock edge state.
Furthermore introduce a new `enum clk_edge` (typedef'd to
`clk_edge_t`) which represents all possible clock edges and add a
function (`clk_edge`) to retrieve the type of current clock edge as a
`clk_edge_t`.
Signed-off-by: Leon Schuermann <leon@is.currently.online>