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: 
835 Views
Registered: ‎03-16-2018

oversampling using GTHE4 on Zynq Ultrascale+

I've had the XAPP1240 running on a Kintex7 325T oversampling a 333Mhz source.  However, when I ported this to the Zynq Ultrascale+, I seem to be seeing data dropouts.  I have a source sending a constant K28.5 pattern, so I expect to see a pattern in the output of my 20 bit GTHE4.  This pattern is there, but occasionally, I see the pattern jump and 5 20 bit samples are dropped... see attached.

 

Is the porting of this straightforward?  Or are there additional ports I should be enabling / disabling.  Currently I'm setting: rxcdrhold_in, rxlpmen_in, rxlpmhfovrden_in, rxlpmlfklovrden_in, and rxlpmosovrden_in to 1.  The drop of 5 samples makes me think that the buffer is still in place somehow.

hotlink_k285.PNG
gth.PNG
0 Kudos
5 Replies
Moderator
Moderator
759 Views
Registered: ‎07-30-2007

Re: oversampling using GTHE4 on Zynq Ultrascale+

 Is your reference clock on the Zync part based on the same oscillator as the partner refclk?  It is a requirement of this application note that this be a synchronous system.  This sort of skip could also be the result of a frequency mismatch.

 

To see if the buffer is enabled check the RXBUF_EN attribute in the GT*_CHANNEL in your implemented design. See attached pic.

 

 

Roy


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


rxbuf_en.JPG
0 Kudos
744 Views
Registered: ‎03-16-2018

Re: oversampling using GTHE4 on Zynq Ultrascale+

It should be synchronous.  The data source is a 333.33MHz serial stream +/- 25ppm.  I'm 10x oversampling using a 166.667Mhz reference clock +/- 50ppm, and a 20 bit output sample.

 

The engineer who I borrowed this from had difficulty getting things to work with the elastic buffer in place, so I kept what he had.  I've checked and RXBUF_EN is FALSE.   The user clock is the recovered clock.   The NIDRU is then used to account for clock differences.

 

I'm questioning if this is the best solution, or should I be looking at enabling the elastic buffer per the app note.  Would I then need to specify the receiver clock correction sequence to account for any drift between my source and refclk?

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
733 Views
Registered: ‎11-29-2007

Re: oversampling using GTHE4 on Zynq Ultrascale+

hello

the NIDRU recovers the ppm differences (if in a certain range). There is no requirement to have source and receiver synchronous.

There is no requirement to bypass the RX buffer - this only makes your design more complicated. Yes please enable the RX buffer.

I am concerned you are using DFE (you set 20dB losses, EQ selection auto): in this case all your settings about LPM will not be considered. Please set LPMEN=1.

 

The USRCLK should be RXOUTCLK, that is not the recovered clock! when we are in lock to reference condition the CDR is frozen and it acts as a simple oversampler. the RXOUTCLK will be synchronous to local  REFCLK. The true recovered clock is generated by the NIDRU.

 

No need at all of clock correction.

 

719 Views
Registered: ‎03-16-2018

Re: oversampling using GTHE4 on Zynq Ultrascale+

I've built with LPMEN=1, and the buffer enabled.  I'm still not getting a consistent output from the GTHE4s, although the behavior now appears different.  I've added an additional chipscope trace below.  The sampling of my characters seems consistent, getting groupings of 10 samples for long stretches, but then it appears that the sampling rate changes, as if we are no longer locked to the reference clock.  

 

One thing of note on our hardware is that we are having the FPGA generate the reference clock, it is driven out of the FPGA via an OBUFDS, and then fed back in as a reference clock.   This was done to save an oscillator due to space constraints.

 

 

 

 

 

 

hotlink_sample2.PNG
0 Kudos
Xilinx Employee
Xilinx Employee
614 Views
Registered: ‎11-29-2007

Re: oversampling using GTHE4 on Zynq Ultrascale+

hello,

this is not a supported REFCLK source.

The REFCLK input signal phase noise must pass the datasheet phase noise mask constraints.

Please double check the quality of your REFCLK.

Image 008.png