ADC3422: test PRBS generated on LVDS outputs

Hello,

I'm adding here some more information I discovered.

I tried to plot waveforms of samples received and acquired from a real ADC.

High bits of each channel (A,B,C,D) have always the same value, so are driven from the same source.

Definitely this is not the case for a true LFSR generated value...

Please give your advice.

Thanks

Andrea

Hi Andrea,

Have you tried other test pattern modes, such as a ramp test pattern?

If so, does that look correct?

Please advise.

Thanks,

Rob

Hello,

as I specified in my previous posts, I tried also alternate and ramp patterns,

which seem to work.

Ramp pattern produces numbers from 0 to 4095, however each number is repeated 4 times:

I receive, for each channel, 0,0,0,0,1,1,1,1,2,2,2,2,3,3,3,3,4,4,4,4,5,5,5,5,6,6,6,6, ....and so on.

The channels are not synchronized, so the ramps have random offsets.

This behavior could represent a situation where a 14bit up-counter is used, but only most significant bits [14:2] are produced at output (this ADC is 12bit). I suppose this is correct.

The data received from ADC during normal operation also seems good, however occasionally I receive some strange peak, which I would investigate.

Furthermore, I would implement a delay calibration procedure, but I would use pseudorandom pattern having any bit changing randomly, instead of ramp pattern, with most significant bits moving very slow with respect to less significant. Calibration is less effective.

Please let me know about the PRBS pattern generator.

If possible, please send also a generated data sequence, so I can validate my test logic against realistic data. I'm not able to explain how the data I receive is generated.

If it could help with double-check, I could send a couple of binary files with data received from ADC with ramp and PRBS patterns.

Thanks

Andrea

Hi Andrea,

Please see the attached config file with the proper register sequence and also this help align the outputs.

Regards,

Rob

RampAlign.cfg

Here is the pic of the ADC GUI, where this needs to be checked in order to align the ADC channel outputs

Hi Rob,

the alignment settings are not a problem.

All I really need is: how are PRBS data generated?

Please supply a correct example sequence, and explain how you generate it.

Thanks

Andrea

Hi Andrea,

I will need to discuss with design on those specifics. Please give me a few days to respond back.

Thanks,

Rob

Dear Rob,

this is the very same answer I received on my first post.

However, I analyzed DEEPLY the results of real hardware, and I'm quite sure that something is wrong in this answer.

This can be clearly demonstrated looking at the waveforms I posted.

An LFSR is basically a shift register with a feedback from xorred taps toward the input. Using 1+x^18+x^23 polynome, taps bits 22 and 17 are used to generate the next bit0; this respects what you write on the example code. This means: bits [15:2] used for the output should be simply shifted left, sample by sample. Do you agree?

Now please look the waveforms I posted:

- bits [5:0] show pseudorandom patterns, but bits clearly are not simply shifted.

-bits [11:6] have all the same value in each sample. Probably these are generated by the very same source. Again not simply shifted.

My assumption is, the PRBS23 alone can't produce these patterns.

Maybe output bits values are derived from LFSR taps with some permutation and/or some bit replications.

Please check about this info with technical stuff.

Thanks

Andrea

Hi Andrea,

Thank you for your patience.

I have spoken to design and I need to collect some data in the lab for them to analyze.

I will give you an update on this by the end of the week.

Regards,

Rob

Hi Rob,

thanks for the effort.

If it can be useful, I can send you binary files with data dumped from all channels simultaneously, for both the RAMP and PRBS tests.

Thanks

Andrea

Hi Andrea,

To summarize, I think you are saying the following two things.

1. Output data is not PRBS

2. If the output data was prbs_data[15:2], then each bit should have been a shifted version of the next bit because you are obtained it from an LFSR. Seems you are not observing it like that.

However, this data I captured from the ADC in PRBS test pattern mode, shows we are not seeing (2). The bits are shifted versions of each other. Please see attached.

Thanks,

Rob

ADC3422-PRBS.csv

Hi Rob,

thanks for the efforts.

Could you please clarify what are the values on the first columns of the spreadsheet?

I suppose you are testing only one channel here. Indeed it seems an LFSR!

Could you specify how the output interface is configured?

Are you using one or two lanes for the data?

In my test I used two lanes, where lane0 has data changing in random mode, while lane1 has the "stuck" bits. I also enabled the PRBS test on all channels at the same time. Don't know if it could affect the result.

Thanks

Andrea

Hi Andrea,

In the spreadsheet, the first columns are data from 4 channels, next 12 columns are individual bits, next 12 columns are difference between one bit and shifted version of next bit

I did not capture in two lane mode, as this is new information. Are there any other features or configurations being enabled/disabled?

I will retake the data in two lane mode and forward you what I am seeing. It might be possible one of your lanes is stuck.

Does the ramp pattern look correct in two mode?

Thanks,

Rob

Hi Rob,

