LVDS: length matching within a pair and between pairs

Question

I'm interested in the LVDS communication between a Zynq (Xilinx, xc7z020-1C) and a camera (ON semiconductor Python 1300 NOIP1SE1300A−QDI).

I have read some articles about USB2.0 where the maximum skew for the differential pair is given; it can then be derived the maximum length difference between two traces of a pair.

However, I looked for similar specifications in the Zynq documentation without success, so I went more into the current design on the demo board. 6 LVDS pairs goes from the camera to the Zynq (4 data, 1 clock, 1 sync). Internal terminations from the Zynq are used for differential pairs. The Avnet IP to connect the Python 1300 to the Zynq uses 3 primitives for the data channels:

• IBUFDS
• IDELAYE2
• ISERDESE2

I found some info about the setup and hold time for the ISERDESE2 primitive:

My guess is that the length difference tolerance within a pair can be derived from the setup and hold time of the ISERDESE2 primitive, and the IDELAYE2 is there to compensate for the length difference between pairs. However, I do not understand how I can derive a timing budget based on these information.

Could anyone give me some hints to better understand how to calculate the length matching tolerances in this scenario? Rule of thumbs are also welcome.

Thank you

Answer 1

Trace length equalization for a differential pair is not determined by setup/hold timing. It is determined by having a crossover point of eye diagram in right place, to keep it in the middle. The allowable timing skew therefore depends on reasonable slew rate of signal edges.

As I understand, the camera max frequency is 720 mbps, or 1380 ps of unit interval. Therefore the edge rate can be about 400 ps, so 100 ps difference wouldn't make much of a shift in eye crossover position. And the 100ps would be equal to 15-20 mm in trace length difference, which is huge. So the diff. pair length equalization to 2-3mm is not an issue.

Regarding the parallel channels and IOBUF programmable delay, I believe Xilinx has it in 15ps-something granularity (x256), so almost any reasonable trace difference can be tuned up and corrected in RTL.