Fiergolski, Adrian

Fall, Peter

1G eth UDP / IP Stack

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 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

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