Data corruption at 1G Ethernet with SGMII interface

barco2 · ‎02-13-2009

Hi,

I have implemented the example design of the Virtex-6 TEMAC on an ML605 board using the SGMII interface to the Marvell 80E1111 Phy.

When running at 10Base-T or 100Base-T speed everything works fine. But when auto-negotiating to 1000Base-T I see only corrupted ethernet frames being transmitted. Further investigation showed each data byte is transferred twice. This can also been seen on the SGMII tx-port, so the data is already corrupt when leaving the TEMAC.

Does anybody know this error?

Did anybody successfully use the V6TEMAC at Gigabit speed with SGMII?

Regards

Martin

barco2 · ‎02-13-2009

With GMII there is the same issue, so it is not related to the interface.

Thus let me rephrase my question: Did anybody successfully implement the V6TEMAC at Gigabit line rate? BTW, I use the V6TEMAC wrapper version 2.1

Regards

Martin

ejanney · ‎04-16-2008

This XAPP uses the V6TEMAC targetting the ML605 with both tri-speed GMII and SGMII interfaces:

http://www.xilinx.com/support/documentation/application_notes/xapp1144.pdf

barco2 · ‎02-13-2009

The XAPP1144 example design works for me at 1G speed. However, this design does not use the AXI version of the TEMAC wrapper, but the old LocalLink interface. I can see the desribed problem only when implementing the example design which is generated with the new 2.x versions of the wrapper with AXI interface. I will further debug this and eventually open a support webcase. BTW, in simulation all works fine...

Regards

Martin

barco2 · ‎02-13-2009

Hi folks,

found the problem. An invalid setting of the speed configuration causes this behavior. When implementing the example design the lowest two bits of the SW1 DIP switch are used for speed selection: 00 is 10M, 01 is 100M, 10 is 1G. Setting this to the invalid setting 11 gives you a succesful link, because for the PHY configuration this is treated identical to the setting 10. But for the MAC configuration this is invalid and gives the behavior I have seen.

Thus, it was simply a configuration fault, not an TEMAC failure.

Regards