Problem Description
Recently, while debugging a system project, I discovered that after successfully establishing a link with the ADC and DAC on the main control board, the link would automatically drop. This phenomenon was consistent across multiple attempts to establish the link. The ADC used is the domestic AD9680, and the DAC is the domestic AD9154. The following diagram shows the timing diagram captured by the ILA during the link establishment, where it was found that the ADC received the K code normally, but the link would automatically drop as soon as the ADC and DAC were linked. This issue is consistently reproducible.
The following diagram shows the block diagram of the ADC and DAC.AD9680
AD9154
Problem Analysis
First, I checked the power supplies for the ADC and DAC, and the tests showed that they were all normal. The 2G clock provided to the DAC and the 1G clock provided to the ADC were normal as well. The GTH reference clock provided to the FPGA was also normal. The clock phase noise metrics were within range. When reading the clock chip’s lock status, it was found to be locked normally.I suspected that the core voltage provided to the FPGA might be borderline, causing anomalies after the link was established. However, measurements showed that the core voltage was normal.Since all high-speed interfaces on the board were nearly used up, and other high-speed interfaces were used for fiber communication, I tested whether the other optical ports were functioning normally to verify the related power supply. All optical ports established links normally, and there were no link drops during stress testing.
I checked the register configurations for the DAC and ADC, verified the 204B mode for both, and found no issues. Reading the lock registers for both the ADC and DAC showed that they were in a locked state.ADC Lock Status IndicationThe following diagram shows the ADC lock status indication.
By reading back the lock register through software, the lock register was found to be normal, as shown below:
DAC Lock Status IndicationThe following diagram shows the DAC lock status indication.
By reading back the lock register through software, the lock register was found to be normal, as shown below. Since only 4 lanes were used, the readback value was 0x0f.
I checked the 204B core and PHY core configurations on the FPGA side, and all configurations were normal, with correct line rates.Transmitting 204B Core Configuration
Receiving 204B Core Configuration
204B PHY Core Configuration
By configuring the ADC mode, I tested the ADC’s bit error rate and eye diagram, both of which were normal, with no bit errors. The quality of the eye diagram was also acceptable.
This issue troubled me for several days, and I felt that I had checked everything that could be checked. After communicating with technical support, it became clear that the root cause of the problem still revolved around power supply, clock, phase noise, and clock jitter. I decided to recheck all of these points. Upon rechecking, I found that the GTH reference clock provided to the FPGA was normal, but the system clock frequency provided was incorrect. Since the core clock used by the 204B is generated from the system clock, this led to an incorrect core clock frequency for the 204B. Actual measurements showed that the frequency deviated slightly from the required frequency, but the difference was not significant. This explains why the link could be established but dropped afterward. If the frequency deviation were very large, it would likely be impossible to establish the link. The K code transmission and reception are related to the underlying PHY, and the GTH reference clock is normal, as are the clocks for the ADC and DAC. Therefore, the underlying K code transmission and reception have always been normal.After modifying the clock configuration, I measured the system clock of the FPGA, which was normal. I then conducted the link establishment test again, and both the ADC and DAC established links normally without dropping.
The ADC collected both the baseline noise and the signal normally.
Conclusion
I have debugged many ADCs and DACs, but I still encounter various inexplicable issues each time. Therefore, debugging experience and regular summaries are extremely important. Through this debugging process, I gained a deeper understanding of the 204B link establishment. The focus of troubleshooting is primarily on power supply, register configuration, and clock frequency (including the fast and slow clocks of the ADC and DAC, the GTH reference clock of the FPGA, especially the core_clk clock, which is the working clock for the 204B; if this is incorrect, the link will be abnormal). By verifying each point, I ultimately found the root cause of the problem.Although the root cause of the problem turned out to be simple, the hardships during the troubleshooting process are known only to myself. I must continue to work hard, and engineering experience needs to be accumulated over time.
Follow Us