cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
362 Views
Registered: ‎11-04-2019

Frequency difference between RXUSRCLK and TXUSRCLK in GTP transceiver

Jump to solution

Hi,

I'm currenly working on a project using a GTP transceiver 7 serie. In the same GTPE2_CHANNEL, TX and RX has the same REFCLK and are connected to each other so basically the transceiver is sending to itself data for testing purposals. In both channels Buffer is bypassed and data_width=40. On the TX side I use TXOUTCLK to drive TXUSRCLK and TXUSRCLK2 through a PLLE2 to get TXUSRCLK frequency (240 MHz)  to be 2 times the TXUSRCLK2 (120 MHz) frequency. The same setup on the RX side, RXOUTCLK drives RXUSRCLK and  through a PLLE2. 

I have simulated the system and works fine but I have noticed that the frequencies of  TXUSRCLK2 and  RXUSRCLK2 are not the same. RXUSRCLK2 has a 106.6 MHz frequency. As I understand, RXOUTCLK, the source of RXUSRCLK and RXUSRCLK2, it is recoverd from CDR, so, is it posible that this recovery is not "perfect" and because of that I have that difference?

If you know something about this, please let me know.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Moderator
Moderator
331 Views
Registered: ‎07-30-2007

Often a frequency mismatch on the recovered clock is caused by the RX input not being stable when the RX reset is performed.  During the RX reset the clock data recovery (CDR) circuit needs a stable input to lock to.  If you are in loopback and do a "reset all" the TX reset would interrupt the RX input while it is being reset.  In loopback it would be best to do a tx datapath and pll reset followed by an rx and datapath reset.




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
----------------------------------------------------------------------------


View solution in original post

3 Replies
Highlighted
Moderator
Moderator
332 Views
Registered: ‎07-30-2007

Often a frequency mismatch on the recovered clock is caused by the RX input not being stable when the RX reset is performed.  During the RX reset the clock data recovery (CDR) circuit needs a stable input to lock to.  If you are in loopback and do a "reset all" the TX reset would interrupt the RX input while it is being reset.  In loopback it would be best to do a tx datapath and pll reset followed by an rx and datapath reset.




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
----------------------------------------------------------------------------


View solution in original post

Highlighted
Visitor
Visitor
265 Views
Registered: ‎11-04-2019

First of all, I just checked deeply the simulation and the system doesn't work good, due to that difference between frquencies I think.

I have corrected what you mentioned. First, the tx initialization starts and only when it finishes the rx initilization starts. But I still have a difference between those frequencies, now RXUSRCLK frequency is even worse (70 MHz). What do you mean with RX input stable? When rx init procces takes place, TX is sending a comma character, I dont know if that is stable. Also, is there another setup I could use? I mean, I only want to verifify (whith a simulation, I don't have the hardware) if I am receiving the same data that I am sending. As I have mentioned in a previous post I have used TXOUTCLK to drive RXUSRCLK with buffer bypass enabled and I have good results, the data received matched the data sent. But they told me that that is not a possible configuration.

https://forums.xilinx.com/t5/Serial-Transceivers/TXOUTCLK-driving-RXUSRCLK-with-Buffer-Bypassed-enabled/m-p/1127150#M8359 

Do you have any suggestions? As I said, I only need to verify the matching between data sent and received in a loop, nothing special.

 

0 Kudos
Highlighted
Visitor
Visitor
173 Views
Registered: ‎11-04-2019

I just discovered the problem: Due to the clock recovery process, the RXOUTCLK is not stable in the early stages of the initialization. And because of that, the PLL driving the RXUSRCLK and RXUSRCLK2 does not get the locked status properly. To get arround this problem I just reset the PLL after the recovered clock is stable.

Thank you very much sir!