Fiergolski, Adrian

Fall, Peter

1G eth UDP / IP Stack

I haven't tested this yet, but reviewing the code in IPv4_RX.vhd, when in state IP_HDR, if rx_count is at the point of checking the DEST_IP_ADDR (ie, between the count of x"0010" and x"0013"), if the ip_addr byte is = x"FF" in any of these, but otherwise matches at least one byte of "our_ip_address", then the packet will be accepted erroneously (again I haven't verified this, this is just by review). 

There appears to be code below in this state which was commented out by someone that when rx_count = x"0013" it verified a full match on the dest_ip_address to be either matching our_ip_address or broadcast. It seems to be more correct than whats there now.

IPv4_RX.vhd erroneously accepts if any part of IP address is 0xff

Hi! Thanks a lot to the developer of the 1G UDP/IP stack. It works well and was easy to integrate.

However, I found an issue which could lead to a wrong first byte of the TX IP frame (destination MAC address). It also seems to depend on the implementation of the TEMAC. I tested it with Xilinx XCVU9P-L2FLGA2104E FPGA and tri_mode_ethernet_mac v9.0 (axi_ethernet v7.1 IP).

In IPv4_TX.vhd, sending the TX IP frame starts in state SEND_ETH_HDR. When entering this state, mac_data_valid is asserted to indicate that data is there. However, mac_data_out has no valid data yet because the assignment occurs only when mac_data_out_ready is asserted. In my case, the TEMAC still propagated this wrong first byte although mac_data_out_ready was not valid in the beginning.

That's why I suggest to always assign the correct value to mac_data_out and only use mac_data_out_ready to calculate the next state in the TX FSM. Here is the new code snippet I propose for the state SEND_ETH_HDR in IPv4_TX.vhd:

    when SEND_ETH_HDR =>
        ip_tx_data_out_ready <= '0';  -- in this state, we are unable to accept user data for tx
        if mac_data_out_ready = '1' then
            if tx_count < x"00d" then
                tx_count_mode <= INCR;
            elsif tx_count = x"00d" then
                tx_count_mode <= RST;
                next_tx_state <= SEND_IP_HDR;
                set_tx_state  <= '1';
            else
                -- shouldnt get here - handle as error
                next_tx_result <= IPTX_RESULT_ERR;
                set_tx_result  <= '1';
                next_tx_state  <= IDLE;
                set_tx_state   <= '1';
            end if;
        end if;
        case tx_count is
            when x"000" =>
                mac_data_out_first <= mac_data_out_ready;
                tx_data            <= tx_mac (47 downto 40);  -- trg = mac from ARP lookup
            when x"001" => tx_data <= tx_mac (39 downto 32);
            when x"002" => tx_data <= tx_mac (31 downto 24);
            when x"003" => tx_data <= tx_mac (23 downto 16);
            when x"004" => tx_data <= tx_mac (15 downto 8);
            when x"005" => tx_data <= tx_mac (7 downto 0);
            when x"006" => tx_data <= our_mac_address (47 downto 40);  -- src = our mac
            when x"007" => tx_data <= our_mac_address (39 downto 32);
            when x"008" => tx_data <= our_mac_address (31 downto 24);
            when x"009" => tx_data <= our_mac_address (23 downto 16);
            when x"00a" => tx_data <= our_mac_address (15 downto 8);
            when x"00b" => tx_data <= our_mac_address (7 downto 0);
            when x"00c" => tx_data <= x"08";  -- pkt type = 0800 : IP                                         
            when x"00d" => tx_data <= x"00";
            when others => tx_data <= x"00";
        end case;

IP TX ready/valid issue

i am trying to implement udp_ip_core(downloaded from here) in virtex5 lx50t board,
in this project, implementation of gmii interface has been done, but in the userguide of this board, no pins were specifed  for GMII instead they have given for SGMII interface.
please guide me further hwo to proceed...

or fully running, ethernet code would be highly appreciated...

thanks in advance...

in virtex 5 lx50t

I have a few questions about synchronization between tx_clk and rx_clk:

1. arp_req_req.lookup_req is launched by tx_clk in IPv4_tx.vhd, and it only keeps for one tx_clk cycle. arp_req_req.lookup_req is latched by rx_clk in arp_req.vhd, i'm not sure if this signal can be correctly latched since tx_clk and rx_clk are asynchronous. 

2.  This is a part of arp_sync.vhd:     
        case ip_entry_state is
          when IDLE =>
            if arp_nwk_req.req = '1' then
              ip_entry_reg   <= arp_nwk_req.ip;
              ip_entry_state <= HOLD1;
            else
              ip_entry_reg   <= ip_entry_reg;
              ip_entry_state <= IDLE;
            end if;

   Similarly, arp_nwk_req is launched by rx_clk, and latched by tx_clk. when arp_nwk_req.req = '1', arp_nwk_req.ip may not be valid for rx_clk.

arp_sync

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.

Browse

1G eth UDP / IP Stack