08-03-2017 08:15 AM
SerDes links can fail due to issues such as: i) signal integrity, ii) clock jitter, iii) eye opening, iv) voltage margins etc.
The purpose of IODELAY2 is to move the sampling clock position within the data eye when using static capture, while the purpose of dynamic capture is to move the sampling point to the optimum position based upon a feedback loop.
1) If we sample at he transitions of the eye, we will pick up random bit errors and out SerDes decoded output should be reasonably random.
2) If we sample close but not at the transitions, then we will have two distributions close together and therefore an error probability for ones and error probability for zeros. If we send the string '000' we will probably get a different error for the last zero, in comparison to the string '110' due to ISI. This should manifest itself as data dependant errors, but ones that last a single bit period.
3) I have another issue, that is that within say 14bit serial data, a particular bit, say bit 6 is not showing a single period error but a long term error in the decoded output. In terms of the output data, I see distinct bands, where for a while the bit is correct, and then a while when the bit is incorrect. The signal attributed to bits 0 to 5 and 7 to 13 seems perfectly fine. This would suggest that in the serial domain we have some event that is periodically timed with bit 6, which is corrupting its value.
Does anyone have any ideas what may cause such a SerDes failure mode?
08-03-2017 09:34 AM
A few questions for you:
What are you doing to initially lock onto the bit stream?
Are you using an encoding technique such as 8b/10b or 64b/66b?
How often are you retraining, and what is your idle K code?
How fixed is the temperature of the FPGA and the source?
Have you confirmed on a scope that the bits are all the same width, and you don't have an issue with your source?
What speed is the data transferring at?
What FPGA family/part are you using?
Is this across a bus of multiple bits, or a single bit stream coming into the ISERDES?
Have you fiddle with your drive strength at all on your source?
Have you matched impedance?
Is this LVDS or single-ended?
Can you confirm your IODELAY2 is working as expected? Can you send a known patter, then move the IODELAY2 delay value and see the pattern change as expected?
When debugging SERDES designs like this, I usually like placing a big buffer in the FPGA that I can read out ( ILA is fine ) so I can see what the output of the SERDES actually is. I then do a full sweep of the IODELAYS inside of my design, and any delays on the source that may be tunable with a known pattern and see how it comes through. Using the bit slip to watch the bits slip by is also really valuable, so you can see how close to the transition you are.
08-04-2017 01:32 AM
It is 560Mb/s DDR LVDS 14 bit SerDes data. We are using a bitslip to a provided framing signal which locks fine. It is a Xilinx Spartan 6 LX45 using ISERDES2 and IODELAY2. We matched impedance and trace lengths as best we could.
The decoded frame signal is perfect with no bit errors once bitslip has locked. Temperature of the FPGA does vary after initial cold bootup.
Many if the issues you suggest should hit all bits in the 14bit serial data in a uniform random probability, in terms of input SerDes, bit 0 and bit 5 are the same as they are just sequential bits in time.
But the issue we have is very very often bit 6 only, with the MSB (two's complement) and many of the LSBs being perfectly fine. This would suggest some periodic issue in time that happens to hit bit 6 repetitively.
08-04-2017 12:10 PM
could it be that the bit is actually corrupted externally
noise, from something thats divided off the same clock ?
out with the sampling scope ?