you are absolutely right, it is better to share the same configuration.

After generation of sampling clock and hardware reset of the ADC, I write registers with following sequence:

# REG 06, reset, normal mode
400601
400600

# REG 70A, disable SYSREF
470A01

# REG 03, configure interface bit ordering 0,1,2 and so forth
400300

# REG 04, configure interface wires unflipped
400400

# REG 05, configure interface two wires
400500

# REG 00A, PRBS test mode on CHA, CHB
400A88

# REG 00B, PRBS test mode on CHC, CHD
400B88

# REG 006, enable test pattern
400602

After configuration, I receive data from the interface.

I attached two binary files for you to double check the results.

ADC_ramp.zip

ADC_PRBS.zip

Data from all four channels is written in ordered mode, A, B, C, D and repeat, 16bit little-endian per word (only 12bit MSB are used, remaining 4 are zero).

If you configure a binary viewer for 8 bytes per line, 2 bytes per group, it is easy to read the data directly.

Here is RAMP test result: as you can see channel A is generating 1EB 1EB 1EB 1EB 1EC 1EC 1EC 1EC, and so on.

Similarly channels B, C and D are also generation ramp data, increased only every four samples.

I checked this behavior on a large amount of data, it is correctly generation a RAMP 0-4095, using all bits.

No errors, all channel work as expected.

Now the PRBS.

The data from one could be plotted in a waveform as in my previous post.

Bits [5:0] received from lane 0 seem to move randomly, but not shifting like in a LFSR.

Bits [11:6] received from lane 1 also change state (the lane definitely is not stuck electrically, RAMP works!), but they assume almost always the same value, i.e. value is repeated inside the same frame.

Here you see a detail of bits [11:6] of previous screenshot.

Bit 6 some time differs from value of other bits.

Hope you can understand something from these data.

Thanks for your advice.

Thanks

Andrea

Hi Andrea,

Just a quick update, I am looking into this and discussing with design on the results.

Just a silly question if the data formatting on your side correct? The data should be in 2s compliment when capturing.

Regards,

Rob

Hello Rob,

real sample data is captured with sign (2 complement). 

However, I don't think this should be relevant. 

I suppose, when internal pattern generation is used, sample format should have no effect.

Andrea

Okay, thank you for verifying Andrea.

I am still waiting to hear back from design.

Regards,

Rob

Hi Andrea,

This is a 12-bit version of the parent device, which is 14-bit. Because of this, you'll see the ramp repeat the same output code 4x before incrementing to the next as you indicated in a previous post. Just wanted to give context to that.

I can confirm that your register sequence posted is correct and does indeed achieve PRBS. Also, you can use the align test pattern to align the PRBS of all the ADC channels. I am suspecting the issue is in the way your data is being offloaded or unpacked - perhaps the samples are out of order. This problem may be masked in the ramp mode due to the repeating values. My recommendation to test your sample unpacking is to supply a sine wave into the ADC as an input. It doesn't have to be high power or frequency, just needs to be something so you can clearly see the rising edge of the sine wave in the sampled data when samples are plotted.

I would be surprised if your captured sine wave is clean because I am able to achieve the PRBS on my side with your exact register sequence. Because of that, I suspect your sine wave will be full of discontinuities. However, if the sine wave is indeed clean and the sample order is correct, then this would indicate some problem with your specific device not generating a PRBS correctly - which could be due to power supply issue or the ADC itself... and I would then have to ask if this is seen on multiple devices/hardware or if the issue is only with this single device/hardware which you are testing with.

Thanks, Chase

Please share the raw data immediately out of your FPGA before any sample unpacking as well for the case with the sine wave. Also please post the image of the sampled sine wave when you can test this.

Hi Chase,

I already tried to capture a real signal, i.e. an analog sinewave or also more complex signals (modulated), and they are fine. So I suppose the data is sampled and captured correctly from the interface. Also the RAMP test works as expected (same value repeated 4x times).

As additional test, I now enabled the SINE pattern, in place of the PRBS or RAMP, to see the result.

Here you can see captured data bits from ILA just after the SERDES inputs, related to channel A only.

The SERDES perform 6:1 input capture, i.e. provide 6bits at output for each clock cycle. Q6 is the first value received from the input, Q1 the last.

I have two SERDES, for DA0 and DA1.

Captured data is fed in three 4bit signals D0[3:0] = DA0[Q3-Q6], D1[3:0] = DA1[Q5-Q6],DA0[Q1-Q2], D2[3:2] = DA1[Q1-Q4].

This means that sample data is concatenation of D2,D1, D0, i.e. SA[11:0] = D2[3:0],D1[3:0],D0[3:0]

Also see packed data from all channels (12bits per channel, i.e. bits[11:0] are CHA, bits[23:12] are CHB, and so on). Data sequence is exactly the same in all channels, and the same from previous picture for channel A only, but obviously is shifted in time channel-to-channel, because synchronization is not enabled.

