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.

ADC16DX370 serial data errors

Other Parts Discussed in Thread: ADC16DX370, THS4509

I have a board that uses an ADC16DX370 with a 325 MHz clock. I am using just one channel (A). The ADC is connected to a GTH transceiver of a Xilinx Kintex UltraScale FPGA.

Described in few words, the problems I observe is the following: when the analog signal level is low, the serial data transmission is perfect. However, when the analog signal level increases to about -27 dB FS, the GTH (SERDES) core reports very frequent line code errors which produce a resynchronisation (SYNCb assertion) of the ADC.

It follows the details:

  • The analog input is DC coupled to a THS4509 differential driver through two serial 10R resistors and one 200R resistor in differential termination, in parallel to the input, forming a low attenuation voltage divider.The common mode voltage of the amplifier comes from the ADC. Values are inside specification, very close to nominal ones. There is low noise, however there was previous measurements that revealed low frequency noise. However, I could not repeat measurement, maybe due to poor probe grounding.
  • The CLKIN comes for a IDT8T49N203 whose outout is configured for LVDS level. It is AC coupled with 2x100 nF capactitors. Clock frequency is 325 MHz.
  • SYSREF comes from the FPGA through an FMC interface. The line is AC coupled and includes a termination resistor like figure 48 of ADC datasheet. The OM1 register has been configured to 0x85, as recommended. I make an initial synchronisation and then the gate is disabled.
  • SYNCb is comes from the FPGA through direct connection to the ADC (as in figure 51 of the ADC datasheet)
  • ADC serial data output is connected to a FPGA GTH input through 2x10 nF capacitors.

The serial differential pairs have been traced with great care in the PCB.

When the ADC sees a very small signal level (just noise) the operation is flawless. SYNCB synchronisation is done at the beggining and everything runs smoothly.

When I insert a tone whose level is about 0.046 of full scale (peak output codes about 730 and -2200) everything is also correct.

However, if I slightly increase (1 dB) the analog input level, the GTH transceiver in the FPGA reports errors in very frequenct bursts and the logic in the FPGA activate the SYNCb output in order to force reaquisition of the serial signal.

I have checked OVRA signal and does not activate. It does when the signal level is very high.

If I program JESD204B test patterns like JESD_TEST_MODES=7, everything runs flawlessly despite the level of the analog signal at the output. I have also tested ramp test with different steps sizes and the result is also perfect: no errors, no resyncs and perfect ramps.

While an slow ramp test (RSTEP=1) is running, I tried to program different deemphasis levels in order to check the serial link robustness. No errors were found in the line while VOD is 0 and DEM is configured to any value from 0 to 7.

While in normal mode operation with the highest level sinusoid that produces no errors, I changed the preemphasis configuration. When DEM is 0 to 5, no line code errors were detected. When DEM is configured to 6, very esporadic error bursts are detected and when DEM is configured to 7 there are bursts of errors. Sometimes the error is just a byte and does not activates SYNCb, sometimes are longer and the SYNCb reacquisition sequence is triggered.

I have been able to see that the SYNCb activation is allways a consecuence of a large burst of errors (and not the inverse order).

I have tested two boards, with the same result.

It seems to be an  interaction between the an alog input level and the serial data output, but this is very unlikely.

While I continue investigating all comments are welcomed.

Best regards

