Re: Hello, is there an know problem with the 1000Base-X autonegotiation in the PCS_PMA unit of the triple speed ethernet mac ? Best regards, Andre

AHart2 · ‎08-15-2019

The design is compiled with Quartus 16.0 for CYCLONE V SOC with

transceivers

I follow the PCS initialization scheme suggested in the TSE user

manual and have already tried the workaround suggested in

https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/solutions/spr378244.html

but without success

In some cases the link comes up and data can be exchanged when the

switch is fault tolerant enough however a NW traffic analysis shows

that the autoneg does not complete in this case too.

Deshi_Intel · ‎08-16-2019

Hi Andre, I checked the KDB link and I can see below are 2 other factors that may affect TSE auto-negotiation. Feel free to check it out. https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/solutions/rd09082010_546.html https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/solutions/rd02282012_17.html General recommendation is to always try out latest Quartus version as there will be more issue fixed update in latest Quartus version. Thanks. Regards, dlim

AHart2 · ‎08-16-2019

Dear Dlim,

thanks for your reply, that was much faster than I expected !

I have carefully read the articles, for the first KDB answer I can assure that AUTONEG is enabled on

both sides - the PCS and the switch, so this is not causing the issue.

Regarding the second KDB answer ( incorrect device availability advertized ) I'm not sure if this has

been fixed in the current quartus version. The KDB article is dated from 2012 - I have compiled my

design with Quartus 16.0 and also tried 16.1 both without fixing the problem. Is there something

like a list of release notes where I can see which issues have been fixed and which are still open ?

All the best!

Andre

Deshi_Intel · ‎08-16-2019

Hi Andre, There is too many design changes from one Quartus version to another Quartus version. The Quartus release note doc won't be able to track all the low lower design fix detail. Regarding the KDB fix update - Unfortunately this was old 2012 KDB case where the original issue database was already obsolete in Intel and therefore there is no way to track back the exact version that contains the fix. Therefore, I can only recommend to you to upgrade to latest Quartus version like v19.1 or v19.2 if possible. Another thing to check with you is have you completely isolate this is due to auto-negotiation feature issue where there is no concern from board design signal integrity or cable issue ? Eg : like did you disable auto-nego feature and fix the Ethernet speed and everything is working fine ? Eg : or at minimum ensure Ethernet traffic flow is working with TSE internal loopback enable ? Other debug suggestion will be to cross check your design with TSE IP reference design in below link https://fpgacloud.intel.com/devstore/platform/14.0.0/Standard/triple-speed-ethernet/ Thanks. Regards, dlim

AHart2 · ‎08-16-2019

Hi dlim,

thanks for getting back to me.

I will try to upgrade the design to the latest Quartus Version and see what happens,

further I have checked the link without autonegotiation. When I disable AUTONEG

in the PCS and the switch port my board is connected to I can estalish a connection

and exchange data, so this problem seems to be only related to the autoneg process

but not the data exchange itself.

Best regards,

Andre

AHart2 · ‎08-19-2019

Hi Dlim,

meanwhile I have also compliled the design with QUARTUS 18.1 i.e. the latest prime version that is

available ( the lite edition ). I have checked the version register of the PCS core and found that it has

been changed from 0x1000 to 0x1201 so the IP core is a newer version however the autoneg does

not work either. Only thing that makes the 1000Base-X link work properly is disabling the autoneg

on both sides ( i.e. PCS and switch ) of the connection.

Best regards,

Andre

Deshi_Intel · ‎08-19-2019

HI Andre,

The other possibility that I can think off that may affect TSE auto-nego functionality is whether user configure all the required register setting correctly.

Have you cross check your TSE design register setting vs the TSE reference design link that I shared with you earlier ?

Attached are some of the register setting that's related to TSE auto-negotiation feature. KIndly review to ensure you set them correctly.

Thanks.

Regards,

dlim

AHart2 · ‎08-19-2019

Hi Dlim,

sorry I forgot to tell you that I'm not using the TSE MAC but have connected the PCS/PMA to a

CYCLONE V SOC HPS MAC using an appropriate bridging system - of course data between the

clock domains is properly synchronized using FIFO units. As far as I understand the MAC itself

is not involved in the AUTONEG process, this is solely carried out by the PCS/PMA. I'm using

this configuration also in SGMII mode, means the SGMII bridge is enabled. In the SGMII mode

autonegotiation between PCS and the PHY device is carried out properly. However in 1000Base-X

