cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tommcleod
Observer
Observer
881 Views
Registered: ‎06-08-2018

Xilinx Aurora 8B10B hotplug detection during configuration

We have a design that uses an Aurora 8B/10B interface to communicate between two Artix 7 FPGAs at 3.75 Gbps. One of the devices is mounted on a daughterboard through an M.2 connector. There is a total of about an inch of trace length between the two devices. Signal integrity shouldn't be an issue and all measurements that I've taken with IBERT seem to indicate a pretty large eye opening.

The problem that I'm running into is that some percentage of device configurations (configuring either of the two devices) result in a dead Aurora link with no indication as to why. Providing an external reset or re-configuring one of the two devices will typically bring the Aurora link back up, but this is an undesirable requirement. I was under the impression that the Aurora hotplug detection module would handle all cases in which the link was down and then back up, but it seems as though it is not properly handling re-configuration of a the device at the other side of the connection in some situations.

I have been able to reproduce this issue with multiple different configuration methods including JTAG (through a Digilent JTAG-HS3 adapter), though it seems to be more common when configuring over 1-bit serial. I'm not sure why that would be the case.

Are there any known issues along these lines? Are there any tools/methods you would recommend for debugging this? At first I thought the issue was with the configuration method alone but since I can reproduce it with JTAG through Vivado that seems unlikely.

I may be able to work around the issue by adding my own hotplug detection type logic, but this seems like it shouldn't be necessary and could introduce numerous other bugs.

Any help would be appreciated.

7 Replies
guozhenp
Xilinx Employee
Xilinx Employee
821 Views
Registered: ‎05-01-2013

Try doing one more GT RX RESET after the configuration is completed.

Can it solve the issue?

0 Kudos
tommcleod
Observer
Observer
793 Views
Registered: ‎06-08-2018

Can you clarify what you mean when you say to try one more GT RX RESET? As far as I'm aware there is no RX-specific reset line available on the Aurora IP (this is in a duplex configuration). Are you suggesting that I modify the Aurora IP sources themselves?

I've been able to reproduce this issue with both my own design and the Xilinx example design. My design holds the `gt_reset` line of the Aurora IP high for 256 `init_clk` cycles after configuration then releases it. The Xilinx example design does not seem to do any reset like this at startup. Both designs have the same issue.

0 Kudos
allanherriman
Mentor
Mentor
768 Views
Registered: ‎01-08-2012

If you are using the DFE, try changing over to the LPM equaliser.  My experience has been that the DFE doesn't like short, low loss links.

0 Kudos
tommcleod
Observer
Observer
757 Views
Registered: ‎06-08-2018

Unfortunately I don't believe that the GTP Transceivers in the Artix 7 have a DFE so I don't think that's an option to try and improve anything. If there are other knobs I should try turning I can take a stab at those, though I believe I've tried much of what is available.

0 Kudos
guozhenp
Xilinx Employee
Xilinx Employee
727 Views
Registered: ‎05-01-2013

Do you follow Figure 3-5 in PG046 about the power on sequence?

0 Kudos
tommcleod
Observer
Observer
718 Views
Registered: ‎06-08-2018

Yes, when using our design we follow the power sequence in Figure 3-5. We have been able to reproduce this issue with the Xilinx example design as well which does not follow this sequence as far as I can tell.

0 Kudos
Reto
Observer
Observer
152 Views
Registered: ‎07-29-2020

Hi @tommcleod 

Did you find a solution to this topic?
I have a similar issue.

Thank you

Kind regards
Reto

0 Kudos