cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jeremy.duncan
Visitor
Visitor
670 Views
Registered: ‎10-07-2019

Ultrascale GTH tranceivers: tx->rx prbs test showing errors. When reading drp register "rx_prbs_err_cnt" stays at 50.

Jump to solution

Hello, 

I'm doing a simple external loopback to test the MGT lanes and Im noticing the rx prbs err toggles. I believe for the test to pass this status registers should remain low. When I access the rx_prbs_err_cnt it remains at hex value 50. Everything seems like it's hooked up correctly as I am able to read and write to other DRP registers. I checked to see if TX_GEARBOX_EN was high and it was not. Has any one seen this issue before? I get errors on all lanes and its a brand new cable. Figured I may have missed a step in configuration maybe?

0 Kudos
1 Solution

Accepted Solutions
karnanl
Xilinx Employee
Xilinx Employee
601 Views
Registered: ‎03-30-2016

Hello

1. Perhaps you can share your GTH transceiver configuration here ?
   # Insertion-loss value should be configured correctly.
      Please select equalization mode that fit your system requirement.
      If you are using Equalization mode=DFE, you need to scramble your data.
     Check_GT_configuration.png

2. Do you have IBERT EyeScan result to share ?

Kind regards
Leo

 


------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs
Versal Example Designs : LINK
>>------------------------------------------------------------------------------------------------

View solution in original post

8 Replies
karnanl
Xilinx Employee
Xilinx Employee
602 Views
Registered: ‎03-30-2016

Hello

1. Perhaps you can share your GTH transceiver configuration here ?
   # Insertion-loss value should be configured correctly.
      Please select equalization mode that fit your system requirement.
      If you are using Equalization mode=DFE, you need to scramble your data.
     Check_GT_configuration.png

2. Do you have IBERT EyeScan result to share ?

Kind regards
Leo

 


------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs
Versal Example Designs : LINK
>>------------------------------------------------------------------------------------------------

View solution in original post

jeremy.duncan
Visitor
Visitor
563 Views
Registered: ‎10-07-2019

I haven't connected in system Ibert yet. Is there more I need to do before enabling tx_prbs_sel and rx_prbs_sel?

tranceiver_config.PNG
0 Kudos
jeremy.duncan
Visitor
Visitor
499 Views
Registered: ‎10-07-2019

Also the value 50 is present on the lower and upper 16 bits of the rxprbs_err_cnt register address whether the prbs pattern is on or off. Seems odd. 

0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
390 Views
Registered: ‎03-30-2016

Hello @jeremy.duncan 

> Is there more I need to do before enabling tx_prbs_sel and rx_prbs_sel?
> I've been working to figure out why my rx prbs err cnt doesnt move and I started to monitor rxprbslocked. The rx prbs locked signal never asserts.
> But I get toggles on my rx prbs err. Wondering if you had any suggestions.

> Also the value 50 is present on the lower and upper 16 bits of the rxprbs_err_cnt register address whether the prbs pattern is on or off. Seems odd.


From you screenshot above, it seems you are using the Transceiver inside Aurora IP ? (Please kindly confirm)

If this is the case, perhaps this use case is not possible.
As you may already know, there is a Hot Plug Logic inside Aurora IP. This logic is counting CC (Clock Compensation) characters received from partner TX.
Reception of CC characters by the Aurora RX interface implies that the communication channel is alive and not broken.
If CC characters are not received in a predetermined time, the hot-plug logic resets the core and the GTH receiver.

So if you put the TX side into PRBS mode, TX will not send CC characters, hence that would make Hot Plug logic to think link is down and GTRXRESET will be attempted.
Hot Plug logic can be disabled but this is not recommended because it can make the link more robust.


If you want to verify your channel quality, I would suggest to use In-System IBERT instead.
You can use In-System IBERT to check EyeDiagram of each channel using normal Aurora data.

Kind regards
Leo


------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs
Versal Example Designs : LINK
>>------------------------------------------------------------------------------------------------
0 Kudos
jeremy.duncan
Visitor
Visitor
376 Views
Registered: ‎10-07-2019
  • Yes I am using the transceivers inside the Aurora IP. I believed prbs mode was provided to verify channel quality since the gt signals are accessible and the document explains how the signals are used. Does prbs mode not work?
0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
372 Views
Registered: ‎03-30-2016

Hello @jeremy.duncan 

>Yes I am using the transceivers inside the Aurora IP.
>I believed prbs mode was provided to verify channel quality since the gt signals are accessible and the document explains how the signals are used.
>Does prbs mode not work?


PRBS check between TX and RX will not work if Aurora 64B66B IP is used.
As already mentioned on above post
Aurora 64B66B IP has Hot Plug Logic inside the IP core, this Hot Plug Logic will reset the IP if Aurora 64B66B IP does not receive CC characters for some period of time.
A watchdog counter will reset Aurora RX (including GTH RX), so PRBS mode cannot be used with Aurora 64B66B IP.

Kind regards
Leo


------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs
Versal Example Designs : LINK
>>------------------------------------------------------------------------------------------------
jeremy.duncan
Visitor
Visitor
330 Views
Registered: ‎10-07-2019

I have a correction. I created aurora with external mgt. I am seeing very similar results that match what you described above. But do you think it would make a difference whether created with an internal or external MGT? 

0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
274 Views
Registered: ‎03-30-2016

Hello @jeremy.duncan 

>I have a correction. I created aurora with external mgt. I am seeing very similar results that match what you described above.
>But do you think it would make a difference whether created with an internal or external MGT?

No different.
Even if you generated Aurora IP with external Transceivers,
Aurora IP will reset Transceiver block if IP does not receive CC (Clock Compensation) character for some period of time.

Kind regards
Leo


------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs
Versal Example Designs : LINK
>>------------------------------------------------------------------------------------------------
0 Kudos