Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Driving copper and optical SFP using Ethrenet cores

Status
Not open for further replies.

zakhar

Newbie level 6
Joined
Apr 12, 2018
Messages
11
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
105
Hi,

I have implemented two Ethernet links using Xilinx's 1G Tri Mode Ethernet MAC and 1G Ethernet PCS/PMA cores on a Kintex-7 FPGA. The board on which I have implemented the design has two SFP cages on one quad.

The links work fine when I connect them to an Ethernet switch via copper SFP modules. However, when I use optical SFP modules, the links of the switch does not come up. Actually, the LED of the switch that indicates an active link is turned on every 3 seconds for a very short time and then is turned off.
When I connect a port of the switch to its another port using the same optical SFP modules, the switch links come up. So, the problem is not due to the switch configurations and the SFP modules.


Could you please help me to resolve this strange problem? As far as I know, the type of SFP transceiver must not be important!
 

The optical SFP modules need several signals that aren't used/connected in copper SFP modules.

Tx and Rx power must be provided on separate pins. Your board may have the power pins controlled by a logical signal.
The logical signals TxDisable and RateSelect must be correct.
 
  • Like
Reactions: zakhar

    zakhar

    Points: 2
    Helpful Answer Positive Rating
The optical SFP modules need several signals that aren't used/connected in copper SFP modules.

Tx and Rx power must be provided on separate pins. Your board may have the power pins controlled by a logical signal.
The logical signals TxDisable and RateSelect must be correct.

Thank you @std_match

This is the schematic of the board I have designed. I have left RS0 and RS1 unconnected. When I insert an optical SFP module, RS1 is internally connected to GND (I tested it using a multi meter). However, RS0 seems to be unconnected. I am using a Cisco SFP module which does not have a datasheet. However, RS0 is unused in the datasheets of other SFP modules I have found in the Internet. Also, I have connected TxDisable directly to GND.


sfp.JPG
 

Where are the Tx and Rx power connections? Pins 15 and 16 on the SFP module.

You should probably connect pin 7 to a high level.
 
  • Like
Reactions: zakhar

    zakhar

    Points: 2
    Helpful Answer Positive Rating
Where are the Tx and Rx power connections? Pins 15 and 16 on the SFP module.

You should probably connect pin 7 to a high level.

The schematic of the power section is attached to this post. Actually, I am using a 2*4 stacked SFP/connector cage. I will test the point you mentioned regarding pin 7. However, it should also be noted when I implement IBERT core and connect two ports of the board to each other using the optical SFP modules, the IBERT link comes up and shows a good eye diagram.
sfp2.JPG
 

It wasn't due to pin 7 (RS0) and RS1. I pulled up each of them, but the link didn't come up again.
 

Last edited:
  • Like
Reactions: zakhar

    zakhar

    Points: 2
    Helpful Answer Positive Rating
If IBERT works the SFP signals are probably OK.
You should now change the GTX RX equalizer mode from DFE (default) to LPM.
The 8B/10B coding of the ethernet link does not guarantee enough randomness of the data for the DFE mode to be stable in all circumstances.

http://www.xilinx.com/support/answers/61695.html
http://www.xilinx.com/support/answers/56894.html

Could you please explain more? Do I need to change something in the PCS/PMA core? Does it downgrade the link's effective speed?
 

This is a hardware setting inside the GTX transceiver. Search for the RXLPMEN port in the GTX transceiver instantiation.
Then follow that signal as high as possible in the hierarchy and do the change there.

If you are lucky, they have now implemented some support in the wizards to change this signal. The default DFE mode is not good when you use SFP modules close to the FPGA.

The line speed is not affected by changing to LPM mode.
 
  • Like
Reactions: zakhar

    zakhar

    Points: 2
    Helpful Answer Positive Rating
the IBERT link comes up and shows a good eye diagram.

If IBERT work fine, then view IBERT project sources MGT signal settings and compare it with yours.

Also check if you get link up between your board and the switch when you have IBERT project on your board.
It should go up, but of course BER will be very high due to switch don't generate test patterns appropriate for IBERT.
 
Last edited:
  • Like
Reactions: zakhar

    zakhar

    Points: 2
    Helpful Answer Positive Rating
Search for the RXLPMEN port in the GTX transceiver instantiation.
Unfortunately, I couldn't find the port! :sad:

If you are lucky, they have now implemented some support in the wizards to change this signal. The default DFE mode is not good when you use SFP modules close to the FPGA.
It is not supported in the wizard of PCS/PMA core.
What do you mean by "SFP modules close to the FPGA"? If it is regarding PCB layout, yes it is! The SFP connector is very close to the FPGA in my board. I thought making the distance as close as possible is the best PCB layout!


Also check if you get link up between your board and the switch when you have IBERT project on your board.
It should go up, but of course BER will be very high due to switch don't generate test patterns appropriate for IBERT.
The link doesn't go up! Even, the link LED of the switch remains completely off. I think it is due to that the IBERT does not use a MAC core. Isn't it?


I am doubtful about the MAC core I am using, especially the auto negotiation. I think something is wrong with the MAC core, since the link LED of the switch is turned on and off every about 3 seconds.
 

Unfortunately, I couldn't find the port! :sad:
It is not supported in the wizard of PCS/PMA core.
Maybe you can run a wizard for only the GTX transceiver and then compare the generated files with your current files.
It was a few years since I worked with this, and at that time the wizards had no support for LPM mode. A comment at this link suggests that you still have to make manual changes:
http://www.xilinx.com/support/answers/61695.html

What do you mean by "SFP modules close to the FPGA"? If it is regarding PCB layout, yes it is! The SFP connector is very close to the FPGA in my board. I thought making the distance as close as possible is the best PCB layout!
Yes, it is best to have short distances, but the DFE mode is intended for lossy channels with a high-frequency roll-off. In your case, the LPM mode is the right choice.



The link doesn't go up! Even, the link LED of the switch remains completely off. I think it is due to that the IBERT does not use a MAC core. Isn't it?
I am doubtful about the MAC core I am using, especially the auto negotiation. I think something is wrong with the MAC core, since the link LED of the switch is turned on and off every about 3 seconds.
It is possible that you have some other problem, but you should change to LPM mode anyway.
You can try to get the DFE mode to work by making sure that a lot of data is sent to your unit (DFE/LPM is only affecting the receive channel).
Send a lot of UDP broadcast data thru the switch, or set the port to mirror traffic on other heaviliy loaded ports. If the link goes up when "random" data is sent to your device, the DFE mode is the problem.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top