GT Wizard for Ultrascale+ GTY transceiver

[srdatucsd]

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.  

[roym]

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?

[srdatucsd]

Thanks.  I'll try the reduced speed and see if it helps and get back with the result.

[roym]

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.

[srdatucsd]

See also the following to better understand what I am doing. My counters tell me that I sent all the words I intended to, and that can only happen if Aurora said it was ready. I suspect Aurora feels it is getting overrun and sending me something that I may be ignoring. It cannot be a sys_out_reset because if it were, I would see it an reset my counters to zero. In prior versions I monitored link_reset, but I am not now and do not see why I should in loopback mode.

https://forums.xilinx.com/t5/Serial-Transceivers/Aurora-near-end-loopback-does-not-work/td-p/1165652

[srdatucsd]

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.'

 

[roym]

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.

[srdatucsd]

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.