ADS6444: Zero crossing problems

Hi,

There is a type of logic error that can happen in the deserialization logic that is not immediately visible with the usual test patterns that are available in this device.  That is, if when the deserialized data is being put back together into a sample you have some MSBs of the output belonging to sample n-1 while the rest of the LSBs belong to sample n - this results in things like the custom pattern looking good and the all ones or all zeros looking good - even maybe the toggle pattern but I don't recall on that one.    One real good pattern to detect this kind of error is an arithmetic counting pattern (also called ramp), but the ADS6444 does not provide this pattern.   With a ramp pattern, you can look at the point where the output goes from all 1 on one sample to all 0 on the next and look to see that all 14 bits are on this boundary.    In the absence of a ramp pattern, I like to use a *very* slow sine wave pattern and look at the time domain logic-analyzer style output.   Something like 10KHz.   This makes a very recognizable pattern - the MSB is simple square wave.  The next MSB is a low-high-low-high around the MSB transition then a high-low-high-low around the next.   I am attaching an old ppt of some FPGA debug examples that I put together some time back to illustrate this.    The last picture shows a single bit that is out of place timing-wise although it is in the proper place as far as the LSB to MSB ordering is concerned - just out of place as the timing is concerned.  It is easy to get the deserialized data latched into the parallel output register such that some number of MSBs are one cycle off from the rest of the LSBs.  The ramp pattern can show this quickly, and the slow sine can show this for some of the MSBs but looses its usefulness as you look closer to the LSBs.

Else, show me capture of what your 'spikes' look like and maybe a csv listing of the captured data.

Regards,

Richard P.

deserialFPGAdebug.ppt

Hi Richard,

Thanks for your detailed answer.

As suggested, I've applied an analog ramp on my system and this is what I'm getting:

Don't mind the discontinuity close to the middle, it is due to my triggering schem. Problem are obviously not only at zero crossing and that could validate you time shift between bytes assumption. I'm also attaching the captured data in CSV format (Sample n°, signed value, hex value (2's comp)). The file only contains the 2nd half of the displayed data. I'm using '2-Wire Interface 16x Serialization', but padding zeros are replaced by sign extension in my firmware.

ramp_hex.zip

I'm going to try to spot assumed patterns, but you'll maybe be better than me at that game...

Kind regards,

Jerome

Hi,

I've thought a bit more and noticed that the issue systematically occurs when bit 8 increases or other said when lowest byte wraps around.
That tends to validate a time shift problem between MSByte and LSByte .

That is a bit surprizing is that the same occurs on the 4 channels. Using "2-Wire Interface 16x Serialization, Byte-Wise Mode", MSByte and LSByte are each transmitted on their own LVDS pair and deserialized separately.

On FPGA side, I'm using "DDR Data Reception Using Two BUFIO2s" as adviced by XAPP1064.

Anybody having faced the same issue? Any advice/solution?

Kind regards,
Jerome