Problem with test application for UDP/IP Core

[sebblonline]

Hi,

I'm using the UDP/IP Core from opencores.org.
My problem is to realize a best effort transmission from the FPGA to the PC. In the following code snippet I have two processes to transmit constant data. The send process is sending as soon as the destination is ready (ctrl_tx_phase_on=1). With the second process I control the start_enable signal. There I have a built-in delay (with the variable k) between two datagrams. When I leave out the counter k (for a true best effort transfer!) the datagrams are not sent correct any more. In wireshark I can notice, that the length of the data is not correct (length of data < number in length-field).

	send_proc : process (ctrl_clk)
	begin
	if rising_edge(ctrl_clk) then
		if ctrl_reset = '0' then -- global reset
				datagram_length <= MAX_DGRAM_LENGTH;
				if cnt < datagram_length then
					if ctrl_tx_phase_on = '1' then
						dgram_sent <= '0';
						ctrl_tx_data_out <= "01010101";
						cnt <= cnt + 1;
					else
						cnt <= 0;
					end if;
				else
					dgram_sent <= '1';
					cnt <= 0;
				end if;
		end if; -- reset
	end if; --clk
	end process send_proc;

	enable_proc : process(ctrl_clk)--frame_buf_valid, cnt)
		variable i : integer := 0;
		variable k : integer := 0;
	begin
		if rising_edge(ctrl_clk) then
			if dgram_sent = '1' and i = 0 then
				if k < 100000 then
					k := k + 1;
				else
					i := i + 1;
					ctrl_tx_start_enable <= '1';
				end if;
			else
				k := 0;
				i := 0;
				ctrl_tx_start_enable <= '0';
			end if;
		end if;
	end process enable_proc;

Can someone give me a hint, where my mistake actually is or how that kind of functionality is made right?

thanks a lot in advance,
sebastian

 

[lucbra]

I don't think that you enter the first process.

what other devices are connected to the same connection? are you using a router?

Does your PC receive the data when you are using the delay? Have you established the connection between FPGA and PC? Is the header (use Wireshark to check this) correct?

these are just some basic things to check before going deeper

try hooking a chipscope (or similar) to the FPGA

good luck

 

[sebblonline]

as i wrote, the PC always receives data. with the delay, the data is correct, without delay, only the data length is wrong. the header is always right as it is built in the UDP Core where I dont have influence.
the first process is entered because I can see the right data (01010101) in wireshark. the PC and FPGA are directly connected - no router/switch....

sebastian

 

[permute]

make the data transmitted be a counter, except for the first and last elements, which should have different, easily recognizable values. This should allow you to see most common problems, like:
1.) first/last word duplicated
2.) first/last word missing
3.) first/last word at wrong end of packet
4.) first/last word offset into packet
5.) missing data within packet
6.) duplicated data within packet
7.) RAM overflow splices packets together (eg, S 0 1 2 3 0 1 2 3 4 5 6 ... E)
8.) bit errors within data.

the counter can be set up with a max limit, counting from 1 to 253 (or any other value, 253 is just a prime number). The idea is to make each packet somewhat unique in order to catch issues like #7.

 

[lucbra]

The accompanying description of the UDP core states that the EMAC needs about 40 clock cycles before processing the next dgram.

I assume you took this into account?