cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
joe2008
Visitor
Visitor
9,027 Views
Registered: ‎06-02-2014

GTP IBERT unexpected behavior on a custom board

Jump to solution

In my university, I recently started working with GTP, first on SP605 and now on a custom made board.

 

The board has a Spartan-6 XC6SLX150T (-2 grade). Two of its GTP duals (X0Y0, X1Y0) connect to four SATA connectors, two of which has their TX and RX switched for convenience. A 125MHz reference clock is connected to each dual and a 200MHz clock is available.

 

I was told there were issues with running GTP so I decided to take a look. This Spartan-6 should allow speeds upto 2.7Gbps. Working with IBERT, at the speeds of 1Gbps and 2Gbps, everything works perfectly. Loopbacks work with no errors and two GTPs can communicate with zero errors.

 

Going up to 2.5Gbps, the link starts going ON and OFF sporadically. It takes upping the swing voltage a bit to get the link to stabalize and even then the BER is around 10^-3. Looping the PCS gave no errors but looping the PMA caused also a BER of around 10^-3.

 

I thought that it was the high speed, so I tested frequencies between 1 and 2Gbps (1.25 and 1.5625), but the result was worse. First, some GTPs (sometimes all four) will immediatly have a BER of 1. Connecting two GTPs established no links, loopbacks don't work, and occationaly when connecting the short SATA cable, random GTP links will go momentarily up.

 

I got similar results using the reference clock (125MHz) and the general clock (200MHz) to drive the IBERT core. I also tested similar configurations on the SP605 board for comparision and they gave me no issues.

 

I guess my questions are:

1- What can generally cause such an issue?

2- What do errors with a near-end PMA loopback signify?

3- What is happening when the BER is stuck at 1?

4- What do a complete failure of PCS and PMA loopbacks mean?

5- How can I rule out (or in) the possibility of the problem being in the hardware?

 

Thank you

0 Kudos
1 Solution

Accepted Solutions
athandr
Xilinx Employee
Xilinx Employee
15,172 Views
Registered: ‎07-31-2012

1- What can generally cause such an issue?

2- What do errors with a near-end PMA loopback signify?

3- What is happening when the BER is stuck at 1?

4- What do a complete failure of PCS and PMA loopbacks mean?

5- How can I rule out (or in) the possibility of the problem being in the hardware?

 

A: A failure in Near End loopback modes can be because of 

 

1) Power supply instability/noise

2) Clock not meeting the phase noise mask specification as per the http://www.xilinx.com/support/answers/43154.html

 

Try working with better clock inputs and check the power supply noises.

Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.

View solution in original post

4 Replies
athandr
Xilinx Employee
Xilinx Employee
15,173 Views
Registered: ‎07-31-2012

1- What can generally cause such an issue?

2- What do errors with a near-end PMA loopback signify?

3- What is happening when the BER is stuck at 1?

4- What do a complete failure of PCS and PMA loopbacks mean?

5- How can I rule out (or in) the possibility of the problem being in the hardware?

 

A: A failure in Near End loopback modes can be because of 

 

1) Power supply instability/noise

2) Clock not meeting the phase noise mask specification as per the http://www.xilinx.com/support/answers/43154.html

 

Try working with better clock inputs and check the power supply noises.

Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.

View solution in original post

smarell
Community Manager
Community Manager
9,015 Views
Registered: ‎07-23-2012

Hi,

 

First of all, TX/RX circuitry of GTP is different. Please refer to UG386 for details. Switching TX/RX doesn't make sense to me since there are few dedicated blocks in RX for decoding, CDR etc which are not available on TX side.

And similarly, the RX can't encode the data. Can you please brief us on what grounds you swapped TX & RX?

 

1- What can generally cause such an issue?

The descriptions sounds odd to me.In other words, you didn't see any errors in chip-to-chip communication but whereas you saw poor BER and link up issues in near end loopback.

I'm not very sure on the reasons for this odd behavior.

 

2- What do errors with a near-end PMA loopback signify?

You can see poor BER issues in near-end PMA when there is high noise/ poor clock/ noisy power supplies.

Please try to following to improve the BER-

 

a. Increase pre-emphasis/post-emphasis and see if there is an improvement in the BER. Post-emphashis has more impact than pre-emphasis.

b. Set TX DIFF SWING to maximum value.

c. You can also modify RX_CDR_CFG settings after refering to UG386 for supported values.

 

3- What is happening when the BER is stuck at 1?

If you are seeing a constant BER, then I assume that it is an issue with the GUI. In general, the BER value fluctuates.

 

4- What do a complete failure of PCS and PMA loopbacks mean?

If you are seeing an issue in near-end PCS/PMA it can mean two things-

 

a. Issue with the chip-> This may not be the possibility in all the cases. The chances of chip getting damaged are rare.

b. Issue with the clock (not following the phase noise mask specs or high noise) or noisy power supply lines.

c. Incorrect GT attributes.

 

5- How can I rule out (or in) the possibility of the problem being in the hardware?

Try the above suggestions and if they fail, we will discuss on the next steps.

 

Regards,

Krishna 

-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
joe2008
Visitor
Visitor
8,613 Views
Registered: ‎06-02-2014

I want to thank you both for your detailed answers.

 

The problem is solved and the issue was in the power supply. The GTPs power pins were being provided with less than the required 1.2V due to a circuit error. Fixing this made everything work as expected.

 

Thanks again for the help.

0 Kudos
athandr
Xilinx Employee
Xilinx Employee
8,609 Views
Registered: ‎07-31-2012

Hi @joe2008 ,

 

Good to hear that....As expected!..Most of the near end loopback failures are because of power stability issues or clock instability(noise) issues...

Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.
0 Kudos