12-20-2018 10:18 AM - edited 12-21-2018 01:57 AM
i was trying to verify if there is any incoming signal from some the on-board QSFPs. I tried to connect the incoming differential interface to an ILA debug core (I've tried implementing the various methods of debugging). First I've connected the inputs to the transceiver IPs (SDI, Ethernet,..) and was successful at doing so, but wasn't capable of marking the nets as debuggable. I've also tried to connect the pins to other custom modules, but got the error - invalid placement site, which i suppose is some sort of asserting measure.
Is there any way i can debug or check if there is any signal in any of these ports?
12-21-2018 01:54 AM
are you trying to connect TXP/N or RXP/N or REFCLK pins of GT transceivers to a Debug core like ILA?
those ports are dedicated pins, which are not debuggable.
you can debug the TXDATA or RXDATA (i.e., the parallel interface), which are debuggable.
12-21-2018 06:51 AM
Hi @borisq thanks for the reply
yes, i was trying to find a way to debug the dedicated pins since, in my implemented design, I'm not getting any data on the RX DATA channel, and so I tried to go back in the data flow a step or two. Although I was aware of not being able to debug them, I thought some workaround to check if there is any signal in them would be possible.
12-23-2018 06:19 PM - edited 12-23-2018 06:30 PM
it is impossible to debug the dedicated pins because there is no fabric register connected to those.
If RXDATA has no valid data, the next debug is to check if GT initialization is done and also check the TX side.
12-26-2018 06:33 AM
Hi @borisq, thanks for the additional information.
I did indeed check the initialization of the GT, which was based on the example designs, and configured the RX control registers but I'm still seeing the RX side being unresponsive.
The TX side, I did not debug to the full extent.
01-02-2019 06:21 AM
it might be worth mentioning that one of the problems that I've first faced was the one described in AR# 71680 (https://www.xilinx.com/support/answers/71680.html), and I have implemented the workaround using the buffered MGT_SI570_CLOCK0 for the custom clock frequency.
I've tested the output of the BUFG using the TP1 in which I verified the clock frequencys, and then connected the BUFDS to the GT.
After some more debugging, I have verified in ILA and also the TP1 on an oscilloscope, that the rxoutclk is always at 0 and doesn't commute, even after configurations. Could this be related to the workaround?
01-03-2019 04:11 PM
In your GT wizard, did you set the REFCLK to match the actual clock frequency, e.g. 156.25MHz?
What is your free-running clock frequency, and do you have it coming from a valid source on VCU1525, and the GT wizard has the correct frequency entered?
If you have the example design implemented, check if you have gtwiz_reset_tx_done_vio_sync and gtwiz_reset_rx_done_vio_sync asserted indicating the GT has completed TX/RX reset initialization?
01-04-2019 12:16 AM
when you see rxoutclk is always 0, does txoutclk show right frequency? does RXRESETDONE assert?
01-04-2019 03:44 AM
As I'm currently using the SDI GT, I've configured the si570 to generate a 148.5MHz clock, which I verified on an oscilloscope as I mentioned earlier. To do so, as the user clock from the clock generator is a flat line, it was required to buffer one of the outputs into the fabric and route it to the testpoint TP1 as shown in the block design screenshot.
I've also verified the signals you mentioned with the ILA and it seems that the RXRESETDONE does not get asserted.
In the meantime I'm implementing one design with both RX and TX to verify if the txoutclk signal is working.
01-10-2019 06:20 AM
Have you already figured out how to solve your problem? I'm facing a similar issue in a project I'm working on. I'm struggling to find why RXRESETDONE does not get asserted.
01-15-2019 02:24 AM - edited 01-15-2019 02:33 AM
after some more debugging I was able to get the RXRESETDONE asserted. My problem was that I was not generating the reset to the QPLL properly, and with that solved, I seem to be able to get data on the RX side, but I'm still not getting the clock working on the TX side.
Similarly to the RXRESETDONE, the TXRESETDONE is not being asserted. The issue seems to be different, as already I tried the same solution that I used on the RX. Any help or insight on what might be causing the problem would be welcomed, as I been here for a while trying to find the solution.