10-22-2020 04:54 PM
I'm using an XCVU37P and configuring for 100Gbps Aurora on a production board. I am testing it in near-end loopback mode at that speed. That requires setting GTOUTCLKSEL to a specific value for the near-end loopback to work according to page 87 of UG578. I use near-end modes 1 & 2 with 4x 25G per lane. It behaves as if it is doing the loopback correctly except not sending back the final 1.6% of the transmissions.
All the transceiver settings related to that clock are in "Do not modify" files. But there is no gtwizard_ultrascale_v1_7... anywhere to be found in my Vivado IP list nor in the license list for our installation. I suspect the wizard is where I would need to make the clock change though no one has confirmed that.
Can you confirm that a) this wizard is required and b) if it requires special licensing. Or, if not, c) where is the wizard?
This is the 3rd time I asked this question in the forums here and there in various ways. No one has any answers.
10-26-2020 10:12 AM
It is not clear to me what settings you are trying to change. Normally I would expect they are set to what you need for loopback. The PMA reset will be brought out if you select "additional transceiver control and status ports" on the first page of the aurora wizard.
Unfortunately Aurora always keeps the GT inside of their core so if you really have to change the selection ports you have to unmanage the design and make all parts of it modifiable. This will be a bit tedious and will make upgrading to new vivado versions difficult. See https://www.xilinx.com/support/answers/57546.html on unmanaging the core.
Since this is aurora it seems like you might have the option of going to a line rate under 25 Gbps as well?
10-26-2020 10:38 AM
It seems to me this isn't a clocking or loopback issue but probably something in the aurora core (or your code) that is turning something off too soon. If it is an RTL issue I think you will see the failure in simulation and debug will be easier there.
10-26-2020 10:44 AM
10-28-2020 12:19 PM
I tried your suggestion and knocked the speed down to 20G per lane. It had no effect on the problem. See attached. Someone else suggested to put a free running clock into the dbg_hub soit does not do weird things. What do you think about that idea? The current clock is the user_clk_out from Aurora IP which I thought was 'free running.'
10-28-2020 12:53 PM
Yes I think that should be a free running clock. By free running we mean there all the time. A userclk will not be there at times and at times won't be a consistent frequency because of the RX or TX reset. At times it could even have glitches so it is not a good candidate to run state machines.
10-28-2020 05:54 PM - edited 10-28-2020 06:07 PM
I said something incorrect. The debg_hub has no specific assigned clock. It just uses 'clk' from who knows where. Hence the suggestion I was given. I'll tell it to follow the init clock which is free running.
A question about the Aurora user clock comes from using it to sample signals derived from a free running 100 MHz init clock to sync those to the state machines that run off the Aurora user clock. So what signal tells me when the user_clk_out is valid from the Aurora IP? I do not get that yet from the documentation.
The thing is that you can see in my example that it counts all the transmitted packets just fine. It only fails to count all the received. If this is a dbg-hub fluke, it sure is subtle.