The shape is a sinewave indeed, the signed values 000, 3D2, 568, 3D2, 000, C2D, A97, C2D.

Here a plot of samples from all channels.

The values however again are not those indicated in the datasheet (unsigned), i.e. 000, 257, 800, DA8, FFF, DA8, 800, 257.

Both are 8-point sinewaves, however they have different level.

How could this be explained, given that they are constant  values stored inside the chip?

Are you performing your tests with an ADC3422 or with the 14bit version you mentioned (maybe the ADC3442?), which could be partially different?

Could you confirm that you are using the interface with both the two lanes Dx0 and Dx1?

Could you send a binary file with captured PRBS data?

The chip I have has markings below:

I still suspect there's something strange in the ADC3422, that is not quite as described from the datasheet.

Thanks

Andrea

Hi Chase,

I converted you sequence for SINE to hex values, an it is exacly the same as mine:

0=000, -979=C2D, -1385=A97, 978=3D2, 1384=568

Basically this confirms that our interface works as expected, and datasheet values for sine pattern are wrong.

Now I'm checking your results with the PRBS.

I see you only use generation synchronized on all channels, which I never tried yet.

Maybe this difference is important.

Did you already compare these values with the LFSR formula you provided time ago?

Thanks

Andrea

Hi Chase,

I tested you file with the FPGA simulator, the PRBS checker locks after several samples and then remains locked. PRBS checker works. Your data sequence is perfect.

I'm trying now to replicate what you did to generate the PRBS samples.

I modified my scripts to write 0x02 to register 0x09, i.e. enabling pattern synchronization on all channels.

This means, the PRBS pattern generator doesn't work at all without channel synchronization.

Could you confirm this?

Anyway, with synchronization enabled the data looks far better, finally all the bits "almost" show a shift register behavior. However, the PRBS checker still doesn't lock...

I checked the data waveforms, and I still saw something wrong happens.

During the shift, some bits "disappear" and then "reappear" later in time. 

I thought about a bit error in the interface, however all the channels A,B,C,D always show the very same value, which would be not very probable if the problem was a borderline bit sampling. Again, all other patterns are always fine with zero errors...

I'm operating at 49.5 MSps. I could try to reduce the sampling rate to see if the problem is related.

What sampling rate did you use for the tests?

What is your advice?

Andrea

Hi Andrea,

I used 50MSPS. The align bit doesn’t need to be on for PRBS to work. It worked fine on individual or more than one channel, but just not aligned. I’d suggest running at 25MSPS or something considerably slower and then bumping up. Do you need the PRBS to work for mass test or is sine wave pattern okay? The align bit makes all channels of the device fully aligned for any of the test modes, so that would be a good replacement test, much more lightweight also than a lfsr checker. We usually only advise PRBS as debug step for higher data rate interfaces, 2x mode will be 6x serialization factor so your data rate is only 300Mbps. If you cut sample rate in half this should cut in half also. I still think it’s strange for you to see incorrect data on all the channels synchronously. That doesn’t make me think signal integrity. Perhaps DVDD supply for that code is much higher current and causing a drops out of the supply or something similar. Can you share power supply schematic?

Thanks

> The align bit doesn’t need to be on for PRBS to work.

This is very strange. In my configuration without sync it goes completely nuts,

so in PRBS mode it has a completely different behavior. Other patters do work as expected.

> We usually only advise PRBS as debug step for higher data rate interfaces.

I would use PRBS to implement an automatic delay tuning function on the LVDS interface, as our devices shall operate on very large temperature ranges. Also, the current 50MSps rate is just a starting point, as we would reuse also the 125MSps version of the ADC on the same PCB.

I would prefer a fully unsynchronized checker, otherwise there's data repetition on alternate lanes.

> I still think it’s strange for you to see incorrect data on all the channels synchronously.

This indeed is what let me think that maybe the problem is not on the interface.

The schematic of the ADC section.

The +1V8D is generated from a switching DC/DC shared with the FPGA banks hosting the LVDS interface and other electronic devices. This DC/DC can supply several amperes, I don't detect peaks/dips on +1V8D.

Maybe there's an errata for this chip, maybe the version I'm using is bugged?

Can you understand something from the datecode I sent to you?

Do you think it could worth to try with another chip lot?

Andrea

Hi Andrea,

To me personally, I don't know how to decode the package markings. I'm asking around for info on this. I'll let you know if there is any concerns with it.

If you have other device you can solder to the board and retest that would be good. I don't think you answered my previous question on if this is occurring on just this one board/device or if this behavior is seen on multiple devices.

Thanks, Chase

Hi Chase,

maybe I found a problem in the structure of variable delay lines in the FPGA inputs, which could lead to data corruption and partial interference across separate lanes. I have to perform more tests to check this.

I hope this is the cause of the problem.

Stay tuned.

Andrea