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.

  • Resolved

ADC3424: Misalignment of data channels and frame clock

Prodigy 40 points

Replies: 6

Views: 207

Part Number: ADC3424

Hello,

in our project we use the ADC3424 part in 2-wire mode sampling at 40MSPS.

We acquire data with an FPGA that performs deserialization and bitslips the data.

We use frame clock FCLK as a reference for our bitslipping procedure.

In a few cases we observed that data at the channel and FCLK gets misaligned.

FPGA is correctly aligned to FCLK but data has an error offset by 3 to 5 bit positions.

Also when this happens, error is different for each channel of the ADC.

For example: we get an error of 3 bits for channel A and 5 bits for channel B.

We observed one additional problem when using the test patterns in ADC's erroneous state.

There seems to be bit error even between two lanes of one channel - e.g: DA0 has error of 3 bits and DA1 has an error of 4 bits.

Is this an expected behavior? I think test patterns are free running and I am unsure whether the lanes in a channel are aligned in this mode.

According to timing diagram (Figure 130 in datasheet) data should be aligned to frame clock.

Only variable propagation delay mentioned in datasheet is t_PDI that applies to propagation of input clock to FCLK.

I assume that data clock DCLK and FCLK should be always aligned considering they are sourced from the same PLL.

Can you provide me more information on timing between clocks and data channels? Is it possible there is no deterministic relationship between them?

Is aligning to FCLK clock a valid option or should we consider do the alignment with test patterns instead?

We tried to reset the ADC via reset pin and software reset but that did not change anything. Only power cycling the board helps.

Thank you.

Best regards,

Jakub

  • Hi Jakub,

    Yes, DCLK and FCLK are aligned as you have described.

    Triggering the FPGA data acquisition off of the FCLK or DCLK should be reliable.

    Is a hardware reset being performed as part of start up? Are any register writes being performed for the expected normal operation?

    When you see the error in the data, is it a shifting of data, or is it just completely wrong? Can you share a screen shot of what one of these errors looks like?

    Best Regards,

    Dan

  • In reply to dBrock:

    Hi Dan,

    thank you for a quick response.

    We do perform hardware reset on the ADC. Although it seems it doesn't impact the ADC behavior if we trigger it again when erroneous state happens.

    Triggering the software reset does not help either.

    We don't change any registers since default configuration of the ADC works fine for us, we only start test patterns for debugging.

    When we see the error, the data is shifted.

    I cannot share a screenshot right now. It is hard to reproduce, because it happens once in many power cycles.

    But lucky enough, colleague of mine debugged the board in the last erroneous state with test patterns an this is what we got for channel DAx:

    ADC Test Pattern Data Received in the FPGA Channel 0 shifted by # bit positions Channel 1 shifted by # bit positions
    0x800 0x100 N/A 3 to the right
    0x400 0x080 N/A 3 to the right
    0x200 0x040 N/A 3 to the right
    0x100 0x800 N/A 3 to the right
    0x080 0x400 N/A 3 to the right
    0x040 0x200 N/A 3 to the right
    0x020 0x001 5 to the right N/A
    0x010 0x020 5 to the right N/A
    0x008 0x010 5 to the right N/A
    0x004 0x008 5 to the right N/A
    0x002 0x004 5 to the right N/A
    0x001 0x002 5 to the right N/A
    0xF0F 0x9DE 5 to the right 3 to the right
    0x0F0 0x621 5 to the right 3 to the right
    0xF00 0x9C0 N/A 3 to the right
    0x00F 0x01E 5 to the right N/A
    0xE00 0x1C0 N/A 3 to the right
    0x1C0 0xE00 N/A 3 to the right
    0x038 0x031 5 to the right N/A
    0x007 0x00E 5 to the right N/A

    For channel DBx we got these errors: DB0 by 5 bits to the right, DB1 by 4 bits to the right.

    He didn't get the data for channels DCx and DDx, but you should be able to get the overall idea.

    What troubles me is the fact that the bit shift is not consistent within one data channel in 2-wire mode.

    Thank you.

    Best regards,

    Jakub

  • In reply to Jakub Tomko:

    Hi Jakub,

    I am not certain as to why this is happening. It looks like it could be a firmware issue though. Do you have a way to test the firmware without the use of the ADC?

    For instance, when you get into this error state, can you reset the firmware and see if that clears the issue?

    Are you able to share a schematic? What is the sampling clock source? Can we verify that the clock source / power rails is not getting disturbed during the error state?

    Best Regards,

    Dan

  • In reply to dBrock:

    Hi Dan,

    we thought it could be a FPGA FW issue. We tried multiple resets, reboots, and even flashing with a bit different version of the FW, although the ADC interface logic is still the same. None of these changed anything. Once in the error state only power cycling of the ADC board helps.

    The number of bits the data is shifted by always remains the same after each reset or reboot of the FPGA.

    This behavior made me think of some misalignment between FCLK and data channels.

    We provide sampling clock from SI5338B (https://www.silabs.com/timing/clock-generators/general-purpose/device.si5338b)

    I cannot confirm that power rails do not get disturbed. It is under further investigation since the module is part of the larger fairly complex system.

    Wouldn't a reset recover the ADC from the error state once power rails are stable? Communication with the ADC works fine. We are able to set registers and ADC responds to it as expected, only the data continues to be shifted. If there is power rail disturbance, I think it gets stabilized over time.

    Best regards,

    Jakub

  • In reply to Jakub Tomko:

    Hi Jakub,

    Do you happen to have access to an oscilloscope or logic analyzer? If you are able to probe the FCLK and the data lines for one channel coming out of the ADC (please share images), we can see what the ADC is actually putting out. I think this will help to best guide our troubleshooting efforts at this point.

    Additionally, if you are able to share the ADC schematic, this would be helpful.

    Best Regards,

    Dan

  • In reply to dBrock:

    Hi Dan,

    I am sorry for late response, but we did investigate it a bit more and now we know the cause.

    We found out that out system occasionally experiences a power supply outage for ADC's analog supply while digital supply is OK.

    This always gets the ADC into a weird error state - SERDES interface sends wrong data and if you read SPI registers you receive random values.

    Resetting the ADC helps though.

    Our problem was a bit more complex since it was masked by the FPGA a bit.

    This happened to us:

    1. Our system booted up correctly (all power supplies up), ADC was reset, afterward FPGA logic does bitslip procedure to align data channels etc.

    2. Analog power supply outage happens. During this event DCLK is glitching which causes SERDES cells in the FPGA to have different bitslip values and thus the bitslip difference per lane in channel, etc.

    3. After last event ADC is stuck in error state and DCLK is inactive.

    4. We reset  the ADC

    5. ADC is functioning and DCLK is active again.

    6. FPGA logic deserializes data and since we got corruption in bitslip logic due to DCLK glitches we get different offset per each lane/channel only FCLK is correctly aligned since it is the reference signal.

    7. Resetting the SERDES cells is enough to get it back in order, but we did more automated recovery logic for our use case.

    Our testing proves that ADC gets into error state even when digital supply is up first and analog one a few seconds later.

    I hope this post helps anyone encountering the same behavior.

    Thank you.

    Best regards,

    Jakub

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.