ADS62P24 EVM spurious codes at midpoint (0V).

Hi,

I have seen this kind of result if one of the bits of the sample is not aligned with the other bits through the pipeline stages of the FPGA.  This is easier to do with deserializing the serial formats than with the DDR formats.  But still - if you *could* use the SPI port you could enable the test pattern called digital ramp (register 16) and this makes the outputs an arithmetic counting pattern.  This makes it easy to see that you have the msb in the right position, as well as lsb and every bit in between.  Also by looking at the sample position where the arithmetic count rolls over you can check that the pipeline delay for every bit matches.  Very helpful pattern.

in your case, it may simply be that you have the DDR positions flipped.  You may be seeing bit 10-11-8-9-6-7-4-5-2-3-0-1 instead of 11-10-9-8-7-6-5-4-3-2-1-0.   Or, you may have the bit ordering correct at 11-10-9-8-7-6-5-4-3-2-1-0 but it may be a case of bits 11,9,7,5,3,1 being from sample n while bits 10-8-6-4-2-0 are from either sample n+1 or n-1.  This is actually what i think you have going on here.  Note the datasheet polarity for the LVDS DDR clock and which edge is odd bits adn which is even, adn then pay close attention to whether the clock polarity gets inverted either in the routing of the TSW1200 or the EVM circuit board.  My TSW1200 firmware has a register bit to swap whether the rising edge of the DDR clock is first in a sample or the falling edge is.  Notice at midscale where the msb flips position you have one sample where the msb is inverted.  It may not be inverted so much as delayed one cycle.  Looking at your plots it looks like there are some other positions where there is a repetitive but smaller negative spike at the same point on every rising edge and a repetive smaller positive spike on the falling edge, and in between them even smaller repetitive deviations - possibly due to bits being out of position in time.

Regards,

Richard P.

Richard,

Thanks for the help. I thought I might be seeing bit ordering problems and thought I resolved those, but I never thought about the clock side of things. I coded up the spi interface on your suggestion to take advantage of the test patterns. I also had to changes some resistors on the ADS for serial mode.

Finally got a chance to test it in the lab and I see it trying to send the pattern, but I no longer get an LVDS clock out. When I put it back in parallel only mode, I get the clock back. Is there something I missing in the documentation  regarding setting the clock up in serial mode?

I first write a reset to the reset register and then program the pattern register to generate a ramp. (the reset pin is not longer connected to the FPGA connector). I leave all the other registers in their default configuration after the reset.

Thanks,

Anthony

Richard Prentice said:

Hi,

I have seen this kind of result if one of the bits of the sample is not aligned with the other bits through the pipeline stages of the FPGA.  This is easier to do with deserializing the serial formats than with the DDR formats.  But still - if you *could* use the SPI port you could enable the test pattern called digital ramp (register 16) and this makes the outputs an arithmetic counting pattern.  This makes it easy to see that you have the msb in the right position, as well as lsb and every bit in between.  Also by looking at the sample position where the arithmetic count rolls over you can check that the pipeline delay for every bit matches.  Very helpful pattern.

in your case, it may simply be that you have the DDR positions flipped.  You may be seeing bit 10-11-8-9-6-7-4-5-2-3-0-1 instead of 11-10-9-8-7-6-5-4-3-2-1-0.   Or, you may have the bit ordering correct at 11-10-9-8-7-6-5-4-3-2-1-0 but it may be a case of bits 11,9,7,5,3,1 being from sample n while bits 10-8-6-4-2-0 are from either sample n+1 or n-1.  This is actually what i think you have going on here.  Note the datasheet polarity for the LVDS DDR clock and which edge is odd bits adn which is even, adn then pay close attention to whether the clock polarity gets inverted either in the routing of the TSW1200 or the EVM circuit board.  My TSW1200 firmware has a register bit to swap whether the rising edge of the DDR clock is first in a sample or the falling edge is.  Notice at midscale where the msb flips position you have one sample where the msb is inverted.  It may not be inverted so much as delayed one cycle.  Looking at your plots it looks like there are some other positions where there is a repetitive but smaller negative spike at the same point on every rising edge and a repetive smaller positive spike on the falling edge, and in between them even smaller repetitive deviations - possibly due to bits being out of position in time.

Regards,

Richard P.

KH,

Thank you for the help. I have it working now. The override bit was key. I was having a problem programming the ADS because the schematic for the ADS62PXX and the TSW1200 had the SEN and SCLK pins swapped on the high speed connector. It is just a labeling issue, and once I changed the pins in the FPGA, it worked fine. Just thought I would mention that in case someone else runs across it.

Thanks again,

Anthony