ADS5463 glitching

Hello,

  Here is quick thought, 1) the EVM is tested at its default setting before it sent to the stock, so please make sure the board is not damaged, jumper setting are correct. 2) when test the board we need BPF on the signal path and clock path between the source and the board to get clean analog input signal and clean clock signal. 3) glitch can be caused by data capture timing, if this the factor in this case shifting clock phase by small steps we should see the change on SNR. 4) incorrect code in the program can also cause glitch in the data. 5) poor PCB or connection between two boards can cause bad data.

The device is characterized on the BER and we don't have such report from other users. Could you pass your measurement plot shown the glitches to us? Also, timing plot?

Regards,

Hui Qing

Hello Qing,

Thanks for your quick reply. My responses to your suggestions are below

***-Qing Liu said:

  Here is quick thought, 1) the EVM is tested at its default setting before it sent to the stock, so please make sure the board is not damaged, jumper setting are correct.

Apart from the (relatively infrequent) glitches the board operates very well in terms of linearity, phase noise, etc. Also, I see the same behavior on 4 ADS5463 devices: one on ADS5463EVM and three on my own boards.

***-Qing Liu said:

2) when test the board we need BPF on the signal path and clock path between the source and the board to get clean analog input signal and clean clock signal.

I have filters on both clock and data, plus I am using very low phase noise synthesizers. When the signal is not glitching, the performance is as good as I would expect. Also, in my experience clock and signal problems show up as more than a single sample deviation.

***-Qing Liu said:

3) glitch can be caused by data capture timing, if this the factor in this case shifting clock phase by small steps we should see the change on SNR.

I can dynamically shift the clock phase and I see basically no change in the SNR until I hit bit 10 glitching in one direction (+590 ps away from nominal timing) and bit 8 in the opposite direction (-530 ps).

***-Qing Liu said:

4) incorrect code in the program can also cause glitch in the data. 5) poor PCB or connection between two boards can cause bad data.

I think I have eliminated that, since I have two different setups (one as a single board with 50 ohm microstrip between the ADC and the FPGA). All my FPGA code does is receive ADC data and save it in the memory. I have also recoded that section i several different ways, always seeing the same glitching behavior.

***-Qing Liu said:

The device is characterized on the BER and we don't have such report from other users. Could you pass your measurement plot shown the glitches to us? Also, timing plot?

Here is a table of my measurements at different frequencies

I'll post more data and plots shortly.

***-Qing Liu said:

Could you pass your measurement plot shown the glitches to us? Also, timing plot?

Here is one fairly typical glitch event (clocked at 500 MHz, 6.25 MHz signal):

Note that sample 54 is shifted negative. If we plot values for that sample from consecutive periods we get this:

Around the glitch over 5 periods we see values -321, -320, -376, -321, -320.

We can also plot the section of the waveform over multiple periods:

You can see that the signal is very repeatable cycle-to-cycle, with only the glitch clearly offset.

Glitch is offset by -56 counts. If we correct it to expected value (-320), we see the two bit patterns:

Errors are in bits 3 and 6.

***-Qing Liu said:

Could you pass your measurement plot shown the glitches to us? Also, timing plot?

Here is the timing sweep. I am moving FPGA clock using a DCM in 24 ps steps. I typically run the clock at -96 ps setting, roughly midway between the error points.

A few more bits of data:

1. ADS54RF63EVM also has glitches, but at a lower rate and amplitude at 500 MHz.

2. On ADS54RF63EVM at 544 MHz the error rate is sensitive to the device temperature (9e-7 glitch rate drops to 6e-7 going from 45degC to 28degC).

3. Glitch rate is sensitive to the +5V supply. Strangely enough it gets better at both 4.8V and 5.2V relative to 5.0V

Hi,

  I looked at 3 plots on sample#54 in your other e-mail, I think I understand the plots. But I like to confirm is this sample #54 a example of the glitch or all glitches you have seen happened at this point each time? I am thinking it is just an example of the random glitches. Please confirm it.

Regards,

Hui Qing

Hello Qing,

Its good we see the same behavior.

I've collected more data meanwhile, will post shortly.

Hello Qing,

***-Qing Liu said:

  I looked at 3 plots on sample#54 in your other e-mail, I think I understand the plots. But I like to confirm is this sample #54 a example of the glitch or all glitches you have seen happened at this point each time? I am thinking it is just an example of the random glitches. Please confirm it.

It is one glitch event of many captured by my code. Normally the real-time system produces output as follows:

Glitch start: 26 (454480)
0       824     29      562     533     561
Glitch start: 16 (4042480)
1       434     17      450     467     451

This shows two glitch events, one of 29 counts, and one of 17 counts. First number on the line is the glitch counter, next is the sample in the period (this was setup with 1040 samples per period), next is the absolute deviation. Last three integers are the samples from previous period, one with the glitch, and the next period.

My code can be setup to dump full data snapshot when a glitch is detected, of course.

Regards,

Dmitry Teytelman

Hello Qing,

First of all, I would like to point out that my numbers are sample error rates (SER), not bit error rates (BER). Typical sample error event has multiple (3-4) bits flipped, so counting bit error rate is somewhat difficult. If glitches involved single bit, then BER=SER/12. But in this case each glitch can contribute multiple bit errors.

Secondly, when you say ADS54RF63 has better error rate than ADS5463, is that compared at the same clock frequency or at the maximum frequencies for each (550 and 500 MHz respectively)?

I have some more data collected with ADS54RF63EVM. Here is a plot of SER versus clock frequency:

Here is the same data on the log scale:

I also see a clear pattern of codes where errors occur. Here is a plot of ADC values where glitch occurs (correct values from next period) vs. sample in the period. This dataset was collected over 6 hours, so there is some phase drift between the synthesizers:

From this it is pretty clear that the ADC "likes" to glitch at transitions spaced by 128 counts. Another way to see this is to plot the histogram of glitch events:

If we zoom in near the zero crossing, we see the following:

Each glitch group is split into two islands, one on positive slopes, one - on negative. For example, on positive slopes we have a glitch around 74 ADC counts and on negative - around 56. Negative values start at -68 and -84. Then there are glitch islands at 74-n*128, 56+n*128, -68-n*128, -84+n*128 where n is positive integer.

Regards,

Dmitry

Qing,

***-Qing Liu said:

Thank you for the test data. I agree with SER. The term BER I mentioned in previous e-mail actually is defined as ER at glitch appears higher than m LSB by the test team, but we some how changed term with some customers. So it has same meaning as SER.

Good to know we are looking at the same numbers.

***-Qing Liu said:

Secondly, when we say ADS54RF63 has better error rate than ADS5463, it means at same frequency especially at max frequency.

So at 500 MHz ADS5463 as higher error rate than ADS54RF63. At the same time, at ADS54RF63 at 550 MHz has error rate around 1.3e-6 - higher than ADS5463 at 500 MHz with the rate of 2e-8.

***-Qing Liu said:

The SER test data looks reasonable comparing with our test data. What is the threshold for glitches in this test?

The threshold is 15 ADC counts (condition is abs(jump)>15)

***-Qing Liu said:

The pattern data is pretty good to show the possible cause from the internal design. I will show it to the designer.

I hope this comes in useful. I am thinking of more ways to home in on the problem. It would be great to identify a solution to this issue.