Luis Migue

  • Hi Luis

    Does the FPGA receiver report the type of errors that are encountered at that particular signal level?

    Is the error reported on just the data lanes related to the ADC input with the signal or on all of the data lanes?

    Does the problem occur regardless of which input the signal is applied to?

    Does the problem occur with L=1 and with L=2?

    Is scrambling enabled? If it is currently disabled, does enabling scrambling change the behavior?

    Best regards,

    Jim B

     

  • Dear Jim,

    Thank you for your fast response:

    Q. Does the FPGA receiver report the type of errors that are encountered at that particular signal level?

    A. No. We are investigating if we can obtain more detailed information

    Q. Is the error reported on just the data lanes related to the ADC input with the signal or on all of the data lanes?
    Does the problem occur regardless of which input the signal is applied to?

    Does the problem occur with L=1 and with L=2?

    We use just one lane, just one ADC: single data line

    Q. Is scrambling enabled? If it is currently disabled, does enabling scrambling change the behavior?

    Sorry, our JESD204B block does not support scrambling.


    I have had an interrupt in my work. I will let you know if there is more data.

    Best regards

    Luis Miguel

  • Hi Jim,

    My research does not give great insight for time being.

    All I have observed that worths reporting is that setting the SR (Soft Reset) bit in CONFIG_A register seems not to fulfill the sencente "causes all registers to be reset to their default state". As an example, JESD_CTRL1 register does not change to default state after a soft reset.

    Do you recommend a configuration sequence? We have applied a common sense approach:

    1. Configure SFI_CFG for proper SPI voltage
    2. Wait for assertion of CLK_RDY, CAL_DONE and PLL_LOCK in JESD_STATUS
    3. Apply a Soft Reset (SD) in CONFIG_A
    4. Configure all relevant registers. The only difference from default is JESD_CTRL1, which is done in two steps. First to disable JESD and then to configure K=9, single lane, JESD enable
    5. We configure the FPGA to generate the SYSREF signal
    6. We wait ultil ADC reports LINK active in JESD_STATUS
    7. We reconfigure OM1 for IDLE equal to 0b01 and SYS_EN to 0

    Could you confirm if this is correct?

    Best regards

    Luis Miguel

  • Hi Jim,

    The news about debugging are:
    * We were applying Soft Reset (SR) incorrectly. The state of bit 7 has to be replied in bit 0. This was corrected.
    * We have changed the clock to 173 MHz (half of nominal rate) and the incorrect behavior continues and the signal level for errors is virtually the same before.
    * We have programmed a recalibration sequence in the initialization routine for evey configuration we do. We did also some other maybe improvements in the configuration sequence. No change in behavior.
    * We have removed the ADC input circuitry and we inject analog signal from a well proven differential driver. Same behavior.

    We are decided to remove the chip and test with another new device: we wonder if the one we are testing is broken.
    Best regards
  • Luis,

    Thanks for your detailed information. Your start-up sequence looks OK.

    The fact that the ramp pattern is running flawlesly at full speed makes me confident that the back-end JESD204B interface and signal integrity is working OK. Still, it appears that the JESD204 link is affected when the input amplitude becomes large. I am inclined to think that the ADC core is in an unfavorable condition which is most stressed then the ADC is at large amplitude, and that the JESD204 link is indirectly impacted when the core is stressed. This makes me think there is an issue with the power supplies. I do have other theories as well.

    Here are some suspected potential causes at this time:

    - The ADC supplies are having a noise issue. Perhaps an issue with insufficient decoupling.

    - The JESD204 link is having issues handling alignment characters. If you find the the link is breaking due to detection of illegal alignment characters, we can investigate this option further.

    - The input common-mode to the analog input is not tighly controlled and is causing gross issues with the first and second stages of the pipeline ADC core.

    Can you please share a schematic and layout so that I may review supply routing, decoupling, and generally the circuits around the ADC? We can do this through personal correspondance instead of the forum if desired.

    Regards, Josh

  • Joshua,

    I have the requested documentation ready to send. Please, let me know your email address.

    Best regards

    Luis Miguel

  • We have changed the device in one of the boards and the performance remains the same: line code errors when signal level above a threshold.

    Regards

    Luis Miguel

  • The problem is solved and it is not correlated at all to ADC but to FPGA.

    The JESD204 standard makes use of the K.28.7 comma symbol, which may produce false misaligned comma symbol overlapping under certain conditions which are data dependent.

    The Xilinx GTH/GTX cores include control lines (rxpcommaalignen_in and rxmcommaalignen_in) that allow disabling comma alignment once synchronisation has been reached.

    Best regards

    Luis Miguel