mode the AUTONEG is never carried out properly even whith those switches that connect to

the PCS I can see that AUTONEG process in 1000 Base-X mode is multiply repeated and

the sniffing device that listens on the optical connection shows messages like 'malformed packets'.

Obviously some end devices ( switches ) are tolerant enough to deal with this and some are not.

In the latter case I can see that the end device simply does not accept the initial autoneg sequence

( /C/ with dev_availability set to 0x00 ).

When the AUTONEG is turned off on both sides, the 1000Base-X works properly.

If there is a way to debug this via JTAG/Signal Tap connection I will try this next, maybe

this video gives some information.

https://www.youtube.com/watch?v=LKMNAmFLtEg

Best regards,

Andre

Deshi_Intel · ‎08-21-2019

Hi Andre,

Thanks for sharing the debug video. Yup, that's indeed helpful and hopefully you are following the debug checklist accordingly.

Your understanding is also correct that auto-negotiation is handled at TSE PCS level and not in MAC.

I presume you are using TSE IP with "1000 BASE-X/SGMII PCS only" setting option.

As you mentioned SGMII mode Auto-nego is working correctly and issue only impact 1000 BASE X mode, I believed there shouldn't be issue with your board system and most likely should be TSE register setting issue.

Just wonder have you cross check your TSE IP setting in 1000 BASE X mode ? Attached is TSE setting screenshot from the youtube video and I previously also screenshot the register address location to you. SGMII mode is using different setting from 1000 BASE X mode.

I would only advise to look into Auto-negotiation operation signal_tap after you verify all register setting is correct first. I can see that the video did taught user on how to signal_tap the signals accordingly

Thanks.

Regards,

dlim

Deshi_Intel · ‎08-21-2019

Also, don't confused auto-negotiation PHY mode and MAC mode with actual TSE MAC design block.

there are two auto-negotiation setting - PHY mode and MAC mode

PHY mode = the speed and duplex mode of Intel FPGA and external device will be resolved based on the value set in the dev_ability register. Meaning PHY mode is for advertise the link speed and duplex mode to the link partner

MAC mode is wait for the link speed and duplex mode from link partner and then resolve based on the link_partner ability register.

Thanks.

AHart2 · ‎08-23-2019

Hi dlim,

my design is in a CYCLONE V SOC, the PCS/PMA block is used to connect the HPS Ethernet MAC ( not the TSE MAC ) to

a fibre or copper SFP. Connections are made using appropriate clock bridges. When a connection can be established

the data exchanges works fine even at high rates so I do not think the problem is here. I have identified the problem

exists only in 1000Base-X mode when autoneg is enabled on both sides. In some cases this connection may work

depending on how tolerant the switch handles autoneg, in some it does not. THE PCS/PMA block is configured to

operate in MAC mode but actually this only applies to SGMII which is causing no problems.

I follow the initialization schemes given in the Manual. Further I have tried all the Erratas I could find about this.

When I disable AUTONEG on both sides the connection can be established without problems in 1000Base-X mode

( 1000Base-T is not affected anyway as it is using SGMII ). I have compiled the design with the latest quartus lite

version 18.1 lite and tried again but the result is the same. Of course I have deleted all the databased and generated

the IP cores with the latest version to rule out there's some old data used in the new compilation then.

Further I have sniffed into the data sent coming out of the 8b10b encoder and sent to the transceiver without finding

abnormal data transmitted. Please see attachment for a screen shot - autoneg sequence starts with /C/ 0x00 as required.

We're abbout to procure a Network tester that allows sniffing the data on the fibre lines and tracking the autoneg process,

I'll get back to you when we have done this. For the time beeing I'll disable the autoneg in 1000Base-X mode and set

the link to fixed speed as a workaround. Of course it would be nice to find out what is really going wrong here.

How shall we proceed, shall we close this case and shall I ask to re-open it when I'm able to do deeper debugging ?

Thanks for for your kind support and for beeing patient with us!

Best regards,

Andre

Deshi_Intel · ‎08-23-2019

HI Andre,

Thanks for providing more info. Hopefully you are able to proceed with your project development using the fix speed workaround method.

Yup, it never looks good to keep the case idle for too long. I can close this forum case first.

Once you gather enough debug info, then you can always file new case in this Intel forum again in future.

Thanks.

Regards,

dlim

AHart2 · ‎08-23-2019

Hi dlim,

OK, thanks again for your support!

Please close this case for now.

All the best,

Andre