This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS62P28 clocking problem

Other Parts Discussed in Thread: ADS62P28

Hi,

I have a QAM demodulator consisting of ADS62P28 connected to Spartan-6 FPGA using parallel CMOS signals (FPGA latches data using CLKOUT from ADC).

When sampling incoming signal at 140 MSPS (or lower rates) everything works very well - MER is over 43 dB. At 160 MSPS MER falls to 39-40 dB and the constellation points become fuzzy. I can't find out what causes this behavior. If there was a problem between ADC and FPGA (wrong setup/hold times, etc.) then the received signal would be completely unusable (unless errors appear only on two-three LSBs, and rest of the bits are correctly latched by FPGA - but that's unlikely).

I thought this may be caused by ADC sampling clock jitter (that affects symbol clock recovery in FPGA) - but that would cause similar degradation at 140 MSPS (according to my calculations the MER at 140 MSPS should be only 0.2-0.3 dB better than at 160 MSPS is the jitter was to blame and if the overall system MER without jitter was 43 dB).

Any other suggestions?

Best regards,

Piotr

 

  • Hello Piotr,

    Besides checking the setup/hold time between the ADC and the FPGA, I would recommend you also check the following:

    1. By changing the sampling rate from 140MSPS to 160MSPS, the higher order harmonics would now fold back differently than before. It could now be possible that the harmonics could now fold in band. Please try to check and calculate if there are any harmonic folding that could potential cause the problem. 

    2. The SNR of the device may vary between the two sampling rates. Please check the SNR contour plot in Figure 97 to see if there are much variation between the two sampling frequencies with the same input frequency. There should not be much variation, but it is possible the slight variation could cause the additional error.

    3. How are the 140MSPS and the 160MSPS clock being generated? I am assuming they come from different clock sources since the least common multiple of the two frequencies are fairly large and must be generated from a different VCXO. You may want to measure the phase noise between the two clock sources in order to understand the cause of the issue.

    -KH