Gigabit Ethernet UDP/IP

Hello, for a printing application I would like to receive data from a Unix workstation over Gigabit Ethernet (copper) at maximum speed. A first test showed us that today 2 workstations are able to interchange data over GB Ethernet with about 110 MB/s, nearly at the theoretical limits. The receiver should be implemented with an FPGA, put the data into DDR memory and process the data with the same FPGA.

Looking at the Gigabit Reference Design from Xilinx I had the impression that it probably not so easy to go at the limits of the bandwith when the embedded PPC processor handles the protocol. A viable way seems eventually to implement some UDP acceleration, where UDP would also fit the data better, since the data to receive is always made up of packets (lines) ot the same length.

Does anybody have some experience with receiving data at high data rates? Thank you very much for every hint.

Best regards Klaus Falser

R&D Electronics Department Company : Durst Phototechnik AG Vittorio Veneto Str. 59 I-39042 Brixen Voice : +0472/810235 : +0472/810111 FAX : +0472/830980 Email :

Reply to
Klaus Falser
Loading thread data ...

If you use UDP without checksums (they're optional in IPv4 for UDP) then the PPC overhead will be proportional to number of packets (not total data) so if you use a DMA MAC core and jumbo frames you might do fine with a standard network stack. Jumbo frames should be an option if you control the whole network. If you don't, don't expect to get anything like the theoretical maximum out of GigE!

Ben Jackson AD7GD
Reply to
Ben Jackson

The problem with jumbo frames may be the Ethernet switch. I'm not shure if they are supported, but I could check it.

Thanks Klaus

Reply to
Klaus Falser


I have an application here that streams from a PC to a FX60 at 250Mbps. We only use 250 because our application doesn't need more but streaming tests showed we can go a lot higher (>800MBps but we read data from a hdd so this could be the bottleneck).

We're using the Virtex4 embedded MAC and it's connected directly to a hw state machine that handles the protocol on the fly and stores data payload in a FIFO. Another state machine reads from that fifo to a DDR2 bank.

When the FIFO becomes almost full, we send "PAUSE" frames on the ethernet link so the PC stops sending. Since PAUSE frames are handled by the hardware of the network card, the data flow stops almost always at the next packet (some time 1 packet later), but you should just dimension your FIFO and it's afull threshold to handle that.

With this we are sure we didn't loose any packets and we don't need to handle retransmission or whatever.


Reply to
Sylvain Munaut

Can anyone tell me some example to implement an ethernet comunication between PC and FPGA?. I have a .NET app for transmit UDP packets and I want the Spartan 3e to receive it but I don't know how can I do it?. I have probed LWIP, XILNET but I have no idea.

I only want an easy example to receive and transmit.


Reply to

We built a UDP off load engine for a custom data streaming protocol using a PicoBlaze processor on a V4FX, and that worked great for us. It makes a copy of the header as the packet is moved from the EMAC to a fifo, and then has the PicoBlaze inspect the header. If it is packet from the stream we want to offload from the PPC, the PicoBlaze sets up the DMA engine to send it to a circular buffer. If it was anything else, it is just passed on to the PPC and the Linux IP stack deals with it.

This protocol has 1 KB of data and a small header wrapped in UDP, so we are not using jumbo frames, and the PicoBlaze still has plenty of processing power to decide what to do with one packet before the next shows up. We are getting just a bit under 100MB/s. We do not use the PicoBlaze to calculate any checksums. You can either ignore them, or add some hardware to calculate them. The EMAC checks the Ethernet checksum for you.

The PicoBlaze is an absolute gem. We have done many neat things with it.


John McCaskill

formatting link

Reply to
John McCaskill

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.