Hi,

I am an FPGA engineer in charge of developing a test application that must offload a continuous test data stream between host PC and a test hardware. I do not need to set up a network, just a point to point link.

The test hardware must supply with continuous data at max 640 Mbps to the design under test, running in another FPGA based board. I am doubting between UDP and TCP 1Gbps to do this. 

I am new in networking applications, . UDP implementation seems simpler in this test HW, but also have read is more unreliable , packets might be lost and order of delivery might be affected. My question is , does this still hold for a point to point connection? Or should I go for a TCP/IP 1Gbps implementation, which seems more complex to keep up with this 640 Mbps data rate?

Jose

In a point-to-point go for UDP, it is simple and reliable enough; it is only when you travel long distances over switches and ISP that packets and order get lost.

TCP is a lot more work and testing. 

You can find a low-cost package here: https://comblock.com/com5402soft.html I haven't used it, so YMMV

Regards,

Josy

Thanks for the reference , I will check it out...as stated I am more to go after UDP. Will let you know once i start the task (has been de-prioritized now)

Assuming that the data source and PC have no more than one (maybe 2) switch(es) between them UDP is the way to go. You will need to design your own protocol to cope with lost or errored UDPs.

I've done this and it's reasonably simple even on a basic (lattice ECP3) FPGA. A reasonable protocol will be able to ask the PC to resend failed UDPs. It's much easier (lighter load on PC) if you use maximum length (multi fragment) UDPs and I had no problems from doing this.

MK

Thanks. I am thinking in a direct link between a test PC and a suitable FPGA demo board. 

What worries me about retries is that I would not be using this to transmit setup data to the FPGA, but actual signal waveforms to be sent to a DAC. I have a requirement of sending 40 (complex) Msps (at 16 bits) , so its actually above the 1 Gbps (I may drop some degree of interpolation. But honestly, have no idea on how to deal with retries in UDP in a corner case (the time taken by the retry is above the max time length of signal that can be buffered in the FPGA).

will put more thinking on this

Jose

You will almost certainly need buffer memory outside the FPGA. If you design the system to operate at close to or over 1GB/s you are setting yourself to fail. Start with maybe 75% of max wirespeed as a maximum - if you can't achieve that you need a faster link.

40 complex 16 bit samples per second is 1600 Mbits per second - about twice the reasonable capacity of 1Gb Ethernet.

At 75% capacity I would be thinking in terms of a 1 second buffer  - before you start outputting data get the buffer 80% full. The FPGA can demand data - if you are using approx 64kbyte UDPs it can demand maybe 20ms worth  - if they are good and it has space it demands more, if bad it demands them again. If you demand them one at a time you end up with too many control interactions, if you demand too many at a time the re-try gets too expensive.

MK

A bit late of a reply, but anyhow: If it's somewhat predictable data, you could use DPCM compression/Huffman coding and then get by without external (and nasty to implement) DDR RAM buffers.

I'm happily streaming video using standard RTP/UDP at compression rates up to 1:15 without much quality loss. When not close to the full bandwidth, even frequently chatting aliens on the Ethernet don't cause packet UDP packet loss, at least not with a Linux receiver.

When moving towards TCP or bulk USB transfers: that's the case where you won't be able to avoid the buffering. And this also means a lot of work, a simple lwip hack won't do the job.