08-01-2019 11:44 AM
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.
08-07-2019 02:14 PM
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.
08-09-2019 05:39 PM
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.
08-12-2019 09:51 AM
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.