Out of curiosity, have you tried freeze-it on the FPGA or ADC after the 10 minutes of operation to see if it will quickly un-do the problem?
Just for clarification, are you clocking your SERDES from the CLK+/- input from the ACD or are you using the DCO+/- as your SERDES clock. How do you capture the FCO+/-?
I have tried freezing the fpga back when the logic was considerably different, I will try it again.
SerDes is clocked using the DCO. The FCO is captured in the same way as the DCO. See attachments in post #12.
Warning: The FCO is in sync with the AD9257's data outputs, not the DCO. In Altera, I made this mistake with a HSYNC signal from a DDR (a wide parallel 320Mhz buss with balanced clock) out HDMI receiver. At some sensitive frequencies, video has a huge spread on clock speeds, I would occasionally randomly slip 2 pixels left and right. What was going on is I was receiving my HDMI clock on a dedicated clock input as well as the HSYNC. The timing of the sync matched the data buss, which was on DDR inputs, not the clock phase & I had to fix that timing. Believe it or not, this occasionally was so stable, but would hiccup not due to the temperature of the FPGA & HDMI RXic, but the temperature of my tiny analog supply linear regulator for the PLL/DLL.
I got lucky finding a set clock phase and current IO drive strength in the HDMI decoder's I2C settings.
Since you are working with 1 clock frequency, adjusting the clock phase of the AD9257 should do the trick. If you are using a variable frequency source clock, you may want to increase the drive strength and lower the impedance settings on the AD9257 to make things stick under all environments and different PCBs.
Remember, if you are already accessing the AD9257's control registers, you may accidentally be fiddling with the clock phase without knowing at 10 minutes due to a software bug, not a firmware problem in the FPGA's SERDES.