FPGA design - Debugging Gigabit Ethernet Transmissions

[nickagian]

Hi!

I have created a MAC transmitter in a Xilinx Spartan-6 FPGA that is externally connected to a PHY Marvell 88E1111 IC. On the FPGA development board (SP605) there LED indicators for the Ethernet. I have now connected my board with a Zyxel switch (that supports Gigabit ethernet) and from there another cable goes to an Ethernet PCI card (that also supports 1Gbps) on my PC. During my debugging I see the following :
(1) First of all the LEDs on the board indicate that the detected speed is indeed 1Gbps
(2) During transmission, the TX LED on the board that indicates that the PHY IC is transmitting is on, which is correct.
(3) At the same time I also see the corresponding on the switch to blink.
(4) However the switch LED for the PC card never blinks.
(5) And I never get anything in Wireshark.

Could anyone help me locate the problem? What does it mean that the data do not leave the switch for the PC? Is only a matter of CRC error perhaps? Or an error in the IP address? At the MAC field I have actually set the value of all FF's, so that I have a broadcast. So the case of wrong MAC address is not real.

Nikos

 

[lucbra]

If your phy is transmitting, you should be able to see this in wireshark.
What MAC address have you put in your development board? you could filter on this.

What makes you believe that the LEDs on the PC card should blink?

 

[nickagian]

If your phy is transmitting, you should be able to see this in wireshark.

Should I? And what if the CRC I'm transmitting is wrong? Then when would the frame be rejected?

What MAC address have you put in your development board? you could filter on this.

I'm actually seeing all the in/out traffic through the card. So I guess if I received something I would have seen it.

What makes you believe that the LEDs on the PC card should blink?

I'm not sure about that, but isn't it true? If there is incoming traffic, shouldn't the LED of the PC card blink? Actually the card doesn't have LED, I'm talking about the LED of the switch corresponding to the port that the PC is connected.

 

[joelby]

If the CRC is incorrect, or if you're transmitting an IP packet and the IP header checksum is incorrect, some network cards/drivers will drop the packet before it gets far enough up the chain for Wireshark to see it.

It's possible that switches will drop packets with bad CRC/checksums too (particularly managed switches), though I haven't personally tested this. Are you calculating the checksums or have you set these to dummy values too?

 

[nickagian]

If the CRC is incorrect, or if you're transmitting an IP packet and the IP header checksum is incorrect, some network cards/drivers will drop the packet before it gets far enough up the chain for Wireshark to see it.

It's possible that switches will drop packets with bad CRC/checksums too (particularly managed switches), though I haven't personally tested this. Are you calculating the checksums or have you set these to dummy values too?

Yes, I think that this is it. I checked more carefully my CRC and it was not correct, so I guess this must have been the problem. Now it remains to correct the error and re-do the test. It would be interesting to know in the end if the switch dropped those packets with bad CRC. thanks for the tip!

 

[joelby]

Yeah, if you look at port statistics of a managed switch such as a Cisco Catalyst (**broken link removed**, you'll note that it records a couple of different input errors including CRC. I presume that it would (by default - maybe it can be overridden) not forward these frames. If your switch records these sorts of stats it might be helpful to check them, as it's very easy to make small mistakes and send incorrect frames.

Good luck with your debugging!