cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
billauer
Adventurer
Adventurer
5,514 Views
Registered: ‎06-10-2014

GTX Eye scan patters through SMA connectors on KC705

Hi,

I'm setting up a statistical eye pattern scanner for use on a custom board, but I'm testing it on KC705. It's based upon XAPP743, but several adaptations were made to work in the target environment. In particular:

  • The code, that controls the scanning through DRP, runs on a Linux host rather than on an on-chip Microblaze processor. This required a replacement of the wrappers for read/write to the DRP and some other changes in the main-level control of the scan. However the es_simple_eye_acq() function, which does the actual work, remained intact.
  • The result data is displayed with octave (a free MATLAB clone) using the “cool” colormap rather than Xilinx' IBERT plot viewer.


The tested channel ran at 10 Gbps through the SMA ports of the KC705 board (40 bits with 8b/10b enabled, data randomized with a scrambler, DFE enabled). Two RG-316 cables of 6” each were used to loop back TXN to RXN and TXP to RXP.

The channel ran practically error free (no errors detected for several minutes).

After running an eye scan with max_prescale=9, both horizontal and vertical increments at unity (took 30 minutes or so), this is what I got:Eye pattern at 10 Gbit/s

The turquoise segment in the middle is the no-error zone. Purple marks the high-error region, and intermediate colors show a logarithmic transition between the two regions.

I would be happy with this eye scan, had it not been for it's vertical asymmetry: I can't see any reason why the no-error zone is pushed towards a positive voltage when sampling earlier in time.

The cables are not to blame. I've also run a similar test with RG-316 cables of 36” (!) and got very similar results. The equalizer does a good job.

This is not a matter of differences in cable lengths either: When disconnecting either of the cables (running only through an P or N channel), the turquoise region gets smaller and rounder, but with the same downwards slope.

So I said OK, maybe it's because I'm running at 10 Gbps through lousy cables. I reduced the rate to 1 Gbps, with the same parameters, and changed max_prescale=3 to speed up the scan.

This is what I got:
Eye pattern at 1 Gbit/s
Looks somewhat better: There's still a slight vertical asymmetry, but the really weird thing is around horizontal shift zero: There are errors. And it gets weirder: These errors appear only at horizontal positions from 1 to 6 with an error rate of 2*10^(-5) at position 1 and going towards zero at 6. What makes this even more weird, is that no errors were measured at the respective negative horizontal shifts or at zero. Let's keep in mind that the scan starts at horizontal shift 0, and then jumps to -1, 1, -2, 2 etc. So the errors are consistent with the horizontal positions. Needless to say, I ran this twice and got very similar results.

So -- has anyone an idea on what's going on here? Have I made a silly mistake?

Thanks in advance,
   Eli

0 Kudos
4 Replies
trenz-al
Scholar
Scholar
5,506 Views
Registered: ‎11-09-2013

1G eye must be much better..

 

https://wiki.trenz-electronic.de/display/TE0741/GTX+Multi+Gigabit+Transceivers

https://wiki.trenz-electronic.de/display/TE0712/IBERT+Testing

 

however even your 1G looks too much off from ideal, please look the 1G eye with TE0712 there is almost full rectangle of open area!

 

At 10G the eye opening can disapper with lousy cables.

 

You should run Xilinx IBERT on your boards to compare the eye scans.. then you know what they would need to look ,if your octave stuff is working properly.

0 Kudos
billauer
Adventurer
Adventurer
5,482 Views
Registered: ‎06-10-2014

Hi,

 

Thanks for trying, but --

 

I don't think the cables can be blamed, because of the variations I tried with them. Besides, lousy cables tend to cause a narrow eye opening, not an assymetric pattern.

 

As for the 1Gb/s pattern -- it seems OK to me, except for the errors near the sampling point. This is not a problem with the graphical representation -- I've seen the numbers in the text file generated by the scanning program.

 

And of course, running Xilinx reference design as is could shed some light on this. But it would be even nicer, if someone spotted an obvious problem which could lead to the patterns I got.

 

Regards,

   Eli

0 Kudos
karamp
Visitor
Visitor
639 Views
Registered: ‎07-08-2018

Hi Eli,

           I know this was a long time ago, but did you ever get to the bottom of this, as I have exactly the same problem now. Getting a very similar eye to yours running Aurora at 6.25GHz on a KC705 using xapp743 derived software, yet an IBERT at 6.25GHz shows a good clean eye ?  

0 Kudos
billauer
Adventurer
Adventurer
636 Views
Registered: ‎06-10-2014

Hello,

It was a long time ago indeed. Frankly speaking, I don't remember how this particular issue was resolved, if at all. I usually write follow-ups when there's a solution, so the answer is most likely that I stopped being fussy with this eye scan thing and went on with the project.

But I can confirm that the link remained error free and it all ended up with a working, functional project.

Regards,

   Eli

0 Kudos