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

Good Day!
I have a question on supporting ICMP and DHCP protocols. Does UDP/IP Stack support such protocols? If Core have no support for those protocols does UDP/IP Stack filters or passes through ICMP and DHCP frames? Also I'm interesting in that what's about compatibility with Artix 7 FPGA's? And I've checked in bug tracking some notes on ARP issues. Does ARP communications are stable and bug fixed now?

ICMP, DHCP support and stability on Artix 7

I'm Using a Spartan-6 board to implement the UDP/IP stack with ISE14.1,the Spartan-6 board does not support 'Trimode Ethernet MAC Wrapper V2.2',but I can use 'Trimode Ethernet MAC V5.3' ,What should I do to properly use your design?
              Thanks

My problems on implementing 1G eth UDP/IP Stack

Hi,
i think i found a little bug in arp_RX.vhd, triggered by a change done 2013-01-14 assuming the comment is correct.

BUG:
Changing the last byte of our_ip-value in testbench (8 instead of 9 for example) will also trigger an ARP-reply due to a bug in ARP_RX.vhd

REASON:
When the incoming ARP is processed in rx_combinatorial (-- RX FSM) of mentioned vhd-file the current data_in is parsed depending on rx_count.
The first check condition was changed from rx_count = 42 to 41 resulting in not using the second if-clause (not_our_arp()), which checks for correct last byte of our_ip when count = 41.

SOLUTION:
Change order of if-clauses to first do a check with not_our_arp() and after that place the check for rx_count = 41.
If the not_our_arp()-check fails the error condition is raised, if the check succeeds, the next if-clause will be choosen, due to rx_count=41, and the ARP is processed.

I'm quite new to the project, so it might be that my solution will have side-effects, which I didn't noticed so far.

ARP fail on checking last own-ip-octet

i am trying to implement 1G_eth udp_ip_stack on vertex-6 board with ise 14.4, but during implementation following error is coming..

logical block 'udp_block/mac_block' with type 'mac_layer_v2_2' could not be resolved..... mac layer v2_2 is not support in vertex -6 board..

how i am proceed furthur..
plzz help

mac_layer issue in vertex-6

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

I ported the UDP/IP stack to a custom Virtex 6 board using an SFP 1000baseX GTX interface.  The board would not respond to ARP requests.  Via ChipScope, I saw that the ARP packets were being received, but the UDP/IP core's responses were not being transmitted.  Further inspection showed that the V6EMAC was keeping tx_axis_mac_tready low, so the ARP module was never setting tx_axis_mac_tvalid high.

Reading UG800 for version 2.2 of the V6EMAC shows that the MAC was behaving as expected (figure 6-8)... tx_axis_mac_tready should go high in response to tx_axis_mac_tvalid going high, and not the other way around.  I implemented the UDP/IP example on an ML605 for comparison, which worked.  It appears that when using a GMII interface (ML605) instead of a GTX interface (my custom board) the V6EMAC core happens to holds tx_axis_mac_tready high in advance, so this bug doesn't show up in the ML605 example.

I can send you modified code that works (arp_tx.vhd and ipv4_tx.vhd needed corrections).

Thanks for contributing a valuable project!

-Greg

MAC ready/valid handshaking

In UDP_TX.vhd you have the line:

next_tx_result (assign) IPTX_RESULT_ERR;

But I think it should be:

next_tx_result (assign) UDPTX_RESULT_ERR;

udp_tx

Hello Peter,

In UDP_TX.vhd you have the code:

when SEND_USER_DATA =>
    udp_tx_data_out_ready <= '1';

However, it seems to me that it should be:

when SEND_USER_DATA =>
    udp_tx_data_out_ready <= ip_tx_data_out_ready;

Otherwise if the ip layer happens not to be ready for data, udp_tx would accept it from the user but unable to forward it to the ip layer.

Of this I'm not sure, it is just something I noticed while going through the code.

Possible bug

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.

Headers sometimes have errors

In the following module, what is the synchroniser? Is it a Xilinx IP?

  ------------------------------------------------------------------------------
  -- Component declaration for the reset synchroniser
  ------------------------------------------------------------------------------
  component reset_sync_v2_2
  port (
     reset_in                   : in  std_logic;    -- Active high asynchronous reset
     enable                     : in  std_logic;
     clk                        : in  std_logic;    -- clock to be sync'ed to
     reset_out                  : out std_logic     -- "Synchronised" reset signal
  );
  end component;

xv6mac_straight implementation issue ...

I could not get it implemented on ML605. I used your xv6mac_straight.vhd module. When I am running the java app, I am not getting any response back. In Wireshark, I could see that ML605 is responding to ARP request, but it is not responding to UDP packets. Any idea, what am I missing? Also, last entry in the ucf file "*mac_bloack/gtx_clk_bufg" error out during mapping. So, I commented out that line. Is it okay? Any help from you is greatly appreciated. 

Thank you.

ML605 project

hello
shekhar here,
i want to use your design in one of my application for data transfer between FPGA(ML605) and PC.
i tried to implement your design using ISE 13.1,i found that you have used "Xilinx LogiCORE IP Virtex-6 FPGA Embedded Tri-Mode Ethernet MAC v2.1".i am trying to add this IP core in design(.XCO file has not been given) but entity of ethernet mac core looks different as u used in the design.i am not able to port map the signals with IP core.
plz send me .XCO file or guide me to proceed.

1G eth UDP/IP development

Hello.  Current version does not handle udp broadcasts, which are sometimes required.  Broadcast tx (ip=255.255.255.255) is not accepted because it is forwarded to arp.vhd and will never get a response.  Broadcast rx is never accepted because it compares dst ip with our ip, and our ip is not 255.255.255.255.  

Arp seems will hang if reply is not received (no timeout).  Not really acceptable in my opinion.

Application case is gigE vision cameras (purely UDP+ARP).  For example, they are discovered by udp broadcasting (ip=255.255.255.255 and mac=FF:FF:FF:FF:FF:FF), and some commands like forcing IP are done via udp broadcast as well.

ARP timeout and UDP broadcast

For the "Virtex-5 FPGA Embedded Tri-Mode Ethernet MAC Wrapper v1.4" in the "Local Link Transmitter Interface" the signals are the next:

 -- Local link Transmitter Interface - EMAC0
      TX_LL_CLOCK_0                   : in  std_logic;
      TX_LL_RESET_0                   : in  std_logic;
      TX_LL_DATA_0                    : in  std_logic_vector(7 downto 0);
      TX_LL_SOF_N_0                   : in  std_logic;
      TX_LL_EOF_N_0                   : in  std_logic;
      TX_LL_SRC_RDY_N_0               : in  std_logic;
      TX_LL_DST_RDY_N_0               : out std_logic;

In the "UDP_Complete_nomac" in the "MAC Transmitter Interface" the signals are the next:

-- MAC Transmitter
mac_tx_tdata  : out  std_logic_vector(7 downto 0); -- data byte to tx
mac_tx_tvalid : out  std_logic;	-- tdata is valid
mac_tx_tready : in std_logic;	-- mac is ready to accept data
mac_tx_tlast  : out  std_logic; -- indicates last byte of frame

So, he lacks a signal for the first byte of the frame (Start of frame) 

Thanks for you project and sorry my bad english !

Browse

1G eth UDP / IP Stack