02-14-2018 07:13 AM - edited 02-14-2018 07:23 AM
Hello!
I am using a GTY transceiver (generated from the wizard with a custom design) and I want to capture both the TXUSRDATA (transmitter data) and RXUSRDATA (received data) with ILA.
The main problem is that ILA requires a free run clock. The TXUSRCLK2 and RXUSRCLK2 are not freerun clocks, so they cannot be used.
Second, I cannot use the qpll0outrefclk output. After the implementation, I get a message about failing nets.
How I can derive a freerun clock from the GTY transceiver? Or I have to generate a clock from a MMCM and use FIFO buffers for clock domain crossing?
Any suggestions please?
02-15-2018 07:53 AM
A couple things to try/check: Make sure the CE/CEMASK and CLR/CLRMASK signals on the BUFG_GT are set to the right values. Check that the clock isn't activated by PS (if relevant), and if so you'll have to program the FPGA from SDK instead of Vivado. Have you tried resetting your system/refreshing the device in Hardware Manager?
I have experienced this error a few times and sometimes found it to be a mistake in the constraints file generated by the 'Set Up Debug' function, or having the wrong debug probes (.ltx) file selected. I have used this method of clock generation for the ILA debugger before, and I can confirm it works. I was also using a free-running external clock source. If none of the above works, try hooking up the clock to a PL LED or something just to confirm that it is in fact a free-running clock.
02-14-2018 07:38 AM
The reference clock for GTY transceivers has to go through a transceiver clock buffer IBUFDS_GTE4 for Ultrascale+ devices, or IBUFDS_GTE3 for Ultrascale devices. Check out UG578 for more information on this. These buffers have two outputs, one that can be used only as the transceiver reference clock, and an exact copy of the clock (with a div-by-2 option if you should need it) to use in the FPGA fabric. This clock should work fine to drive your ILA.
02-14-2018 08:02 AM
02-14-2018 10:06 AM
Invalid connection (1)
IBUFDS_GTE3 (1)
REQP-1848
REQP #1 Critical Warning The IBUFDS_GTE3 ref_clk_inp_buffer ODIV2 pin may only be connected to a BUFG_GT or BUFG_GT_SYNC component. The IBUFDS_GTE3 ODIV2 pin cannot drive ila/U0/PROBE_PIPE.shift_probes_reg[0][0], ............. (the first 15 of 51 listed). ...
I shall try with BUFG_GT...
02-14-2018 10:25 AM
Oh yes. Sorry, I forgot to include that part. ODIV2 output goes to BUFG_GT, then to fabric. Should work fine then.
02-14-2018 01:08 PM
Nope...
WARNING: [Labtools 27-3361] The debug hub core was not detected.
Resolution:
1. Make sure the clock connected to the debug hub (dbg_hub) core is a free running clock and is active.
2. Make sure the BSCAN_SWITCH_USER_MASK device property in Vivado Hardware Manager reflects the user scan chain setting in the design and refresh the device. To determine the user scan chain setting in the design, open the implemented design and use 'get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub]'.
For more details on setting the scan chain property, consult the Vivado Debug and Programming User Guide (UG908).
WARNING: [Labtools 27-3403] Dropping logic core with cellname:'ila' from probes file, since it cannot be found on the programmed device.
02-14-2018 01:30 PM
What clock drives the IBUFDS_GTE3/4?
02-15-2018 04:09 AM
The clock comes form a SI5341 external oscillator.
The FPGA lies in a HTG9100 hitech global board
Maybe the BUFG-GT does not give an output immediately after the programming
02-15-2018 07:53 AM
A couple things to try/check: Make sure the CE/CEMASK and CLR/CLRMASK signals on the BUFG_GT are set to the right values. Check that the clock isn't activated by PS (if relevant), and if so you'll have to program the FPGA from SDK instead of Vivado. Have you tried resetting your system/refreshing the device in Hardware Manager?
I have experienced this error a few times and sometimes found it to be a mistake in the constraints file generated by the 'Set Up Debug' function, or having the wrong debug probes (.ltx) file selected. I have used this method of clock generation for the ILA debugger before, and I can confirm it works. I was also using a free-running external clock source. If none of the above works, try hooking up the clock to a PL LED or something just to confirm that it is in fact a free-running clock.
02-22-2018 06:02 AM
Thank you very much. It worked!
09-24-2019 12:21 AM