UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor tigi
Visitor
394 Views
Registered: ‎01-17-2018

newbie: GTH QPLL1_Lock problem

Jump to solution

I use a KCU105 dev kit, and i can get a serial link to work with a project developped by other people, this probably means that on-board power and clock are fine. Then I have developed my project and my GTH (see wizard in attachment). I have designed my GTH to run at half the line rate of the previous project, but it does not work, and with VIO i see that the following signals are constanty zero:    gtwiz_reset_tx_done_out ,  gtwiz_buffbypass_tx_done_out ,   QPLL1Lock_out ,   txprgdivresetdone_out  .

How can i debug this ?

GTH_QPLL1_Lock_problem.png
0 Kudos
1 Solution

Accepted Solutions
Visitor tigi
Visitor
137 Views
Registered: ‎01-17-2018

Re: newbie: GTH QPLL1_Lock problem

Jump to solution

For the moment i have found a work-around: i have found an old design where the GT IP is an XCI file, so i have been able to re-customize it with the Wizard in order to match the new requirements. This way the GT works fine , at least with an external fiber looped back.

I do not know why the IP i built from scratch does not work, maybe in future i will try again.

Thanks for all suggestions, at least i have learned about some details of the GT.

0 Kudos
11 Replies
Adventurer
Adventurer
356 Views
Registered: ‎03-16-2019

Re: newbie: GTH QPLL1_Lock problem

Jump to solution

check your project clocking ( freerun, gtrefclk_00) and active_in pins, 

have you used the exapmle design of GT then change the line rates?  if yes build the example design from scratch after changing rate.

Xilinx Employee
Xilinx Employee
332 Views
Registered: ‎06-01-2017

Re: newbie: GTH QPLL1_Lock problem

Jump to solution
If QPLL1 is not locked, the most likely cause is MGTREFCLK. Check that you have the correct GT quad configured, and the REFCLK is coming in at the right FPGA pin with the 120MHz frequency as the wizard is set to.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Visitor tigi
Visitor
311 Views
Registered: ‎01-17-2018

Re: newbie: GTH QPLL1_Lock problem

Jump to solution
I give a quick reply, both suggestions were useful: i had gtwiz_reset_clk_freerun_in left with a frequency twice as high as it should (i found the requirement on PG182 ) and also i was not using the correct GT quad. Still the problem persists... i will keep working on it.
0 Kudos
Xilinx Employee
Xilinx Employee
297 Views
Registered: ‎06-01-2017

Re: newbie: GTH QPLL1_Lock problem

Jump to solution
Check the freerun clock frequency setting in the Physical Resources tab. It needs to match your actual freerun clock frequency.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Visitor tigi
Visitor
280 Views
Registered: ‎01-17-2018

Re: newbie: GTH QPLL1_Lock problem

Jump to solution

i have checked or corrected things as you guys suggested. My confusion about the correct quad and GT is because you can set this in two different places: in the GT wizard, Physical Resources tab, and in the xdc file where the data lines are assigned to pins. I find this an ambiguous feature of Vivado, anyway my GT assignment should be consistent now, but the link still does not work. I looked at the REFCLK: in the GT wizard there are many options, including MGTREFCLK0 and MGTREFCLK1. I selected: MGTREFCLK0. In the files generated by the wizard i find:
gtrefclk01_in : IN STD_LOGIC_VECTOR(0 DOWNTO 0);
which is a single input, and i tied it to the RefClk coming fro the FPGA pins. Is it ok ?

0 Kudos
Adventurer
Adventurer
268 Views
Registered: ‎03-16-2019

Re: newbie: GTH QPLL1_Lock problem

Jump to solution

yes, this the way that VIVADO select for showing a single bit. put (0) near your instantiation to handle a problem of assigning std_logic to std_logic_vector.

for example, if temp_sig is STD_LOGIC_VECTOR(0 DOWNTO 0) and you want to assign temp_assign to it. in your PORT MAP do as like as me.

PORT MAP (

...

temp_sig(0)=> temp_assign,

...

 

I really recommend you to start a new example design from scratch at first. 

Xilinx Employee
Xilinx Employee
257 Views
Registered: ‎06-01-2017

Re: newbie: GTH QPLL1_Lock problem

Jump to solution

On the KCU105, all the MGTEFCLK pins are pre-wired on the board. A given MGTREFCLK pin would have pre-wired sources where the clock is coming from. Here is an example below on the bank 227 connections. MGTEFCLK0 comes from Si570, and MGTREFCLK1 comes from Si5328.

Which bank are you using and where is the MGTREFCLK coming from?

image.png

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Visitor tigi
Visitor
228 Views
Registered: ‎01-17-2018

Re: newbie: GTH QPLL1_Lock problem

Jump to solution

I use the SFP with the "P5" text on the KCU105 card, this is connected to a GT on Quad X2Y2, bank 226: pins T1,T2,U3,U4.
As a RefCLK, i have an external clock generator (running at 120 MHz) tied to the two SMA connectors labeld "MGT CLK" on the card.
On the xdc files i have the following constraints:

## SERIAL LANES:
set_property PACKAGE_PIN T1 [get_ports SFP_RX_N]
set_property PACKAGE_PIN T2 [get_ports SFP_RX_P]
set_property PACKAGE_PIN U3 [get_ports SFP_TX_N]
set_property PACKAGE_PIN U4 [get_ports SFP_TX_P]

## MGT CLOCK ##
set_property PACKAGE_PIN V6 [get_ports SMA_MGT_REFCLK_P]
set_property PACKAGE_PIN V5 [get_ports SMA_MGT_REFCLK_N]


Note that the same hardware setup and xdc constraints work fine when i program a "legacy" design (done by other people, not in my team anymore). On my design i rebuilt from scratch the GT IP in order to run at half the line rate (this is the specification for my design). I have chosen to keep the same external RefClk frequency, and make (or at least tried to make) the IP working off the same RefClk. The problem i see is QPLL1_Lock constantly zero. The legacy design was done with Vivado 2016.3, while i work with Vivado 2018.3. I have also ported the legacy design to Vivado 2018.3, but in the Vivado Hierarchy panel the GT IP has apparently been replaced by a verilog file in the process of porting ; so i cannot just re-customize the legacy IP. I am now thinking to do my work on Vivado 2016.3, so i can try recustomize the legacy IP.

0 Kudos
Adventurer
Adventurer
203 Views
Registered: ‎03-16-2019

Re: newbie: GTH QPLL1_Lock problem

Jump to solution

I don't know what legacy design is.but when your QPLL didn't lock, firstly you should check clocks that is inserted to a GT. run counter to see is your clock really running or not. being aware of your clock must have the same value which you chose in generation GT. 

0 Kudos
Xilinx Employee
Xilinx Employee
155 Views
Registered: ‎06-01-2017

Re: newbie: GTH QPLL1_Lock problem

Jump to solution

Hi @tigi 

As a test, to confirm the design works if input REFCLK is 120MHz, set the wizard to source REFCLK from bank 227 MGTREFCLK0. With the system controller, set Si570 output frequency to 120MHz.

Can you see if a design configured like this works?

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Visitor tigi
Visitor
138 Views
Registered: ‎01-17-2018

Re: newbie: GTH QPLL1_Lock problem

Jump to solution

For the moment i have found a work-around: i have found an old design where the GT IP is an XCI file, so i have been able to re-customize it with the Wizard in order to match the new requirements. This way the GT works fine , at least with an external fiber looped back.

I do not know why the IP i built from scratch does not work, maybe in future i will try again.

Thanks for all suggestions, at least i have learned about some details of the GT.

0 Kudos