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.

ADC3669EVM:Data corruption - ADC3669EVM

Part Number: ADC3669EVM

Tool/software:

Hello,

I am experiencing an issue with the ADC3669EVM Devkit. Below, I will describe the problem.

The ADC3669EVM kit is running on the Agilex 7 platform - AGIB027R31B1E1VB. The device is connected to FMC B, and the sampling clock is set to 400 MHz.

The first issue I encountered is as follows: the device, purchased in December 2024, is labeled as REV. B on the silkscreen layer of the PCB. However, the documentation (schematics) available online corresponds to version C - REV. C.

The documentation states that component R125 is not soldered. This pin, pulled to GND, detects whether the module is connected to the FMC. In REV. B, such a designation does not exist. By tracing the pin from the FMC, I discovered that it corresponds to R188. Let’s say this problem has been resolved.

The next issue is more serious, namely data corruption on certain bits.

I configured the ADC test pattern to RAMP. On the FPGA side, I collect data on the rising and falling edges, and I observe the following effect: some bits are shifted.








The FPGA design is timing-consistent, so the issue likely isn't there. On the FPGA side, I tried shifting the CLK phase. The result was that the alignment improved for some bits but worsened for others.

I also attempted applying delays to individual lines from the FPGA. While this partially improved the situation, it didn't fully resolve the issue.

Could you assist with this problem?

  • Hi Robert,

    Kindly confirm if you are carrying out some form of IO calibration in order to meet timing at 400MHz (800Mbps). Your data corruption issue seems to indicate that there is a bit slip on some of the lanes, which is dependent on the capture architecture. This can happen during IO calibration (if each data lane is tuned independently and lanes correct in a way that they are skewed by a bit). In addition if you are using SERDES instances, the the reset to the SERDES of all the lanes should be synchronously de-asserted (else the de-serialization counters can be out of sync). 

    If you are doing neither and just using IDDR elements (possibly in same_edge mode), then it does seem to point to a timing issue. Does the issue get corrected if you slow down the clock rate?

    Regards,

    Ameet