Communication between PC and Atlys board via ethrnet

[Taki_comp]

Hi guys,

I am trying to create a loop between FPGA and pc to transmit an receive raw ethernet frame, I found a vhdl implementation of ethernet MAC core in https://github.com/pkerling/ethernet_mac. Any ideas how to test the system ?

 

[barry]

Send some data and see if you receive the same data?

 

[dpaul]

See the Xilinx TEMAC example design. You will get an idea how to test it.
Perhaps you can also adapt the the xilinx test-bench for this GitHub MAC core.

 

[Taki_comp]

Send some data and see if you receive the same data?

Very smart answer, my question is how to do that ?

 

[barry]

Very smart answer, my question is how to do that ?

Well, since I know exactly nothing about your system that's the best answer you're going to get. I know you have an FPGA and a pc, that's not a lot of information.

 

[vGoodtimes]

First, example designs are best for this purpose. There are exceptions for RGMII. SGMII can also be weird in some cases.

Ethernet is a "plesiosynchronous" system -- each device generates its own TX clock and regenerates the RX clock of the device it is connected to. In some cases, this might be performed by an upstream device.

For a loopback on the FPGA, the external PHY might have various loopback options. you can look into using them if desired. The first thing to look for is a link with the PHY. This allows you to determine if you have other issues, typically pins that hold the PHY in reset or "coma" mode or otherwise do not configure the PHY to "just work". Likewise you can see if the link runs in the correct mode.

The next part to monitor is the interface between the FPGA and the PHY. RGMII and SGMII present additional challenges that might make a reference design invalid for some HW.

At this point, the packet reaches the MAC. The MAC has some error detection capabilities.

After the MAC, the packet goes to a RX fifo or a RX packet fifo. There are design decisions here based on what properties you want the interface to have. Normally packets are denoted by a contiguous grouping of valid data cycles which are actually valid. A basic clock domain crossing violates both as the clock rate difference can result in occasional invalid cycles between valid cycles. This may not show up in prototype testing based on which side's clock is faster. Applications that don't need low buffering/latency benefit from a fifo design that can also drop packets denoted as invalid. This is useful as it moves error handling into a single infrastructure module vs a processing module. The implementation can either use a fast-drop (change of pointer) or a slow drop (read entire packet from fifo, but don't mark data as valid).

Now the data is in the TX clock domain (or system clock domain) and can be processed. For a loopback, there is no processing other than to retransmit the packet. If the data goes to a system clock domain vs a tx clock domain, a packet fifo would be required to get the packet back onto the tx clock domain. The basic loopback doesn't need this, but a practical design loopback might benefit from testing this as well. Likewise if the RX fifo is very shallow another fifo might be needed to avoid underflow.

This data now goes into the MAC TX side, which might have some error reporting. From there you can look at the GMII interface to see if "error" is ever set. Then it goes to the PHY, then to the network.

At this point, raw packets can be looped back. However, the device will not respond to ARP, does not have an IP address, and does not have an ICMP processor to correctly reply to pings. These can be implemented in FPGA FSM's as they are simple.