11-02-2018 10:19 AM
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.
11-05-2018 10:22 AM - edited 11-05-2018 10:24 AM
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.
11-05-2018 01:42 PM
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?
11-06-2018 01:15 AM
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.
11-06-2018 09:41 AM
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.
11-16-2018 06:04 AM
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.