01-31-2018 03:49 AM
I'm implementing an asynchronous demapper on KCU105 Ultrascale family EVB, and using Si5328 as my jitter cleaner and frequency multiplier. and using the gapped clock controlled with justification bytes (clock gating with BUFGCE) to transport the client side REFCLK.
The 0ppm client rate works good, But when I cfhange the client rate mapped in the line, the REFCLK at the client side won't follow the ppm inserted!
I am wondering where the problem is !
I did the same with Si5324 on the KC705 Kintex7 EVB, and in there, i couldn't even have the 0ppm linerate of client!
What is the problem i'm facing with? And how can I solve that?
01-31-2018 03:59 AM
Hi @arashkm73, you have an interesting problem, but your description of how you are trying to solve it is too sparse to make sense of where it's failing. You'll have to explain in more detail what you are doing, and why it's not doing what you want.
01-31-2018 04:24 AM
Hi @jmcclusk Thanks for your reply.
I'm implementing OTU2 to STM-64 Demapper running 1 GTH on OTU2 rate and 1 GTH on STM-64 rate. In this demapper the mapped client rate in the OTU2 shall be provided and transported to the STM-64 line rate.
Now using the CDR in GT, i can have the recovered clock (rxusrclk) of OTU2. And with Gapped Clock and justification bytes i am generating proper clock to the Si5328 input. (Doing so with BUFGCE and Clock control and Recovered clock)
Now when there is no justification byte , all things are ok... But when i insert the justification bytes with Network Test Equipment(in OTU2) , i see the output clock of Si5328 (GTREFCLK of STM-64) won't follow the rate change properly.
-- > By follow i mean as the justification bytes in OTU increases, the Gapped clock have to increase it's frequency, and consequently the GTREFCLK of STM-64 have to increase either.
01-31-2018 07:29 AM
I'm trying to follow your algorithm flow, so I'll have to guess at a few things.. Are you using a BUFGCE to distribute a clock with gaps to the Si5328 input? and you see that the Si5328 is more or less ignoring those missing clock cycles? This is not a problem with a Xilinx device, so we might not be able to help with this issue. I can suggest a workaround, which might be to use the PICXO circuit as a way to generate a frequency modified clock input to the Si5328.