09-11-2017 03:35 PM
We are now trying to use vc709 as a NIC in a computer system. Now we use the xilinx offered reference design with no modification. We sent the bitstream xilinx provided to the fpga and used the default driver in application mode. We connect the port 0 with 1, 2 with 3 by optic cables.
Here comes the problem. On the PC, when we try to ping the port 1 from port 0 using "ping -I eth0 10.50.1.1", we failed and it said "from 10.50.0.1 destination host unreachable". After further test by tcpdump we found that the arp broadcast message had been sent from port0 and been received by port1, but there was no more message.
We have been struggling in this problem for several weeks. We assume that there is no problem with the board, driver and reference design. So does anyone know the problem or have anyone succeeded in doing this? Should we modify some setting on PC or something else? thanks
09-11-2017 04:23 PM
@diannaodanshi What is running on the VC709? Linux?
Something has to respond to the ARP packet tying the MAC address of your card to the IP you sent the ping to.
09-11-2017 04:33 PM
Nothing other than the NIC reference design is running on the board. And there is no reply to the arp request
09-11-2017 05:24 PM
@diannaodanshi Looking at the TRD it looks like all packets are forwarded to the host, which handles ARP.
You should be able to debug all this using standard Linux tools.
Did you check all the LEDs in page 18?
You also seem to have plenty of debug tools in the TRD GUI. Be sure to use it. Are you seeing any packets at all coming?
09-12-2017 02:17 PM
actually we have checked the status of the led and all of them work correctly.
In both of the performance modes we can see the packets sent and received correctly by the different ports from the TRD GUI. But things go wrong when it comes to the application mode(no peer to peer).
09-12-2017 04:15 PM - edited 09-12-2017 04:16 PM
I am not familiar with the "software driver" that is provided in the TRD but does it create a network interface?
If so then the problem is of a strict linux configuration and you should be able to intercept the packets with system utilities like tcpdump.
09-12-2017 04:38 PM
well, we have tried tcpdump. on this side of sending data, we can see the request of arp(with a length of 28). and on the side of receiving data, we may also see the request(but with a length of 46), and there is no reply message.
09-12-2017 07:40 PM
@diannaodanshi If you are seeing the incoming ARP request but there is no answer, that might be the Linux kernel on your side.
I am not sure about the driver you have - perhaps it is just a low level packet handler? Perhaps it does not implement a full network kernel module so Linux is never aware of that interface and does not handle the ARP requests. In this case, this is normal.
09-12-2017 07:45 PM
I do not get a deep insight of the driver because I just use the one xilinx provided as default. But there is such a possibility. Anyway, thanks for your answer.
09-13-2017 04:20 PM
after some more experiment, we find that the receive-side can receive the broadcast from the send-side, but not the uni-cast, even if we configure the arp address manually. So is there any possibility that there is some thing wrong with the mac address configuration in the hardware?
09-19-2017 12:03 PM
After further digging into this problem, now we are sure that the problem roots from MAC address configuration of the VC709 NIC interfaces. As explained in the last post, we can receive broadcast packets at the interfaces (destination MAC set to "FF:FF:FF:FF:FF:FF") but we fail to receive any unicast packet (destination MAC set to the destination interface MAC address). Inside the driver, when I set the destination MAC address of all outgoing packets to "FF:FF:FF:FF:FF:FF", then I can ping the interfaces without any issue.
Does anybody have any clue regarding this problem? It seems that for some reasons, the 10GbE IP core drops incoming packets that has destination MAC set to something other than broadcast.