1G eth UDP / IP Stack

Dear Mr. Fall, i am currently developing a GigE Vision Core and I found the UDP/IP Stack very helpful in my work. However, I have a problem sometimes with the UDP and IP headers (or at least in the header bytes, especially length, I can realize that there is an error somewhere in the UDP/IP Layer or more likely in emac core configuration). Didi you make some special settings in the IODELAY or for MMCM phase shift? Sometimes while receiving stream data from the camera I get UDP lengths of more than x"05c0", which is impossible... I would be very happy if you could give me some hints/suggestions how can I fix this.

You are correct that UDP lengths 0x5c0 should be impossible. The UDP_TX.vhd has the following code:

if unsigned(udp_txi.hdr.data_length) > 1472 then next_tx_result <= UDPTX_RESULT_ERR; set_tx_result <= '1'; else -- start to send UDP header

so while you can get longer eth frame sizes or IP pkt sizes, the UDP length should be max 1472.

There are some settings in the Xilinx V6 EMAC wrapper core that use some IODELAYs. I have not touched these, but maybe they need some adjustment. You are the first to report a problem of this nature.

The problem could be in the UDP stack or could be in the underlying MAC layer. Can you check (eg: with Chipscope) what the data is at the mac_tx_tdata signal of udp_complete_nomac (you might need to set up some fancy triggering). That way it might be easier to see if the error is in the MAC interface layer (I suspect it is more likely to be there than in the UDP stack).

Actually, I just realised that although the max UDP payload size is 1472 (x5c0), the length value transmitted in the UDP header is the UDP payload length + UDP header length, so for a max sized payload, the UDP length will be 1472 + 8 = 1480. Please check that this is is not the issue.

Thank you for the quick reply. I will check the mac data for the receiver. The problem is detected in the receiver...the whole system is strongly relying on the UDP and IP headers and thats why it hangs when they are wrong, that's how I detected that for example the length are wrong sometimes (I used last time the situation when the UDP length is not IP length - 8 as a trigger).

Thank you for the quick reply. I will check the mac data for the receiver. The problem is detected in the receiver...the whole system is strongly relying on the UDP and IP headers and thats why it hangs when they are wrong, that's how I detected that for example the length are wrong sometimes (I used last time the situation when the UDP length is not IP length - 8 as a trigger).

The mistake comes from the emac :) I checked mac_rx_tdata (triggered when mac_rx_tdata = x"45") and i saw that for the packets with faulty UDP or IP lengths, also other bytes can be faulty, like address, port, etc. After that I also checked the gmii_rxd and I got the same results. SO I guess an IODELAY adjustment is required. Hopefully after that the system will be more stable. If not, I have to switch to SGMII, which I would like to avoid .

The solution to the problem was using the axi fifos. I found out that without the fifos there is a possibility of arising of bit errors. I also modified the UCF file (copied the other constraints from the example design) and now it works like a charm. :D

Great! Thanks for the feedback! Could you please email me the files that you modified and I can add them to the project. Many thanks, Peter

Sure, however I dont guarantee that it works for every design (most probably the delays have to be adjusted).

contributed files received from Edit.