Hacker News Reader

Comment by nanumbat | Hacker News Reader

From the comments: "Protip: don’t try to be fancy and provide a local REFCLK from an independent oscillator. Always use the host’s REFCLK as it may be spread spectrum modulated for EMI compliance in most PC systems."

Someone handed me a non-functional prototype system a few years ago (the first time I'd encountered PCIe), and it had a local REFCLK and an upstream Android-style host which, indeed, had enabled spread-spectrum clocking. Took me two miserable weeks to figure that one out.

View on HN

Also it's a good point to understand just how these SERDES blocks work. There is a CDR circuit, but it is fully dependent on the refclk, which can only be off a tiny amount from the one used on the transmit side- it's not like there's a wide-bandwidth PLL that recovers the embedded clock from the encoded data.

This is unfortunate, because for transporting video you would like to also transport the pixel clock, but you don't get it for free from the SERDES CDR.

DisplayPort use SERDES and have to transport the pixel clock. They do it by sending a message with fractional relationship between the pixel clock and the SERDES clock to the receive side, which derives the pixel clock from the recovered SERDES CDR clock using a fractional-N PLL.

I had the idea of transporting video over PCIe at one point, so I was interested in this. The reason is that PCIe is sometimes available for free, so why not use it. I wanted to use a local reference clock, so would have been forced to use the DisplayPort scheme (but no fractional-N PLL available).

SERDES with actual PLL CDRs in them for video do exist, but they are different from the generic SERDES used for PCIe and networking.

[edit: removed HDMI, only DisplayPort works as I said above]

iirc that’s why only very few GPUs supported more than two HDMI/DVI outputs, you need a complicated clock generator for them as the bit clock is a multiple of the pixel clock. Meanwhile DisplayPort only has like four possible link clocks.

HDMI/DVI has dedicated pixel clock pair as do the various LVDS LCD panel interfaces (and CameraLink, which is a related PHY). These interfaces are more or less “dumb” and simply serialize the display data onto three pairs with the same timing as VGA/DPI (discrete serdeses for these interfaces tend to have internal x10 PLL for generating the bit-clock).

The newer versions of Camera Link don't need the clock lane, FPD Link-II and above or Channel Link-II and above.

For the hardware I was using, the downstream CDR was actually doing a reasonable job locking on the spread-spectrum clock, such that PCIe negotiations would sometimes work through quite a few states without error (I was watching the state machine in Xilinx/Vivado's ChipScope), before inevitably failing when the CDR lost lock.

Reply on news.ycombinator.com