cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Contributor
Contributor
780 Views
Registered: ‎02-19-2018

Artix7 recovered clock (RXUSRCLK2) runs at 156.250MHz/2 when it should be 125MHz/2?

Jump to solution

We have a design that uses a GTP transceiver in Artix7 running at 1.25Gbps.  We notice when there is no fiber or loopback in the transceiver, the recovered clock (RXUSRCLK2) runs at 156.250MHz/2.  When there is fiber or loopback, it runs at 125.0MHz/2 which is correct.  Do you know why?  Is there a way to force it to always run at 125.0MHz/2?

0 Kudos
Reply
1 Solution

Accepted Solutions
Explorer
Explorer
661 Views
Registered: ‎03-16-2019

read karnanl answers twice, 

I mention the important part of that, this part may be so helpful for you.

"If the GTP input is not stable (i.e electrical-idle state),
RX CDR will not be able to observe signal transition correctly,
so GTP RX recovered clock may drift away from expectation value.


If you are using GTP RX recovered clock, this is expected behavior"

when you use recovered clock you must have a correct input on your SFP if you don't have your CDR doesn't work properly and after that, if you connect an SFP, you need CDR to reset.

I don't how did you recover your clock, but for more detail, you can see the hold parameter in JAT.(for example:si5328)

the hold parameter shows how long JAT can be in a correct data rate after you don't have data in your line.

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

View solution in original post

5 Replies
Explorer
Explorer
754 Views
Registered: ‎03-16-2019

You have 8b/10b encoder in your GT config that make your rate being 1 gig

You select 64 bit for your data width that make your Rxuserclock2 156.25Mhz/2.

Are the above note correct?

What loooback do you mean? Pma or pcs 

Do you see change the clock rate after conecting fiber to the sfp?

What do you to measure your clock rate?

Xilinx Employee
Xilinx Employee
719 Views
Registered: ‎03-30-2016

Hello @jaharvey 

1. If you have a stable input ( with a proper line-rate) at GTP RX input pin,
recovered clock (RXOUTCLK) will have a stable clock frequency.

2. If the GTP input is not stable (i.e electrical-idle state),
RX CDR will not be able to observe signal transition correctly,
so GTP RX recovered clock may drifted away from expectation value.


If you are using GTP RX recovered clock , this is an expected behavior,
I dont think there is a workaround for it.

Thanks & regards
Leo

Moderator
Moderator
682 Views
Registered: ‎07-30-2007

Like karnanl says there needs to be an input to see the right recovered frequency.  It shows 156.25 when there is not input. Is this the case?

If it is you can still see the 125/2 Mhz by using the lock to reference mode.  Set the RXCDRHOLD to 1. If the CDR is not updating the output will just be a subdivision of the reference clock.  However you would need to turn off the cdr hold to read regular input data.




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


Contributor
Contributor
670 Views
Registered: ‎02-19-2018

Thank you All for the input and help!  Here is some more data on the design:

- We have an 8b/10b encoder in your GT config that makes your rate 1 gig

- We have selected 16 bits at the FPGA interface width

- it's an external loopback (basically a fiber connecting tx port to rx port)

- for measuring the clock rate we have a circuit in the FPGA to measure the RXUSRCLK2.  Essentially it’s frequency counter.  When the fiber is in, RXUSRCLK2 is 62.5MHz.  When it’s out (ie, nothing is plugged in sfp) RXUSRCLK2 is 78.125MHz

0 Kudos
Reply
Explorer
Explorer
662 Views
Registered: ‎03-16-2019

read karnanl answers twice, 

I mention the important part of that, this part may be so helpful for you.

"If the GTP input is not stable (i.e electrical-idle state),
RX CDR will not be able to observe signal transition correctly,
so GTP RX recovered clock may drift away from expectation value.


If you are using GTP RX recovered clock, this is expected behavior"

when you use recovered clock you must have a correct input on your SFP if you don't have your CDR doesn't work properly and after that, if you connect an SFP, you need CDR to reset.

I don't how did you recover your clock, but for more detail, you can see the hold parameter in JAT.(for example:si5328)

the hold parameter shows how long JAT can be in a correct data rate after you don't have data in your line.

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

View solution in original post