cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
520 Views
Registered: ‎03-31-2019

GTH SerDes qpll unlock when setting up debuger

In my design, there are GTH SerDes and DRP logic which sets 64b66b or 8b10b encoding method according to a input.

 

The problem is when inserting debugger, GTH qpll is unlock.

 

When eliminating debuger, GTH qpll is lock and all fucntion is work.

 

There is no change in my design except inserting debugger. All source codes are same.

 

I try to fix this problem by driving GTH reset, but it is not works.

 

I don`t understand why inserting debugger result in qpll unlock.

 

Is there anyone who experience same problem?

 

Is there any point should i check?

 

Unfortunately i can`t provide design file. Plz understand my situation.

 

Thanks

 

 

 

 

0 Kudos
4 Replies
eschidl
Xilinx Employee
Xilinx Employee
422 Views
Registered: ‎10-19-2011

Hi hs0622.kim@samsung.com ,

as debugger you mean inserting an ILA?

It could be that some parts of your design are not constraint correctly for timing. And then with inserting the ILA you change the topology and therefor the timing on these parts. If that includes the reset state machine for the transceiver you might get stuck here.

Which device do you use? And do you use the transceiver IP core and its setup from example design?

Do a timing check and look for unconstrained paths.
Use the write_xdc command to write out all constraints in the design. you will also see where it is defined.
Maybe look for constraints that overwrite others.

You can still use the ILA to observe signals that controll the QPLL. Is the QPLL held in reset or power down?

 

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
408 Views
Registered: ‎03-31-2019

Thanks for your reply.

There is no timing violation after inserting debugger ila. My device is vu13p.

And actually i`m not using transceeiver with example setting, through DRP i controls transceiver register.

(Using DRP to switch encoding scheme like 8b10b to 64b66b)

Additionaly I can check GT power signal, it remain high(1'b1) state.

0 Kudos
eschidl
Xilinx Employee
Xilinx Employee
391 Views
Registered: ‎10-19-2011

Hi hs0622.kim@samsung.com ,

when you switch between 8b10b and 64b66b encoding, there will not just be attribute changes necessary. You will have to change ports and attributes.

I assume you created a transceiver wizard design for both setups and got the necessary settings/connections from there, which you now change through your control from one to the other, right?

It might well be that there is no timing violation, but did you check that all paths are constraint and considered? Are there any unconstrained paths? It should be in the timing summary. Are there false paths set? Is this done correctly?

Did you check in your ILA what the PLL control signals are set to, directly at the primitive?

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
358 Views
Registered: ‎03-31-2019

As you mentioned,  both changing attribute value and port value are done in encoding swithcing state.

 

Actually this problem came after modiy userclock helper block code.

 

In origianl userclock helper block code, BUFG div port have fixed value.

 

But in my modified code, these port`s value have different value according to encoding method.

 

For example, in case of using 8b10b encoding 1 is the value of BUFG div port and in case of using 64b66b encoding 0 is the value of BUFG div port.

 

As your advice, i need to recheck all constraint and setting related timing.

 

Thanks

 

 

 

0 Kudos